The primitive you need was standardised in 2020
Every enterprise deploying agents eventually asks the same question: when an agent calls an API on behalf of an employee, whose identity is on the request? The answer that ships in most pilots is a shared service account with broad scopes, which means the audit log records that the integration user did it. That's not an audit trail. That's a shrug with a timestamp. The delegation model has an RFC. OAuth 2.0 Token Exchange, RFC 8693, published January 2020, defines exactly this: an actor token representing the party doing the work, a subject token representing the party it acts for, and the act claim recording the chain. A token minted through that flow carries both identities, so the downstream service can authorise on the human's entitlements while the log preserves which agent made the call. Almost nobody uses it for agents yet. The category is being sold as new, and the load bearing standard is six years old.
Why service accounts fail here specifically
Service accounts were designed for software whose behaviour is fixed at deploy time. A batch job's permission set can be derived from its code, reviewed once, and left alone. An agent's behaviour is decided at runtime by a model reading text that may have come from outside your perimeter. That inverts the assumption. The permission you grant an agent is not the permission it will use in a specific run, it's the ceiling on what an attacker or a confused planner can reach. OWASP tracks this as LLM06 Excessive Agency in the 2025 Top 10 for LLM Applications, and the mitigations it lists are unglamorous: minimise extension functionality, minimise permissions, require human approval for high impact actions. The second failure is chaining. Agent A holds a token and delegates to Agent B. If B inherits A's session, the permission set widens silently at every hop, and it widens in a direction nobody drew on the architecture diagram. Workload identity frameworks solved the machine to machine half of this: SPIFFE gives each workload a cryptographically verifiable identity document instead of a shared secret, which at least makes the question who is calling answerable before you get to the question on whose behalf.
What the standards bodies actually require
NIST AI RMF 1.0, released in January 2023, puts this under GOVERN and MAP rather than treating it as a security bolt on: know your AI actors, know the context of use, and assign accountability for each system. The framework is voluntary, but it's the vocabulary US enterprise risk teams are writing policy in. The EU AI Act is more direct. Article 12 requires high risk AI systems to automatically record events over their lifetime, which is unachievable in any useful sense if every event is attributed to one shared robot user. Article 14 requires human oversight that an operator can actually exercise, and Article 26 places obligations on the deployer, so the identity design of your agent deployment is your problem even when the model and the framework are someone else's. Penalties top out under Article 99 at EUR 35 million or 7 percent of worldwide annual turnover for the most serious breaches. ISO/IEC 42001, published December 2023, carries the same expectation through Annex A control A.6 on the AI system lifecycle and A.9 on the use of AI systems. Auditors reading against A.9 ask who is permitted to operate the system and how that's enforced. A shared credential is a hard answer to give well.
A model that holds up under review
Give every agent a first class identity of its own, registered in the same directory as your humans and services, with an owner who is a person. Not a team alias. A person who can be paged. Authorise per run, not per agent. The agent's registered identity establishes what it could ever do. The token minted for this run, carrying the delegation chain, establishes what it may do right now, scoped to the task and expiring with it. Short lifetimes matter more here than in classic service to service traffic because the blast radius of a leaked agent token includes whatever a model can be talked into asking for. Write both identities into every log line: the acting agent and the principal it acted for. Then a question like show me everything the reconciliation agent did on behalf of finance staff last Tuesday has an answer that takes a query rather than a week. And put approval where a silent error is expensive rather than where the model is least confident. Confidence and consequence are unrelated, and sizing review by confidence is how teams end up approving the harmless steps.
What the emerging platform category gets wrong
A market is forming around agent identity platforms, and the pitch usually leads with visibility: discover your agents, see what they touched. Visibility is worth having. It's also the half that changes no access decision. The hard half is that identity for agents only works if it reaches into the systems the agent calls, which means your existing identity provider, your API gateways, and your data platform all have to honour the delegated token. A separate console that observes agent traffic without being in the authorisation path gives you a record of decisions you didn't control. Ask any vendor how their identity shows up in the access decision made by the downstream system, and whether the answer requires that system to change. Our read, from delivering AI into production in financial services, healthcare, and government: teams shopping for an agent identity platform usually need to extend the identity infrastructure they already run, plus a delivery path that treats identity as a design input rather than a launch blocker. Difinity partners with regulated teams on exactly that sequence, so the AI you ship is one you can trust, control, and prove.
Frequently asked questions
What is AI agent identity management?
It's the practice of giving each AI agent its own verifiable identity, authorising what it can do on a per run basis, and recording both the acting agent and the human or service it acted on behalf of. The delegation pattern is defined in OAuth 2.0 Token Exchange, RFC 8693.
Can an AI agent just use a service account?
It can, and that's what most pilots do, but it breaks accountability. A shared service account attributes every action to one identity, so you can't answer who the agent acted for, and the permission ceiling stays wide open at runtime. OWASP lists this pattern under LLM06 Excessive Agency in the 2025 Top 10 for LLM Applications.
Does the EU AI Act require per agent identity?
It doesn't name the control. Article 12 requires automatic event recording over a high risk system's lifetime and Article 14 requires exercisable human oversight, and both are difficult to evidence when every action is logged against a single shared credential. Article 26 puts the duty on the deployer, not only the provider.
Where do agent identity platforms fit?
Most of them sit outside the authorisation path and observe traffic. That gives you discovery and a record, not enforcement. The question to ask a vendor is how their identity appears in the access decision the downstream system actually makes.