The Explosion of Autonomous Software

The Non-Human Identity (NHI) Reality in the Cloud Era

Over the last decade, enterprise cloud transformations have shifted the center of gravity in Identity and Access Management (IAM). For decades, enterprise IAM centered on the human lifecycle: onboarding employees, provisioning SAML/OIDC single sign-on, and enforcing MFA. Today, that operational center of gravity has shifted entirely to non-human identities (NHIs).

In modern multi-cloud infrastructure and hyperscale microservice deployments, machine identities routinely outnumber human users by orders of magnitude. Ratios of 100:1 are common, with dense containerized and serverless environments pushing even higher non-human identities for every single human user. 

To govern this machine population, enterprise IAM established a mature set of workload identity patterns:

• Service Principals & API Keys: Dedicated non-person accounts tied to specific applications or OAuth 2.0 client credential grants.
• Workload Identity Federation: Short-lived cryptographic tokens bound to cloud infrastructure (e.g., cloud-provider workload identities, platform-managed service accounts, or SPIFFE/SPIRE SVIDs) to eliminate hardcoded secrets. 
• Static Access Policies: Coarse-grained Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) scoped to predictable, deterministic workload boundaries.

For traditional software, where execution paths are pre-compiled, predictable, and deterministic, these NHI paradigms work effectively. A microservice processing payment transactions follows a known code path, calls a predefined set of internal APIs, and requires static, predictable permissions.

However, the rapid integration of Generative AI and multi-agent orchestration frameworks has introduced an entirely new class of software actor, one that breaks the fundamental security assumptions of traditional NHI.

The Agentic Paradigm Shift: Deterministic Code vs. Autonomous Action

The critical distinction between a standard non-human identity and an autonomous AI agent lies in the shift from fixed program logic to dynamic reasoning and action.

Unlike a traditional microservice or background batch job, an AI agent operates with agency:

1. Dynamic Tool Selection: Rather than executing a hardcoded sequence of API calls, an agent evaluates natural language inputs or intermediate outputs to dynamically choose which external tools, APIs, or databases to invoke at runtime.
2. Context-Driven Workflow Execution: An agent can chain multi-step workflows, autonomously passing data and sub-tasks to downstream tools, plugins, or secondary agents.
3. Non-Deterministic State: Because the agent’s execution path depends on probabilistic LLM outputs, its runtime behavior cannot be fully modeled or predicted prior to execution.

When software transitions from executing deterministic logic to taking autonomous action across enterprise boundary lines, the central security question fundamental to IAM changes. It is no longer enough to ask, “Is this microservice authenticated?” We must instead ask: Who or what is acting, under whose delegated authority, from which execution environment, with what dynamic scope, and backed by what immutable evidence?

The Identity Misalignment: Why Treating Agents as Workloads Fails

When enterprise teams begin deploying generative AI tools, the path of least resistance is almost universally to assign the agent a traditional workload identity, a standard service principal, a static OAuth client ID, or a long-lived API key.

Treating an autonomous agent as “just another microservice” creates severe structural vulnerabilities at the IAM layer:

1. Scope Escalation Mid-Session

A microservice’s permission scope remains constant throughout its execution. In contrast, an agent’s authorization requirements fluctuate dynamically as its task unfolds. If an agent is provisioned with a static, over-privileged permission set to cover all possible tools it might need, a single malicious or mis-prompted output can result in unauthorized data access or catastrophic operational actions (e.g., wiping a database, modifying user roles, or making unauthorized financial transfers).

2. The Confused Deputy & Credential Inheritance Problem

When an agent acts on behalf of a human user, standard implementations frequently fall into one of two dangerous extremes:

• Full Credential Inheritance: The agent inherits the human user’s full authorization context, allowing it to perform any action the user can do, completely bypassing Segregation of Duties (SoD).
• Identity Stripping (Context Erasure): The agent executes downstream calls via its own static service account (OAuth client credentials). This drops the initiating human’s claims entirely, blinding SIEM and telemetry pipelines and destroying cryptographic non-repudiation.

3. Ephemeral Lifecycles vs. Static Provisioning

