Non-Human Identity for AI Agents: The Architect's Guide

30 July 2026 · Bedrock AI

Non-human identity (NHI) for AI agents means giving every agent its own cryptographically verifiable identity, scoped permissions and a lifecycle, rather than sharing a service account or API key across a fleet of autonomous systems. The problem is scale and behaviour: agents now outnumber human users inside most enterprises, and unlike a service account, an agent can choose new actions at runtime that nobody explicitly authorised.

Why isn’t a service account good enough for an AI agent?

A service account is a static identity with a predictable access path: it calls the same three endpoints every night and nothing about that changes. An AI agent is not static. It reasons about which tool to call, requests new permissions when a task demands them, and chains actions together in sequences its own creators didn’t anticipate. Treating an agent like a beefed-up service account means granting it standing access wide enough to cover every path it might take, which is precisely the over-privileging that turns one compromised agent into an enterprise-wide incident. Non-human identity for agents has to be dynamic where a service account’s identity is fixed.

Industry research on this gap is now converging on the same number: non-human identities, agents included, already outnumber human identities by roughly 144 to 1 inside large enterprises, and that ratio is growing at around 44% a year according to reporting from Virtualization Review. Most of those identities were never designed; they accumulated as teams stood up agents faster than security teams could register them.

Why does traditional IAM break down for autonomous agents?

Traditional identity and access management assumes an identity belongs to a person who has a manager, that access reviews happen on a certification calendar, and that unusual behaviour is a deviation from a known baseline. None of those assumptions hold for an agent. There is no manager to email when an agent’s access looks wrong; there is often no defined owner at all. Access certification campaigns built around quarterly human reviews are too slow for identities that can be spun up and torn down in minutes. And “normal behaviour” for an agent is a moving target, because the whole point of giving it autonomy is that it acts differently depending on context.

The Cloud Security Alliance frames this directly as a governance vacuum: the tooling enterprises built for human IAM and even for static machine credentials simply doesn’t have the primitives agentic AI needs, and only a minority of organisations have closed that gap so far. Surveys cited by Built In put the number starkly: 92% of security leaders agree that governing AI agents is critical, but only 44% have actually implemented policies to do it. That 48-point gap between belief and practice is exactly where an AI architect’s identity design work sits.

What does an AI architect actually design for agent identity?

The job isn’t picking a vendor. It’s specifying a five-layer stack, in this order, before a single agent goes into production:

1. Workload identity foundation. Every agent instance gets a cryptographic identity bound to its deployment, not to a shared secret. This is the layer SPIFFE and SPIRE exist for: SPIFFE issues short-lived X.509 SVID credentials to workloads, and because the identity is tied to the workload rather than a person, it survives redeployment and scaling in a way a hardcoded API key never does.
2. Delegation context. When an agent acts, the system needs to answer “on whose behalf?” as well as “which service is calling?” OAuth 2.0 token exchange (RFC 8693) carries that delegation chain as a scoped, short-lived token, layered on top of the workload identity from step one.
3. Per-action authorization scoping. Access is granted per task, not per agent. An agent doesn’t get standing read access to a database; it gets a token scoped to the specific query class it needs for the specific job it’s running right now.
4. Just-in-time, ephemeral credentials. Credentials expire when the task ends, not on a rotation schedule. Zero standing privilege is the design goal: if an agent isn’t actively mid-task, it should hold no live credential at all.
5. Audit and attribution. Every tool invocation is logged against the identity that made it, the policy that allowed it, and whether the action matched the agent’s declared intent. Attribution here is what makes an incident review possible six weeks later.

Skip any one of these layers and the stack degrades to “agents share a service account with broad scope,” which is the exact pattern security teams are now racing to unwind.

How should architects handle trust between agents that delegate to each other?

This is where most designs quietly fail. The intuitive assumption is that if Agent A delegates a task to Agent B, and B calls in Agent C to finish it, C should inherit whatever access A originally had. It shouldn’t. Trust in a delegation chain has to be non-transitive: each hop is a fresh authorization decision, scoped to what that specific agent needs for that specific sub-task, not a pass-through of the original grant. Otherwise a three-hop delegation chain becomes a privilege escalation path, where the weakest agent in the chain effectively holds the access of the strongest one.

The architect’s job is to make each delegation an explicit, policy-checked event rather than an implicit inheritance. That means the token exchange at every hop is evaluated against its own policy, not rubber-stamped because an upstream agent already had the access.

Which standards should architects actually build on today?

The practical takeaway for an architect scoping a project in 2026: SPIFFE and RFC 8693 token exchange are safe to build on now. WIMSE is worth tracking so the identifier model you choose today doesn’t need replacing in eighteen months. Pre-action authorization is still the least settled layer, which is exactly why architects should design the audit and revocation layers (steps four and five above) as the safety net rather than betting the whole design on pre-action controls maturing on schedule.

What does decommissioning an agent’s identity actually require?

Decommissioning is where the lifecycle discipline either holds or doesn’t. Turning off an agent has to trigger automatic revocation of every credential it held, not a ticket that sits in a queue. In practice that means: the workload identity is revoked at the SPIFFE/SPIRE layer immediately, any outstanding delegated tokens are invalidated rather than left to expire naturally, and the audit trail is checked for any access granted in the agent’s final active window that hasn’t yet been reviewed. An agent identity that lingers after the agent is retired is a credential with no owner watching it, which is precisely the failure mode that got the enterprise into a 144:1 identity ratio in the first place.

FAQ

Is a non-human identity the same thing as a service account? No. A service account is one type of non-human identity, but it’s a static one with a fixed access path. An AI agent’s identity has to account for dynamic, context-dependent behaviour that a service account was never designed to have.

Do AI agents need their own identity provider, separate from human IAM? Not necessarily a separate provider, but a separate authorization model layered on the same governance discipline: named ownership, lifecycle controls and audit trails, applied through standards like SPIFFE and OAuth token exchange rather than the certification-campaign model built for human accounts.

What’s the single biggest identity mistake businesses make with AI agents? Granting standing, broad-scope access up front to avoid the engineering work of per-task scoping. It solves the integration problem for a week and creates the security problem for a year.

Does every agent need its own SPIFFE ID? Under the WIMSE model, yes: every agent workload should be assigned exactly one identifier, which may be implemented as a SPIFFE ID. Sharing an identifier across agent instances defeats the purpose of workload-bound identity.

How does non-transitive trust change how architects design multi-agent systems? It means delegation chains need a policy checkpoint at every hop, not just at the first one. That adds design overhead up front, but it’s the difference between one compromised agent staying contained and one compromised agent handing an attacker the access of everything downstream.

Bedrock AI maps your systems, team and workflows to show where AI actually pays, before you spend a pound building. Book a strategy call.