Skip to content
Start with Identity
machine-identity · Advanced

Securing AI Agent Identities: A Guide for Security Teams

By SWI Community Team · Updated 2026-11-05 · 11 min

Securing AI agent identities means giving every AI agent its own identity that is scoped to a task, delegated from the human it acts for, logged end to end, and revocable in seconds, instead of letting it borrow a user's session or a shared service account. The 2026 verdict: treat agents as non-human identities, mint short-lived audience-bound tokens per task, and enforce authorization at every tool call.

AI agents are the newest and most dynamic kind of non-human identity. An agent is not a person and not a traditional machine. It acts on behalf of a user, makes autonomous decisions, acquires permissions at runtime, calls external APIs, and can chain actions across dozens of systems in a single task. Some spawn sub-agents. That behavior breaks the assumptions our identity systems were built on.

The risk is not theoretical. In the Cloud Security Alliance's January 2026 survey, commissioned by Oasis Security, 92% of respondents were not confident their legacy IAM could manage AI and NHI risk, 79% rated their ability to prevent NHI attacks as low or moderate, and 78% had no formally adopted policy for creating or removing AI identities.

What an agent identity needs

An AI agent needs an identity with four properties that a service account does not provide:

  • Scoped. Least privilege per task. An agent that reads one calendar should not be able to read every calendar.
  • Delegated. The agent acts for a user, not as itself. The identity should carry both the agent and the human who authorized it (a delegation chain).
  • Auditable. Every action is traceable to the agent and the delegating user.
  • Revocable. A misbehaving agent can be killed instantly, not after a credential-rotation project.

Why service accounts fail

The instinct is to give each agent a service account. It fails for three reasons:

  1. Over-broad scope. Service accounts carry standing permissions, so a compromised or confused agent can reach far beyond its task.
  2. No delegation context. A shared service account erases the human in the loop, so the audit log cannot say who an action was really for.
  3. Slow revocation. Rotating a service-account credential is a project. Stopping a rogue agent needs to be a button.

The standards, and where they stand in November 2026

The emerging pattern borrows from OAuth: short-lived, narrowly scoped tokens minted per task, carrying both the agent's identity and the delegating user's, with authorization enforced at the tool and API boundary. Each piece now has a spec:

Problem Standard Status (2026-11-05)
Agent calling a tool server MCP authorization Revision 2026-07-28, stable
One token per server, no reuse RFC 8707 resource indicators, RFC 9728 metadata RFCs, required by MCP
Enterprise IdP decides which agent reaches which app ID-JAG / Cross App Access IETF draft-06, 31 October 2026
Carry user and workload context through internal calls Transaction Tokens IETF draft-11, IESG milestone December 2026
Workload-to-workload authentication WIMSE IETF drafts, no RFC yet
Swap a user token for a narrower agent token Token exchange, RFC 8693 RFC
Revoke sessions everywhere on a signal Shared Signals Framework Final, August 2025

Under the MCP 2026-07-28 authorization spec, servers "MUST validate that access tokens were issued specifically for them", "MUST NOT accept or transit any other tokens", and clients must send the resource parameter in both authorization and token requests. Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. ID-JAG, per its IETF datatracker entry, lets an app get a token for a third-party API through the IdP both already trust for SSO, replacing per-user consent with IdP policy. The Agent Identity Standards Map 2026 tracks every spec in more detail; see agentic identity for the concept.

Control checklist

  1. Inventory your agents. Register each one, with an owner, in your NHI program or an agent registry. Include coding assistants and local MCP servers on developer laptops.
  2. No static keys. Replace API keys with short-lived workload credentials (workload identity 101); vault anything that must stay static with secrets management and revoke, not just delete, any key that leaks.
  3. Audience-bind every token. One token per resource, rejected anywhere else. This blocks the confused-deputy pattern where an agent forwards a token to a server it was never meant for.
  4. Authorize at the tool call. Check each tool and API call, not just the initial login, with a policy engine (see best authorization tools) and just-in-time access for anything privileged.
  5. Log the delegation chain. Record agent, user, task and tool on every call.
  6. Gate high-impact actions. Require human approval or step-up authentication for payments, deletions and permission changes.
  7. Monitor and revoke. Watch for anomalous agent behavior with identity threat detection, and wire revocation to a single control.

