The Agent Key That Must Not Identify a Person: Web Bot Auth and the Audit Attribution Gap

The identity layer currently being standardised for AI agents on the open web is, by explicit normative design, non-attributing. Section 6.2 of the Web Bot Auth protocol draft (draft-meunier-webbotauth-httpsig-protocol-00, 26 June 2026) states that "The key used for signing MUST NOT be tied to a specific human individual." That is a deliberate privacy decision with a stated rationale, and it is the correct decision for the problem the draft is solving. It is also the exact opposite of what an enterprise audit log needs when an agent moves money, deletes a record, or approves a change. The mechanism that does carry that attribution, RFC 8693, has existed since January 2020 and appears in neither the Model Context Protocol authorization specification nor the A2A specification.

Four forces put this on the 2026 agenda. First, Web Bot Auth reached its second document generation on 26 June 2026, replacing the architecture draft that carried the same clause at Section 5.9. Second, the Model Context Protocol shipped a new authorization revision on 25 November 2025 that added scope selection and step-up authorization but still lists no token-exchange mechanism. Third, A2A reached protocol version 1.0 on 12 March 2026 and states plainly in Section 7 that identity is handled outside its semantics. Fourth, RFC 8693 turned six years old in January 2026 having solved the attribution problem the agent-native layers now face. For CISOs, identity architects, and anyone who has to answer an auditor, the question is no longer theoretical.

This post is the Stingrai research team's clause-level reading of those five specifications. It quotes primary specification text directly, stamps every claim to a named revision and date, and publishes the resulting matrix as an open dataset under CC BY 4.0. Every cell cites the clause and the specification version it came from, so any conclusion here can be checked against the source rather than taken on trust. Two of the five documents are Internet-Drafts and will change; the re-validation cadence and the exact revisions read are stated below.

Direct answer: if an AI agent takes an action on my systems, can I prove which human authorised it?

Not from the agent identity layer alone, and not from Web Bot Auth, MCP, or A2A as specified. As of 26 July 2026, only one of the five specifications examined here carries an attributable link from a human subject to an acting agent: RFC 8693, through the act claim and its nested form. Web Bot Auth normatively excludes that link. RFC 9421 defines no identity semantics at all and hands them to the application. The MCP authorization specification carries a human identity only insofar as the authorization server chooses to put one in the token, which the specification places out of scope. A2A states that identity is not part of its semantics.

The practical consequence: an audit log built on the agent-native layers can prove which automation signed a request, but not which person stood behind it. Proving the second requires composing an OAuth 2.0 Token Exchange delegation chain underneath the agent transport. That composition is available today. It is simply not what any of the agent-native specifications require you to do.

Figure 1: The agent identity attribution matrix, five specifications by four properties. Sources: draft-meunier-webbotauth-httpsig-protocol-00 (26 June 2026), RFC 9421 (February 2024), RFC 8693 (January 2020), MCP authorization 2025-11-25, A2A v1.0.0 (12 March 2026).

Accurate as of 26 July 2026, against these specification revisions

This is the block to check first if you arrive here later. The value of a standards reading dies the moment its version stamps go stale.

Re-validation cadence: quarterly. Next scheduled re-validation 26 October 2026. Two of these six rows are Internet-Drafts, which expire six months after posting and can be replaced without notice. The Web Bot Auth architecture draft was already replaced once during the period covered here, which is precisely why the clause is cited to both documents below.

TL;DR

• The clause (Web Bot Auth, Section 6.2): an agent's signing key "MUST NOT be tied to a specific human individual", with keys instead representing a role, company, or automation identity (draft-meunier-webbotauth-httpsig-protocol-00, 26 June 2026).

• The rationale, quoted fairly: the clause exists to avoid "accidental exposure of personally identifiable information" and to prevent "the misuse of keys for user tracking or profiling" (same section). This is a privacy design decision, not an oversight.

• The counterpart (RFC 8693, Section 4.1): "A chain of delegation can be expressed by nesting one act claim within another", with the outermost representing the current actor and nested claims representing prior actors (RFC 8693, January 2020).

• The attenuation counterpart (RFC 8693, Sections 2.1 and 2.2.1): optional scope, resource, and audience request parameters narrow the issued token, and the response scope becomes REQUIRED whenever the issued scope differs from the requested scope.

• MCP does not reference it: RFC 8693 appears in the Standards Compliance list of neither the 2025-06-18 nor the 2025-11-25 revision, and neither revision mentions token exchange, the act claim, or a delegation chain (MCP authorization).

• A2A does not carry it: "Identity information is handled at the protocol layer, not within A2A semantics" (A2A specification, Section 7, v1.0.0).

