The Agent Has a Credential. x401 Asks Who Actually Gave It the Authority.

Proof launched x401 on 25 June 2026. Moona Intelligence is verifying it now, nearly two months later, against the specification as it actually reads today, version 0.2.0, not against the launch material that first announced it. That distinction matters more than it might for most protocol launches, because the specification has changed in ways that bear directly on the one question this record exists to answer: not whether x401 lets a resource demand proof before an agent acts, which it plainly does, but what that proof actually establishes about where the agent's authority came from.

What x401 actually is

x401 is a header based HTTP protocol. Read directly from the current specification, its own framing is precise: HTTP already has 401 Unauthorized for authentication and 402 Payment Required for payment, and no general, machine readable way for a server to say present a qualifying credential to proceed. x401 fills that specific gap. A protected route can return a machine readable proof requirement rather than a bare rejection, and an automated caller, human operated or agentic, can read that requirement, obtain a credential result that satisfies it, and retry.

The mechanics run over three dedicated headers, verified directly against the current specification text. A Verifier, meaning the protected resource or an entity acting for it, composes a route specific proof requirement and returns it in a PROOF-REQUEST header, a base64url encoded payload built using the Digital Credentials Query Language, DCQL, to describe exactly what credential the route needs. The Agent obtains a result that can satisfy that requirement, through native invocation, a relay, or remote generation, and retries the original route carrying that result in a PROOF-RESPONSE header. The Verifier returns its decision, an error, or further detail in a PROOF-RESULT header. This is not the same set of header names version 0.1.0 used at launch. The original specification defined PROOF-REQUIRED, PROOF-PRESENTATION and PROOF-RESPONSE, with the Agent itself constructing an OpenID4VP presentation request from the decoded payload. Version 0.2.0 moved that construction to the Verifier, which now composes the presentation request the Agent executes directly, and removed a wrapper object the original payload nested credential queries and nonces under. An implementation built against the launch text and one built against the current draft are not interchangeable, and this record verifies against the current one.

A Verification Token is not a new attestation about the person

A successful check can return what the specification calls a Verification Token, defined, quoted directly, as a verifier issued, short lived access token returned after successful proof verification and used by the Agent on later protected route requests. It is worth being precise about what that token is and is not, because the distinction is easy to blur. It is not a new issuer attestation about the credential subject. It is the Verifier's own record that a specific presented result satisfied a specific route's proof requirement, at that moment. The specification is explicit that this coexists with, rather than replaces, an application's own access control: if the protected route already requires an application token in Authorization, and the x401 Verification Token is separate from that application token, the Agent SHOULD preserve the existing Authorization value. An x401 Verification Token and an ordinary API credential are meant to travel together on the same request, answering two different questions, not to be collapsed into one.

Agent binding is optional, and that is a change from launch

This is the qualification this record treats as load bearing, and it is worth stating in the specification's own words rather than rounding it into something stronger. The current draft states plainly that Agent binding is OPTIONAL in x401, and separately that x401 does not, by default, require the result to be bound to the Agent. The Agent Identifier itself is defined as an optional identifier for the Agent that a Verifier MAY bind to the HTTP caller. A deployment that wants the presented credential result cryptographically tied to the specific agent that will use it has to add that binding itself, through one of several named optional mechanisms: Web Bot Auth and HTTP Message Signatures at the request layer, OAuth proof of possession and mTLS for certificate and key bound authentication, DPoP for application layer proof of possession, or workload identity systems including SPIFFE IDs, JWT-SVIDs or WIMSE tokens for service to service scenarios. The specification states it mandates no single agent identity system, and that whichever mechanism a deployment adds must not alter the composed request or the payment boundary.

This was not always optional. Version 0.1.0, the specification Proof launched on 25 June 2026, required it: the Agent MUST identify itself to the Wallet with an Agent Identifier matching the protected route's HTTP caller, and the Verifier MUST bind the returned presentation to that identifier. Version 0.2.0 changed that MUST to an explicit OPTIONAL. Moona Intelligence could not establish the exact calendar date that change was published; the repository carries no tagged release, and the commit history available to this session runs from 22 June through 1 July 2026 without a commit naming version 0.2.0. What is independently confirmed by reading both texts directly is that the change happened, not when.

Workload identity proves less than it sounds like it proves

Among the optional binding mechanisms the specification names, workload identity gets a specific, careful limitation stated directly in the text, quoted verbatim: workload identity proves the caller's operational identity. It does not prove that the caller holds the requested credential, that the credential subject is authorized, or that an end user delegated authority to the Agent. That sentence is doing real work. A service knowing which workload is calling it, through a SPIFFE ID or a similar mechanism, is a genuinely useful fact. It is not the same fact as knowing that workload is entitled to use the credential it is presenting, or that a human actually authorized it to act on their behalf. The specification does not let one substitute for the other, and this record preserves that distinction rather than treating operational identity as a stand in for delegated authority.

Delegation evidence is composable, not automatic

