AI Agents as Non-Human Identities: A New IAM Security Problem

In April we looked at non-human identities (service accounts, keys, tokens and workloads) as the IAM problem of this decade. AI agents are the fastest-growing category of non-human identity, and they bring a twist that traditional service accounts do not: they act on behalf of someone else, with authority that changes from task to task.

Getting this right is the difference between agents that are auditable and safely bounded, and agents that quietly hold the combined privileges of everyone who has ever used them.

#Three anti-patterns

1. The agent uses the human's session. The agent runs inside the user's browser or with the user's full OAuth token. Downstream systems cannot tell whether a person or an agent acted, cannot apply different limits, and any manipulation of the agent inherits all of the user's access.

2. The agent has its own super-account. A single service identity with broad access serves every user. Each request is only as safe as the agent's own judgement about what this user should see, a classic confused deputy.

3. Static API keys in configuration. Long-lived keys per integration, shared across users and never rotated.

#The target model: explicit delegation

Every agent action should be attributable to three things:

• the agent (which registered agent and version),
• the principal it acts for (a user, a team or a scheduled job owner), and
• the scope granted for this task.

Effective permissions are the intersection of what the principal is allowed to do and what the agent is allowed to do, further narrowed to what the task needs.

flowchart LR
  U[User token<br/>sub = alice] --> TX[Token exchange service]
  AG[Agent credential<br/>client = invoice-agent] --> TX
  TX -->|down-scoped, 10 min| T["Delegated token<br/>sub = alice<br/>act = invoice-agent<br/>scope = invoices:read"]
  T --> API[Invoices API]
  API --> Z{Authorise:<br/>alice can read?<br/>agent may read?}
  Z --> R[Result + audit record]

#Building blocks available today

OAuth 2.0 Token Exchange (RFC 8693) lets a service exchange a user's token, together with its own credentials, for a new token that represents delegation. The resulting token can carry the user as the subject and the agent as the actor (the act claim), with narrower scopes and a short lifetime.

On-behalf-of flows offered by major identity providers implement similar delegation for calling downstream APIs.

Audience restriction and resource indicators ensure a token minted for one API cannot be replayed against another.

Workload identity (cloud-native identities, SPIFFE and similar) gives the agent runtime itself a verifiable identity without stored secrets.

A decoded delegated token might look like this:

{
  "iss": "https://idp.example.com",
  "sub": "alice@example.com",
  "aud": "https://api.example.com/invoices",
  "scope": "invoices:read",
  "act": { "sub": "agent:invoice-assistant", "ver": "2026.05.1" },
  "exp": 1779180000,
  "iat": 1779179400
}

Downstream services log both sub and act, apply the user's permissions and enforce the agent's scope.

#An agent registry

You cannot govern what you cannot see. Maintain a registry of agents, as you would of applications:

Integrate the registry with your identity provider, so only registered agents can obtain delegated tokens, and only within their registered scopes.

#Lifecycle controls

• Creation: agents are registered and reviewed before they can obtain credentials.
• Change: new tools, broader scopes or a new model version trigger review.
• Access reviews: include agents in periodic access certification alongside humans and service accounts.
• Offboarding: when an owner leaves or a project ends, the agent's registrations and grants are revoked.
• Emergency revocation: a way to disable an agent everywhere within minutes.

#Detection

Agent identities make detection easier when done well:

• alert when an agent requests scopes outside its registration,
• flag unusual volumes, new resources or new destinations per agent,
• detect agent credentials used from unexpected runtimes or networks, and
• correlate agent actions with the delegating user's activity. Actions for a user who is not active can be a warning sign.

#The bottom line

AI agents are not just more service accounts. They borrow authority from people and exercise it dynamically. Model that explicitly: give each agent its own identity, delegate narrowly and briefly with token exchange, enforce the intersection of user and agent permissions, and govern agents through a registry with owners and expiry. That makes agents auditable, bounded and revocable, which is exactly what IAM is for.

Our information security audit and CISO as a Service teams help organisations design agent identity and delegation models.