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.

There are plenty of meaningful solutions being worked on to help prevent errant agents in the enterprise, as well. For instance, we are seeing the creation of standards (Such as IETF draft on OAuth Client ID Metadata Documents or the IETF draft on Identity Assertion JWT Authorization Grants), best practices (Such as the AIMS draft that Jeff Lombardo wrote about recently), and articles abound providing a path forward. These are powerful, meaningful works. However, we are left with gaps that cannot be resolved with these solutions alone- securing the path of known agent to enterprise resource does not end the fight.

What do I mean, here? Specifically, I am talking about the increasing prevalence of capable, locally-ran generative models. Coupled with abliteration- Abliteration being a process that uncensors generative models by removing the model’s ability to refuse requests by various means- these local models (Called abliterated models or “Heretic models” after Heretic, a tool that performs the work) have no compunctions to perform actions on behalf of the user, any action.  These local models will potentially be given credentials from users to perform actions. This could range from the mundane to the momentous. One can quickly imagine a scenario where a business user offers such a model the credentials to their CRM to create dynamic reports for them, or access to a corporate git repo to help write code or develop gating around a build process. One can likewise imagine a scenario where a user utilizes a local abliterated model to perform actions as an insider threat to the organization.

Research¹ has been performed and presented² in this field.  With local, open-weight models becoming increasingly capable and the ease³ by which these local models are having their rejection mechanisms stripped, this means these models can perform tasks that would otherwise be rejected by a frontier model in a manner that while is not at the forefront of capability, is sufficient in many cases to get done what the user is looking to get done.  I will not editorialize the ethics of abliteration or the usage of abliterated models (As has been done recently across the United States’ legislative branch⁴), but I will note that any grandstanding about whether or not they should exist at this point is moot- the tools and techniques exist, and they are at our door.  As a matter of practicality, your humble offer has engaged with local models inside of Capture the Flag (CTF) environments (With permission!) and has found them impressively effective in performing tasks sufficient to perform at the top end of these CTFs; the capabilities of these models are impressive, and I can see a point not even a few years from now (It’s already happening!) where local models are used in conjunction with frontier models to maximize cost efficiency while maintaining quality in a wide range of tasks.

You may be thinking “Models that could harm us take huge resources to run”, and that is not necessarily true.  Laptops already in the enterprise, such as the humble Macbook Pro, can run local models with impressive performance. x86-based architectures are moving towards this as well, because the market has a demand for AI- there are already compact desktops that can perform this work with some degree of prowess, and it stands to reason chipmakers will look to rise to this demand further. An astute reader may think “This is a whitelisting problem at runtime, not an identity problem”, and I would offer you are partly right. While there are means by which to determine if something we don’t want running is running, life finds a way. Even still, in the era of BYOD organizations cannot stop every new tool that comes out that can act as an inference server, or act as an agent harness. We’re left what I reluctantly call “Shadow agents”, in the way shadow IT is manifested- it’s a bad term, but the intent is to make it clear the agents performing actions on behalf of users are not vetted by the organization or necessarily approved.  

So what do we do as practitioners of identity to help mitigate this risk in the enterprise? We fall back to fundamentals. The machine acting on behalf of the user still has to come to a remote service, still has to present credentials, and still has to send requests to the remote system. We can determine when the user logs in, how they move in the system, and the speed at which they perform operations. Agents categorically do not act like users- which means we can determine if a user is potentially letting a machine act on their behalf, shut down the session, and communicate the concern to the rest of the enterprise. And while a sufficiently devious agent acting on behalf of a user may seek to emulate the user, we have a historical understanding of how a user (Not just this user) may move through the system and what actions they may take in what order. This is powerful information, and signaling inside of a robust continuous authentication process that can help us differentiate.

It’s fair to have concern over the changing nature of how we interact with systems. Systems are moving faster, in non-deterministic ways, and in ways that may not necessarily be beneficial on any given action. It is not fair, however, for the marketing hype to pretend we are entirely defenseless in this brave new world. The defenses of the past may no longer tell the whole story, but they still tell a story- sufficiently robust authentication and authorization, as far down in the stack as possible, allow us a great deal of mitigation against the risk of an errant agent.

References

1: https://go.alice.io/hubfs/alice-abliteration-report-april2026.pdf

2: https://www.unomaha.edu/ncite/news/2026/09/dc-demo-day2.php

3:  https://www.irishtimes.com/business/2026/05/25/ai-guardrails-stripped-from-meta-and-google-models-in-minutes/

4: https://www.yahoo.com/news/articles/lawmakers-shown-jailbroken-ai-plan-223247817.html

Rusty Deaton has been in Identity and Access Management for over a decade. He began in technology as a technical support engineer for a Broker-Dealer and has since worked across many industries, carrying forward a passion for doing right by people. When not solving problems, he loves to tinker with electronics and read. He currently works as Federal Principal Architect for Radiant Logic.

The post The Concern of Local Autonomy appeared first on IDPro.