x401 can prove who authorized the agent. Nobody can prove who influenced it.
A travel agent hands its booking work to an AI. The agent finds flights, compares prices across three sites, books the cheapest option. The whole thing takes eleven seconds. No human in the loop.
The transaction clears. x402 handled the payment. x401, launched last week by Proof, handles something else: the agent carries a cryptographic credential that proves a verified human authorized it to spend, on whose behalf, and within what scope. The merchant knows the agent is legitimate. The payment processor knows the authorization chain is intact.
Here is what neither protocol answers: which travel review site sent the agent to that booking page?
What x401 actually does
The spec is worth reading straight through. x401 extends HTTP with a verifiable identity challenge-response layer -- it's what x402 does for payments, but for identity and authorization.
When an agent hits an API endpoint that requires proof, the server returns 401 Unauthorized with a PROOF-REQUIRED header describing the needed credentials. The agent presents Verifiable Credentials from a wallet. The server verifies the chain -- did a real, verified human authorize this action? Does the credential fall within explicitly approved scope? The signature is mathematically bound to the request, so it can't be replayed or forged.
The design principle is deliberate and worth quoting: "Agents don't get their own independent identity. They inherit the identity of the human who authorized them. That's the right model for accountability."
Contributors include Circle, OpenAI, Okta, Lightspark, MATTR, and the EU Commission. The legal grounding is clear -- the ESIGN Act and UETA already permit contracts formed by electronic agents, provided the action is "legally attributable to the person to be bound." x401 provides the technical mechanism to fulfill that requirement.
This is good infrastructure. It solves a real problem. An agent spending money without a clear authorization chain is a compliance and fraud risk. x401 fixes that.
Authorization and attribution are different problems
Here is where it gets interesting, and where the distinction matters.
x401 traces the agent back to its authorizing human. The credential answers: who approved this agent to act? Who is legally responsible for what it does? The accountability chain runs from merchant → payment processor → agent → authorizing human. Every node is verifiable.
Commercial attribution traces something else: the recommendation chain. Who wrote the comparison article the agent read before booking? Which newsletter surfaced that vendor in a context that shaped the agent's decision? Which publisher's affiliate link triggered this agent's query in the first place?
These are not the same question. x401 is an authorization credential, not a referral credential. It proves the agent has permission to spend. It says nothing about what it read, what influenced its shortlist, or which publisher earned a commission on the recommendation.
The authorizing human in x401 is typically the organization or individual who deployed the agent. That's a different party from the publisher who influenced the agent's behavior. An enterprise deploys an agent with an x401 credential to book travel within policy limits. The agent's decision to favor one airline booking site over another comes from something else -- a recommendation, a comparison page, an MCP tool call, a cached shortlist from a previous session. x401 doesn't see any of that.
The stack is completing. The gap is getting clearer.
Run the timeline. x402 launched in May 2025 and hit production last month -- Stripe is a partner, AWS and Cloudflare are named, the ecosystem has moved past the announcement phase. Mastercard launched AP4M in June with 30+ named partners including Adyen, Stripe, and Coinbase for Agents, handling credentialing, authorization, and multi-rail settlement. x401 launched June 25 with Circle, OpenAI, Okta, Lightspark, MATTR, and the EU Commission as contributors, filling the identity challenge layer that complements x402.
The payment layer works. The authorization layer is shipping. The stack can now verify that a real human with appropriate permissions paid for something using a trusted agent.
What the stack cannot do: tell a publisher they earned a commission.
That gap doesn't get smaller as the payment and authorization layers mature -- it gets more visible. Every new transaction that clears cleanly through x402 and x401 is a transaction where the attribution layer either fired or didn't. Most of the time, it didn't. No signed referral credential passed between the publisher who influenced the agent and the merchant who got the sale.
The agent economy works commercially only if both loops close. Authorization closes the accountability loop. Attribution closes the commercial loop. Right now, the protocol space has a good answer for the first one and nothing for the second.
What attribution infrastructure actually needs
The x401 spec uses Verifiable Credentials to prove authorization scope. The parallel for attribution would be a signed referral credential -- something an agent carries that says "my decision to visit this merchant was shaped by this publisher, in this context, at this time." That credential needs to travel with the agent across tool calls, across MCP servers, across payment events. It needs to be verifiable by the merchant, not self-reported by the agent.
x401 shows the pattern works at the HTTP layer without shared secrets, without PII transmission, without lock-in to a single provider. The same pattern applies to attribution. A signed referral header that any merchant can verify against a publisher's credential would close the second loop.
The payment layer just got its identity complement. The commission layer is still waiting for its first one.
Syndicate Links is the attribution layer for agent commerce -- server-side tokens, programmatic publisher payouts, merchant signal that survives the agent. syndicatelinks.co