[{"content":"","date":null,"permalink":"/tags/agent-identity/","section":"Tags","summary":"","title":"Agent Identity"},{"content":"","date":null,"permalink":"/tags/agentic-ai/","section":"Tags","summary":"","title":"Agentic AI"},{"content":"","date":null,"permalink":"/tags/ai-agent-security/","section":"Tags","summary":"","title":"AI Agent Security"},{"content":"Welcome to my archive! Here you\u0026rsquo;ll find a complete list of everything I\u0026rsquo;ve written. Feel free to browse through the topics below, or use the search bar to find something specific.\n","date":null,"permalink":"/blog/","section":"Blog","summary":"","title":"Blog"},{"content":"Enterprise IAM was built for people: onboarding employees, wiring up SAML/OIDC single sign-on, enforcing MFA. In most cloud environments, the identities that matter now belong to software. Machine identities outnumber humans 100 to 1 or more, and every one of them was designed around a single assumption: the code behind it does the same thing every time.\nAI agents break that assumption. This piece proposes a test for when a non-human identity (NHI) stops being a workload and becomes an agent, and says what changes once it does.\nThe baseline: what NHI handles well #The mature workload identity toolkit looks like this:\nService principals and API keys: non-person accounts tied to an application or an OAuth 2.0 client credentials grant. Workload identity federation: short-lived tokens bound to infrastructure (cloud-provider workload identities, platform-managed service accounts, SPIFFE/SPIRE SVIDs) so no secret is hardcoded. Static access policies: coarse RBAC or ABAC scoped to predictable workload boundaries. This works because traditional software is predictable. A payment microservice follows a known code path, calls a fixed set of internal APIs, and needs the same permissions every time.\nWhat changes when software chooses its own actions #Workload identity proves which software is running. Through SPIFFE/SPIRE, platform-managed identities or mutual TLS, it verifies that a specific container, binary hash or cloud instance is executing. For static automation, that is enough.\nFor an agent, it isn\u0026rsquo;t. The same instance, with the same cryptographic identity at startup, can be steered by a prompt or an intermediate model output into very different operations. Workload identity cannot tell you whether this action, in this context, under this delegation chain, should be allowed.\nSo the question changes. \u0026ldquo;Is this microservice authenticated?\u0026rdquo; stops being the one that matters. The question becomes: who or what is acting, under whose authority, from which environment, with what scope, and with what verifiable evidence?\nThe threshold test #Three questions sort workloads from agents.\nTest 1: Does a model choose the next action? #An LLM that produces varying text inside a fixed pipeline doesn\u0026rsquo;t count. What counts is model-directed control flow: the system uses non-deterministic reasoning to plan and pick actions, so the sequence of operations can\u0026rsquo;t be mapped before it runs.\nStandard NHI: the branches and possible actions are hardcoded. Inputs vary; the set of actions doesn\u0026rsquo;t. Agent: the model decides what happens next. Test 2: Are capabilities bound at runtime? # Standard NHI: downstream APIs, queries and integrations are fixed at deployment, so OAuth scopes and IAM roles can be declared up front and bound at startup. Agent: the software queries a tool registry, reads schema descriptions, and decides which endpoints to call based on intermediate results. Privileges have to be evaluated at the moment of action, not granted at boot. Test 3: Does it act with delegated human authority across hops? # Standard NHI: the service acts as its own principal (a synchronization daemon, say) or completes a single-hop user action. Agent: it acts for a person while coordinating with sub-agents or third-party platforms. The resulting operation has to be attributable to both the initiating human and the specific agent instance. How to apply the results #Tests 1 and 2 together make an entity an agent. If both are true, a workload identity alone is the wrong tool. Test 3 adds a second requirement: whenever an entity acts on a person\u0026rsquo;s behalf, it needs delegation controls that preserve and bound that person\u0026rsquo;s authority.\nThat gives three outcomes:\nFails Tests 1 and 2, passes Test 3: a deterministic service doing token exchange. It needs delegation controls, not a full agent identity. Passes Tests 1 and 2, fails Test 3: an autonomous agent with no human principal. This is arguably the riskiest case, because nobody\u0026rsquo;s authority bounds it. It needs its own agent identity with a named, accountable owner. Passes all three: a full agent identity with composite attribution. A few examples (illustrative; adjust to your own environment):\nSystem Test 1 Test 2 Test 3 Verdict Nightly billing reconciliation job No No No NHI Fixed pipeline: OCR, LLM summary, database write No (output varies, control flow doesn\u0026rsquo;t) No No NHI, plus output validation Support agent choosing from a tool registry for a logged-in user Yes Yes Yes Agent identity Scheduled research agent, no human principal Yes Yes No Agent identity with an accountable owner What breaks when an agent runs on a workload identity #It is tempting to give a new agent a service principal, a static OAuth client ID or a long-lived API key. Teams do it because it is the path they already know. Past the threshold, the identity layer goes blind to execution context, and four failures follow.\nDelegation dilution. When an agent hands sub-tasks to tools, services or peer agents, the initiating human\u0026rsquo;s identity is usually replaced by the calling service\u0026rsquo;s. Downstream systems see only the agent process. Accountability fades, and authorization falls back on generic machine trust. The opposite mistake is just as bad: the agent inherits the user\u0026rsquo;s full authorization context and bypasses segregation of duties.\nConfused deputy. Workloads typically hold standing permissions for several functions. An agent that reads tainted input, such as an indirect prompt injection, can use its legitimate credentials to reach data or trigger actions nobody intended.\nAutonomous privilege creep. When dynamic tool use hits an authorization wall, a static identity leaves two options: fail the pipeline or pre-grant broad roles. Operators pick the broad roles. Each new tool the agent learns to use then widens the blast radius without any step-up consent. One mis-prompted output can wipe a database, change user roles or move money.\nRogue or escaped execution. Credentials bound to a runtime process, rather than to a time-bounded intent, outlive the task. A compromised sandbox or runaway reasoning loop keeps working, spawning resources or retaining access after the user session ends. Ephemeral sub-agents make this worse: they live for seconds, and provisioning built around weekly rotation can\u0026rsquo;t keep up with them.\n[Add one real incident, or a clearly labeled composite scenario, here. For example: a support agent holding a CRM token reads a ticket containing injected instructions and exports customer records. Walk it through the tests.]\nOWASP\u0026rsquo;s Top 10 for LLM Applications calls the underlying condition Excessive Agency: an agent holding more functionality, permissions or autonomy than its task needs. \\[Verify wording against the current list.\\] Identity design is where that excess is either granted or prevented.\nWhat an agent identity looks like #Trust has to move from static startup tokens to short-lived, task-derived credentials that bind three things: the human initiator, the specific agent instance, and the declared task. A token along these lines (modeled on the act claim for delegation in RFC 8693) shows the idea:\n{ \u0026#34;sub\u0026#34;: \u0026#34;user:alice@example.com\u0026#34;, \u0026#34;act\u0026#34;: { \u0026#34;sub\u0026#34;: \u0026#34;agent:invoice-reconciler/instance-7f3a\u0026#34; }, \u0026#34;task\u0026#34;: \u0026#34;reconcile-q3-invoices\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;invoices:read\u0026#34;, \u0026#34;exp\u0026#34;: 300 } The human is the subject, the agent instance is the actor, the task is declared, the scope is narrow, and the credential expires in minutes. Each downstream hop narrows the scope further rather than widening it. With these in the token, identity teams can enforce segregation of duties and least privilege even when the execution path can\u0026rsquo;t be predicted.\n[Add one paragraph from your own experience running identity at scale: what workload identity guaranteed in practice, and where it stopped short.]\nThe choice #Agents are coming either way. The only open question is whether you govern them with an identity plane built for agency, or let excessive agency write your threat model.\n","date":"26 October 2026","permalink":"/blog/nhi-to-agentidentity/","section":"Blog","summary":"Enterprise IAM treats machine identities as predictable workloads, but AI agents choose their own actions at runtime. This article offers a three-part threshold test: model-directed control flow, runtime capability binding, and delegated human authority across hops. It describes the four failures that follow when agents run on service accounts, and shows how a task-bound, short-lived composite token fixes them.","title":"From Non-Human Identity to Agent Identity: Where the Threshold Sits"},{"content":"","date":null,"permalink":"/tags/identity-and-access-management/","section":"Tags","summary":"","title":"Identity and Access Management"},{"content":"","date":null,"permalink":"/tags/non-human-identity/","section":"Tags","summary":"","title":"Non-Human Identity"},{"content":"","date":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags"},{"content":"","date":null,"permalink":"/","section":"victorh.dev","summary":"","title":"victorh.dev"},{"content":"Welcome to my website. Your privacy is important to me. This Privacy Policy explains how information is collected and used when you visit this site.\nAnalytics, Advertising Features \u0026amp; User Data Collection #This website uses Google Analytics alongside advanced features including Google Analytics Advertising Features (such as Google Signals) and User-Provided Data Collection for User-ID. These tools help me understand visitor interactions, analyze cross-device usage patterns, and measure site performance securely.\nWhat is collected: Google Analytics collects standard technical data such as your IP address, browser type, operating system, referring pages, pages visited, and time spent on each page. With Google Signals enabled, Google Analytics associates tracking data with Google information from users who have signed in and consented to ads personalization, enabling cross-device reporting and remarketing. User-Provided Data \u0026amp; Hashing: If you provide first-party data (such as signing in or submitting information), certain identifiers may be processed. To protect your privacy, personally identifiable information (like email addresses or phone numbers) is securely hashed using industry-standard SHA256 algorithms before being shared with analytics or advertising features. How cookies and identifiers work: Google Analytics and its advertising features use first-party cookies (such as the Google Analytics cookie) and third-party cookies or identifiers together to collect traffic data and measure audience engagement. Opting out and user controls: You can prevent Google Analytics from recognizing you on return visits by disabling cookies in your browser settings, installing the Google Analytics Opt-out Browser Add-on, or managing your preferences through Google\u0026rsquo;s Ads Settings or the Network Advertising Initiative (NAI) consumer opt-out. External Links #My website may contain links to other sites of interest. Once you click these links and leave my site, I do not have any control over that external website. Therefore, I cannot be responsible for the protection and privacy of any information you provide while visiting such sites.\nUpdates to This Policy #I may update this privacy policy from time to time to reflect changes in practices or legal requirements. Any updates will be posted on this page with a revised \u0026ldquo;Last updated\u0026rdquo; date.\nContact #If you have any questions about this privacy policy or data collection, feel free to reach out via the contact information provided on this site.\n","date":"19 September 2026","permalink":"/privacy/","section":"victorh.dev","summary":"","title":"Privacy Statement"},{"content":"They say time flies when you\u0026rsquo;re having fun, but when you spend two decades doing something that you love, it doesn\u0026rsquo;t just fly, it blurs. This is a short exploration of my life in tech in the hope of connecting with fellow builders and minds who share this obsession.\nThe time I had a drink with Steve Ballmer, 2013. The Origin Story: From a Nintendo Magazine to Enterprise Identity #Every engineer has a spark that started it all. Mine didn\u0026rsquo;t come from a computer science textbook or a high-tech lab, it started with a Nintendo magazine.\nAs a teenager, I stumbled upon a small guide explaining how to write basic HTML in its pages.\nIntrigued, I built my very first website. That tiny project cracked open a door to an entirely new world, and I quickly found myself diving headfirst into C#, SQL, JavaScript, and anything else I could get my hands on. I didn\u0026rsquo;t have to look far for inspiration; fueled by my uncle and mentor, who guided my early steps, I knew early on that this was the path I wanted to pursue. I devoured every technical book, tutorial, and problem I could find.\nClub Nintendo Magazine, 1997. Building from the Ground Up: The Entrepreneurial Leap #That early curiosity eventually scaled up, leading me to co-found a company alongside a team of talented engineers to deliver tailored software solutions for small and medium businesses.\nRunning that business gave me an invaluable perspective that you can\u0026rsquo;t get anywhere else: a direct, unfiltered taste of working side-by-side with end-users. Solving their real-world problems forced me to develop a true product-oriented mindset and a deep service attitude. It wasn\u0026rsquo;t just about writing clever code anymore; it was about listening closely, understanding business pain points, and building technology that genuinely made people\u0026rsquo;s lives easier.\nChoosing the Red Pill #A major turning point in my career came when I joined Microsoft. I faced a rare luxury: choosing between three distinct teams: MSN Hotmail (now outlook.com), MSN Messenger (now extinct), and Windows Live ID (now Microsoft account).\nWhat could possibly be cooler than security? For me, it was an absolute no-brainer. What could possibly be cooler than security? Ever since I watched The Matrix for the first time, I had wanted to be a hacker (the good kind, of course). Securing complex systems felt like playing in the ultimate digital sandbox.\nWindows Live ID logo Fast forward 15 years, and that fascination hasn\u0026rsquo;t faded an ounce. The threat landscape has evolved, the perimeters have dissolved into the cloud, and the protocols have grown infinitely more sophisticated, but the core thrill remains. Computers and security are, and always will be, one of the most exciting spaces to work in.\nThe Microsoft Era: Finding My Footing at the \u0026ldquo;Olympus of Computer Science\u0026rdquo; #When I joined Microsoft, I always looked up to the people working there. To me, it felt like the Olympus of computer science. A place where only the best and brightest could belong.\nEarly on, I had the chance to do some penetration testing on pre-release versions of the service. I managed to find a security vulnerability, something that, to this day, still makes me genuinely proud. Discovering a flaw in code that was already considered rock-solid was a humongous achievement for me. It was the moment it truly clicked: I am here, and I have what it takes to stand shoulder-to-shoulder with this team.\nEarly years at Microsoft, with my dear friend Cuervo and my cousin Edgar (2009) That validation set the stage for what came next. I was blessed to be part of shaping identity as the world knows it today. We were pioneering features that didn\u0026rsquo;t exist yet:\nAdding authentication via push notifications Shipping Two-Factor Authentication (TFA) for the first time Building session authentication for \u0026ldquo;dumb\u0026rdquo; devices Delivering quite literally the very first WebAuthn implementation in the entire industry, building it while the W3C specification was still a draft. It genuinely felt like we were writing history. Back then, we had to explain to users why security mattered and what TFA even was. Today, those concepts are universal, every website uses them, and everyday users understand why they\u0026rsquo;re essential.\nIt was an unforgettable time to be building the future. Of course, working at Microsoft back then had another massive perk: exposure to the latest and greatest before the rest of the world ever laid eyes on it. Surrounded by heavily guarded IP and early prototypes, I got a sneak peek at an Xbox One (back when it was Project Scorpio), the HoloLens (a mind-blowing augmented reality headset at the time), early Surface tablets, and Windows Phones. It was an unforgettable time to be building the future.\nMy very first office at Microsoft Building 50 rocking 5 monitors. Forging Engineering Rigor #At Microsoft, I met some of the most talented engineers I’ve ever had the pleasure of working with. It was an era of old-school, high-quality software and services, a time when building the best, most polished product was the absolute top priority. That’s not to say today’s software isn\u0026rsquo;t good, but priorities have shifted; in the modern spirit of rapid, continuous delivery, inevitable trade-offs are made.\nThat experience forged the way I view software engineering. I learned how to thrive in ambiguity and developed a high tolerance for frustration. Up until that point, my career had been spent in companies where software was an internal tool applied to business operations. Microsoft was different: it was my first time working at a place where software was the main product.\nWorking at that scale makes you a trailblazer. When you can\u0026rsquo;t rely on off-the-shelf package solutions, you have to build from scratch. That constraint changes how you approach architecture entirely, it forces a level of creativity and problem-solving that only grows when you work at the bleeding edge of a product-first technology company.\nReunited with my ITESO university crew who are now making waves at Microsoft, circa 2018 😅. The Evolution of Identity: From Consumer Scale to Bare-Metal Infrastructure #My career in identity has taken me across the entire spectrum of the ecosystem. I started on the consumer side with Microsoft Account, moved into enterprise territory with Entra ID when those teams merged, and eventually journeyed all the way to a completely different domain: infrastructure identity.\nAs a technical leader owning a core foundational component of Azure, I took on the biggest responsibility of my career. This identity provider ran at the bare-metal level, meaning it couldn\u0026rsquo;t rely on any other service to handle the complexity of scaling. In modern cloud architecture, it’s rare to build something that stands entirely on its own, you can almost always lean on another layer to abstract away complexity. Not here. At the bare-metal tier, you are the bedrock, the ultimate problem solver everyone else relies on.\nTo put its criticality into perspective: when a new Azure datacenter spun up, the absolute first thing deployed was DNS, because you need network access before anything else. Right after that came our authentication service, so that every other service could securely talk to one another. Operating at that foundational tier of cloud infrastructure profoundly shaped my leadership. It taught me how to thrive under intense pressure, navigate unprecedented complexity and juggle multiple concurrent projects.\nTaking the Next Leap: DocuSign #That incredible journey left me hungry for the next big challenge. I took a leap of faith and joined DocuSign as an architect, stepping into a role where I had a blank check to improve and secure our identity organization.\nThis is where I am having the most fun right now, doing my best work alongside an amazing team of brilliant people. Beyond the technical challenges, this great company has shown me that technology truly has a very human face. The team culture here is fantastic, balancing a rigorous engineering discipline with a genuine human touch that keeps everyone engaged, supported, and inspired every single day.\nThe day I joined the DocuSign team, 2025. Fast-forward 15\u0026hellip; 20 years, and it feels like it all happened in a flash. Yet, every morning I sit down to tackle a new challenge, I still have the same curiosity I felt as a kid building my first website. The tech changes, but the thrill of the craft never gets old.\n","date":"19 September 2025","permalink":"/about/","section":"victorh.dev","summary":"","title":"About Me"},{"content":"","date":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories"}]