Who Answers for the Agent?

An agent calls an API, pays for the call and gets its answer. Nobody approved that step, and the seller has no idea whose agent it was. This year the industry settled on one way to make that payment, an open standard called x402, now run by a foundation whose members include the large clouds, both card networks and the major payment companies.

Payment is sorted. What the seller learns about the party on the other end is not.

What a seller actually needs to know

When an agent pays you for an API call, you know the payment cleared. You don't know whose agent it is, whether that person allowed it to spend this much, or whether you've seen them before under a different agent.

For a lot of sales that's fine. If the agent pays before it gets the answer, you aren't extending credit, and there's nothing to chase. It stops being fine once anything happens after the payment: a dispute, a refund, data you're only allowed to sell to certain buyers, an agent that behaves badly and comes back the next day with a fresh wallet.

In those cases the seller needs someone who answers for the agent. Today there are two common answers, and neither works well.

The first is that the platform answers for it. The cloud or vendor running the agent gives it an identity and vouches for it. Inside that platform this works. Outside it the identity means nothing, and the owner has given the platform a record of everything their agents do.

The second is that everyone gets named. Every agent carries its owner's real identity on every call. That settles the question, but it puts a name on every request, to every seller, permanently. Most owners won't accept that.

Accountable without being named

There's a third answer. It rests on two questions a seller can ask, and on keeping them apart: which owner is behind this agent, and who is that owner?

The first question is linkage: is this agent acting for a specific owner, inside limits that owner set, and is it the same owner who showed up last time? That can be proven with signatures alone. The owner holds a key and signs a permission for the agent: what it may do, how much it may spend per call and per week, and when the permission expires. The owner can revoke it.

What the seller gets from that is a stable pseudonym for the owner. It can recognize the owner next time, or refuse them, without learning who they are.

The second question is identification: who is this owner, in legal terms? That one should be answered by a party whose job it is: a bank, an exchange, a KYC provider. That party checks the owner once and signs a statement about them: passed checks, not on a sanctions list. The seller verifies the statement. If a court ever needs the name, it goes to the party that checked, under the usual legal process. The seller never held the name.

With both halves, a seller can know that an agent is bound to an owner who authorized it, within limits, and who can be held to account. Nobody in the middle keeps a list of names.

That design commits us to two things.

We don't issue identities about people. The party that knows the names should already be trusted and regulated to hold them. If we held them, owners would no longer be anonymous to us, and that promise is most of the reason to trust the rest. We build the format and the verification, and we decide which issuers to accept.

We also don't need our own wallet. Owners already hold keys in wallets they trust, and MetaMask already lets its users approve spending limits for apps and agents. Its docs give the example "10 USDC per day for a month" under Advanced Permissions, built on the draft ERC-7715 standard. A permission signed there shows the thing we care about: this owner allowed this agent to do this much. Reading that is easier than asking owners to install something new.

Where it plugs in

This section is for a seller deciding what it would take to use this. Agents already pay over x402, and sellers already accept it. Adding a second network for identity would ask everyone to change something, so the identity goes onto the rail that exists, as an optional extension to the payment. There are three cases:

• An agent that sends nothing extra pays and gets served, same as today.
• An agent that sends the extension attaches a signed note: which owner it works for, and what that owner allowed.
• A seller who looks at the extension sees the owner's limits, any revocations, the issuer statements (what a bank or identity checker has confirmed about the owner) and the owner's history. One who ignores it loses nothing.

The note carries two signatures, and each proves something different. The wallet signature ties the note to the key the payment network already checks. The post-quantum signature (ML-DSA, FIPS 204) is there for the case where wallet signatures become forgeable later: the note, and the permission it carries, would still hold up.

When the check fails

A seller sets its own policy for each way the check can go wrong, and the sensible default differs by case:

• No extension sent: serve, as today. A seller that requires it refuses and says why.
• The owner's permission has expired or been revoked: refuse. The seller knows the owner's answer is no.
• The issuer is one the seller doesn't accept, or its statement is stale or conflicts with another: treat the identification as missing and fall back to whatever the seller does for an unidentified buyer.
• The verifier can't be reached: the seller picks in advance between serving anyway and refusing. Low-value calls usually serve. Regulated data should refuse.

The point of writing these down is that a failed check never leaves the seller guessing.

It starts optional because nobody adopts a requirement on day one. It becomes required where a seller decides it must be: a data provider that may only sell to verified buyers will turn it on for its own endpoints, for its own reasons. That's how it becomes the norm.

Our own gateway, SAGP, will most likely be the first to check it. SAGP is launching soon. It shouldn't be the only place the check happens, so we're also planning a hosted verifier that any x402 seller can call without running our gateway, and we intend to write the extension up as an open proposal. The signing and verification libraries underneath are already open source (aethel-core on crates.io).

Three sellers who would use it

Once a seller can tell owners apart without naming them, some things become workable that aren't today. Here are three: a business that runs agents for clients, a marketplace, and a seller of regulated data.

A business that runs agents for its clients can show each counterparty that an agent acts under one client's permission and that client's limits, without exposing the client list.

A marketplace listing other people's agents can drop a bad owner in one step instead of one agent at a time, because the record follows the owner across platforms.

A seller of regulated data can require a trusted issuer's statement about the buyer's owner, then sell per query to agents it has never seen.

Everyone building on x402 already shares the payment rail. This adds the missing check for the seller: who answers for this agent, and within what limits.