Every AI agent needs an identity: access, delegation and least privilege

Between August 8 and 18, 2025, a threat actor that Google tracks as UNC6395 used stolen OAuth access and refresh tokens to export data from the Salesforce instances of hundreds of organizations, then searched the exports for AWS keys, Snowflake tokens and passwords. The tokens belonged to Drift, an AI chat agent that Salesloft customers had connected to Salesforce. Salesforce itself was not breached. The attackers did not need to break anything: they held valid, long-lived credentials that an AI integration had been trusted with, and they used them exactly as designed until Salesloft and Salesforce revoked every Drift token on August 20.

That is the identity problem with AI agents in one incident. Agents need access to systems to be useful. How that access is granted, what it is scoped to, how long it lasts and whether anyone can tell the agent apart from a person decides whether a mistake, an injected instruction or a stolen token stays small or becomes a breach.

Every article in this series so far has said the same thing in passing: give each agent its own identity, scoped and short-lived. This one explains how. It covers what an agent identity is, the three ways agents get access and the right token pattern for each, how to keep privileges least, and how to run identities for agents the way you already run them for people. It is written for identity, security and platform teams, and for the architects who have to sign off agent designs.

Part one: the problem

1. Three ways agents get access, and why two are wrong

Look at how agents in your organization actually authenticate today and you will usually find one of three patterns.

• Borrowed human credentials: the agent runs with a user’s session, personal access token or API key. It can do everything that person can do, and in the logs it is that person. When something goes wrong you cannot tell what the human did from what the agent did, and you cannot revoke the agent without locking out the human.
• Shared service accounts and static keys: one client ID and secret, or one API key, used by several agents or several instances of one agent, often with broad scopes and no expiry. There is no attribution, no way to cut off one agent, and a stolen key works until someone notices.
• An identity per agent, with delegated access: each agent is a distinct principal in your identity provider, with an accountable owner. When it acts for a person, it receives a token that carries both identities and can never exceed what that person may do. When it acts for itself, it gets narrow permissions for its job, through short-lived credentials it never sees directly.

Only the third pattern holds up under the questions supervisors and auditors now ask. The OCC’s November 2026 examiner framework, as summarized by King & Spalding, says banks should manage AI agents’ identities and permissions with the same care as privileged human users. NIST’s National Cybersecurity Center of Excellence made the same point in a February 2026 concept paper on agent identity and authorization, which frames the work around identifying agents distinctly from people, authenticating them, authorizing them, delegating access from users, logging their actions and tracking the data they use.

2. What an agent identity actually is

An agent identity is a non-human principal in your directory, like a service account but with more context attached. At minimum it should carry a unique identifier, a human sponsor who is accountable for it, a stated purpose, the version or template it was created from, the permissions it holds, and its lifecycle dates: created, last reviewed, due for review, retired.

It helps to separate the type of agent from the running instance. Microsoft Entra Agent ID, now generally available, models this explicitly. An agent identity blueprint is the template and holds the authentication credentials; agent identities are created from it and hold the permissions; and an agent can optionally have an agent user for systems that only understand user accounts. Agent identities are confidential clients by design, so they cannot be public clients that keep secrets in a browser or on a device. Other platforms use different names, but the separation is worth copying wherever you are: one place to rotate credentials for a whole class of agents, and per-instance identities you can scope, review and revoke individually.

The other half of the definition is what the agent does not have. It should not have a long-lived secret in its own configuration, environment variables or prompt. Credentials belong in the platform, a vault or a workload identity mechanism, and the agent asks for a short-lived token when it needs one.

Part two: the three access patterns

3. Acting for a user: delegation, not impersonation

Most enterprise agents act for someone: they read the user’s mailbox, search the documents the user can see, draft in the user’s name. The right mechanism is delegation. The agent receives a token that says, in effect, “this agent, acting for this user, for this resource, with these scopes”, and the resource enforces the user’s own permissions on top.

The standard building block is OAuth 2.0 Token Exchange (RFC 8693). The agent presents the user’s token together with its own credentials and receives a new token for the downstream resource, with a narrower scope and an audience limited to that one resource. The new token carries the user as the subject and the agent in an act (actor) claim. Microsoft’s on-behalf-of flow works on the same principle, and AWS made on-behalf-of token exchange in Bedrock AgentCore Identity generally available on April 30, 2026, producing a scoped-down token that carries both the user and the agent identity.

{
  "iss": "https://login.example-bank.com",
  "sub": "m.chen@example-bank.com",
  "act": { "sub": "agent:payments-exception-assistant",
           "client_id": "svc-agent-pexa" },
  "aud": "https://payments-api.example-bank.com",
  "scope": "wires.read repairs.prepare",
  "iat": 1794560100,
  "exp": 1794560400
}