• RFC 9421 is agnostic by construction: it defines keyid as "The identifier for the key material as a String value" (Section 2.3) and requires the application, not the RFC, to define how keys resolve to identities (Section 1.4).

• CVE position, verified: no CVE exists against the delegation-attribution design of any of these specifications. Two CVEs exist against RFC 9421 implementations, and 64 NVD records match "Model Context Protocol", all against implementations (NVD, swept 26 July 2026).

• The gap is being worked: draft-mcguinness-oauth-ai-agent-instance-00 (4 July 2026, active) defines attested agent instance identifiers and delegation-chain semantics for sub-agents, building on RFC 8693.

• Open dataset: the full matrix with per-cell citations is published under CC BY 4.0 at matrix.csv and matrix.json.

Key takeaways

This is a collision of two legitimate goals, not a flaw in either. Web Bot Auth is solving bot identification on the open web, where a crawler key that resolves to a named employee would be a tracking vector aimed at that employee. RFC 8693 is solving enterprise delegation, where the entire point is that the audit trail resolves to a named person. Both are right within their scope. The gap sits in the space between them, which is exactly where agentic enterprise deployments now live.

The attribution primitive predates every agent-native layer examined here. The most useful finding in this reading is not that a gap exists but that the fix has been Standards Track since January 2020, more than five years before the earliest agent-native revision in this matrix, the Model Context Protocol authorization revision 2025-06-18, and more than six years before A2A reached version 1.0 on 12 March 2026. RFC 8693's nested act claim was designed for service-to-service delegation chains, and an AI agent calling a tool on a user's behalf is structurally the same shape. Nothing new needs to be invented; something existing needs to be composed.

MCP moved toward least privilege without moving toward attribution. The 2025-11-25 revision added a Scope Selection Strategy in which clients "SHOULD follow the principle of least privilege" and a step-up flow driven by insufficient_scope responses. That is a real improvement in attenuation. It is also orthogonal to attribution: narrower scope tells you what the token could do, not who authorised it.

The specifications actively forbid the wrong fix. Both MCP revisions require that servers "MUST only accept tokens specifically intended for themselves" and state that token passthrough is explicitly forbidden. A2A Section 7.6.3 warns that in-band credential exchange "can allow credentials to be passed across chains of multiple A2A agents, exposing those credentials to each agent participating in the chain." The naive way to preserve a chain, forwarding the original token, is precisely the pattern both documents rule out.

No CVE means no CVE, and that is worth saying plainly. The NVD sweep found nothing against the design of any of these mechanisms. The CVEs that exist are ordinary implementation bugs. Framing a design gap as a vulnerability would be wrong, and it would cost the standards audience this analysis is written for.

Methodology

Five specifications were read directly at the revisions stamped in the table above. Nothing here is sourced from a summary, a vendor explainer, or a secondary article.

Retrieval. IETF documents were retrieved as plain text from the IETF archive and the RFC Editor. Internet-Draft revision numbers, publication dates, expiry dates, working group assignment, and document state were confirmed against the IETF Datatracker document API rather than rendered pages, because rendered pages can lag state changes. The Model Context Protocol authorization specification was retrieved for both the 2025-06-18 and 2025-11-25 revisions and read in full. The A2A specification was retrieved from the project repository, and its release dates were confirmed against the repository's release API.

Property definitions. Four properties were assessed per specification: whether it carries an identity for the agent, whether it carries an identity for the delegating human, whether it preserves a delegation chain across hops, and whether attenuation or scope narrowing is supported. Each was scored Yes, Partial, No, or No, normatively excluded. A property was scored No only where the document is silent. Where a document explicitly hands a property to a layer it does not define, it was scored Partial and the delegating clause was cited rather than the absence.

Citation discipline. Every cell in the published matrix names the clause and the specification revision that supports it. Where a claim is about absence, the absence was verified by searching the full specification text for the relevant terms, and the search terms are recoverable from the citation. For the MCP delegation-chain cell, that meant confirming that RFC 8693, token exchange, act claim, and delegation appear nowhere in either revision.

CVE and advisory sweep. Claims about vulnerabilities were checked against the NVD 2.0 REST API by keyword on 26 July 2026, covering "HTTP Message Signatures", "RFC 9421", "web bot auth", "OAuth token exchange act claim", "Agent2Agent", and "Model Context Protocol". Where matches exist, the record identifier, CVSS base score, and publication date are recorded. Where no match exists, this analysis says so plainly rather than implying unmeasured risk.

