The attribution gap in agent-mediated payments

When an AI agent autonomously pays for an API, the payment settles on-chain with a cryptographic signature. That signature proves a key authorized the spend. It does not prove a legal person did.

For most of the agent-economy tooling being built right now, that distinction is quietly elided. It is the kind of gap that becomes a liability the first time an agent makes a bad purchase, over-spends a budget, or does something its principal never authorized.

The gap, in one sentence

A signature binds a key to a statement, not a person to a statement. The moment you let an autonomous agent hold the signing key — which is the entire premise of agent-mediated payments — those two statements stop being interchangeable.

Three ways the gap shows up in practice

1. The key is held by an agent, not the person.

In agent-mediated payment flows, the signing key is typically held by an autonomous agent acting on behalf of a principal — a company, a DAO, an individual. The agent constructs and signs the payment. So the real chain of authority is:

principal → operator → agent → key

Most current payment models cover only the last hop (key → signature), and at most note that "a key is not a legal person." The full delegation chain is left unmodeled.

2. Most payers are EOAs, not Smart Accounts.

If your answer to the attribution problem is "use a Smart Account / operator delegation chain," you have just excluded the dominant case. Most agent payers today are plain externally-owned accounts, funded directly. Attribution should work identically for an EOA as for a Smart Account — a principal should not have to deploy a Smart Account just to be attributable.

3. The seller needs attribution in-band, at transaction time — not post-hoc.

This is the subtle one. If the principal's identity is only recorded in an audit receipt (say, a transparency log entry) after the fact, then the seller cannot use it to make the correct decision at the moment of payment.

Concrete example: EU reverse-charge VAT applies only if the buyer is a VAT-registered business in the correct member state. The seller has to know who the buyer is at transaction time to select the right tax regime. Post-hoc attribution means the seller's in-band decision is a guess.

What a minimal fix looks like

A principalAttribution object, carried in-band, signed by the principal's own key:

{
  "principalId": "urn:vat:FR32123456789",
  "scheme": "vat-eu | did | ens | legal-entity",
  "scope": "pay-per-call; service=audit; max=1000 USD/mo",
  "nonce": "a1b2c3",
  "exp": "2026-10-01T00:00:00Z"
}

Three properties make this work:

• Signed by the principal's key — an EOA or a Smart Account, it doesn't matter.
• Carried twice — in the transaction declaration (for the seller's good-faith check) and in the audit receipt (for later verifiability). Two copies of one fact, two different consumers.
• Scoped, not blanket — scope + nonce + exp make it a delegation with bounds. That also limits the blast radius of a compromised agent.

Why this matters beyond tax

• Liability. If an agent over-spends, who is on the hook? Without principal attribution, the answer is "whoever controls the key" — which may be an unincorporated agent runtime with no assets.
• Trust. A reputation score for "this buyer pays its bills" needs to anchor to a stable principal identity, not a rotating agent key.
• Compliance. Tax regime selection is the concrete case, but the same attribution is required by any jurisdiction that wants to know who transacted.

The N-hop problem

Delegation is rarely one hop. It's agent → operator → principal, or deeper. Each hop needs its own scope, nonce, and expiry — and the receipt should record the chain, not a single terminal identifier. Otherwise two distinct legal relationships collapse into one.

Where this is going

This is an active spec discussion, and now is the right time to get the shape right — before agent payments reach a volume where "who authorized this" is a question a lawyer asks rather than a curiosity. If you are building agent-payment rails, the cheapest time to add principal attribution is before the first real money flows.