Giving AI Agents Their Own Identity: Short-Lived, Audience-Bound Credentials for Agentic Workloads

IdentityOctober 15, 2026

AI agents often run on shared keys or borrowed user tokens. Recent Five Eyes guidance and emerging standards point to a better model: distinct agent identities, delegated short-lived tokens and a tested off switch. Here is a checklist to start.

Abstract navy illustration of concentric teal and blue rings around a bright core, with small nodes on each ring and outer nodes linked by thin lines, representing agent identities delegated from a central identity

AI agents are moving from answering questions to taking actions: opening tickets, querying databases, changing configuration, sending email. Each of those actions runs on a credential. In many early deployments that credential is a long-lived API key in a config file, a shared service account, or a copy of the deploying engineer's own token. None of these tells you which agent did what, on whose behalf, or how to stop it quickly.

Government guidance and standards work have now converged on the same answer. In May 2026, CISA, NSA and partner agencies from Australia, Canada, New Zealand and the UK published Careful Adoption of Agentic AI Services, warning that agent autonomy brings risks such as privilege escalation and accountability gaps, and advising that agents should not receive broad or unrestricted access. This article turns that direction into identity decisions you can make this week.

Why borrowed credentials fail for agents

A human session has natural limits: a person signs in, works for a while and signs out. An agent can run continuously, chain many tool calls in seconds, and be steered by content it reads along the way. When it uses a borrowed credential, three things go wrong at once.

Attribution disappears. Logs show the service account or the engineer, not the agent, so investigators cannot separate agent actions from human ones.
Scope is inherited, not designed. The agent gets whatever the credential holder could do, which is almost always more than the task needs.
Revocation is blunt. Disabling a shared key breaks every workload that uses it, so teams hesitate to pull it when something looks wrong.

The Cloud Security Alliance's practitioner reading of the joint guidance summarises the expectation plainly: each agent should carry a unique, cryptographically anchored identity with short-lived credentials, operate under strict least privilege, and be prevented from changing its own privileges.

Separate the agent from the person it acts for

The most useful design decision is to treat an agent as its own identity that acts on behalf of someone, rather than as that someone. OAuth already has a vocabulary for this. RFC 8693 (OAuth 2.0 Token Exchange) distinguishes impersonation, where the actor simply becomes the user, from delegation, where the actor keeps its own identity and acts for the user. Delegated tokens can carry an act claim naming the current actor, and a may_act claim lets the authorization server check whether that actor is allowed to act for the subject at all.

Delegation is what you want for agents. A downstream service can then see both the user and the agent, apply policy to the combination, and record both in its logs. When the agent calls another agent or tool, a fresh exchange produces a new, narrower token instead of forwarding the original one, so permissions do not accumulate along the chain.

The IETF has not finished an agent-specific standard. A September 2026 CSA analysis of IETF work notes that the substantive effort sits in the WIMSE working group, with several individual drafts still unadopted, and advises organisations not to wait. The common pattern across those drafts is already clear: short-lived, audience-restricted, narrowly scoped tokens, tied to an accountable owner, with revocation that propagates.

Bind every token to one audience

Agents increasingly reach tools through the Model Context Protocol (MCP). Its authorization specification builds on OAuth 2.1 and is a good model for any agent-to-tool connection, even outside MCP. Three of its requirements are worth adopting everywhere:

Clients must request tokens for a specific resource using the resource parameter from RFC 8707, and servers must reject tokens that were not issued for them.
A server that calls an upstream API must obtain its own token for that API. Passing through the token it received is explicitly forbidden, because it creates a confused-deputy problem.
Authorization servers should issue short-lived access tokens, and must rotate refresh tokens for public clients.

Audience binding is what keeps a token stolen from one tool from working at another. If your agent platform cannot tell you which audience each token was issued for, treat that as a gap to close before widening its access.

A checklist for this week

Inventory agents and their credentials. List every agent or automation that calls internal or SaaS APIs. For each, record the credential type, who issued it, its lifetime and an accountable human owner.
Flag the risky patterns. Mark agents using shared service accounts, static API keys or a person's own token. These are your migration list.
Give each agent a distinct identity. Register it as its own client or workload in your identity provider, so logs and policies can name it.
Scope to the task. Grant only the scopes the current use case needs. Start with read-only access to non-sensitive data, and add write access one capability at a time.
Shorten lifetimes. Prefer access tokens measured in minutes, obtained at run time, over keys that live in configuration. Store refresh tokens as secrets and rotate them.
Use delegation, not impersonation. Where an agent acts for a user, issue tokens that carry both identities, and check that downstream services log both.
Block self-escalation. Make sure no agent identity can grant itself roles, create credentials or edit its own policy. Put those actions behind human approval.
Require approval for high-impact actions. Payments, deletions, permission changes and external sharing should pause for a person, enforced by the workflow rather than by the agent's own judgement.
Test the off switch. Confirm you can disable a single agent's identity and revoke its tokens without breaking other workloads, and time how long it takes.

Make agents part of normal identity governance

Agents should go through the same lifecycle as any other account: request and approval, periodic access review, and formal retirement. According to CSA's reading of the joint guidance, it calls for the same lifecycle discipline applied to human identities, human-readable logging of tool use, and circuit breakers that halt execution and escalate to a person when behaviour is unexpected.

In practice, that means adding agent identities to your quarterly access reviews, alerting on unusual call volumes or new destinations per agent, and deleting credentials when a pilot ends. An agent that nobody owns is the non-human equivalent of a leaver's account that was never disabled.

Teams consolidating identity across their systems, for example with OXU Identity, should bring agent identities into that same inventory and review process rather than managing them on the side.

Conclusion

Agents do not need an exotic new security model. They need the identity basics applied without shortcuts: a distinct identity, short-lived tokens bound to one audience, delegation that shows who acted for whom, least privilege, and an off switch you have tested. Standards for agent identity are still settling, but OAuth token exchange and audience-bound tokens are available today. Start with the inventory, retire the shared keys, and widen agent access only as fast as your ability to see and revoke it.