Identity models for agents

Why this matters

A "user logged in and called an API" is the wrong mental model for agents. Agents persist beyond a session, hold tools with their own credentials, and may act for many users at once. Picking the right identity model up front determines whether your audit logs, scopes, and revocation will actually work.

Learning objectives

1. Distinguish 5 principal types involved in agent flows.
2. Apply the four classical identity models (delegated, impersonation, OBO, service identity).
3. Choose a model per use case.
4. Avoid the confused deputy by design.
5. Express identities cleanly in tokens (subject, actor, on-behalf-of).

1. The five principals

In an agent system you will typically have:

1. End user (alice) — the human whose data and intent the agent serves.
2. Application (acme-helpdesk-app) — the product / web app users sign in to.
3. Agent instance (agent:helpdesk-v1 running for alice) — the LLM-driven runtime that thinks, plans, and calls tools.
4. Tool / downstream API (tickets-api, crm-api, mail-api) — what the agent calls.
5. Sub-agent (e.g. agent:research-v2) — a delegated worker; usually inherits scoped authority from the parent.

Every authorization decision involves at least two of these; agent-to-agent calls involve four. Write them down for your use case before you reach for code.

2. The four classical identity models

Model A — Direct user

The user calls the API directly with their own session / token. The agent isn't in the picture. Boring but correct for any read-only browse where the agent doesn't need persistent rights.

Model B — Impersonation

The agent presents the user's token verbatim. The downstream API sees "Alice did this". Cheap; appalling for audit. Never use unless audit logs explicitly capture the calling agent.

Model C — Delegation / On-Behalf-Of (OBO)

The agent has its own identity and presents a token saying "I am agent:helpdesk-v1, acting on behalf of alice, with scope tickets:read". The downstream API authorises against both identities, logs both.

This is the right default for agents that act for users.

Model D — Service identity (machine-to-machine)

The agent acts on its own authority, not on behalf of any user. Tokens are obtained via Client Credentials (RFC 6749) or Workload Identity (lesson 2.2). Use for cron-like agents that ingest data, monitor systems, or perform pure-internal tasks.

3. The confused deputy problem

A deputy is a program acting on behalf of someone else. A confused deputy mis-applies its authority because it can't tell which caller it should be checking.

Classic example: an LLM agent has admin scope to its database (to manage many users). User Alice asks it "summarise my orders". The agent uses its own admin authority, not Alice's. If injected text manipulates the query, it can return anyone's orders.

Mitigations:

• Delegated tokens instead of admin tokens. The agent's call carries Alice's scoped authority.
• Per-request principal isolation: the agent's runtime accepts a "subject" parameter from the user-bound session, and rejects tools that would let it act outside.
• Capability-based design: tools receive narrow, single-purpose tokens bound to one user and one resource, issued just-in-time.

Confused-deputy bugs are the #1 source of "the agent leaked data across tenants" CVEs in agentic products. Build your identity model so the deputy is never confused — its token can only authorise the right caller's data.

4. Encoding identity in tokens

OAuth 2.0 Token Exchange (RFC 8693) standardised how to express delegation. The two key claims:

• sub — the subject. For delegation, this is the user (the one for whom the work is done).
• act — the actor. A nested claim describing the agent doing the work.
• may_act — optional; lists who may act on behalf of this subject.

Example access token issued via Token Exchange:

{
  "iss": "https://idp.acme.com/",
  "aud": "tickets-api",
  "sub": "alice@acme.com",
  "act": {
    "sub": "agent:helpdesk-v1",
    "iss": "https://idp.acme.com/",
    "tenant": "acme",
    "session_id": "sess_92f...",
    "purpose": "ticket-summarisation"
  },
  "scope": "tickets:read",
  "exp": 1735000000
}

tickets-api authorises Alice's read-tickets scope and logs that agent:helpdesk-v1 did it. Revocation can target either.

Chains are allowed: an agent that delegates to a sub-agent stacks act claims:

"sub": "alice@acme.com",
"act": {
  "sub": "agent:research-v2",
  "act": { "sub": "agent:helpdesk-v1" }
}