Some deployments need more than proof that a credential requirement was satisfied. They need to know not only which agent made the request, but who or what authorized that agent to act. The current specification addresses this directly, where the launch version did not: version 0.1.0 treated delegation evidence as an open question, and version 0.2.0 names specific mechanisms. Read directly from the text, delegation evidence can be carried as an additional credential, a credential disclosed through the request's own DCQL query, an OAuth Token Exchange actor chain, a GNAP grant artifact, a Verifiable Intent credential, or another signed mandate or capability. The specification states, quoted verbatim, that delegation evidence composes best when it is scoped, time limited, replay resistant, and bound to the Agent Identifier and requested resource or action.

Read that sentence for exactly what it commits the protocol to. Composes best is a design recommendation for evidence a deployment chooses to attach. It is not a MUST level requirement that every x401 transaction carry delegation evidence with those properties, and the base protocol does not itself guarantee any of them are present. x401 makes delegation evidence composable with proof satisfaction. It does not make it automatic, and this record does not credit the generic specification with guaranteeing something it explicitly leaves to the deployment.

Proof's own implementation goes further than the base protocol requires

Everything above describes the generic, credential neutral specification. Proof's own product material, corroborated through repeated search passes because proof.com and x401.id are both blocked to direct fetch in this session's tooling environment, describes a considerably more specific implementation built on top of it. A human is verified once to an IAL2 standard, biometric plus government identity, enrolled in a cloud wallet, with that identity re bound per mandate rather than per session. That human signs a scoped mandate naming the agent, the merchant, an action category, an amount ceiling and a time window, cryptographically bound so the agent presenting it cannot exceed those terms. At the point of action, the agent presents the credential through OpenID4VP, and Proof's material states an action falling outside the mandate's parameters is rejected.

This is a real, specific, well described design. It is also Proof's own implementation, not a requirement the base x401 specification imposes on other credential issuers. The specification's own delegation evidence section names mechanisms, an OAuth actor chain, a GNAP artifact, a signed mandate among others, without prescribing which fields any signed mandate must carry. Proof's five named fields, agent, merchant, action category, amount ceiling, time window, are Proof's own product choice, not a base protocol field schema. A conforming x401 deployment built by a different issuer could express delegated scope through an entirely different set of fields, or none at all, since delegation evidence remains optional protocol machinery under the specification this record verified directly.

The Authority Provenance ledger

This is the part a launch announcement is never built to state, so Moona Intelligence separates it out deliberately, dimension by dimension, distinguishing what the generic protocol establishes from what only Proof's own implementation does, and marking what neither establishes as unknown rather than inferring it.

Authority grantor. The generic x401 specification is credential and issuer neutral, read directly this session: it does not require the credential subject behind a satisfied proof requirement to be a natural person, an organization, or any other specific kind of grantor. Proof's own implementation is narrower and specific: an IAL2 verified human is the grantor who signs the mandate. That is Proof's design choice, not a property of the base protocol, and this record does not universalize it to every possible x401 deployment.

Mandate or basis. Undocumented, at both levels. IAL2 verification, as Proof describes it, establishes who the signing human is. Nothing independently available to this session, in the base specification or in Proof's own corroborated material, establishes that the signing human actually held a corporate office, an account ownership right, a contractual authority or another organizational mandate entitling them to authorize the specific action the mandate describes. No organizational credential or signing authority credential feeding into x401 or Proof's mandate format was found. Identity of the grantor is documented. Legitimacy of the grant is not, and this record leaves it recorded as unknown rather than assumed.

Delegated scope. Documented only at the implementer level. Proof's material names agent, merchant, action category, amount ceiling and time window as mandate fields. The base specification, read directly, requires none of these; it defines how a Verifier composes a credential requirement and how delegation evidence can be optionally attached, leaving the actual content of any mandate to the issuer.

Explicit limits. Documented the same way: an amount ceiling and a time window appear in Proof's own mandate description. The base protocol defines no amount or time limit fields of its own.

Inherited permissions and assumptions. The specification keeps three things separate rather than letting one stand in for another: an application's own Authorization credential, a Verification Token recording that a route specific proof requirement was satisfied, and delegation evidence about who authorized the agent. It states directly that workload identity alone does not establish that an end user delegated authority to the agent, and that an ordinary Authorization credential should be preserved alongside, not replaced by, an x401 token. This record preserves that separation rather than collapsing it into a general claim that x401 proves authorization.

Revocation or modification. Undocumented. The specification states a Verification Token SHOULD be short lived and describes validation in terms of scope, audience, expiration and Agent binding, but this session found no revocation endpoint, no propagation rule, and no dedicated security considerations section addressing what happens to an already issued Verification Token if the credential or delegation evidence behind it is later revoked. Whether revoking an underlying mandate invalidates a reusable token immediately or only at its own expiry is left unknown by this record, because the specification leaves it unknown.

Challenge authority. The Verifier decides, for one specific request, whether presented proof is sufficient; the specification states it remains authoritative for proof validation regardless of how the Agent interprets the requirement. That is a different question from whether the original grantor, an issuer, a resource owner, an auditor or a regulator can later challenge or invalidate the delegation itself once accepted. Nothing read directly by this session names such a channel. This record does not confuse the Verifier's real time authority over one proof check with a broader, undocumented authority to challenge a delegation after the fact.

