Verify AI agent transactions at the moment of decision
If an AI agent can propose a payment, booking, or order, the system must be able to answer one question in real time: is this agent permitted to perform this action right now, within explicit limits? Verification means returning a transaction-scoped YES/NO decision plus proof you can log.
Proof of permission
Permission must be encoded as an object (delegation/receipt), not implied by a token or session.
Stateless decisioning
Each transaction is evaluated independently from current context. No long-lived “trust me” state.
Replay-safe
Receipts/nonces can’t be reused to “double spend” authorization in agent workflows.
What must be verified (minimum)
- Agent identity: which agent instance is acting (identifier + key binding).
- Delegated scope: what the agent is allowed to do on behalf of a principal.
- Consent status: valid/unrevoked consent for this class of action (often via a consent receipt).
- Constraints: amount/currency, merchant/category, channel, time window, velocity caps.
- Policy outcome: issuer/merchant rules applied to this context.
- Replay safety: nonce/receipt reuse prevention (online ledger or bounded offline model).
Issuer vs merchant verification
Issuer-side (authorization)
Verify before returning an authorization response. Focus on consent, delegated scope, account standing, and risk signals.
Merchant-side (checkout)
Verify before order creation and value release. Focus on basket policy, agent identity, and permission constraints.
Transaction-time verification flow (reference)
- Construct context: action, amount, currency, merchant/category, timestamp, device/runtime signals.
- Attach permission object: consent receipt or delegation reference + agent ID.
- Verify: signature/provenance, expiry/revocation, scope match, constraint match, policy checks, replay checks.
- Decide: return
eligible: true|falseplus a proof record. - Log: store the proof with the payment/order/authorization record.
{
"agent_id": "agt_123",
"permission": { "type": "consent_receipt", "id": "cr_456" },
"transaction": { "action": "payment.authorise", "amount": 4200, "currency": "GBP", "merchant": "m_789" }
}
→
{ "eligible": true, "proof": "sha256:…", "reason": "in_scope" }
Next: build the page cluster
- Consent receipts and what a consent receipt is
- Proof of permission (core vocabulary page)
- Stateless verification (decision model)
- Consent receipt spec (reference)
- OAuth vs consent receipts (comparison intent)
FAQ
What should I log when verification returns YES?
Log the proof record (hash/ID), the receipt/delegation reference, policy version, and the transaction context used to decide. Don’t rely on UI screenshots.
Where does replay protection live?
Ideally in a nonce ledger that’s checked online. For offline flows, use freshness windows and reconcile nonces on reconnect.