Three rules make delegation safe. The delegated token must never grant more than the user could do directly, so the agent cannot be used to escalate. Its scope should be the subset the task needs, not everything the user has. And consent should name the agent: a person should know they are authorizing this specific agent, not a generic application. That last point is where current standards are still moving. An individual Internet-Draft on on-behalf-of authorization for AI agents proposed a parameter that names the requesting agent and records the delegation chain in the token, but it has expired without IETF endorsement, and you should treat it as a direction rather than something to build on today.

4. Acting for itself: workload identity

Some agents act on their own: a nightly reconciliation agent, a triage agent working a queue, a security agent responding to alerts. There is no user to delegate from, so the agent needs its own access, and it should be as narrow as its job.

Use workload identity rather than secrets. On cloud platforms that means managed identities or workload identity federation, where the platform vouches for the running workload and no secret is stored at all. Where you must use OAuth client credentials, authenticate with a signed assertion (private key JWT) or certificate rather than a shared client secret, keep the key in a managed store, and issue tokens that last minutes. Give each autonomous agent permissions for exactly the queues, records and actions its function needs, and nothing it might need one day.

Be especially careful with autonomous agents that have write access to systems of record. They are the closest thing to an unattended privileged account most organizations have ever deployed, and they should be treated with at least the same controls: approvals for elevated actions, hard limits on volume and value, and alerts when they act outside their usual pattern.

5. Agents calling tools and other agents

Real deployments are chains. A user asks an assistant; the assistant calls an MCP server; the server calls a document system; another agent is asked to check the result. Identity has to survive every hop without getting broader.

Two rules carry most of the weight. First, every hop gets its own token for its own audience. RFC 8707 resource indicators let a client ask for a token that is only valid at one resource, and the MCP specification requires this and forbids passing a token received from a client on to an upstream API. If a server needs to call another system for the user, it exchanges the token for a new one rather than forwarding it. Second, keep the originating user visible all the way down. Token exchange can nest actor claims so the final resource knows the chain of agents involved, and the IETF is working on related ideas such as transaction tokens for agents. Whatever mechanism you use, the last system in the chain should still be able to answer “for whom, and through which agents?”

For connections between AI clients and MCP servers in an enterprise, there is now a better pattern than asking each employee to click through a consent screen. MCP’s Enterprise-Managed Authorization extension, stable since June 18, 2026, lets your identity provider decide which servers each user’s client may reach. The client exchanges the user’s single sign-on assertion for an Identity Assertion JWT Authorization Grant (ID-JAG) at your identity provider, then presents it to the MCP server’s authorization server for an ordinary access token. Okta markets the same pattern as Cross App Access, and Anthropic made it generally available for Claude Team and Enterprise connectors in August 2026. The ID-JAG specification itself is still an IETF draft, so check support with each vendor before you depend on it. Our MCP governance guide walks through the flow in detail.

Part three: least privilege that holds

6. Scope by task, not by agent

The usual way to scope an agent is to list everything it might ever need and grant it once. That produces agents with the combined access of every task they perform, permanently. Scope by task instead: the token for a given step carries only the scopes that step needs, requested at the time it is needed.

Identity scopes are coarse, so add a second layer of authorization at the point where the agent calls tools. A policy enforcement point in front of the tools can check arguments as well as scopes: this agent may read invoices, but only for the user’s own business unit; may prepare a payment, but not above a threshold; may email, but only to internal domains. Deny by default, and allow elevated actions just in time, with an approval bound to the specific action. Our reference design for kill switches, approvals and audit logs covers that layer.

agent_id: agent:payments-exception-assistant
sponsor: Head of Payment Operations        # accountable human
blueprint: pexa-blueprint@3.2               # template holding credentials
purpose: Investigate failed wires; prepare repair instructions
modes:
  delegated:                                # acting for a signed-in user
    grant: token-exchange (RFC 8693)
    scopes_by_task:
      investigate: [wires.read, accounts.read]
      prepare_repair: [repairs.prepare]     # needs approval at the gateway
  autonomous: none                          # never acts without a user
token_lifetime_minutes: 5
refresh_tokens: false
credential_storage: platform vault; agent never sees secrets
conditional_access: [managed-runtime-only, block-outside-us-east]
review_every_days: 90
last_review: 2026-10-30

7. Short-lived everything

The Drift incident ran for ten days on stolen OAuth tokens. Long-lived credentials are what turn a compromise of the agent, its vendor or its host into ongoing access to your systems.