Exclusions. No claim is made about what any vendor's implementation does beyond that vendor's published documentation. Any figure that could not be traced to a named primary specification clause or a named NVD record was dropped rather than estimated.

What Web Bot Auth actually says, and why

Web Bot Auth is an architecture for identifying automated traffic using HTTP Message Signatures. The model in Section 4 is three parties: a User, defined in Section 3 as "An entity initiating requests through an agent" that "May be a human operator or another system"; an Agent, an orchestrated user agent that constructs signed HTTP requests; and an Origin, an HTTP server that verifies those signatures. The Agent signs. The Origin verifies. The User appears in the definitions and in the architecture diagram, and then does not appear in any signed field.

Section 6.2, headed "No Human Correlation", is the clause that matters here. Quoted in full:

The key used for signing MUST NOT be tied to a specific human individual. Keys SHOULD represent a role, company, or automation identity (e.g., "news-aggregator-bot", "example-crawler-v1"). This avoids accidental exposure of personally identifiable information and prevents the misuse of keys for user tracking or profiling.

The rationale deserves to be taken seriously rather than treated as boilerplate, because the surrounding sections make the reasoning explicit and coherent. Section 6.1, "Public Identity", establishes that the identity associated with a signing key "is expected to be publicly discoverable for verification purposes", that this "reduces anonymity and allows receivers to associate requests with specific agents", and that an agent unwilling to identify itself has chosen the wrong protocol. Section 6.3, "Minimizing Tracking Risks", then tells implementations to avoid long-lived, globally unique key identifiers unless strictly necessary, to support key rotation, and to avoid signing information that could correlate activity across contexts.

Read together, the three sections form a single argument. Web Bot Auth deliberately builds a publicly discoverable, durable identifier for automated clients. A publicly discoverable, durable identifier that resolves to a named human is a surveillance primitive. The same property that makes the mechanism useful for the open web, a stable key any origin can look up, makes human binding actively dangerous. The MUST NOT is not a gap the authors overlooked. It is the safety rail that makes the rest of the design publishable.

The clause has also been stable across a document generation. It appeared at Section 5.9 of draft-meunier-web-bot-auth-architecture-05 (2 March 2026, now marked Replaced) with identical wording, and carried forward to Section 6.2 of draft-meunier-webbotauth-httpsig-protocol-00 (26 June 2026). Both documents are individual submissions with no working group, discussed on the web-bot-auth@ietf.org mailing list.

What Web Bot Auth is not

It is not an authorization layer, and it does not present itself as one. There is no scope field, no permission field, and no capability field anywhere in the draft. The bounding it offers comes from RFC 9421 signature parameters it inherits: created, expires, nonce, and tag. Those bound a signature in time and in application context. They do not narrow what the signer is allowed to do.

That distinction matters when reading the matrix. Web Bot Auth scores No on attenuation not because it fails at authorization, but because authorization is not in its problem statement.

RFC 9421: signatures without semantics

RFC 9421, published February 2024 on the Standards Track, is the base mechanism Web Bot Auth builds on. Its abstract describes "a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message." Note what is absent from that sentence: any claim about identity.

That absence is deliberate and stated. Section 1.4 lists what an application profile of RFC 9421 must define for itself, and the list includes "A means of retrieving the key material used to verify the signature", noting that an application "will usually use the keyid parameter" but that "the appropriate key could be known from other means such as preregistration of a signer's key." Section 2.3 defines keyid with maximum economy as "The identifier for the key material as a String value." A string. The RFC assigns it no structure and no semantics.

The result is that RFC 9421 proves possession of a key and integrity over a chosen set of message components. Everything about who holds that key, and what that holder is allowed to do, belongs to the profile. Web Bot Auth is one such profile, and the identity it layers on top is an automation identity by construction.

One nuance is worth recording because it is the closest thing to a chain in the signature layer. Section 4.3, "Multiple Signatures", permits several signatures on a single message and gives the example of "a reverse proxy may include information about the client in fields when forwarding the request to a service host, including a signature over the client's original signature values." An origin receiving that message can establish an ordering: this client signed, then this proxy countersigned the client's signature. That is a verifiable sequence of signers. It is not a delegation chain, because nothing in it states that the client authorised the proxy to act, nor what the proxy was authorised to do. Ordering is not authority. The matrix scores this Partial for that reason.

Section 7.3.2 adds the assumption everything rests on: "A foundational assumption of signature-based cryptographic systems is that the signing key is not compromised by an attacker." An agent key stolen from a runtime is an agent key that signs perfectly valid requests. This is one of several reasons that key custody testing belongs in scope for any agentic deployment, a theme picked up in non-human identity attacks and leaked API keys.