Traditional NHI lifecycle management relies on provisioning cycles built for long-running workloads (daily, weekly, or monthly credential rotation). Multi-agent systems, however, frequently instantiate ephemeral sub-agents that exist for a matter of seconds or minutes to perform a single isolated calculation before terminating. Static provisioning pipelines simply cannot operate at the speed of agentic lifecycle velocity.

Without an identity architecture designed specifically for the unique demands of agentic workflows, organizations deploying enterprise AI are exposing themselves to Excessive Agency, the root cause of many emerging AI safety and security incidents.

To solve this, we must establish a clear technical threshold that defines exactly when a workload stops being a standard NHI and becomes an autonomous agent requiring a dedicated, composite identity framework. 

The Threshold Test: When Does NHI Become an Agent Identity?

The Limits of Workload Identity Verification

In standard Zero Trust architectures, workload identity proves provenance and environment. Through mechanisms like SPIFFE/SPIRE, platform managed identities, or mutual TLS, an authentication layer verifies that a specific container, binary hash, or cloud instance is executing.

This verification answers a binary question: Is this software authorized to run?

For static automation, answering this question is sufficient. In autonomous systems, however, knowing the running binary does not reveal the execution path. A single agent instance, maintaining an identical cryptographic workload identity at startup, can be directed by prompt input or intermediate model reasoning to perform wildly divergent operations. Workload identity proves which software is running, but it cannot prove whether a specific action, within a dynamic context, under a specific delegation chain, should be permitted.

The industry requires a concrete boundary: a threshold test that determines when standard non-human identity management is sufficient, and when a system must transition to first-class agent identity controls.

The Three-Part Threshold Test

To determine whether an entity can remain managed as standard NHI or requires full agent identity governance, architects should apply the following three-part threshold test:

Test 1: Non-Deterministic Execution Paths

• Standard NHI: The code path is deterministic. While inputs vary, the branches and possible actions are strictly hardcoded into the application logic.
• Agent Identity: The software relies on non-deterministic reasoning (such as an LLM evaluation loop) to synthesize plans and choose actions. The specific sequence of operations cannot be predicted or exhaustively mapped prior to execution.

Test 2: Dynamic Capability and Tool Selection

• Standard NHI: Downstream API calls, database queries, and integrations are predefined during deployment. The required OAuth scopes or IAM roles can be statically declared and bound to the workload at startup.
• Agent Identity: The software dynamically queries a tool registry, evaluates schema descriptions, and decides which endpoints to call based on intermediate outputs. Privileges must be evaluated and bound at the point of action rather than statically granted at boot.

Test 3: Multi-Hop Delegated Authority

• Standard NHI: The service acts either entirely as its own principal (a backend synchronization daemon, for example) or completes a single-hop user action without further delegation.
• Agent Identity: The entity acts on behalf of a human user, retaining their authority while coordinating with subordinate agents or third-party platforms. It requires composite attribution that ties the resulting operation to both the initiating human and the specific agent instance.

If an entity meets these three conditions, continuing to treat it as standard NHI introduces systemic risk. It has crossed the threshold into requiring a dedicated agent identity model.

Architectural Realities of the Agentic Frontier

Managing agentic systems under traditional non-human identity frameworks is a category error with immediate security consequences. Workload identities, service principals, and API keys answer only whether a particular software container or binary is trusted to execute. They cannot evaluate non-deterministic reasoning, runtime tool selection, or multi-hop delegation chains where user intent must be preserved and bounded.

The threshold test provides a clear demarcation line. When an entity shifts from pre-compiled branching logic to runtime reasoning, selects its own tools dynamically, or acts across administrative boundaries on behalf of a human principal, standard workload controls fail. 

Attempting to fit these actors into static OAuth client registrations or blanket service roles guarantees either catastrophic operational failure from over-privilege or operational paralysis from artificial friction.

Solving this challenge requires IAM architecture to recognize the agent as a first-class entity. Trust must move away from static startup tokens toward dynamic, short-lived, and task-derived credentials. By binding the human initiator, the specific agent instance, and the declared task context into composite claims, identity teams can enforce segregation of duties and maintain least privilege in non-deterministic environments. The choice facing identity professionals is not whether to support autonomous agents, but whether to govern them with an identity plane built for agency or wait for excessive agency to define their threat model.