Most IdPs (Keycloak, Auth0, Okta, Curity, ForgeRock) now support token exchange + act. We'll wire it in lesson 3.1.

5. Tenant identity

Agents almost always operate in a multi-tenant world (one product, many customer organisations).

• Tenant = the customer / org (acme, globex).
• Every token must carry tenant (or org, realm) as a top-level claim.
• Resource servers must scope every query by tenant, not just by user.
• Cross-tenant calls require explicit consent and a separate token.

Multi-tenant agent products fail when tenant isn't a first-class identity axis. Burn this in: tenant before user before scope before resource.

6. Pseudonymous vs real identities

Sometimes agents need to act under a stable pseudonym (e.g. customer-facing chatbots that shouldn't reveal real engineer names).

• Use a stable internal ID (agent:helpdesk-v1) for audit.
• Expose only a public name to end users.
• Tie agent IDs to a registered agent record (purpose, owner, scopes allowed, lifecycle).

This becomes critical under EU AI Act transparency obligations: an agent must declare it is AI, but you still want internal accountability.

7. Agent registration

Treat every agent like a service: register before deploy.

A minimum agent record has:

• agent_id (immutable).
• Display name + version.
• Owner (team / person).
• Purpose statement (free-text + tags).
• Allowed scopes / tools.
• Permitted user-delegation patterns.
• Tenant scoping rules.
• Lifecycle: created, activated, deprecated.
• Risk tier (per your governance framework).
• Pointer to the model + system prompt + version (immutable).

Some IdPs are adding "AI Agents" as a first-class object type (WorkOS, Stytch, Auth0 announced agent identity primitives in 2024-25). Until that's universal, model it yourself in your IdP's application/client registry plus an internal agents table.

8. Choosing a model — decision flow

Does the agent act for a specific end user?
│
├── No → Service Identity (Model D). Client Credentials or Workload Identity.
│
└── Yes
     │
     Does the user authorise per session, or once and walk away?
     │
     ├── Per session (synchronous chat) → Delegation via on-behalf-of token after user OAuth login.
     │
     └── Once + autonomous (background agent for days)
          │
          ├── Risk tier: low → Refresh-token rotation + short access tokens.
          ├── Risk tier: medium → CIBA: agent triggers user push approval for sensitive actions.
          └── Risk tier: high → CIBA + DPoP + per-action step-up auth.

Apply this once per agent + per tool. Document the chosen model in the agent record.

9. Hands-on lab (2 h)

1. Sketch the identity diagram for a hypothetical "Calendar Agent" that:
   • Reads Alice's Google Calendar.
   • Writes events on her behalf.
   • Calls an internal company API to look up colleagues.
   • Occasionally hands off to a "Research Sub-Agent".
2. For each tool call, pick a model from A-D and the relevant token claims.
3. Identify two confused-deputy bugs that would exist if you used Model B everywhere.
4. Draft an agent record JSON document.
5. In Keycloak, create a client for the parent agent and one for the sub-agent. Configure the parent so it is permitted to perform Token Exchange targeting the sub-agent's audience.

10. Common pitfalls

1. One "service account" used by both the agent backend and the agent's runtime — audit becomes useless.
2. Letting users impersonate the agent's service account in dev → leaks habits into prod.
3. Tenant not in tokens → cross-tenant data leaks via the agent.
4. Agent records as a spreadsheet — diverges from reality immediately.
5. Confusing "the agent" with "the LLM" — same agent_id can call multiple models; same model can power many agents.

11. Self-check

1. Five principal types in an agent system.
2. Why impersonation is bad for audit.
3. Confused deputy in one sentence.
4. What act and may_act claims express.
5. Why tenant must be a first-class claim.

12. References

• RFC 8693 (OAuth Token Exchange).
• "The Confused Deputy" — Hardy, 1988 (the original paper, still readable).
• Auth0 "Identity for AI Agents" guide.
• WorkOS "AgentKit / agent identity" docs.
• Stytch "Authentication and authorization for AI agents".
• OpenID Foundation "AuthZEN" working group output.
• NIST SP 800-207 (Zero Trust Architecture).