RFC 8693: the attribution mechanism that already exists

RFC 8693, "OAuth 2.0 Token Exchange", was published January 2020 on the Standards Track. Its abstract commits to "security tokens employing impersonation and delegation", and Section 1.1 draws the distinction that the rest of the specification builds on.

Under impersonation, principal A "is given all the rights that B has within some defined rights context and is indistinguishable from B in that context." The token says B. The audit log says B. A has vanished.

Under delegation, "principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B." Both parties survive into the token. The specification then names the shape this produces: a composite token, "composed of information about multiple subjects", where the request's subject_token represents the party on whose behalf the token is requested and the actor_token represents the party receiving the delegated rights.

Section 4.1 defines the JWT claim that carries this. The act claim "provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated." A token with a top-level sub of a user and an act naming a service says, unambiguously and in a form any JWT consumer can parse, that this service is acting for that user.

The chain follows directly:

A chain of delegation can be expressed by nesting one "act" claim within another. The outermost "act" claim represents the current actor while nested "act" claims represent prior actors. The least recent actor is the most deeply nested.

The specification calls the nested structure "a history trail that connects the initial request and subject through the various delegation steps undertaken before reaching the current actor." For an agent that calls a tool that calls another service, that is the audit record an enterprise reviewer is asking for, in a standard format, with the human at the top.

Figure 2: A nested act claim in RFC 8693. The top level sub names the human, the outer act names the current actor, and the inner act names the prior actor. Source: RFC 8693 Section 4.1, Figure 6, January 2020.

The caveat that must travel with the claim

Section 4.1 immediately constrains how the chain may be used:

For the purpose of applying access control policy, the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the "act" claim. Prior actors identified by any nested "act" claims are informational only and are not to be considered in access control decisions.

This is a genuinely important qualification and it is frequently dropped when the act claim is cited. The nested history is evidentiary, not enforceable. A resource server may not grant access because an ancestor in the chain was privileged. Read correctly, that makes the nested chain a near-perfect fit for the audit use case and an explicitly unsuitable input to an authorization decision. It answers "who authorised this" without becoming a new privilege-escalation surface.

Attenuation in the same specification

RFC 8693 also carries the narrowing property the agent-native layers lack. Section 2.1 defines scope, resource, and audience as optional request parameters that let a client "specify the desired scope of the requested security token in the context of the service or resource where the token will be used" and indicate the target service by URI or logical name. Section 2.2.1 makes the response scope REQUIRED whenever the issued scope differs from what was requested, which means a client always learns when it received less than it asked for. Section 1.1 gives the canonical use: a resource server exchanging a token it received for one "more narrowly scoped for the downstream service."

That is attenuation with an audit trail attached, in a single exchange, defined in January 2020.

MCP authorization: what the specification says and does not say

The Model Context Protocol authorization specification is the layer most enterprise agent deployments actually authenticate through, which makes its silences consequential. Two revisions were read: 2025-06-18 and the current 2025-11-25.

Both open the same way. Authorization "is OPTIONAL for MCP implementations", and where supported, HTTP-based transports "SHOULD conform to this specification". The Roles section places an MCP server as an OAuth 2.1 resource server and an MCP client as "an OAuth 2.1 client, making protected resource requests on behalf of a resource owner". Crucially, it then scopes out the component that would carry human identity: "The authorization server is responsible for interacting with the user (if necessary) and issuing access tokens for use at the MCP server. The implementation details of the authorization server are beyond the scope of this specification."

That sentence is why the matrix scores MCP Partial rather than Yes on human identity. A user identity may well be present in the token, because a real authorization server running an authorization code flow with user consent will usually put one there. But it is present because of the deployment, not because MCP requires it. Nothing in the specification tells a server what claim to look for, or that one must exist.

The Standards Compliance list is the decisive evidence on delegation chains. The 2025-11-25 revision names OAuth 2.1 (draft-ietf-oauth-v2-1-13), RFC 8414, RFC 7591, RFC 9728, and OAuth Client ID Metadata Documents. The 2025-06-18 revision names the first four. RFC 8693 appears in neither. Reading the full text of both revisions confirms it: neither contains the string 8693, token exchange, act claim, or any description of a delegation chain.

This is not an accusation of insecurity, and it should not be read as one. MCP is explicit that it "implements a selected subset" of the features of the standards it builds on "to ensure security and interoperability while maintaining simplicity". Token exchange is a feature it did not select. That is a scoping choice with real benefits, and it comes with the consequence recorded in the matrix.

What 2025-11-25 did add