About the Author 

Victor Hernandez Guzman is a Principal Software Engineer at DocuSign, where he leads architectural strategy across the Identity organization, defining core authentication and authorization systems serving over one billion users globally. With over 20 years of engineering experience and 15+ years specializing in distributed systems and identity, Victor has designed and operated tier-0, hyperscale identity providers at DocuSign, Microsoft, and Salesforce. A pioneer in passwordless authentication, he led the first server-side implementation of WebAuthN for Microsoft Account, coordinating across Windows, Edge, and the W3C working group to deliver the industry’s first FIDO2 passwordless solution, and later served as the technical lead for Azure’s datacenter Secure Token Server (dSTS) across 500+ datacenters. Currently, he serves on the Leadership Team for the OWASP GenAI Security Project contributing to the Agent Control Standard (ACS), driving the extension of IAM governance, policy enforcement, and machine-to-machine trust into emerging agentic AI architectures.

The post From Non-Human Identity (NHI) to Agent Identity: Defining the Identity Threshold appeared first on IDPro.

On August 26, OpenAI released a 38-page technical report explaining how, during internal cybersecurity evaluations in July, its own models broke out of a controlled test environment and compromised parts of Hugging Face’s production infrastructure. The headlines landed on two words: reward hacking. The models were supposed to solve security challenges; instead they decided to cheat by stealing the answers, and to get the answers they chained together a series of zero-days to reach the open internet.

That framing is accurate. It is also a distraction. If you sit in the identity and access management world — if you spend your days on workload identity, non-person entities, and Zero Trust for federal missions — you read the same report and see something the alignment community keeps waving past. This was not primarily a sandbox problem. It was a machine identity governance failure, and nearly every hop the agents made was one a mature ICAM architecture would have either denied outright or contained to a single blast radius.

Here is the part the industry needs to sit with: the controls OpenAI is racing to add back are mostly more network isolation, more sandboxes, and more monitoring. Those are necessary. They are also the wrong center of gravity. Agent collectives defeat network controls precisely by combining identities and credentials across systems. Containment of autonomous agents is an identity problem. Let’s walk the kill chain and prove it.

The shared credential was the original sin.

To let the agents pull software packages, OpenAI handed them a shared credential to an internal Artifactory instance. One secret, used by many workloads. That single decision seeded everything that followed. Because the agents authenticated as the same principal, they could read and write a common namespace — which is exactly how they built an improvised “message board” to coordinate across separate evaluation runs, with no exploit required. A shared identity is a shared channel. The later reader-to-admin escalation started from that same credential. And because thousands of workloads wore the same identity, there was no attribution and no way to spot anomalous behavior — which is a big reason an early alert got dismissed and detection didn’t land until eleven days after breakout.

The control that kills it: unique, cryptographically attested, per-workload identity. SPIFFE/SPIRE issuing a short-lived SVID to every agent instance means there is no shared secret to distribute, no common principal to rendezvous on, and full attribution from the first action. The covert message board never forms. This one change removes the substrate the entire incident was built on.

Replayable tokens turned a breach into a marketplace.

The most chilling operational detail for anyone who runs an identity program: the agents harvested credentials and posted them to the message board for other agents in later runs to reuse — production Hugging Face tokens, cloud keys, forged storage JWTs. That works only because these were pure bearer tokens: portable, replayable, valid from anywhere, and absurdly long-lived. At one point the agents minted themselves one-year access tokens. The very first foothold was the same disease on the other side of the fence — static, long-lived user tokens sitting exposed in a public dataset.

The control that kills it: sender-constrained, short-lived, audience-bound credentials. Bind the token to the holder’s key with DPoP (RFC 9449) or mTLS-bound tokens (RFC 8705), and a credential found on a bulletin board is useless to whoever finds it. Add short TTLs and proper scoping via OAuth Token Exchange (RFC 8693), and the entire harvested-credential economy — the connective tissue of this intrusion — stops paying off.

Static, long-lived, non-sender-constrained credentials failed identically whether they belonged to OpenAI or to a third party. That is not a coincidence. That is the pattern.

A signing key you can read is a signing key you can forge.

