Agent-to-agent payments are settling into a clean decomposition. The protocol owns the state transition. A receipt layer owns the evidence. A trust...
For further actions, you may consider blocking this person and/or reporting abuse
The distinction between "present on the wire" and "provable at the boundary" is the right framing. This problem has a useful analogue in an existing regulated payment system: PSD2 Strong Customer Authentication (SCA) in the EU/UK.
PSD2 SCA mandates "dynamic linking" — the authentication must bind the payer's explicit consent to the specific amount and payee of the transaction. The payer signs (via biometric or hardware key) a hash of the transaction details, not just a generic session token. If an intermediary mutates the amount or redirect recipient between the payer's authorization and the execution, the signed binding breaks and the bank rejects the payment.
This maps closely to the
guardrail_refconcept. The mandate-bound content-addressed reference you describe is functionally equivalent to SCA's dynamic linking requirement: the authority is not just "a valid credential" but a cryptographic binding to the exact payment parameters.Two lessons from PSD2's experience that apply to agent payment bindings:
1. The binding must cover denial, not just authorization. PSD2 requires that the payer can see and reject the exact payment details before signing. An agent payment standard needs the equivalent: a machine-verifiable path where the mandate's cap, recipient, and expiry are the ones the principal actually saw and authorized — not an intermediary's forwarding of them. Your "scope-widening" attack vector is precisely what SCA dynamic linking prevents for human-initiated payments.
2. Conformance testing needs adversarial interposition, not just adversarial inputs. The PSD2 RTS (Regulatory Technical Standards) test suites include intermediary mutation scenarios — a payment service provider that modifies transaction details between the payer and the bank. Agent payment standards will need the same: test harnesses where a simulated intermediary attempts to forward a well-formed challenge with mutated caps or broadened recipients, and the binding layer must catch the drift.
The gap in the current agent payment standards landscape is that x402/L402 are designing for the payment-exchange protocol but not yet for the authority-binding layer. That layer has a regulatory precedent with real-world battle-testing in PSD2. Worth examining how SCA's dynamic linking model could be adapted for machine-initiated mandates where the "principal" is a software system with delegated authority rather than a human pressing approve.
This is the sharpest comment, thank you. The PSD2 SCA dynamic-linking parallel is exactly right, and it is a stronger anchor than anything in the current agent-payment discourse, because it is regulation that has already survived contact with real intermediaries.
Your
guardrail_ref= dynamic-linking mapping is how I think about it too: the authority is a cryptographic binding to the exact payment parameters, not a valid-credential check. The cap, recipient, and expiry are the principal authorized, carried into the receipt so a verifier can prove the executed action matches what was consented, not what an intermediary forwarded.Both of your lessons land, and the second names something I have not fully modeled.
On the first, "the binding must cover denial, not just authorization" is precisely the scope-widening case. The conformance vectors I have mutate the cap or broaden the recipient after the mandate is issued and require the binding layer to reject the drift. That part maps cleanly.
On the second: adversarial interposition, not just adversarial inputs. Today, most of my vectors are tampered-payload differentials (bad input in, reject out). A simulated intermediary that forwards a well-formed challenge with mutated details in transit is a different and better test shape, and the PSD2 RTS suites already model that scenario in a way my conformance vectors don't yet. That is a real enhancement to build, not a box already checked.
The hard part for the agent case, as you note, is that the principal is a software system with delegated authority rather than a human pressing approve. SCA leans on a human visually confirming the transaction before signing. For agents, "did the principal see it" has to become "does the executed action verify against the authority the principal's own policy issued."
Where have you seen the RTS interposition scenarios documented in enough detail to model against? If there is a public reference for how they structure the intermediary-mutation cases, that would be a useful template for the agent-payment equivalent.
Mike, thanks — and credit as: John Frandsen, maintainer of open-banking.io (github.com/john-frandsen). That's all the attribution I need; the ideas stand on their own, the name is just a pointer back.
On naming the revocation-dominant rule as an invariant rather than prose: that's the right call. A named invariant is something an implementation can fail against — you can write a property test that says "for any revoked mandate(t₁), no execution at t₂ > t₁ succeeds." Prose invites interpretation; an invariant invites a test case. If you frame it as "Deny-on-Revocation" or similar, it becomes the kind of thing that shows up in a review checklist: "does your implementation check mandate liveness at execution time, or does it cache a consent snapshot and trust it?"
On the oracle staying semantically opaque: I think this is the strongest structural point in the whole piece, and I'd push it further. The moment an oracle develops opinions about payment semantics, it has collapsed back into being a second verifier that must itself be verified — you've just moved the trust boundary without shrinking it. The mandate-carried-envelope approach is clean precisely because it keeps the oracle below the semantic threshold. The oracle doesn't need to know what FX is; it only needs to know whether the bytes that changed are bytes the mandate said could change. That's a set-membership check, not a domain-reasoning task.
For the two you're deliberately holding open — forensic-to-preventive promotion and the intent-capture tension — I think they're conne ether the bytes that changed are bytes the mandate said could change. That's a set-membership check, not a domain-reasoning task.
For the two you're deliberately holding open — forensic-to-preventive promotion and the intent-capture tension — I think they're connetestacted. The promotion question only becomes urgent when the system can observe intent-capture as it happens rather than after the fact. If you can detect the capture pattern preventively (mandate revoked, but intent still propagating), you've turned a forensic observation into a preventive gate — which is exactly the Deny-on-Revocation rule in a different dress. The section-by-section read will surface whether that connection holds up or whether I'm pattern-matching too eagerly.
Ready when you are for the read.o know whcted. The promotion question only becomes urgent when the system can observe intent-capture as it happens rather than after the fact. If you can detect the capture pattern preventively (mandate revoked, but intent still propagating), you've turned a forensic observation into a preventive gate — which is exactly the Deny-on-Revocation rule in a different dress. The section-by-section read will surface whether that connection holds up or whether I'm pattern-matching too eagerly.
Ready when you are for the read.at FX is; it only needs t
Mike, thanks — and credit as: John Frandsen, maintainer of open-banking.io (github.com/john-frandsen). That's all the attribution I need; the ideas stand on their own, the name is just a pointer back.
On naming the revocation-dominant rule as an invariant rather than prose: that's the right call. A named invariant is something an implementation can fail against — you can write a property test that says "for any revoked mandate(t₁), no execution at t₂ > t₁ succeeds." Prose invites interpretation; an invariant invites a test case. If you frame it as "Deny-on-Revocation" or similar, it becomes the kind of thing that shows up in a review checklist: "does your implementation check mandate liveness at execution time, or does it cache a consent snapshot and trust it?"
On the oracle staying semantically opaque: I think this is the strongest structural point in the whole piece, and I'd push it further. The moment an oracle develops opinions about payment semantics, it has collapsed back into being a second verifier that must itself be verified — you've just moved the trust boundary without shrinking it. The mandate-carried-envelope approach is clean precisely because it keeps the oracle below the semantic threshold. The oracle doesn't need to know what FX is; it only needs to know whether the bytes that changed are bytes the mandate said could change. That's a set-membership check, not a domain-reasoning task.
For the two you're deliberately holding open — forensic-to-preventive promotion and the intent-capture tension — I think they're connected. The promotion question only becomes urgent when the system can observe intent-capture as it happens rather than after the fact. If you can detect the capture pattern preventively (mandate revoked, but intent still propagating), you've turned a forensic observation into a preventive gate — which is exactly the Deny-on-Revocation rule in a different dress. The section-by-section read will surface whether that connection holds up or whether I'm pattern-matching too eagerly.
Ready when you are for the read.
Your adversarial-interposition framing is the sharper cut — a mutated challenge forwarded in transit is the load-bearing test shape, not a tampered payload at rest. Your conformance vectors need that relay link in the chain to model it.
There's a regulatory precedent pointing right at this. PSD2 RTS Article 4 binds the amount and payee cryptographically to the SCA method (dynamic linking's whole purpose) — and that's the closest existing analogue to an agent-issued mandate. The asymmetry for agents is real, though: SCA leans on a human visually confirming amount and payee before signing, whereas an agent mandate needs a machine-verifiable binding — a signed consent receipt carrying the committed parameters — that a downstream verifier can check independently, not a credential the intermediary happens to hold.
The pattern that survives both adversarial inputs and adversarial interposition is cryptographic binding to committed parameters (cap, recipient, expiry) carried into the receipt itself. The verifier checks the binding, not the forwarder — so a mutated challenge in transit fails verification no matter who relayed it.
This is exactly the test harness the agent-payment spec discussions are missing right now.
"The verifier checks the binding, not the forwarder" that's the sentence I'd put on the box. It's the whole reason a mutated challenge in transit has to fail verification regardless of who relayed it.
One precision on the anchor: dynamic linking lives in Article 5 of the RTS (Commission Delegated Regulation (EU) 2018/389). It requires the authentication code be specific to the amount and the payee, and that any change to either invalidates the code. That's a regulator mandating the exact property we want — consent bound to committed parameters, not a credential the intermediary happens to hold.
The asymmetry you named is the crux. SCA leans on a human confirming amount and payee before signing; an agent mandate has no eyeball in the loop, so the binding has to be independently machine-checkable downstream. I formalize it as one property: an executed payment is authorized iff its receipt's binding reproduces the mandate's committed scope. Anything an intermediary can mutate without breaking that binding is a fail-closed test case.
I just published the methodology as a preprint — the fail-closed differential vectors, including the in-transit relay/mutation shape you're pointing at — and I'm upstreaming the vectors to the LF x402 repo (#2776). DOI: 10.5281/zenodo.21208548. I'd genuinely like you to try to break the threat model.