The newer revision is materially stronger on attenuation, and the analysis would be incomplete without saying so. It introduces a Scope Selection Strategy in which "MCP clients SHOULD follow the principle of least privilege by requesting" appropriately narrow scopes, with a stated priority order for choosing them. It introduces a step-up authorization flow: when a request fails with insufficient permission, the server responds 403 with WWW-Authenticate: Bearer error="insufficient_scope" and a scope parameter "specifying the minimum scopes needed for the operation", and clients "SHOULD respond to these errors by requesting a new access token with an increased set of scopes". It distinguishes clients acting on behalf of a user, which "SHOULD attempt the step-up authorization flow", from client_credentials clients acting on their own behalf, which may abort instead.

That last distinction is the closest the specification comes to acknowledging the two cases this article is about, and it is a runtime behaviour rule rather than a claim carried in a token.

Both revisions also require audience binding in strong terms: servers "MUST only accept tokens specifically intended for themselves and MUST reject tokens that do not include them in the audience claim", with the Token Audience Binding section stating that token passthrough "is explicitly forbidden". The specification's own Security Considerations explain why, naming the confused deputy problem directly. This is the right call, and it closes off the tempting shortcut of forwarding a user's original token down the chain to preserve attribution. For teams assessing MCP deployments in practice, the operational consequences are covered in the MCP server security assessment guide.

A2A: identity is explicitly outside the semantics

The Agent2Agent specification reached protocol version 1.0 with specification release v1.0.0 on 12 March 2026. A patch release v1.0.1 followed on 28 May 2026, and by the specification's own versioning rules patch numbers "do not affect protocol compatibility" and are not used in negotiation, so the stamped protocol version remains 1.0.

Section 7 states the position in its opening sentence: "A2A treats agents as standard enterprise applications, relying on established web security practices. Identity information is handled at the protocol layer, not within A2A semantics." The companion enterprise guidance is even more direct, listing "No Identity in Payload" as a design property: A2A protocol payloads "don't carry user or client identity information directly", and "Identity is established at the transport/HTTP layer."

The mechanics follow. Section 7.2 has clients verify the server's TLS certificate. Section 7.3 has the client discover required schemes from securitySchemes in the AgentCard and obtain credentials "through an out-of-band process specific to the required authentication scheme". Section 7.5 leaves authorization "implementation-specific", noting it "MAY consider" the specific skills requested, actions attempted within tasks, data access policies, and OAuth scopes.

Section 7.6 is where a chain almost appears. When an agent needs authorization mid-task it can enter TASK_STATE_AUTH_REQUIRED, and if the client is itself an A2A agent it may delegate the request onward to its own client, "enabling forming a chain of Tasks in TASK_STATE_AUTH_REQUIRED". That is a chain of authorization requests propagating back toward a human, which is a genuinely useful pattern. It is not a chain of attributed delegation travelling forward with the action, and nothing in the resulting call carries a record of who consented at the far end.

Section 7.6.3 then documents the risk of the obvious workaround with unusual candour: in-band credential exchange "can allow credentials to be passed across chains of multiple A2A agents, exposing those credentials to each agent participating in the chain." Its recommended mitigations, binding credentials to the originating agent and encrypting sensitive credentials so only that agent can read them, are sound, and they are also the opposite of building a shared attributable chain.

What each layer can actually prove

The practical output of this reading is the last column of the matrix. Given only one specification, what can an audit log establish?

Figure 3: What an audit log built on each specification alone can establish. Sources: draft-meunier-webbotauth-httpsig-protocol-00 Sections 4 and 6.2; RFC 9421 Sections 2.3, 4.3; RFC 8693 Sections 2.1, 2.2.1, 4.1; MCP authorization 2025-11-25; A2A v1.0.0 Section 7.

The composition is the point. A deployment that runs Web Bot Auth at the edge, MCP authorization at the tool boundary, and an RFC 8693 exchange at the identity provider can answer the audit question end to end. A deployment that runs only the agent-native layers cannot, no matter how carefully it is configured, because the field it would need to read is not defined.

Is the gap being closed?

Yes, and this section was written after the matrix rather than before it, because the honest answer changed the conclusion.

Two Internet-Drafts currently address exactly this problem, and both build on RFC 8693 rather than proposing something new.

draft-mcguinness-oauth-ai-agent-instance-00 (4 July 2026, active, individual submission, intended status Standards Track, expires 6 January 2027) profiles OAuth client instance assertions for the case where "a single OAuth client identifier represents an agent platform running many concurrent agent instances." Its abstract commits to claims that convey "an attested agent instance identifier and agent provenance (platform, model, runtime environment)", rules for surfacing that identity in issued access tokens, and "delegation-chain semantics for agents that spawn sub-agents." That is a direct answer to the per-instance identity gap the MCP row records.

