Analysis · By Sam Ortega (pen name) · 9 November 2026

AI agent identity: how Entra Agent ID, OAuth token exchange and SPIFFE compare

AI agent identity is not a single product choice. SPIFFE proves which workload is running, OAuth token exchange (RFC 8693) carries who an agent acts for, and Microsoft Entra Agent ID packages identity, credentials and governance in one directory. They answer different questions, and each leaves gaps that NIST's new agent identity tenets name.

We compare what each proves and where each falls short against NIST's design tenets. It is not like-for-like: SPIFFE is a set of open standards, token exchange an IETF protocol and Entra Agent ID a vendor product. We name no winner. All sources were checked on 4 November 2026.

What AI agent identity has to prove

On 27 October 2026, NIST published "Design Tenets for Agent Identity Management Systems" on its Cybersecurity Insights blog. The authors write that "we have proposed an initial set of ten design tenets". It is a blog post, not a standard (see our overview of NIST's ten design tenets). Three matter most here:

Tenet 01 (distinct agent identification): "Agents should have an identity, credential, and access management lifecycle distinct from human principals." See agent identity and non-human identity.
Tenet 02 (linking, delegation and attenuation): "as authority is delegated down to sub-agents or downstream services, scopes attenuate so that downstream entities can never claim more authority than the parent."
Tenet 04 (short-lived, dynamic and revocable authorization): "All access grants are Just-In-Time (JIT), time-bounded and audience-specific."

NIST's NCCoE summary of comments on its agent identity concept paper says "Almost everyone expressed the need for agents to have distinct, verifiable non-human identities". NIST concedes that "not all of these design tenets will be immediately fulfilled by the current state of standards and technology".

The tenets ask three questions: which workload, acting for whom, and with what authority for how long? Our assessment: none of the three approaches answers all three alone, so they are layers, not rivals.

SPIFFE: proving which workload is running

SPIFFE is "a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments". A workload gets a SPIFFE ID inside a trust domain and proves it with an SVID, either an X.509 certificate or a JWT. According to the SPIFFE concepts page, "your application need not co-deploy any authentication secrets with the workload", and keys are "short lived, rotated frequently and automatically".

That maps well to tenets 01 and 04. NIST's August 2026 post "Back to the Future: Why Agentic AI Needs a Strong Identity Foundation" says that for enterprise deployments, "protocols such as Secure Production Identity Framework for Everyone (SPIFFE) and OAuth 2.0 provide mechanisms that address agentic identification and authorization challenges." The NCCoE comment summary notes that SPIRE provides a reference implementation and describes its maturity as "relatively mature and operational for SPIFFE/SPIRE".

Where it stops. SPIFFE says which workload is calling, not which user it serves, so on its own it does not cover the linking in tenet 02 or the signed task mandates of tenet 06 (mandates and constraints). The concepts page also warns that tokens "are susceptible to replay attacks" and advises X.509-SVIDs "whenever possible". The newer WIT-SVID profile is marked "Stability: Incubating". Our assessment, not tested by any source we found: a process-level identity may not separate several agents that share one runtime.

Bridging work is under way: draft-ietf-oauth-spiffe-client-auth-03 (2 November 2026, a work-in-progress IETF draft) lets OAuth clients authenticate with SVIDs "without the need for client secrets".

OAuth token exchange: carrying who the agent acts for

RFC 8693, OAuth 2.0 Token Exchange (January 2020), defines how a client swaps one token for another at a security token service. It separates two models. In impersonation, "A is B within the context of the rights authorized by the token". In delegation, A keeps its own identity: "In a sense, A is an agent for B." Delegation fits tenet 01, because the agent never becomes the user.

The act (actor) claim can record a chain of actors, which resembles tenet 02's linking. But the RFC limits it: "Prior actors identified by any nested "act" claims are informational only and are not to be considered in access control decisions." For access control, only the token's top-level claims and the current actor count. RFC 8693 permits narrowing scope at each hop but does not require it.

MCP already builds on this. Its extensions overview lists Enterprise-Managed Authorization as Stable, and its specification has the MCP client send an RFC 8693 token exchange request to the enterprise identity provider to obtain an Identity Assertion JWT Authorization Grant (ID-JAG). See our MCP explainer.

Where it stops. Token exchange identifies nothing by itself, and chain-wide enforcement and attenuation depend on profiles and each token service's policy.

Entra Agent ID: identity, credentials and governance in one directory

Entra Agent ID gives agents their own directory objects; every claim here is from Microsoft Learn. The key concepts page says: "Unlike user accounts, agent identities don't have credentials of their own. They authenticate using tokens issued by their agent identity blueprint." Interactive agents act for a signed-in user via the on-behalf-of (OBO) flow; autonomous agents use their own identity and client credentials. The protocols page adds: "All agent auth flows involve multi-stage token exchanges where the agent identity blueprint impersonates the agent identity to perform operations." Microsoft Learn does not say this implements RFC 8693.

The blueprint is the unit of control. The blueprint page says "OAuth permissions granted to a agent identity blueprint are granted to all agent identities created from that blueprint." With inheritable permissions, "all agent identities in that organization receive those permissions automatically." The best practices page notes that credentials "live on the blueprint, not each instance." And per Microsoft, "Extending Microsoft Entra security features to agents requires Microsoft Agent 365."

Where it stops. Our assessment: blueprint-wide and inheritable permissions widen authority across agents, the opposite of tenet 02's attenuation, and one blueprint credential stands behind every agent built from it. It is tied to one identity provider, though Learn documents a sidecar and federation path for third-party agents.

Side by side: what each proves and where each stops

	SPIFFE / SPIRE	OAuth token exchange (RFC 8693)	Entra Agent ID
What it proves	Which workload is running, via a SPIFFE ID in a trust domain	Nothing by itself; it swaps a subject token, plus an optional actor token, for a new token	An agent identity object created from a blueprint
Credentials	Short-lived X.509 or JWT SVIDs; no stored secret	Whatever the token service accepts and issues	Held by the blueprint, not the agent
Delegation	None: it says which workload, not for whom	Delegation or impersonation; the `act` claim records the chain	OBO for interactive agents, client credentials for autonomous ones
Gaps against NIST tenets (our assessment)	No binding to the user (tenet 02) or to a signed task mandate (tenet 06); JWT-SVID replay risk	Prior actors informational only; narrowing not required (tenet 02)	Blueprint-wide and inheritable permissions widen rather than attenuate (tenet 02); security features require Microsoft Agent 365 (included in Microsoft 365 E7, an add-on for Microsoft E5/A5/Business Premium)

When identity binding fails: two MCP session bugs

Identity helps only if each session stays bound to the right principal. A GitHub advisory and a CVE record, both published on 3 November 2026, show the failure mode.

MCP C# SDK. GHSA-x863-g495-4cjc (High) says an authenticated principal lacking the NameIdentifier, sub and UPN claims "is represented by null, exactly like an unauthenticated principal". Another such user holding the victim's Mcp-Session-Id can then act in that session. Its structured fields list the 1.4.2 and 2.3.1 releases of 3 November as patched, though its description still says "Patched versions: none known".
SurrealDB. CVE-2026-121419 covers SurrealDB from 3.1.0 before 3.3.0, the range also listed in SurrealDB's own advisory GHSA-pgh9-49q4-hqcx (19 October). The record says the MCP fingerprint "uses the access method name instead of per-user identity for JWT/Bearer access", so attackers with "a valid low-privilege token for the same access method and a victim's mcp-session-id can hijack the session and execute MCP tools with the victim's roles and permissions."

In our assessment, both fit ASI03 Identity and Privilege Abuse in the OWASP Top 10 for Agentic Applications 2026, which warns: "Without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible." See our OWASP agentic analysis. None of the three identity approaches would by itself have prevented these bugs, because session binding is an implementation duty.

How the layers fit together

The IETF shows the layering most clearly. draft-ietf-wimse-aims-01, "AI Identity Management System" (2 November 2026), is a work-in-progress IETF draft, not a standard. It says "An agent participating in this framework MUST be assigned exactly one WIMSE identifier, which MAY be a SPIFFE ID." It layers the OAuth 2.0 family on top and is blunt about secrets: "The Large Language Model MUST NOT have access to an agent's credentials", and "Static API keys are an antipattern for agent identity."

The MCP authorization specification (2026-07-28) adds the audience rules. Servers "MUST validate that access tokens were issued specifically for them as the intended audience" and "MUST NOT accept or transit any other tokens." Its security considerations state: "The MCP server MUST NOT pass through the token it received from the MCP client." One caveat: "Authorization is OPTIONAL for MCP implementations." Our tool poisoning explainer covers a different MCP risk, in tool definitions.

Research is moving toward attenuation. AgentCap, a preprint (arXiv 2611.00729) accepted at a non-archival NeurIPS 2026 workshop, describes capability tokens where delegation preserves action and resource "while budget and lifetime can only be attenuated". Another preprint, "The Agent Clicks Approve" (arXiv 2610.15138), tested page text steering browser agents into approving a third party's access; without a defense, "the unauthorized action completed in all 73 attack runs". Our assessment: these are lab results, but they fit tenet 07's call to check authority outside the model (see our prompt injection Q&A).

What security leaders should do now

Our assessment, mapped to the NIST tenets and the AIMS draft:

Inventory which question each system answers. For every agent, record what proves the workload, what carries the user, and what limits authority.
Give agents their own identities (tenet 01). Stop handing agents user credentials or shared service accounts. NIST's August post: "Credential sharing is a bad idea in all contexts."
Prefer delegation to impersonation. With token exchange or OBO, make sure downstream services can tell the agent from the user, and do not base access decisions on nested act claims.
Make scopes shrink at every hop (tenet 02). Review Entra blueprint-level and inheritable permissions, and token service policies elsewhere, for places where authority widens. Apply least privilege per agent, not per blueprint.
Keep credentials short-lived and away from the model (tenet 04, AIMS). Replace static API keys with X.509-SVIDs or other short-lived credentials, kept out of the model's context.
Test session binding. Ask vendors and teams how MCP sessions are bound to principals, and patch the C# SDK and SurrealDB issues where they apply.
Enforce approvals at the service. Keep human-in-the-loop checks for high-impact actions outside the agent.

See also our agentic AI security landscape.

Frequently asked questions

What is AI agent identity?

AI agent identity is a distinct, verifiable identity for an AI agent, separate from the humans it works for, with its own credentials and access lifecycle. NIST's 27 October 2026 tenets say agents "should have an identity, credential, and access management lifecycle distinct from human principals."

Is SPIFFE enough to identify an AI agent?

SPIFFE can prove which workload is running, using short-lived SVIDs and no stored secret. It does not say which user or task the agent is acting for. The work-in-progress IETF draft draft-ietf-wimse-aims-01 allows a SPIFFE ID as an agent's identifier and layers OAuth on top.

What does OAuth token exchange add for AI agents?

RFC 8693 lets a token service swap one token for another and express delegation, where the agent acts for a user but keeps its own identity, recorded in the "act" claim. Its limit: nested "act" claims for prior actors "are informational only and are not to be considered in access control decisions."

Does Entra Agent ID work with non-Microsoft agents?

Microsoft Learn says yes: third-party agents can use the Microsoft Entra ID Auth SDK as a sidecar, so the agent never handles credentials directly, or workload identity federation for agents running outside Azure.

Should an AI agent use a user's credentials?

NIST's 27 August 2026 identity post says "Credential sharing is a bad idea in all contexts." The alternative is delegation: the agent keeps its own identity and receives a narrower token to act for the user.

Sources

This article is analysis. Bylines on AIAgentThreats are disclosed pen names of our editorial team. Spotted an error? Email info@aiagentthreats.com. See our Editorial Standards.