Agent Identity Management System (AIMS)

Sources#

• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers
• AI Agent Authentication and Authorization
• Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems
• MCP Specification Changelog — 2026-07-28
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts

Summary#

AIMS is the conceptual model at the center of IETF Internet-Draft draft-klrc-aiagent-auth-03 (Kasselman/Lombardo/Rosomakho/Campbell/Steele/Parecki — Defakto/AWS/Zscaler/Ping/OpenAI/Okta; July 2026). Its thesis: an AI agent is a workload, and the identity, authentication, and authorization problems it raises are not new — they should be solved by composing existing, widely-deployed standards (WIMSE/SPIFFE workload identity, the OAuth 2.0 family, OpenID Shared Signals) rather than inventing agent-specific protocols. AIMS is "the set of functions required to establish, maintain, and evaluate the identity and permissions of an agent workload" — a conceptual model, not a product, protocol, or single architecture; it may live in one component or be spread across identity providers, provisioning services, authorization servers, policy engines, and runtime enforcement points.

Evidence caveat (attach everywhere): this is a standards-track proposal — an individual submission, Informational, with no IETF Working Group consensus yet (it profiles specs from the IETF, CNCF, and OpenID Foundation but is not itself ratified). Treat every MUST/SHOULD as the authors' recommendation, not an adopted standard. Its evidence: tier is practitioner-opinion.

Why it matters to this vault: the agent-security cluster was sourced almost entirely to one vendor ebook (Zero Trust for AI Agents). AIMS is the first standards-track, multi-vendor primary source on agent identity, and it directly targets two long-standing open questions — sub-agent credentialing (Agent Identity and Authentication) and the agent-to-agent trust protocol layer (Agent-Native Infrastructure).

Agents are workloads (the framing move)#

An Agent is a workload that iteratively interacts with an LLM and a set of Tools/Services/Resources until a terminating condition is reached (Figure 1 of the draft). Because it is a workload, it needs an identifier and credentials so it can be authenticated by the parties it touches — and, if it acts for a user or system, that principal must delegate authority to it, with the delegated context preserved into authorization decisions and audit trails. This reframing is what lets the whole problem be solved with workload-identity and delegated-authorization standards instead of new machinery.

Notably, "a Tool endpoint may itself be implemented by another AI agent" — so agent-to-agent is just the workload-to-workload case, and the same primitives cover it.

The layered stack (Figure 2)#

AIMS is a logical stack where higher layers depend on guarantees from lower ones, with two cross-cutting columns:

Policy | [ Monitoring, Observability & Remediation ] | Compliance
 | [ Authorization ] |
 | [ Authentication ] |
 | [ Provisioning ] |
 | [ Credentials ] |
 | [ Identifier ] |

• Identifier → Credentials → Provisioning → Authentication → Authorization → Monitoring is the dependency chain.
• Policy (§12) and Compliance (§13) span all layers but are declared out of scope — deployment-, regulatory-, and jurisdiction-specific, and explicitly not a standardization target. Policy MAY be any versioned, reviewable "policy-as-code" format.

Identifier: WIMSE, with SPIFFE as the deployed instance#

Each agent MUST have exactly one WIMSE identifier ([WIMSE-ID]) — a URI uniquely identifying a workload within a trust domain, stable for the identity's lifetime (authorization, delegation, and audit all key off it). It MAY be a SPIFFE ID (spiffe://<trust-domain>/<path>), which the draft calls the "widely deployed and operationally mature instance of the WIMSE identifier model." This is the concrete answer to "what is a per-agent identity" — a workload-identity URI, not an ad-hoc label.

Credentials + provisioning + posture assessment#

• Credentials cryptographically bind the identifier to the agent. WIMSE defines the WIT (Workload Identity Token) and WIC (X.509 Workload Identity Certificate); SPIFFE defines X.509-SVID, WIT-SVID, and JWT-SVID. They SHOULD be short-lived with an explicit expiry. Static API keys are named an antipattern — bearer artifacts, not cryptographically bound, long-lived, hard to rotate.
• Hardware-backed key storage (TPM, enclave, platform security module) is optional — "not required for interoperability." (This is the sharpest divergence from the ebook — see comparison below.)
• Provisioning is runtime issuance/renewal/rotation in two phases (initial provisioning; automatic rotation before expiry). Short-lived credentials are offered as an alternative to explicit revocation: you don't revoke, you just don't renew.
• Posture assessment happens at each provisioning/rotation event — the draft (v-02 onward) folded the old "attestation" section into provisioning and renamed it "posture management." It evaluates deployment-specific signals (hardware/TEE evidence, software-integrity measurements, supply-chain provenance, orchestration metadata, workload placement, operator assertions) to decide whether a credential issues, which identifier binds, what type, what attributes, and how long it lives. A single signal may suffice; higher-risk deployments require several. No particular attestation mechanism is required.
• Credential exchange for legacy/proprietary environments incompatible with the primary credential: OAuth 2.0 Token Exchange, Transaction Tokens, or Workload Identity Federation mint a targeted secondary credential from the primary one.

The rule: LLMs never hold credentials#

