AI Agent Identity And Access: Non-Human Identities And Tokens.

An AI agent needs its own identity so you can tell what it did, limit what it can reach and switch it off without touching anything else. OWASP puts the risk plainly in its Top 10 for Agentic Applications 2026: "Without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible." That risk is ASI03, Identity and Privilege Abuse.

For OWASP, an agent's identity is two things: its defined persona and "any authentication material (API keys, OAuth tokens, delegated user sessions) that represent it". Those credentials make the agent a non-human identity. If the agent borrows a person's login or a shared admin key, every action looks like that person or that key, and one stolen secret opens everything the agent can reach.

The standards world is catching up. In February 2026 the NIST National Cybersecurity Center of Excellence released a concept paper on software and AI agent identity and authorization. It asks how identity standards and best practices apply to agents, with a focus on identification and authorization. It is a concept paper for discussion, not a finished standard, so for now the practical guidance comes from OAuth and from OWASP.

An agent can act as a user or for a user, and the two are very different. OAuth Token Exchange, defined in RFC 8693, names both. With impersonation, principal A "is given all the rights that B has" and is "indistinguishable from B in that context". With delegation, A "still has its own identity separate from B", and "any actions taken are being taken by A representing B".

For agents, delegation is the safer pattern. The act claim lets a token say that delegation happened and who the acting party is, so logs can show an agent acting for a user rather than a user. OWASP lists the opposite pattern among its examples: un-scoped privilege inheritance, where a high-privilege manager passes its full access to a narrow worker, and identity sharing, where users invoke an agent's tools "as that identity".

Example (illustrative). At acme.com, a finance agent reads invoices for an analyst. With delegation, its token names the agent as the actor and the analyst as the subject, limited to an invoice-reading scope. The audit log then answers who asked and which agent acted. With a shared service key, the log shows only the key.

Treat agent credentials as short-lived, narrow and tied to one service. Each point below comes from a primary source.

• Short-lived and task-scoped. OWASP asks teams to "issue short-lived, narrowly scoped tokens per task" using per-agent identities. Its threats guide adds that agent-generated credentials should "expire after short timeframes".
• Restricted to one resource. RFC 9700, the OAuth security best current practice, says access tokens should be audience-restricted to a specific resource server and limited to the minimum scope required. The MCP authorization page requires servers to check the audience and the resource parameter. See securing MCP servers and tool access.
• Bound to the sender. RFC 9700 recommends sender-constraining tokens, for example with mutual TLS or DPoP, so a stolen token is harder to replay.
• Bound to intent. OWASP suggests binding OAuth tokens to a signed intent with subject, audience, purpose and session, and rejecting use that does not match.
• Re-checked per action. OWASP warns about time-of-check to time-of-use gaps: permissions "validated at the start of a workflow" may change before execution. It recommends per-action authorization with a central policy engine.

How do you revoke an agent?

Plan revocation before launch. RFC 7009 defines an endpoint where a client can tell the authorization server that a token is "no longer needed", and when a refresh token is revoked the server "SHOULD also invalidate all access tokens based on the same authorization grant". OWASP adds automated revocation "on idle or anomaly". Short lifetimes and a tested kill switch together limit how long a leaked token is useful.

OWASP lists the failure modes. Cached credentials can linger in memory, so a later user prompts the agent to reuse an earlier admin's secrets. A low-privilege agent can relay a request to a high-privilege one that trusts it, the classic confused deputy. An attacker can register a fake "Admin Helper" agent that others trust. Its NHI mapping also flags long-lived secrets, which "increase attacker dwell time".

Attackers also go straight for the secrets. MITRE ATLAS (data release v2026.09) lists AML.T0083 Credentials from AI Agent Configuration, because API keys, tokens and connection strings "are frequently stored in configuration files", and AML.T0098 AI Agent Tool Credential Harvesting, where an attacker uses access to an agent to pull credentials from the tools it can reach. Valid account abuse, AML.T0012, covers API keys that give access to AI services. Leaked keys are an old problem with a new target, see leaked credentials. The wider threat map is in top threats to AI agents.

One design to compare against: the Brandefense MCP server has users sign in with their own Brandefense account, and its page states that tools can only do what that account can do. It does not use a copied API token. This describes one approach, not a claim of compliance with any standard.

Use this checklist for every agent before it touches real systems.

Then put the rules in writing with the AI agent governance policy template, add human approval for high-impact steps using the human in the loop and least agency checklist, and log which identity did what, as described in monitoring and logging for AI agents. Apply least privilege to every one of them.