draft-oauth-ai-agents-on-behalf-of-user-02 (26 August 2025, individual submission, expired 27 February 2026) introduced a requested_actor authorization request parameter and an actor_token token request parameter, and stated that the extension "enhances auditability through access token claims that document the delegation chain from the user to the agent via a client application." Its expiry is recorded here rather than hidden, because an expired draft is a signal about momentum, not a solution anyone should deploy against.

Neither is a working group document. Both are individual submissions in the none group on the IETF Datatracker, which means neither has IETF consensus behind it and either could stall. The realistic read for 2026 is that the standards community has correctly identified the gap, has correctly identified RFC 8693 as the substrate, and has not yet converged on a profile. Enterprises deploying agents this year should compose the existing pieces rather than wait.

The CVE and advisory position, stated plainly

No CVE exists against the delegation-attribution design of any specification examined here. That is worth stating without hedging, because the alternative, implying unmeasured risk, would be the easiest way to make this analysis useless.

What the 26 July 2026 NVD sweep did return:

Two patterns are worth drawing out. First, the RFC 9421 CVEs are both verification bugs that fail open: a timing side channel in one, and a comparison that unconditionally succeeded in the other. Signature verification code is exactly the place where a subtle bug converts a strong mechanism into a decorative one, which is an argument for testing verifiers rather than trusting them. Second, the MCP record count reflects ecosystem size and scrutiny, not specification weakness, and the volume is dominated by hosts, SDKs, and individual servers.

What this means for defenders

Decide which layer owns attribution, and write it down. The failure mode is not any single specification. It is assuming that some other layer is carrying the human identity. Name the layer that holds it, usually the identity provider issuing tokens, and treat every other layer as unable to answer the question.

Test that the delegation chain survives the hop. If an architecture claims a user is attributable through an agent to a tool, that claim is testable. Issue an action, then read the audit records at each boundary and confirm the human resolves at every one. Chains that exist in a design document and not in the logs are the common finding.

Test the verifier, not just the signer. Both RFC 9421 CVEs were in verification. A verifier that accepts a bad signature is worse than no signature, because it manufactures false confidence in the audit record. Include malformed signatures, expired created and expires values, replayed nonces, and unresolvable keyid values in test coverage.

Treat agent signing keys as production secrets with rotation. RFC 9421 Section 7.3.2 is explicit that the whole scheme rests on the signing key not being compromised, and Web Bot Auth Section 6.3 asks for rotation support. An agent key sitting in a container image or a long-lived environment variable defeats both. This is the same class of exposure covered in non-human identity attacks and leaked API keys and in cloud IAM penetration testing.

Adopt the 2025-11-25 MCP behaviours even where 2025-06-18 is in use. Least-privilege scope selection, step-up on insufficient_scope, and strict audience validation are all deployable against an older revision. Audience binding in particular is what stops a token issued for one server being replayed at another.

Scope agentic engagements around authorization, not just prompt handling. The interesting findings in agent deployments cluster around broken authorization, delegation that loses attribution, and tool boundaries that accept tokens they should reject. Coverage patterns for this are set out in the OWASP Agentic AI Top 10 test coverage checklist and, for money-moving systems where attribution is a regulatory matter rather than a preference, in red teaming AI agents that move money.

Frequently asked questions

If an AI agent takes an action on my systems, can I prove which human authorised it?

Not from the agent identity layer alone. Of the five specifications examined, only RFC 8693 carries an attributable link from a human subject to an acting agent, through the act claim and its nested form (Section 4.1). Web Bot Auth normatively excludes that link at Section 6.2, A2A places identity outside its semantics at Section 7, and MCP leaves the token's user claims to the authorization server, which it puts out of scope. Proving human authorisation requires composing an RFC 8693 delegation chain underneath the agent transport.

Does Web Bot Auth really forbid tying a signing key to a person?

Yes, normatively. Section 6.2 of draft-meunier-webbotauth-httpsig-protocol-00 (26 June 2026) states that "The key used for signing MUST NOT be tied to a specific human individual", and directs that keys "SHOULD represent a role, company, or automation identity". The identical requirement appeared at Section 5.9 of the replaced architecture draft. The stated rationale is avoiding exposure of personally identifiable information and preventing key misuse for user tracking or profiling.

Is that clause a security flaw?