"The Large Language Model MUST NOT have access to an agent's credentials or to credentials that may be needed to access tools and services." Rationale, stated verbatim: to prevent the LLM from using, exposing, or being manipulated via prompt injection into disclosing the credentials. This is the identity-layer sibling of the out-of-band reference-monitor doctrine — the secret sits outside the manipulable model, and the agent (the workload), not the model, wields it. (Added in -03 as [issue #127].)

Authentication: transport vs application layer#

Per the WIMSE architecture, auth can happen at either layer, and many deployments use both:

• Transport-layer — mTLS, both endpoints presenting X.509 credentials; paired with short-lived SPIFFE/WIMSE identity it gives strong channel binding. Well-suited to service meshes (Istio, LinkerD). Limitation: intermediaries (proxies, API gateways, service meshes, load balancers, protocol translators) terminate and re-establish TLS, breaking end-to-end transport identity — and serverless/multi-tenant-edge/cross-domain topologies obscure transport identity.
• Application-layer — survives intermediaries by binding identity above the transport. Two WIMSE mechanisms:
• WIMSE Proof Tokens (WPTs) — a signed JWT proving possession of the WIT's private key, bound to a specific message context (e.g. an HTTP request), with claims aud/exp/jti/wth (hash of the WIT). Proof-of-possession, not bearer. Protocol-agnostic core (can bind Kafka, gRPC, non-HTTP).
• HTTP Message Signatures ([WIMSE-HTTPSIG] over RFC 9421) — combine the WIT with a signature over request components (method, request-target, content digest, the WIT itself), giving proof-of-possession + message integrity end-to-end.
• Limitation: no inherent channel binding, so implementations must defend against relay/replay via short lifetimes, audience restriction, nonces, and request binding.

Authorization: OAuth 2.0 as the delegation spine#

• Agent Mission (§10.1) — an agent receives a Mission (a natural-language task) from a user, system, or another agent; translating the mission into concrete resource/authorization requirements is a planning step, out of scope (the draft cites Karl McGuinness's "Mission Shaping Problem"). This is where the wiki's agent-native "figure out the details" handshake meets a concrete auth model.
• OAuth as delegation — the agent acts as an OAuth client; access tokens carry the agent identity as client_id and the delegated principal as sub. Flows: Authorization Code Grant when a user delegates (with phishing-resistant user auth like passkeys, and the agent authenticating to the AS with its Section-7 credentials, never static client secrets); Client Credentials / JWT Authorization Grant when the agent acts on its own behalf; and agents themselves can be OAuth protected resources invoked by a system or another agent.
• Transaction Tokens (§10.5) — the blast-radius control for internal call chains. A broad access token passed between microservices is a theft/replay/lateral-move risk (an attacker who finds it in a log or crash dump can invoke a different transaction). Instead, exchange it for a transaction token: a downscoped token bound to one specific transaction (enriched with caller context, transaction context, a unique ID) that cannot be reused for another transaction or with modified details. Short-lived. A transaction token MAY be exchanged (OAuth Token Exchange) for an access token to call the next service.
• Cross-domain chaining (§10.6) — when resources sit behind different authorization servers, the agent uses OAuth Identity and Authorization Chaining Across Domains (or the Identity Assertion JWT Grant / Transaction Token Grant profiles): exchange the current token for a JWT authorization grant, present it to obtain an access token for the target domain. This is the delegation-chain mechanism for ephemeral spawned agents.
• Human in the loop (§10.7) — for high-risk actions the AS SHOULD decline or step up via CIBA (out-of-band approval on the user's device). Crucially, local UI confirmation is not authorization — the draft aligns with MCP's user-solicitation pattern but insists the agent MUST NOT treat a local approval as sufficient; it must be bound to a verifiable AS-issued grant. (Noted gap: CIBA only models client-initiated flows and doesn't map cleanly to mid-execution confirmation — exactly the gap the OpenID AuthZEN AARP draft is designed to close by generalizing CIBA into a policy-level prerequisite/approval pattern; see below.)
• Tool-to-service (§10.8) — tools use Token Exchange / cross-domain chaining to reach downstream resources. Anti-pattern: a tool forwarding the access token it received from the agent (invites theft + lateral attacks) — the same containment logic as transaction tokens.
• Discovery (§10.10) — in dynamic/ephemeral deployments, OAuth Authorization Server Metadata, Protected Resource Metadata, and Client ID Metadata Documents let agents bind to the right issuer/audience/flow at runtime without static config.

The delegation spine, measured in a deployed ecosystem (2026-05)#

Every mechanism above is a recommendation about a shape nobody had counted. Zhou et al.'s census of remote MCP servers (A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, arXiv 2605.22333, empirical, no COI — full treatment on Remote MCP Authentication in the Wild) is the first measurement of that shape in the wild, and it is worth attaching to three of these bullets specifically.

• The multi-hop chain §10.6 models is the majority case, not an edge case. Of 119 end-to-end-testable OAuth-enabled MCP servers, 81 (68.07%) act as an OAuth resource server toward the client while simultaneously acting as an OAuth client toward an upstream service — exactly the cross-domain chain AIMS addresses with token exchange and identity chaining.
• The anti-pattern §10.8 names has a measured cousin, and it is the dominant delegated flaw. AIMS forbids a tool forwarding the token it received; the deployed failure is subtler and worse — 40 of those 81 servers (49.4%) serialize downstream routing state (typically a redirect_uri) into the client-visible upstream state parameter, and where that nested value is not integrity-protected, an attacker rewrites it and the MCP server itself forwards the victim's authorization code to an attacker endpoint. The paper's prescribed fix is precisely the AIMS-shaped one: keep a server-side map from an opaque state to the routing context, so there is nothing client-side to tamper with.
• CIMD (§10.10) is being adopted for the reason this measurement gives. 1,118 of 2,428 (46.0%) OAuth-enabled MCP servers still advertise a DCR registration_endpoint, and 114 of 119 tested (95.8%) accept an arbitrary attacker-supplied redirect_uri on it — seven of the study's nine CVEs. The convergence noted below (an independent protocol reaching for CIMD without coordinating with this draft) now has a failure mode behind it rather than a preference.

What it costs the plural-governance question. The Open Questions below record MCP as a fourth arbiter — a de-facto layer shipping requirements into implementations while IETF and OpenID deliberate, with the possibility that de-facto settles the primitives before ratification does. This census is the counter-datum: the shipping layer's requirements are not being implemented either. The population measured predates revision 2026-07-28 but postdates 2025-11-25, which already preferred CIMD and already required PKCE of clients. So "who governs" is joined by a prior question none of the three bodies answers — what makes any of them binding on a deployment? — and on the current evidence the answer for remote MCP is nothing.

The OpenID AuthZEN drafts (AARP + COAZ): standardizing the authorization slice#

Where the IETF draft-klrc-aiagent-auth stack above standardizes identity, credentials, and delegated authority, the OpenID Foundation's AuthZEN Working Group is standardizing the authorization decision itself — and on 2026-06-15 (timed to Identiverse) it approved two documents as official Working Group Drafts: AARP and COAZ. Both are proposed drafts, not ratified standards — practitioner-opinion, and where they touch the same ground as the vault's empirical per-call-authz systems (ScopeGate, aiAuthZ) they are weighted below the measured work. They build on the AuthZEN Authorization API 1.0 and its Subject-Action-Resource-Context (SARC) decision interface — the interoperable "can this action happen now?" endpoint those two research systems each implement ad hoc.

• AARP (Access Request and Approval Profile). Answers a question allow/deny authorization APIs historically couldn't: what is required before policy can authorize an action? When policy can't yet decide — an approval, consent, delegated authority, attestation, or risk assessment must first be satisfied — AARP defines interoperable patterns for requesting, tracking, satisfying, and re-evaluating those prerequisites, so applications, authorization systems, governance platforms, and agents coordinate while policy remains the decision-maker, evaluated at enforcement. The worked example is exactly this vault's vendor-payment case: an agent attempting an over-threshold transfer gets not a bare deny but a "not yet — here is what is required" signal, records a handle to the pending request, hands off or resumes later, and proceeds only after a manager approves and policy is re-evaluated. AARP explicitly generalizes CIBA: "this is to authorization prerequisites what CIBA is to authentication approval" — the same standardized, asynchronous, out-of-band interaction, but generalized to policy and satisfiable by a person or an automated governance system, not confined to CIBA's client-initiated authentication-approval shape. This is the direct proposed answer to AIMS's own acknowledged mid-execution-HITL gap (§10.7 above; Open Questions below).
• COAZ (AuthZEN Profile for MCP Tool Authorization). A profile standardizing the mapping of MCP tool invocations into the AuthZEN SARC structure via metadata, so different enforcement points — API or AI gateways, service meshes, downstream systems — know how to authorize a tool call against a compatible PDP. It lets an MCP tool expose the authorization checks required to call it, bringing a per-invocation authorization control to agentic workflows — the standards-track form of the action-layer defense the MCP Tool Poisoning and per-call-authz pages argue for. Industry review spans Axiomatics, Cerbos, Okta, SailPoint, Indykite, Keycard, and C1.

The clean division of labor: AIMS (IETF) says who the agent/workload is and how authority delegates; the AuthZEN Authorization API + COAZ say whether this concrete call is allowed; AARP says what must first be true before that decision can even be reached. Together they place the agent-auth problem across two standards bodies — concrete evidence the governance layer is plural and moving, not stalled (see the sharpened Open Questions).

The first measured attack-resistance for an AIMS-shaped composition (2026-08)#

The last open question on this page — AIMS is a design document with no measured attack-resistance — gets its first partial answer from outside the draft. Dantuluri & Sundi (VotalAI; arXiv 2609.00267, 2026-08-31, Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems, empirical) build and adversarially attack an authorization broker / PEP composed of exactly the primitives this page names: a capability token rooted at an OIDC identity (R1 here, §10 above), a SPIFFE-style SVID per agent (the WIMSE identifier), an issuer-mediated token exchange at every delegation hop (RFC 8693 — the transaction-token move generalized), short lifetimes, revocation that propagates down the chain, and a tamper-evident log. It is not an AIMS implementation: the token format is macaroon-style HMAC caveats rather than WIMSE WPTs or HTTP Message Signatures, and the evaluated artifact is a ~160-line standard-library Python demonstrator that is explicitly not released. But it is the same shape — and it is the first time anything of that shape has been attacked and counted.

COI, to carry wherever these numbers are cited. Both authors are at VotalAI; §8 is a two-page architecture description of the company's commercial product, LLM Shield, and the abstract closes by advertising it. The paper keeps the seam explicit — "the reference implementation evaluated in this paper is a separate, minimal demonstrator built on public primitives and is not released" — so no LLM Shield code was measured, and every §8 production figure (pre-call content inspection on the order of 2 ms, a full guardrail-model check on the order of 190 ms, an 8B fine-tuned guardrail model beside NVIDIA's Nemotron 3.5, a red-team portal drawing on 100+ manipulation strategies) is a vendor claim, not evidence.

The evaluation standard: the untrusted-model property#

The framing move is the one worth keeping even if every number is discounted. Because the model is the most attackable component, it must be treated as untrusted, and the correct standard is adversarial:

A multi-agent system is well-governed only if a fully prompt-injected agent — one whose model output is entirely attacker-controlled — still cannot exceed the authority explicitly delegated to it, cannot use a stolen credential off its own workload, and leaves an attributable audit trail. "Security that depends on the model not being hijacked is not security."

This is the identity-layer statement of the doctrine Out-of-Band Prompt-Injection Defense carries for reference monitors and Capability Gating Is Not Authorization carries for per-call policy, and it is the same premise behind this page's own LLMs-never-hold-credentials rule (§8 of the draft) — stated here as an evaluation criterion rather than a design rule, which is what makes it testable.

Four threats, eight requirements#

The threat model names four adversaries under full model compromise: T1 confused deputy (authorized agent, unintended use), T2 token theft / replay, T3 prompt-injection privilege escalation, T4 compromised sub-agent / over-broad scope. From five goals it derives eight requirements — R1 delegation-chain provenance traceable to a human grant, R2 narrow-only attenuation at each hop, R3 sender-constrained credentials bound to a workload identity, R4 short-lived issuance, R5 key/secret rotation, R6 revocation propagation to PEPs, R7 complete tamper-evident audit, R8 model-independent enforcement at infrastructure PEPs. R1–R7 map almost cell-for-cell onto this page's stack (identifier → credentials → provisioning → authorization → monitoring); R8 is the one AIMS states as an architectural rule rather than a requirement, and the paper makes it load-bearing: "it is what makes the untrusted-model property achievable at all. If the model gates access, a hijacked model grants access."

The gap: what was executed, what was read#

Read the framework result with its method attached, because the methods differ per row and the paper says so:

• LangGraph 1.2.10 — executed. A real compiled StateGraph with a scripted agent node (deliberately isolating the authorization layer from model behaviour) driven against the tool node. Vulnerable to all four threats; provides none of R1–R8.
• CrewAI 1.15.13, AutoGen 0.7.5 — capability inspection of the tool-execution base classes, not execution. Same result: vulnerable to all four, none of R1–R8.
• MCP authorization, rev. 2026-07-28 — specification analysis (the same revision this vault's ledger tracks on MCP and Computer Use). The one partial: mandatory Resource Indicators (RFC 8707) audience-restrict each token to a server (partial T2/R3), the resource-server model validates tokens outside the client's model (R8), and OAuth supplies short-lived tokens (R4) and revocation (R6) — but no per-hop attenuation (R2) and no cross-agent delegation provenance (R1) for agent-to-agent chains.

The authors' own gloss is the honest one: "none claims to be an authorization system, which is precisely the point — the governance layer is simply absent."

The standards table is analytical, and it is this page's thesis restated as a gap#

Table 3 maps nine primitives (OIDC, OAuth 2.1, Token Exchange 8693, SPIFFE/SPIRE, mTLS 8705, DPoP 9449, Macaroons, Biscuit, MCP authz) against R1–R8. The paper labels it plainly — "an analytical result: it reflects our reading of each standard's specification rather than measured data, and we invite scrutiny of individual cells" — so it is the weakest evidence in the paper and should be cited as the authors' reading, not as a finding. What it concludes is nonetheless the sharpest thing said about this page's central claim. AIMS argues the agent-auth problem should be solved by composing existing standards; this paper agrees the primitives are mature and then states the missing half:

There is today no standard profile that mints, at each delegation hop, a capability token that is simultaneously attenuated (R2), bound to the sub-agent's workload identity (R3), short-lived (R4), and enforced at a PEP outside the model (R8).

Not a contradiction of AIMS — the same claim from the other side. AIMS proposes the composition; this paper measures that nobody has shipped it, and that no single standard reaches more than a fraction of the set on its own (R1/R2 live in token exchange and capability tokens; R3/R5 in SPIFFE/mTLS/DPoP; R8 is a deployment property none of them mandates).

The broker, and its numbers#

The broker sits between agents and tools: each agent authenticates with an SVID; the human grant is an OIDC-rooted capability token; each delegation hop is an issuer-mediated exchange minting a token attenuated to the sub-task (cap₂ ⊆ cap₁), bound to the receiving SVID, and short-lived, where only the workload a token is bound to may delegate it onward; every tool call is routed through the broker, which checks signature, revocation, sender-constraint, and caveats — no model call — and appends the chain to a tamper-evident log. Caveats are append-only, so authority can only narrow. Results, all against the demonstrator:

• Defense effectiveness (executed). The default runtime — one broad bearer credential passed unchanged to sub-agents and tools, with the model's own reasoning deciding whether an action is permitted — fails all four threats; the broker blocks all four.
• Adversarial robustness (executed) — two experiments, not one. The abstract's "11 direct attacks … 0 of 200,000" conflates them. First, 11 hand-built attacks on the broker's own design (forge from scratch, forge with a guessed secret, strip caveats, widen a caveat, re-bind a stolen token, replay as-is, malformed-caveat fail-closed, widen scope via exchange, delegate a token one does not hold, use a child of a revoked token, use an expired token) — all 11 resisted. Second, a separate fuzz with random and mutated tokens: 0 of 200,000 accepted.
• Blast radius (executed). Over 2,000 randomized delegation scenarios in a synthetic environment of 8,100 tool/resource actions, a compromised sub-agent reaches all 8,100 in every scenario under bearer delegation and a mean of 1.5 under the broker — exactly its delegated sub-task. The authors explicitly refuse the ratio as the headline: the claim is the invariant — defended reach is bounded by the task and independent of environment size, undefended reach equals the environment and grows without bound as a deployment scales. Carried on Blast Radius (Agentic).
• Overhead (executed). ~2.6 µs per authorization (~3.9×10⁵ decisions/s) and ~5.4 µs per token exchange, each measured over 2×10⁵ calls on a laptop — negligible against model inference in hundreds of milliseconds. The paper's own conclusion is that the dominant cost of this architecture is operational (running a broker and an identity plane), not latency.

The boundary test that succeeds by design — and what it costs this page's hardware stance#

A twelfth test is reported as a success for the attacker, deliberately: "if an attacker can present the victim's SVID, a stolen token works — confirming that sender-constraining reduces to the strength of workload-identity attestation (mTLS/SPIFFE)." The authors log it as a stated assumption rather than a flaw, and it is the load-bearing assumption of the whole design.

It also lands squarely on the one substantive divergence tabled above. AIMS makes hardware-backed key storage optional, "not required for interoperability," and replaces remote attestation with deployment-specific posture assessment; the Anthropic ebook drives to hardware attestation as the Advanced target. This result does not adjudicate that — it is a demonstrator, and the divergence is about interoperability versus target state — but it does say something neither document does: whatever attestation strength a deployment picks is the strength of its entire sender-constrained credential layer, because R3 is defined by it. AIMS's "you don't need hardware attestation" is an argument about sufficiency of posture signals; this is a statement that the property degrades continuously with whatever signal you chose. The field instance already sits on Agent Identity and Authentication: in the July 2026 Hugging Face chain the agent authenticated as the node and harvested an EdDSA JWT signing key, then minted correctly-signed identities on demand — the twelfth test passing in production.

Where it does not reach#

Three limits the authors state, and one this vault adds. Theirs: the broker enforces an abstract action model (tool/resource tuples), so a production PEP must map real tool invocations onto it faithfully; the broker is not integrated into any of the evaluated frameworks; and there is no live model in the loop anywhere in the evaluation (the LangGraph agent node is scripted). This vault's: unlike ScopeGate (Apache-2.0 artifact at a named commit) and aiAuthZ (released code and transcripts), nothing measured here was released, so the empirical tier covers systematic measurement, not reproducibility — weigh it below those two on that axis, while noting its multi-hop delegation measurements have no competitor in this corpus.

Observability and remediation as a security control (§11)#

Monitoring is "a security control, not solely an operational feature." Participants MAY subscribe to the OpenID Shared Signals Framework (SSF) with CAEP or RISC to receive signals (session revoked, risk elevated, token replay suspected, subject disabled) and MUST remediate promptly — discard cached tokens, re-acquire with tighter constraints, reduce privileges, re-run policy — and MUST NOT keep using authorization invalidated by a revocation. Deployments MUST keep tamper-evident audit logs (authenticated agent ID, delegated subject, resource, action + decision, timestamp/correlation ID, posture/risk state, remediation events) and SHOULD correlate across agents/tools/LLMs to detect replay, confused-deputy, privilege escalation, and anomalous sequences. Stable verifiable identifiers everywhere are what make "which entity did what, using which authorization context, and why access changed" reconstructable end-to-end.

Comparison: AIMS vs the Anthropic Zero-Trust ebook#

Both target per-agent identity for agentic Zero Trust and converge on the core: static API keys are unacceptable, credentials must be short-lived and cryptographically bound, per-agent identity is the keystone, least privilege / minimal scopes, and observability-as-security-control with tamper-evident audit. But they diverge on primitives and authority:

Dimension	Zero Trust for AI Agents (Anthropic ebook, vendor)	AIMS (IETF draft, multi-vendor standards)
Identity primitive	Cryptographic IDs → X.509 certs → hardware-backed HSM/TPM identity + remote attestation (tiered target state)	WIMSE/SPIFFE URI as the identifier (X.509-SVID or JWT/WIT-SVID)
Hardware attestation	The Advanced-tier target for internet-reachable production	Optional; "not required for interoperability" — one posture signal among many
Attestation model	Remote hardware attestation	"Posture assessment" at each issuance/rotation; deployment-specific signals (folds attestation into provisioning)
Authentication	Short-lived OAuth tokens → mTLS → hardware-bound credentials	Same, plus application-layer (WPT, HTTP Message Signatures) for when transport identity breaks
Delegation / sub-agents	Sub-agents inherit "up to the same permissions as the parent" (left largely open)	OAuth Token Exchange + Transaction Tokens + cross-domain chaining — downscoped, transaction-bound, not raw inheritance
LLM & credentials	Not stated as a rule	Explicit MUST NOT — the LLM never holds credentials
Authority	Single vendor; Claude Code as reference implementation	Six vendors, standards-track — but an individual submission, no WG consensus

The productive tension: the ebook drives toward hardware attestation as the aspirational endpoint; AIMS argues you can get the security property from short-lived, posture-assessed, delegated credentials without requiring hardware attestation on every ephemeral workload — and adds the delegation-chain machinery (transaction tokens, identity chaining) the ebook lacks. Neither is a ratified standard: the ebook is vendor practitioner-opinion, AIMS is standards-draft practitioner-opinion.

Connections#

• Agent Identity and Authentication — the primary sibling; AIMS is the second (standards-track, multi-vendor) source on the same keystone control, and supplies the concrete identifier/credential/delegation primitives the ebook left at the tier-label level

• Zero Trust for AI Agents — the vault's other agent-security framework (hub); AIMS composes existing standards where the ebook prescribes a tiered maturity model — convergences and divergences tabled above

• Least Agency — AIMS enforces least agency through OAuth minimal scopes, audience restriction, and transaction-token downscoping (a token bound to one transaction that can't be reused) — the standards-layer instantiation of "restrict what each tool can do"

• Blast Radius (Agentic) — transaction tokens, the no-token-forwarding anti-pattern, and short-lived non-revoked credentials are all blast-radius containment for the internal microservice call chain (limiting token theft, replay, and lateral movement)

• Agent-Native Infrastructure — AIMS is a candidate answer to that page's open protocol-layer question: the trust/identity/accountability primitives for agent-to-agent negotiation, drawn from IETF/CNCF/OpenID standards (though governance is unsettled)

• Out-of-Band Prompt-Injection Defense — same doctrine at the identity layer: keep the secret and the authorization decision outside the manipulable LLM (LLMs-never-hold-credentials; the AS, not local UI, authorizes) — the credential/authorization twin of the deterministic reference monitor

• Off-Host, Identity-Bound Authorization — the standards layer vs a concrete shipped system: AIMS standardizes workload identity (WIMSE/SPIFFE) and delegated authority (OAuth token-exchange, transaction tokens); aiAuthZ (Kodathala, arXiv 2607.05518) is a running gateway that authenticates the human user per message (per-message HMAC + nonce) and could consume AIMS-issued identities as the service/principal inputs to its role + argument policy — composable at different granularities (AIMS binds identity to a workload/session/token; aiAuthZ to each user message), and empirical where AIMS is design-only. A single-author preprint, so weighted below this multi-vendor standards work on questions of adoption

• Capability Gating Is Not Authorization — ScopeGate is the empirical research counterpart to AuthZEN/COAZ's proposed-standard authorize-each-call: both put a deterministic allow/deny decision over a concrete (tool, args) call, but ScopeGate is a measured in-framework PDP/PEP while AuthZEN's Authorization API + COAZ standardize the SARC decision interface and the MCP→SARC mapping (a WG draft, weighted below the measured system). AARP adds the "not yet — here is the prerequisite" shape a pure allow/deny gate like ScopeGate lacks

• MCP Tool Poisoning — COAZ standardizes putting an authorization decision at the MCP tool-invocation point, the standards-track form of the action-layer defense that page argues must sit downstream of (defeated) detection

• Agentic Prompt Injection — the LLM-never-holds-credentials rule is explicitly a prompt-injection defense: a hijacked model can't disclose a secret it never had

• MCP and Computer Use — AIMS aligns its human-in-the-loop model with MCP's user-solicitation pattern, and treats MCP tools as the resource surface OAuth authorizes; but insists local approval is not authorization

• Hermes Agent — a shipped contrast: Hermes secures multi-user agent access with an ad-hoc DM-pairing + allowlist (human-auth) plus container-as-boundary, where AIMS proposes standards-based workload identity + delegated authorization; the gap between practice and the proposed standard

• Remote MCP Authentication in the Wild — the first population-scale measurement of the delegation shape this page specifies: 68.07% of tested MCP OAuth deployments run the two-hop resource-server/OAuth-client chain of §10.6, half of those pass routing context in an unprotected state (the failure §10.8's anti-pattern gestures at), and 46.0% of OAuth-enabled servers still advertise the DCR endpoint §10.10's CIMD replaces. It is also the counter-datum to the plural-governance question: the de-facto arbiter's own requirements are not being implemented

• OpenAI — Nick Steele (OpenAI) is a co-author, alongside Defakto, AWS, Zscaler, Ping Identity, and Okta

• Guarantees That Degrade at Deployment: Action-Space Soundness, Admissibility Without Effect, and a Vendor-Coupled Security Framework — the AIMS-vs-ebook comparison above is the load-bearing evidence for that synthesis's vendor-neutrality verdict on Zero Trust for AI Agents: it is the one substantive target-state divergence (the ebook drives to hardware attestation as the Advanced endpoint, AIMS makes hardware-backed key storage optional and "not required for interoperability"), and everything else in that framework's identity domain converges — two practitioner-opinion documents, neither outranking the other

• The Price of Mixing Agents, and the Principal Nobody Counted — the limit of a permission-shaped governance layer, stated as a case. This draft covers agent-to-agent by collapsing it into workload-to-workload, and every primitive in the stack answers may this call happen; an agent that abandons its own principal's directive to settle a peer conflict makes no call, touches no resource, and generates no audit event. Not a scope gap the standards can close by adding coverage — the wrong shape of instrument for the failure

Open Questions#

• No WG consensus. This is an individual submission profiling other still-in-progress drafts (WIMSE identifier/creds/WPT/HTTP-sig, OAuth transaction-tokens, identity-chaining are all Internet-Drafts too). Which of these primitives actually reach RFC, and does the composition survive WG review? "Who governs the agent-auth protocol layer" (Agent-Native Infrastructure) is proposed (IETF/CNCF/OpenID) but not settled. Sharpened by the OpenID AuthZEN drafts: the authorization slice is being standardized in a different body from AIMS's IETF identity/delegation work — the OpenID Foundation's AuthZEN WG approved AARP + COAZ as Working Group Drafts (a step past AIMS's individual-submission status, though still pre-ratification, community-review drafts). So the governance layer is concretely plural (IETF for workload identity + delegated authority; OpenID for the authorization decision + prerequisites) and actively moving — not one arbiter but a cross-body division of labor whose eventual composition is itself unsettled. Sharpened again 2026-08-04 by a third venue that ships: MCP spec revision 2026-07-28 (MCP Specification Changelog — 2026-07-28, vendor-claim) legislates its own client-registration and code-redemption rules under neither body — issuer-keyed non-reusable client credentials as a MUST, RFC 9207 iss validation as a MUST, and RFC 7591 Dynamic Client Registration deprecated in favor of Client ID Metadata Documents, the same primitive §10.10 above already names under Discovery. Two things follow. The composition question gains its first concrete convergence — an independent protocol reached for CIMD without coordinating with this draft — and it also gains a fourth arbiter, one that is not a standards body deliberating but a de-facto protocol shipping requirements into implementations while IETF and OpenID are still at draft. The trigger event for this question was always ratification; the observation is that a de-facto layer may settle the primitives before ratification does. Still #oq/wait — the question is which primitives reach RFC and whether the composition survives WG review, and neither has happened.
• Mission → authorization is out of scope. The hardest part — translating a natural-language mission into concrete scopes/resources safely — is explicitly deferred as a "planning step." A manipulated planning step requests over-broad authorization; AIMS gives it clean primitives but no account of securing the translation itself.
• Mid-execution human-in-the-loop. The draft admits CIBA only models client-initiated approval and "doesn't map well" to confirmation needed mid-execution — an acknowledged specification gap. Addressed (in proposal) by the OpenID AuthZEN AARP draft: AARP generalizes CIBA's async out-of-band interaction into a general prerequisite/approval pattern — "not yet, here is what is required" — not confined to client-initiated flows and satisfiable by a person or an automated governance system mid-flow, with policy re-evaluated at enforcement. So the gap now has a proposed standards answer — but a Working Group Draft, not a ratified spec, and not yet integrated with AIMS's IETF stack.
• Posture assessment is deployment-specific by design. By requiring no particular attestation mechanism, AIMS makes interoperability of trust assurance (not just protocol) unspecified: two conformant AIMS deployments can assess posture with wholly different, non-comparable signals.
• No empirical evaluation. Unlike Out-of-Band Prompt-Injection Defense (which at least ran one adaptive reproduction), AIMS is a design document with no measured attack-resistance — its security rests on the composed specs' own (mostly non-agentic) threat models. Partially answered (2026-09-02) by Dantuluri & Sundi (Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems, empirical, VotalAI COI): an AIMS-shaped composition — OIDC-rooted capability token, SPIFFE-style SVID, issuer-mediated token exchange minting an attenuated SVID-bound short-lived token at every hop, revocation propagation, tamper-evident log — has now been built and attacked, blocking all four modelled threats where a bearer-credential runtime fails all four, resisting 11 hand-built design attacks, accepting 0 of 200,000 forged/mutated tokens, confining a compromised sub-agent to a mean 1.5 of 8,100 reachable actions, at ~2.6 µs per decision. Three reasons it is a partial and not an answer: the artifact is a ~160-line unreleased demonstrator with a different token format (macaroon-style HMAC caveats, not WIMSE WPTs), so this is evidence that the shape holds, not that this draft's stack does; the measurement runs against an abstract tool/resource action model with no live model in the loop; and the composed-specs threat models the question actually indicts are untouched — the paper assumes the infrastructure and PEPs are trusted and correctly implemented.
• Integration and a live model are the paper's own next step, and nobody has taken it. The one measured broker is not wired into any of the frameworks it audits, and every agent in the evaluation is scripted. Does an attenuated, SVID-bound, PEP-enforced delegation chain survive integration into a real framework (LangGraph, CrewAI, AutoGen, or an MCP client) driven by a live, injectable model — and does the per-hop exchange stay usable when the model, not a script, is choosing the sub-task the token is attenuated to?

Sources#

• AI Agent Authentication and Authorization — IETF Internet-Draft draft-klrc-aiagent-auth-03, AI Agent Authentication and Authorization (Informational, individual submission), 6 July 2026, practitioner-opinion. §4 (agents are workloads, Figure 1), §5 (AIMS stack, Figure 2), §6 (WIMSE/SPIFFE identifier), §7 (credentials; static-key antipattern; hardware-backing optional), §8 (provisioning + posture assessment; LLMs-never-hold-credentials rule), §9 (transport mTLS vs application-layer WPT / HTTP Message Signatures), §10 (OAuth delegation, mission, transaction tokens, cross-domain chaining, CIBA human-in-the-loop, tool-to-service, discovery), §11 (SSF/CAEP/RISC monitoring + tamper-evident audit)
• Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems — Panduranga Sai Varma Dantuluri & Jyotirmoy Sundi (both VotalAI), Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems, arXiv 2609.00267 v1, 2026-08-31, 14pp, empirical — with a vendor COI and a mixed-method caveat that travel together: both authors are at VotalAI, §8 is a two-page description of the company's commercial LLM Shield and the abstract advertises it, while the evaluated artifact is "a separate, minimal demonstrator built on public primitives and is not released" (~160 lines of stdlib Python). Of the gap analysis, only the LangGraph 1.2.10 row is executed; CrewAI 1.15.13 and AutoGen 0.7.5 are code inspection, MCP authz rev. 2026-07-28 is specification reading, and Table 3 is self-declared "an analytical result … the authors' reading". The broker numbers (0/200,000 fuzz, 11 design attacks, 2,000-scenario blast radius, ~2.6 µs / ~5.4 µs over 2×10⁵ calls) are measured; §8's production figures (~2 ms pre-call inspection, ~190 ms guardrail check) are vendor-claim. Cited here for §1 (untrusted-model property), §3 (T1–T4, trust assumptions), §4 (R1–R8, R8 load-bearing), §5 (per-framework gap, MCP as the partial exception missing R1/R2), §6 (Table 3, the missing standard profile), §7 (broker design, implementation, and all four evaluation axes including the twelfth boundary test), §8 (LLM Shield, vendor), §10 (threats to validity). Figure 1 (broker data flow) viewed per the image two-pass rule; its "untrusted: model-controlled" zone label is welded into the §7.2 prose by the parser — a parse artifact, no content lost
• MCP Specification Changelog — 2026-07-28 — Model Context Protocol project, Key Changes for spec revision 2026-07-28, vendor-claim. Minor changes 7–9 and Deprecated 4: RFC 9207 iss validation, credentials keyed to the issuing authorization server, DCR application_type, and RFC 7591 DCR deprecated in favor of Client ID Metadata Documents. Used only for the plural-governance question — the point is where these rules are being made, not their merits
• OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts — OpenID Foundation, OpenID Foundation advances authorization for the agent era with new AuthZEN Working Group Drafts, 15 June 2026, practitioner-opinion (a standards-body announcement of newly-approved Working Group Drafts — proposals, not ratified specs; framed as proposed throughout, and weighted below the vault's empirical per-call-authz papers where they overlap). Supplies: AARP (Access Request and Approval Profile — prerequisite/approval pattern generalizing CIBA beyond client-initiated flows), COAZ (AuthZEN Profile for MCP Tool Authorization — MCP invocations → Subject-Action-Resource-Context / Authorization API 1.0), the OIDC→OAuth→CIBA→Verifiable-Credentials→AARP progression, and the industry-participation list (Axiomatics, Cerbos, Okta, SailPoint, Indykite, Keycard, C1)
• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers — Zhou et al. (Fudan University; one author at Central South University), A First Measurement Study on Authentication Security in Real-World Remote MCP Servers, arXiv 2605.22333, 2026-05-21, 15pp, empirical, no COI. Cited here for Finding 2.1 (1,118 of 2,428 OAuth-enabled servers DCR-enabled, 46.0%), Finding 2.3 / Table 4 (delegated authorization at 81/119, 68.07%), Finding 3.2 (F1 at 114/119) and Finding 3.3 (40 of 81 delegated deployments using nested state), plus §6.2's server-side-opaque-state mitigation. Parse warning (Table 5 grouped-row collapsed past a clean checker verdict) and full treatment on Remote MCP Authentication in the Wild