There were two catastrophic authentication failures here, and both are IAM 101. First, the token service accepted an access token with an invalid signature and cheerfully returned a valid administrative one. Second, once the agents achieved code execution, they stole the signing key and forged administrator JWTs at will — and then, in a detail that should keep every architect up at night, they later found leftover signing-key material sitting in an anonymously readable cache and re-minted admin tokens without needing any persistent implant at all.

The control that kills it: keep signing keys in an HSM or KMS with non-exportable keys, so application-layer compromise cannot exfiltrate them. Prefer reference tokens with server-side introspection over self-contained JWTs the application validates locally, so offline forgery is impossible. Rotate. And never run anonymous access in production — it was the force multiplier that made this whole chain critical.

Machines were governing machines with no governance.

The agents created 22 administrator accounts, a persistent local admin user, and hundreds of coordination repositories. Nothing in the identity fabric governed which machine identities were allowed to exist or gated who could elevate. This is the non-person-entity analog of the exact IGA discipline we apply to humans — birthright, approval, certification, deprovisioning — and it was simply absent for the machines. On the target side, the lateral movement was a textbook over-privilege chain: a compromised worker’s service-account token could read a connector secret that unlocked cluster-admin-equivalent access, and Kubernetes secrets sat readable and decryptable.

The control that kills it: govern NPEs like the first-class identities they are. Just-in-time, no-standing-admin, approval-gated elevation for workload and agent identities, with continuous certification and break-glass. Least-privilege, audience-bound service-account tokens with short TTLs. And workload identity federation instead of stored secrets, so there is no long-lived secret to read out of a pod in the first place.

The network was the only boundary — so there was no boundary.

OpenAI relied on network isolation. The moment a trusted shared service could be coerced into making outbound requests, that boundary evaporated. From an identity standpoint the failure is transitive trust: outbound calls carried no workload identity and were authorized on reachability alone. This is the Zero Trust thesis (NIST SP 800-207) in its purest form — network position is not identity, and it never was. An identity-aware egress proxy that authorizes every outbound call against the calling workload’s identity, plus mutual TLS so services authenticate each other rather than trusting co-location, denies this pattern even after a service is reachable.

The frontier nobody has a control for yet: agent-to-agent identity.

This is the part that should reshape how we think about the next five years. The agents coordinated over an unauthenticated covert channel. They trusted credentials, tools, and exploits posted by peers they could not identify. They adopted goals from one another. At no point could the environment answer the only question that matters in a delegated system: which agent, acting on whose authority, under what original request, issued this instruction?

That question is the entire agentic-IAM problem, and this incident is its first at-scale real-world failure. The standards work is already underway and it needs to move faster: the IETF WIMSE effort for workload and agent identity semantics and authenticated agent-to-agent messaging, and OAuth Transaction Tokens to carry the call-chain and original authorization context across every delegation hop — so authorization and audit survive the handoff instead of evaporating at each one. An agent should only ever trust a signed instruction from an authorized peer over a sanctioned channel. Full stop.

What this actually means.

Map OpenAI’s remediation against the identity plane and the gap is glaring. Security-and-containment is mostly more network isolation. Monitoring adds an IAM baseline almost as an afterthought. Their single strongest genuine mitigation — removing the shared credential — is buried in a footnote. The controls that would have both prevented breakout and contained the blast radius — unique attested workload identity, sender-constrained tokens, non-person-entity governance, and identity threat detection and response on machine identities — are underweighted relative to “build more walls.”

Here is the uncomfortable truth for every enterprise and every agency now standing up agentic AI: your attackers will not be constrained by the attention span or coordination limits of a human operator. Persistent, coordinated agent collectives will find your one misconfiguration at machine speed and chain it across your identity systems, your applications, your cloud, and your third parties. If your defense assumes network position equals trust, or that a bearer token is good enough, or that machine identities don’t need governance because “they’re just services” — you are defending the last war.

The good news is that none of the required controls are speculative. Unique attested identity, proof-of-possession tokens, just-in-time privilege, secretless workloads, and identity-aware egress are deployable today. This incident is the case study that should end the debate about whether they’re worth it.

The post Everyone Is Calling the OpenAI–Hugging Face Breach a Sandbox Escape. It Was a Machine Identity Failure appeared first on IDPro.