Recovery. Undocumented. The specification contains no dispute resolution, rollback, compensation or reversal language. It ends at the Verifier's decision to permit or refuse the protected operation. What happens after a permitted action has already executed, if that authority is later found to have been illegitimate, sits entirely outside what x401 defines, and Proof's own corroborated material does not fill that gap either. A rejected proof requirement is not recovery from an action that already executed under one that was accepted.

Provenance evidence quality. Layered, not uniform. Proof of grantor identity is real in Proof's implementation, IAL2 verification is a substantive check. Proof that a delegation artifact exists is real wherever a signed mandate or one of the named delegation evidence mechanisms is actually attached, which the base protocol does not require. Proof of delegated scope is real only as far as an implementer's own mandate fields define it. Proof that the grantor held legitimate mandate to delegate in the first place, proof that delegation remained valid at the moment of execution beyond a token's own expiry, and evidence available after execution for a dispute, are each undocumented by anything this session could independently verify. Moona Intelligence does not collapse these seven layers into a single claim that x401 proves authority. It proves some of them, for deployments that choose to build them in, and is silent on the rest.

Reviewers are not adopters, and named endorsement is not the same as unnamed adoption

The specification's own front matter, read directly this session, names Daniel Buchner of Proof and Bhushit Agarwal of Circle as editors, and Jacky Lao of Lightspark, Oliver Terbu and Tobias Looker of MATTR, Tim Cappalli of Okta, Nick Steele of OpenAI, Darren Louie and Adam Lemmon of Proof, and Tony England and Steven Sacia of Visa as reviewers. A commit message in the specification's own repository separately credits changes requested from Google, OpenAI and Okta's FIDO representatives, though Google does not appear in the formal reviewer list itself. None of this is Circle, Lightspark, MATTR, Okta, OpenAI, Visa or Google adopting, deploying or organizationally endorsing x401. It documents that named individuals affiliated with those organizations read and commented on draft text, which is real participation and not nothing, but is a different fact from institutional adoption.

Circle is the one exception this record found to that caution, and it deserves to be stated precisely because it is a stronger claim than mere review participation. Circle's own public statements, not Proof's characterization of Circle, describe Circle as proud to be an early adopter and co-endorser of x401, framing x402 as answering how an agent pays and x401 as answering who authorized the action. That is a company speaking for itself about its own participation. Beyond Circle, Proof's own corroborated material describes unnamed organizations in payments and enterprise insurance as already building on x401, including an unnamed Tier 1 insurer evaluating it for customer authorized agents filing claims, opening accounts and submitting applications. This record keeps those two categories separate: a named participant's own endorsement, and an unnamed vendor claim about unnamed adopters, and does not promote the second into the first.

Non repudiable is Proof's word

Proof's own material, as corroborated through this session's search passes, describes the evidence its implementation produces as non repudiable, binding a credential, an assurance level, scope and a challenge together at the moment of authorization into a record that exists before any dispute is filed. That is a real design goal, and worth taking seriously as one. It is also Proof's own characterization of its own system, attributed here to Proof rather than adopted as an independently established fact. Non repudiation in the strict cryptographic and legal sense requires an artifact a party cannot later credibly deny having produced under adversarial conditions. Nothing independently available to this session tests that property, and this record does not extend the claim beyond what Proof itself asserts.

Where this sits against what Moona Intelligence has already verified

GitLab's composite identity already owns how a human role and a service account role intersect inside one company's own execution surface, with no generic, portable protocol involved. Nuggets' Authority Control Plane already owns a vendor enforcement layer that signs a receipt for its own permit, deny or refer decision. Alipay's AHA protocol already owns how one human's authorization survives being passed through several agents inside one ecosystem before a payment executes. Rain's Agentic Payments Alliance already owns the admission that agent payment authority becoming an interoperability problem, across organizations that never saw the original delegation, is serious enough for competitors to convene over. BIND already owns a research proposal for binding a fresh human biometric to a specific agent identity and task scope at the moment of delegation. None of them, on the material this record could verify, does what x401 does: define a generic, credential neutral HTTP mechanism through which any protected resource, not one vendor's platform and not one company's own systems, can demand a route specific proof requirement and independently decide whether a presented result satisfies it, with delegation evidence, Agent binding and application authorization each left as separate, composable layers rather than one bundled claim. That is x401's distinct contribution, and it is why this record treats it as its own canonical rather than folding it into any of the above.

It is also why this record refuses to let that distinct contribution round up into more than the specification itself claims. An agent can now arrive at a protected resource holding a credential result that satisfies a route's proof requirement, verified by a Verifier that remains authoritative over that one decision. Whether that same credential also proves the credential subject was entitled to grant the authority being exercised, whether the delegation survives to the moment of execution, and what happens if it is later found not to have been legitimate, are questions the generic protocol leaves open by design, and questions Proof's own implementation answers only in part, for Proof's own product. The agent has a credential. Whether anyone can prove where the authority behind it actually came from still depends on what the deployment chose to build on top of x401, not on x401 itself.