Payment envelopes versus rendered statements: two models of agent intent
A payment mandate answers a bounded question well: may this agent spend this much, here, within this window. The question enterprises actually face is broader, and the envelope model does not stretch to cover it.
Do payment mandates cover everything an AI agent does?
No. Selective-disclosure JWTs, as used in card-network agentic payment mandates, bind payment parameters: a ceiling, a merchant scope, a validity window. Adding a beneficiary, changing bank details or granting another agent access are not payments, sit outside the envelope, and are usually where the loss originates.
- Selective disclosure solves a genuine privacy problem in payments: proving a constraint without revealing the underlying value.
- The envelope model binds payment parameters. Actions that are not payments — recipient changes, permission grants, data exports — fall outside it.
- Rendering the whole effect covers the general case at the cost of privacy properties selective disclosure provides. Neither is strictly better.
Part of Agent tool-call gating
What SD-JWT actually provides
Selective disclosure lets a holder present a credential while revealing only some of its claims, and lets a verifier check a predicate without learning the value behind it. In payments this is genuinely useful: a merchant can confirm an agent is authorised up to a limit without learning the limit.
The mechanism is sound and the privacy benefit is real. Nothing below disputes that.
The two models side by side
| Property | Payment envelope (SD-JWT) | Rendered statement |
|---|---|---|
| Signed content | Payment constraints: amount ceiling, merchant scope, validity window | The canonical form of the action as shown to the human |
| Scope | Payments | Any action expressible as structured data |
| Privacy | Strong — claims disclosed selectively | Weaker — the verifier sees the whole statement |
| Granularity | A bounded class of payments | One specific effect |
| Verifier needs | Issuer trust anchor, disclosure handling | Issuer JWKS, canonicalisation |
| Fits existing rails | Well — designed into payment flows | Requires an approval step in the application |
Read the privacy row carefully. The rendered-statement model is worse on privacy, and that is a real cost rather than a rhetorical concession. Where selective disclosure fits the problem, it is the better tool.
Where the envelope stops
Consider a sequence an agent might perform in an accounts-payable system.
- Add a new beneficiary record.
- Update the bank details on that record.
- Schedule a payment to it.
- Grant a second agent access to the payment queue.
Step three is a payment and sits inside the envelope. Steps one, two and four are not payments and sit outside it entirely — and steps one and two are where the loss originates. A mandate that bounds the payment perfectly does nothing about the beneficiary that should never have existed.
This is not a flaw in the specification. It is a scope boundary, and it is stated in the specification. The problem is deployment: enterprises adopt a payment mandate and believe they have covered agent authorisation.
What the rendered model does differently
# The envelope binds parameters of a payment
{ "max_amount": 5000, "currency": "USD",
"merchant": "acme-supplies", "not_after": "2026-07-31" }
# The statement binds an effect, whatever kind it is
{ "action": "beneficiary.bank_details.update",
"beneficiary": "Acme Supplies Ltd",
"account_from": "****4417", "account_to": "****9023",
"routing": "021000021", "effective": "immediate" }
# digest = SHA-256(JCS(statement)) — signed by the human who saw itThe second object is not a payment and has no natural home in a payment mandate. It is also the object that matters most, because a changed bank detail redirects every future payment regardless of how well each individual payment was authorised.
How they compose
The honest answer is that these are complementary rather than competing, and the sensible architecture uses both.
| Action type | Appropriate mechanism |
|---|---|
| Routine agent purchase within a budget | Payment mandate — bounded, private, low friction |
| Change to payment instructions | Rendered statement — the effect is what matters and privacy is not the constraint |
| Permission grant to another agent | Rendered statement — outside any payment envelope |
| High-value one-off transfer | Rendered statement, with the mandate as an outer bound |
An organisation that treats the mandate as its whole agent-authorisation story has covered one row of that table.
Questions worth asking a vendor
- Which actions does this cover, and which does it explicitly not cover?
- What was displayed to the human at authorisation, and is it derived from the signed object or written separately?
- Can a third party verify a presented credential without calling your service?
- What happens to actions taken in the same session that fall outside the envelope?
The fourth question is the one that surfaces the gap, and it is rarely on a vendor's slide.
Where we are wrong
The rendered-statement model trades privacy for generality, and in retail payment contexts that trade is often the wrong way round. A consumer buying from a merchant has a legitimate interest in the merchant not learning their spending limits, and selective disclosure serves that interest in a way rendering does not.
The argument here is about scope, not about superiority. Use the envelope where the action is a payment and privacy matters. Use the statement where the action is an effect that a human must be accountable for.
The privacy property, stated fairly
Selective disclosure lets a holder prove a constraint without revealing the value behind it. A merchant can confirm an agent is authorised up to a limit without learning the limit. That is a genuine benefit, it is the right tool for retail payments, and the rendered-statement model is worse on exactly this axis.
| Action | Better mechanism | Why |
|---|---|---|
| Routine agent purchase inside a budget | Payment mandate | Bounded, private, low friction |
| Change to payment instructions | Rendered statement | The effect is the point; privacy is not the constraint |
| Permission grant to another agent | Rendered statement | No payment envelope contains it |
| High-value one-off transfer | Rendered statement, mandate as outer bound | Both properties wanted |
Objections and honest limits
“The mandate can be extended to cover other actions.” In principle any structured constraint can be signed. In practice these specifications are scoped to payments, and extending one to the general case means rebuilding it as a general case.
“Rendering leaks data.” It does. The verifier sees the statement. Where that is unacceptable, selective disclosure is the better fit — this is a real trade, not a rhetorical concession.
The question that surfaces the gap, and rarely appears on a vendor slide: what happens to actions taken in the same session that fall outside the envelope?
Questions for an agentic payment vendor
- Which actions does this cover, explicitly? And which does it explicitly not cover. Get the second list too.
- What was displayed at authorisation? And is that display derived from the signed object, or written separately?
- Can a third party verify without calling you? If not, the mandate is evidence only while you are a customer.
- What covers the non-payment actions? Beneficiary creation, bank detail changes and permission grants are where the loss starts.
Terms used here
- Selective disclosure
- Presenting a credential while revealing only some claims, so a verifier can check a predicate without learning the underlying value.
- Payment mandate
- A signed envelope bounding what an agent may spend: ceiling, merchant scope, validity window.
- Rendered statement
- The canonical form of a specific action as it was displayed to the human, hashed and signed, so the effect rather than the class is what was authorised.
Frequently asked questions
Is SD-JWT the wrong technology? No. Selective disclosure solves a real privacy problem well. The limitation is that payment envelopes bind payment parameters, and most consequential agent actions are not payments.
Can a mandate be extended to cover non-payment actions? In principle any structured constraint can be signed. In practice payment mandate specifications are scoped to payments, and extending them means rebuilding the general case.
Which should we deploy? Both, for different action classes. Mandates for bounded agent spending, rendered statements for changes to payment instructions, permissions and other irreversible effects.
Does the rendered model leak data? The verifier sees the statement. Where that is unacceptable, selective disclosure is the better fit — this is a genuine trade-off rather than a concession.
Where does the loss usually start? With the beneficiary record and its bank details — created or changed before any payment is scheduled, and outside every payment envelope.
Where this fits in Manav
Manav signs the rendered effect, whatever kind of action it is, and the executing service recomputes the digest before acting. It sits under a payment mandate rather than replacing it: the mandate bounds the spend, the receipt covers the change that redirects it.