Keep agent access tokens to minutes, not hours. Avoid issuing refresh tokens to agents where the platform allows it, and where you cannot, keep their lifetime short and bind them to the client. Store any credential the agent depends on in a vault or platform credential store, so the agent code and its prompts never contain a secret that can be logged, leaked into a model context or committed to a repository. AgentCore Identity’s token vault and Entra’s blueprint credentials are examples of this separation. Where your identity provider and resources support sender-constrained tokens, such as DPoP or mutual TLS, use them, so a stolen token is useless from another machine.

8. Revocation is a kill switch

An identity you can revoke is the most reliable stop you have, because it works even when everything else about the agent has gone wrong. If the agent has its own identity, disabling it in the identity provider cuts off every system that trusts that provider, without touching the human users the agent works for.

Make revocation fast and tested. Short token lifetimes bound how long a revoked agent keeps working. Conditional access policies, which Entra now extends to agent identities, let you block an agent automatically when it signs in from an unexpected place or runtime. And revocation belongs in your incident runbooks and stop drills, with the time it takes measured, alongside the gateway switches described in our kill switch article.

9. Log both identities, every time

Attribution is the reason to do all of this. Every audit record an agent produces, in your gateway, your applications and your identity provider, should show the human on whose behalf it acted, the agent identity and version, the chain of agents involved if there was one, the scopes it held and the action it took.

Delegated tokens make this straightforward, because both identities arrive in the token and can be copied into the log. Identity providers now record agent sign-ins and token issuance separately from users’, which gives you a second, independent record. Check that your downstream applications log the actor and not only the subject. A system that records only sub will show the human as having done everything the agent did, which is exactly the ambiguity you were trying to remove.

Part four: running it

10. Joiners, movers and leavers, for agents

Agents need the same lifecycle discipline as employees, and they are easier to forget. Require a human sponsor before an agent identity is created. Review its access on a fixed cycle, more often for agents that write to systems of record. When its sponsor changes role or leaves, reassign or retire it, so you do not accumulate orphaned agents with live access. Retire identities for agents that have not run in a defined period. Microsoft Entra ID Governance now covers agent identities and their sponsors, and other identity governance tools are adding similar support.

Watch the defaults, too. In October 2026 Microsoft announced (message center post MC1506733) that from November 4, users with no Entra role can create agent identity blueprints unless an administrator turns the setting off; the rollout completes in late November. Whether that suits you is a policy decision, but it should be a decision. Review who in your tenant can create agent identities and blueprints, and align it with your intake process for new AI uses.

11. Vendor and SaaS agents

Many of the agents with access to your systems are not yours. They are AI features in SaaS products, chat and sales tools, copilots and integrations that customers connect through OAuth, exactly as Drift was connected to Salesforce. Each of those connections is a standing grant of access to your data, held by someone else.

• Inventory the OAuth grants and connected apps in your core platforms, including which are AI agents or AI features, and who approved them.
• Restrict scopes to what the integration needs, and prefer read-only where it will do.
• Shorten refresh token lifetimes and require re-authorization periodically where the platform allows it.
• Restrict where tokens can be used from, by IP range or network, where the platform supports it.
• Remove grants that are unused, and monitor for bulk exports or unusual query patterns by connected apps.
• Ask vendors whether they support short-lived, sender-constrained tokens and identity-provider-managed authorization, and put token handling and breach notification in the contract.

12. An access review for agents

Run this review for each agent, or each class of agent, before it goes live and on its review cycle. Every “no” is a finding.

• Does the agent have its own identity, distinct from any person and from other agents?
• Does it have a named human sponsor who still works here?
• When it acts for a user, does it use delegated tokens that carry both identities and cannot exceed the user’s rights?
• Are its scopes limited to the tasks it performs, with elevated actions approved just in time?
• Are its tokens short-lived, and are refresh tokens avoided or tightly bounded?
• Is it free of secrets in its code, configuration, environment and prompts?
• Does every hop in its chain receive a token for its own audience, with no token passthrough?
• Do the systems it touches log the agent as well as the user?
• Can you revoke it in the identity provider, and have you measured how long that takes to take effect?
• Has its access been reviewed within its review period?

If you are starting this month

A realistic first month, aimed at the agents with the most access:

• Week 1: inventory agent access, including borrowed credentials, shared keys, service accounts used by agents and OAuth grants to vendor AI features. Rank by what each can reach.
• Week 2: give the top five agents their own identities with sponsors, move their secrets into a vault or workload identity, and cut token lifetimes.
• Week 3: switch user-facing agents to delegated tokens with the agent as actor, and confirm downstream logs record both identities.
• Week 4: run the access review above, revoke what fails it, test revocation as a stop drill, and set the tenant defaults for who may create agent identities.

Identity is unglamorous next to models and prompts, but it is where most of the damage from agent failures is either contained or multiplied. An agent with its own short-lived, narrowly scoped, revocable identity can still make mistakes. It just cannot make them with everyone’s keys.

Common questions