From Non-Human Identity to Agent Identity: Where the Threshold Sits

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.

AI 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.

The baseline: what NHI handles well #

The mature workload identity toolkit looks like this:

• Service 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.

What 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.

For an agent, it isn’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.

So the question changes. “Is this microservice authenticated?” 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?

The threshold test #

Three questions sort workloads from agents.

Test 1: Does a model choose the next action? #

An LLM that produces varying text inside a fixed pipeline doesn’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’t be mapped before it runs.

• Standard NHI: the branches and possible actions are hardcoded. Inputs vary; the set of actions doesn’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’s behalf, it needs delegation controls that preserve and bound that person’s authority.

That gives three outcomes:

• Fails 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’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):

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.

Delegation dilution. When an agent hands sub-tasks to tools, services or peer agents, the initiating human’s identity is usually replaced by the calling service’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’s full authorization context and bypasses segregation of duties.

Confused 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.

Autonomous 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.

Rogue 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’t keep up with them.

[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.]

OWASP’s Top 10 for LLM Applications calls the underlying condition Excessive Agency: an agent holding more functionality, permissions or autonomy than its task needs.

Identity design is where that excess is either granted or prevented.

What 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:

{
  "sub": "user:[email protected]",
  "act": { "sub": "agent:invoice-reconciler/instance-7f3a" },
  "task": "reconcile-q3-invoices",
  "scope": "invoices:read",
  "exp": 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’t be predicted.

[Add one paragraph from your own experience running identity at scale: what workload identity guaranteed in practice, and where it stopped short.]

The 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.