Secure agent payment mandates: permission with limits

What should a payment mandate contain?

Start with the owner's intent, but turn it into terms a trusted service can check. A broad instruction such as “buy what the team needs” leaves too much unresolved. A narrower envelope makes the intended authority visible to the owner and meaningful to the payment system.

The exact model varies by use case. For example, a one-off purchase and a recurring invoice workflow need different budget and renewal semantics. An agent should not be able to expand its own mandate.

OAuth, OpenID Connect and wallet identity

OAuth 2.0 governs delegated API access. OpenID Connect adds a way for the client to establish the signed-in user's identity. Neither an ID token nor a generic API scope is a complete business authorization for a particular payment. See the OpenID Connect Core specification.

A system needs to distinguish the human owner, the software client and the acting agent. Token audience, privilege and lifetime should match the intended resource and action. The IETF OAuth security best current practice covers threats including token leakage and replay; implementation should use the protections appropriate to its client and flow.

A wallet presentation can supply identity evidence. It still needs a trusted issuer, valid presentation and appropriate request binding. Even correctly verified identity evidence does not, by itself, say that the owner approved a €300 payment to a new merchant.

Enforce the terms outside the agent

The payment-facing service should resolve the owner from a trusted session or credential, load the current mandate and validate the final payee, currency and amount. Descriptions from the agent and merchant-supplied labels are not substitutes for authoritative payment details.

Budget accounting needs to survive concurrent requests and retries. Two €30 requests must not both pass against €40 of remaining authority. A stable payment reference, a consistent reservation or accounting mechanism and reconciliation of uncertain outcomes help prevent accidental duplicate or excess spending.

Prompt injection is also an authority problem. Text in a web page, invoice or tool result must not be able to change the owner's limits or obtain broader credentials. When an input is untrusted, the safest action may be to prepare a proposal and ask for review.

A mandate does not replace bank authorization

Owner-to-agent delegation, API access and the payment provider's authorization are separate layers. The provider remains responsible for its applicable authentication and payment controls. PSD2 includes Strong Customer Authentication requirements; whether a particular flow or exemption is applicable cannot be inferred from an agent mandate. See the Commission's SCA overview.

Keep the human-facing approval understandable. Show the actual terms, recipient and price, and identify whether the person is approving one transaction or ongoing authority. Do not present a login event as proof that the person approved every later agent action.

Revocation and evidence are part of the design

Revocation should prevent new actions once it takes effect at the enforcement boundary. It does not automatically reverse a payment already accepted or settled. Cancellation, refunds and disputes are different processes, with their own authority and provider behavior.

An inspectable record connects the mandate version, agent identity, decision time, relevant payment details and provider reference. A refusal reason should explain which term failed. Keep only the identity and transaction information needed for the purpose; an audit trail should not become an unnecessary store of wallet credentials or access tokens.