Failure modes already seen in incidents

  • Leaked, never-revoked admin key. At LiteLLM, an Agent Platform admin key committed to a public repository in May was deleted but never revoked, and was used in October to publish a poisoned release. See secrets in repositories and CI and static API key abuse.
  • Third-party app tokens as the blast radius. In the Salesloft Drift and Gainsight cases, OAuth tokens held by connected apps were used to pull data from Salesforce tenants. Agents with connector tokens have the same shape; see refresh token abuse.
  • AI tools turned into secret hunters. The Nx npm compromise prompted installed AI command-line tools to search machines for more secrets.
  • A hijacked coding-assistant session. Mandiant described a SaaS provider intrusion where a developer accepted poisoned software recommended through an AI coding assistant session, leading to stolen GitHub OAuth tokens.
  • Instructions hidden in content. Agent instruction injection and scope escalation through delegation turn an agent's own permissions against you, which is why per-call authorization matters more than prompt filtering.

Vendors and 2026 ownership

Specialists in the best AI agent identity tools ranking include Aembit, SlashID, P0 Security, Corsha and Token Security. Consolidation reshaped the field in 2026: Astrix Security is now part of Cisco (closed June 29), Permiso Security part of Okta (closed August 26), Natoma part of Snowflake (closed June 3), Entro Security part of SailPoint (closed June 29), and Oasis Security part of Cyera. After an acquisition, confirm standalone availability, roadmap and contract terms before you sign. The Identity Consolidation Report 2026 tracks every deal.

The bottom line

Agents are identities, and they act faster and more broadly than any human user. The teams that stay ahead give agents scoped, delegated, auditable, and revocable identities from the start, inside a broader non-human identity program. For the wider picture, read the non-human identity security guide and our analysis on agentic AI identity.

Frequently asked questions

What is AI agent identity?
AI agent identity is the identity an autonomous AI agent uses to authenticate to systems and hold permissions. Unlike a static service account, a good agent identity is scoped to a task, delegated from the human it acts for, fully auditable, and instantly revocable. It belongs in the same inventory and lifecycle process as every other non-human identity.
Why can't AI agents just use service accounts?
Service accounts carry broad standing permissions, erase the human in the loop, and are slow to revoke. Agents need narrow, per-task access, a record of which user they acted for, and a kill switch. A shared service account fails all three, which is why agents amplify non-human identity risk rather than introducing a separate category of it.
What does good AI agent access control look like?
Short-lived, narrowly scoped credentials minted per task, carrying both the agent's identity and the delegating user's; least privilege enforced at the tool and API level; full logging of the delegation chain; and immediate revocation. MCP authorization, OAuth token exchange, ID-JAG and Transaction Tokens are the standards pushing the ecosystem in this direction.
How do you govern AI agents at scale?
Inventory every agent as a non-human identity, assign an owner, default to scoped short-lived tokens rather than standing credentials, log the full delegation chain on every action, and monitor for anomalous behavior. Treat agents as first-class identities within your broader NHI program, with creation and removal policies, which most organizations still lack.
Does MCP require OAuth for AI agents?
Authorization is optional in MCP, but when an HTTP-based MCP server uses it, the 2026-07-28 revision makes the server an OAuth 2.1 resource server. Clients must discover the authorization server through RFC 9728 metadata and send an RFC 8707 resource parameter, and servers must only accept tokens issued for them and must not pass other tokens through.
Which vendors focus on securing AI agent identities?
Independent specialists include Aembit for secretless workload and agent access, SlashID, P0 Security, Corsha and Token Security. Several others were bought in 2026: Astrix by Cisco, Permiso by Okta, Natoma by Snowflake, Entro by SailPoint and Oasis by Cyera. Check roadmap and contract terms after an acquisition before you commit.
Last reviewed By SWI Community TeamSuggest a correctionHow we research