No. It is a privacy design decision with a coherent rationale, and within Web Bot Auth's problem domain it is the right one. The draft builds a publicly discoverable, durable identifier for automated clients (Section 6.1). Binding such an identifier to a named person would create a tracking primitive aimed at that person. The clause is what makes the rest of the design safe to publish, not a gap in it.

Does the Model Context Protocol support delegated identity?

Not as specified. RFC 8693 appears in the Standards Compliance list of neither the 2025-06-18 nor the 2025-11-25 revision, and neither revision references token exchange, the act claim, or a delegation chain. MCP inherits OAuth 2.1, so a user identity will often be present in the token, but that is a property of the authorization server, which the specification explicitly places beyond its scope. This is a scoping choice, not an insecurity claim.

What is the difference between impersonation and delegation in RFC 8693?

RFC 8693 Section 1.1 draws it directly. Under impersonation, the acting party "is given all the rights" of the subject and "is indistinguishable from" them in that context, so the audit trail records only the subject. Under delegation, the actor "still has its own identity separate from" the subject, and any actions "are being taken by A representing B", so both parties survive into the token. Audit attribution needs delegation semantics; impersonation destroys the very information an auditor is looking for.

Can nested act claims be used for access control decisions?

No, and the specification is emphatic. RFC 8693 Section 4.1 states that "the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor", and that prior actors in nested act claims "are informational only and are not to be considered in access control decisions". The nested chain is evidentiary, which is exactly what makes it suitable for audit and unsuitable as an authorization input.

Does A2A carry the end user's identity to a remote agent?

No. Section 7 of the A2A specification (v1.0.0, 12 March 2026) states that "Identity information is handled at the protocol layer, not within A2A semantics", and the project's enterprise guidance lists "No Identity in Payload" as a design property, with identity established at the transport or HTTP layer. Section 7.6 does allow a chain of authorization requests to propagate backwards through TASK_STATE_AUTH_REQUIRED, but that is a request for consent, not a record of it travelling with the action.

Are there any CVEs against these mechanisms?

None against their delegation-attribution design. An NVD sweep on 26 July 2026 returned two CVEs against RFC 9421 implementations, CVE-2025-59058 (httpsig-rs, non-timing-safe HMAC comparison, CVSS 3.1 base 5.9) and CVE-2026-26275 (httpsig-hyper, digest verification incorrectly succeeding, CVSS 3.1 base 7.5), plus 64 records matching "Model Context Protocol", all against SDKs, hosts, and individual servers. Searches for "web bot auth", "Agent2Agent", and the OAuth token exchange act claim returned nothing.

What is being done to close the attribution gap?

Two Internet-Drafts, both building on RFC 8693. draft-mcguinness-oauth-ai-agent-instance-00 (4 July 2026, active) defines attested agent instance identifiers, agent provenance claims, and delegation-chain semantics for agents that spawn sub-agents. draft-oauth-ai-agents-on-behalf-of-user-02 (26 August 2025) introduced requested_actor and actor_token parameters and delegation-chain claims, but expired on 27 February 2026. Neither is a working group document, so neither carries IETF consensus yet.

Where can I get this matrix as data?

The full matrix, including a citation for every cell, the CVE sweep, and the revision log, is published under CC BY 4.0 as matrix.csv and matrix.json. Attribution string: Stingrai, Agent Identity Attribution Matrix. It is re-validated quarterly, next on 26 October 2026.

How should I test an agent deployment for attribution loss?

Trace one real action end to end and read the audit record at every boundary it crosses. Confirm the human resolves at each hop, that scope narrowed rather than widened, that the receiving service rejected a token issued for a different audience, and that the signature verifier rejects malformed, expired, and replayed signatures. Attribution loss almost always shows up at a boundary where one layer assumed another was carrying the identity.

References

1. IETF, T. Meunier and S. Major. HTTP Message Signatures for automated traffic. Internet-Draft draft-meunier-webbotauth-httpsig-protocol-00, 26 June 2026. https://datatracker.ietf.org/doc/draft-meunier-webbotauth-httpsig-protocol/. Active individual submission, intended status Informational, expires 28 December 2026. Section 6.2 carries the No Human Correlation requirement analysed throughout this post.

2. IETF, T. Meunier and S. Major. HTTP Message Signatures for automated traffic Architecture. Internet-Draft draft-meunier-web-bot-auth-architecture-05, 2 March 2026. https://datatracker.ietf.org/doc/draft-meunier-web-bot-auth-architecture/. Marked Replaced. Carries the identical clause at Section 5.9, establishing that the requirement is stable across a document generation.

