Agent Identity Explained: How AI Agents Get Credentials, Prove Who They Are and Get Switched Off

"Agent identity" gets used for three different problems. Interviewers notice when a candidate mixes them up, so separate them first.

1. Acting for a user: delegation

When an agent reads someone's calendar or files a ticket for them, it needs delegated authority: a token that carries both the user (subject) and the agent (actor), scoped to the intersection of the user's rights and the task, short-lived, and accepted only by the intended API. OAuth consent plus token exchange produces it. The MCP authorisation specification (2026-07-28 revision) builds on OAuth 2.1, requires resource indicators so tokens are bound to one server, and forbids passing tokens through to other services. IETF work in the WIMSE group (an "AI identity management" draft, November 2026) maps these pieces onto agent use cases; it is a draft, not a standard.

2. Proving itself to others: signatures

A website cannot trust a User-Agent header, and agents run from shared cloud addresses. Web Bot Auth has the operator sign requests with HTTP Message Signatures and publish keys in a well-known directory; Cloudflare's signed agents (August 2025) and Visa's and Mastercard's agent payment protocols (October 2025) use it. Between agents, the A2A protocol's Agent Cards can be signed, but a signature proves the card is intact, not who signed it, unless the key is anchored to the provider's domain or a registry you trust. In both cases the signature identifies the operator; a user's consent to an account action still needs the user's own authorisation.

3. Being governed: the fleet

Inside a company, the problem is hundreds of agents built by different teams. Each needs its own identity (never a shared service account), a human sponsor, a registry entry listing tools, data scopes and autonomy, and credentials that are only issued to registered agents. Platforms now model this directly: Microsoft's Entra Agent ID (generally available in 2026) adds sponsors and lifecycle workflows against orphaned agents, and AWS AgentCore provides agent identities and Cedar policies at its gateway. Kill switches belong at those chokepoints, outside the agents' own code.

A worked example

A support agent reads a customer's open tickets, drafts a refund, and checks the order on a partner's logistics agent. Three identities are in play. Toward the ticketing and billing APIs, it holds a delegated token naming the support employee and the agent, valid for this task only and accepted only by those APIs. Toward the partner, it presents its own client identity, scoped to the order-status skill, and verifies the partner agent against a pinned key. Inside the company, the registry records that this agent may read tickets, propose refunds under a limit, and query one partner; the gateway enforces those limits, and the refund itself waits for the employee's approval bound to the exact amount. If anything looks wrong, revoking the agent's identity at the identity provider and gateway stops all three relationships at once, without touching the employee's own access.

Common confusions interviewers probe

• "The agent is authenticated, so it is authorised." Authentication says who; each action still needs a decision.
• "The card is signed, so it is the partner." Only with a trust anchor for the key.
• "A verified agent can place the order." Only with the user's authorisation for that account.
• "We log everything the shared agent account does." Then you cannot tell which agent did it, or revoke one.

Go deeper

Delegation: delegated tokens for agents and revoking agent access. Proof to others: how websites verify AI agents and A2A protocol security. Governance: governing a fleet of AI agents and agent and MCP gateways.