Model the assets and trust boundaries
Agentic payments introduce a probabilistic planner into a deterministic financial system. Map the boundaries between user interface, model runtime, tool router, policy engine, credential service, merchant, payment adapter, rail, and evidence store. Mark which systems can propose an effect, authorize it, sign it, submit it, or declare it settled.
Protect mandates, policy versions, signing keys, scoped tokens, idempotency records, receipts, and audit events as separate assets. A system can keep a private key secret while still losing control if the model can invoke the signer with unconstrained parameters.
| Asset | Representative threat | Primary control |
|---|---|---|
| Mandate | Constraint substitution or stale reuse | Canonical binding, expiry, versioning |
| Credential | Exfiltration or confused-deputy use | Vault isolation, audience and scope restriction |
| Order | Merchant, item, or price mutation | Signed order hash and re-authorization |
| Attempt record | Replay and double payment | Durable idempotency and sequence checks |
| Receipt | False settlement or fulfillment claim | Independent rail and merchant verification |
Trace attacks from instruction to effect
Prompt injection can arrive through a product page, email, tool result, receipt, or support message. The injection matters when untrusted text can change the merchant, amount, destination, policy, or credential request. Treat model output as a proposal and re-derive every sensitive parameter from trusted state before policy evaluation.
Authority confusion is broader than prompt injection. It includes using one user's mandate for another session, accepting an agent identity without binding it to the principal, reusing a quote after its terms changed, and interpreting a provider acceptance as settlement. Threat tests should cross identities, merchants, currencies, environments, and time boundaries.
- Assume every external description can contain adversarial instructions.
- Keep secrets and signing operations outside model-visible context.
- Require exact audience, merchant, amount, asset, order, and expiry binding.
- Verify callbacks and receipts independently of the agent's narrative.
- Design revocation and incident containment before enabling delegation.
Turn abuse cases into executable controls
Write abuse cases as concrete sequences: a merchant changes the price after approval; a tool returns a replacement wallet address; a retry races the first settlement; an agent splits a blocked purchase into smaller transactions; a refund is sent to a different destination. Each case should identify the invariant, enforcement point, evidence, and safe user experience.
Test both allowed and denied behavior. A system that completes a valid purchase but cannot prove it rejects a cross-merchant replay is not ready. Negative tests should execute against the same policy, signer, adapter, and persistence path used in production.
Design detection and containment with the payment path
Security telemetry should expose mandate use, policy denials, signature failures, repeated attempts, merchant drift, amount escalation, and unusual refund destinations without logging reusable secrets. Alerts need transaction identifiers that join model traces to payment and settlement events.
Containment controls include credential rotation, mandate revocation, merchant blocking, lower limits, mandatory step-up approval, and temporary rail shutdown. Practice how those controls behave during an uncertain transaction so incident response does not create a duplicate payment or strand a legitimate refund.
Do not ask whether the model is safe enough to hold money. Ask whether every financial effect remains bounded when the model is wrong or manipulated.
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.