3. IETF, A. Backman, J. Richer and M. Sporny. HTTP Message Signatures. RFC 9421, February 2024. https://www.rfc-editor.org/rfc/rfc9421.html. Standards Track. Defines the signing mechanism, the keyid parameter (Section 2.3), the application profile requirements (Section 1.4), multiple signatures (Section 4.3), and the key-theft assumption (Section 7.3.2).

4. IETF, M. Jones, A. Nadalin, B. Campbell, J. Bradley and C. Mortimore. OAuth 2.0 Token Exchange. RFC 8693, January 2020. https://www.rfc-editor.org/rfc/rfc8693.html. Standards Track. Defines impersonation versus delegation (Section 1.1), request parameters including subject_token, actor_token, scope, resource and audience (Section 2.1), response scope requirements (Section 2.2.1), and the act claim with its nested chain form (Section 4.1).

5. Anthropic and the Model Context Protocol community. Model Context Protocol, Authorization. Specification revision 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization. Current protocol revision as of 26 July 2026. Source of the Roles, Standards Compliance, Scope Selection Strategy, Step-Up Authorization, and Token Audience Binding sections cited here.

6. Anthropic and the Model Context Protocol community. Model Context Protocol, Authorization. Specification revision 2025-06-18. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization. Prior revision, read for comparison. Lacks the scope selection and step-up sections added in 2025-11-25.

7. Model Context Protocol community. Versioning. https://modelcontextprotocol.io/specification/versioning. Establishes the YYYY-MM-DD revision scheme and confirms 2025-11-25 as the current protocol version.

8. A2A Project. Agent2Agent (A2A) Protocol Specification. Protocol version 1.0, specification release v1.0.0, released 12 March 2026. https://a2a-protocol.org/latest/specification/. Source of Section 7 on authentication and authorization, Section 7.6 on in-task authorization, and Section 7.6.3 on in-band credential exchange across agent chains.

9. A2A Project. Enterprise-Ready Features. https://a2a-protocol.org/latest/topics/enterprise-ready/. Companion guidance stating the No Identity in Payload property and the out-of-band credential acquisition model.

10. NIST National Vulnerability Database. CVE-2025-59058. Published 12 September 2025. https://nvd.nist.gov/vuln/detail/CVE-2025-59058. Non-timing-safe HMAC comparison in an RFC 9421 implementation, CVSS 3.1 base 5.9.

11. NIST National Vulnerability Database. CVE-2026-26275. Published 19 February 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-26275. Digest verification incorrectly succeeding in an HTTP message signatures extension, CVSS 3.1 base 7.5.

12. NIST National Vulnerability Database. CVE-2025-66414. Published 2 December 2025. https://nvd.nist.gov/vuln/detail/CVE-2025-66414. DNS rebinding protection not enabled by default in an MCP SDK, CVSS 3.1 base 8.1.

13. NIST National Vulnerability Database. CVE-2026-25536. Published 4 February 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-25536. Cross-client response data leak in an MCP SDK, CVSS 3.1 base 7.1.

14. IETF, K. McGuinness. OAuth 2.0 AI Agent Instance Profile. Internet-Draft draft-mcguinness-oauth-ai-agent-instance-00, 4 July 2026. https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent-instance/. Active individual submission, intended status Standards Track, expires 6 January 2027. Defines attested agent instance identifiers, agent provenance claims, and delegation-chain semantics for sub-agents.

15. IETF, T. S. Senarath and A. Dissanayaka. OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents. Internet-Draft draft-oauth-ai-agents-on-behalf-of-user-02, 26 August 2025. https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/. Expired 27 February 2026. Introduced the requested_actor and actor_token parameters and delegation-chain audit claims.

16. Stingrai. Agent Identity Attribution Matrix. Version 1.0, 26 July 2026. https://www.stingrai.io/data/agent-identity-attribution-matrix/matrix.json. The open dataset behind this analysis, published under CC BY 4.0, with a citation for every cell and a dated revision log.

Where Stingrai fits

Agent identity and delegation testing is human-led work at Stingrai. It requires reading an architecture, tracing one real action across every trust boundary it crosses, and confirming that the audit record still names a person at the far end. That is judgement work: our senior testers do it as part of red team engagements and web application penetration testing against agentic deployments, and the findings that matter are almost always broken authorization and lost attribution rather than anything exotic.

Stingrai Inc, founded in 2021, is a CREST-accredited penetration testing service provider with offices in Toronto and London. Our penetration testing supports SOC 2, ISO 27001, PCI DSS 4.0, and DORA compliance programs. Teams deploying agents against production systems this year can start with our services and pricing pages, and continuous testing through PTaaS suits deployments where the agent surface changes weekly.