Key takeaways
- Give each agent its own wallet and a small budget: the balance is a hard ceiling on what it can spend.
- Require human approval above a set limit, and check the item, seller, quantity and price before approving.
- Keep secrets server-side, rotate them, and verify every fulfillment call against a settled sale.
- Proof bound to each transaction shows what was paid, by whom and under which authorization; it does not show the decision was correct.
- Write down who owns each control, because policy scope, data accuracy and review stay with your organization.
Step by step
- Write the agent's spending authorityRecord what each agent may buy, from which sellers, up to what amount, and who approves above that amount.
- Segregate wallets and fund a small budgetGive the agent its own wallet, apart from the primary wallet, and fund it with only what the mandate allows.
- Set the approval thresholdSet an auto-approve limit and require human approval, by passkey or phone app, for anything above it.
- Assign roles and protect secretsLimit who can see or move funds on each wallet, keep credentials in a secret store, and plan rotation.
- Verify every fulfillmentOn the seller side, check each fulfillment call's transaction id against a settled sale; on the buyer side, check receipts before any retry.
- Export and reconcile recordsKeep transaction ids and receipts, export the wallet ledger, and match it to your books on a set schedule.
- Test revocationRehearse revoking an API key, rotating a secret and stopping an agent's funding before you need to do it for real.
What are agentic payments risk controls?
Agentic payments risk controls are the limits, approvals, key protections and records that govern money an AI agent can move. They answer the four questions an auditor asks: who authorized the agent, how much could it spend, what did it pay for, and can you prove it?
Most of the control set is familiar from treasury and payments operations. The actor is what changes. An agent works at machine speed, can retry without asking, and may write its own account of what it did. TODAQ Press puts the evidence problem bluntly: "A log generated after the fact by the same system that acted answers nothing" (Settlement Without Proof).
This guide maps each risk to a control and to the evidence that control leaves. It uses Qatom's controls as the worked example, with each step linked to the Capabilities Index.
Which risks do AI agent payment controls need to cover?
Start with a risk register. Each row below names a risk, the control that addresses it, and the evidence the control leaves for review.
| Risk | Control | Evidence it leaves |
|---|---|---|
| Agent spends beyond its mandate | Separate agent wallet with a small budget (A3, A8) | Approved transfer into the agent wallet; agent wallet ledger |
| Large or unexpected purchase | Auto-approve limit, with approval required above it (A14) | No settlement without approval; transaction id and receipt |
| Paying the wrong seller or a test listing | Check item, seller, quantity and price before approving (A31) | Receipt names the item and amount (A15) |
| Silent double charge from a retry | Treat every retry as a new charge; check first (A28) | One receipt per intended purchase; matching balance |
| Too many people can move funds | Role-based access per wallet (C29) | Role assignments for each twin |
| Leaked fulfillment secret | Secret header, secret store, rotation (B12, B24) | Direct calls without the header get 404 |
| Compromised API key | Revocable API keys; server-only credentials (B29, S2) | Your key inventory and revocation records |
| Replayed or forged fulfillment call | Verify X-Qatom-Transaction-Id against the settled sale (B20) | Served ids matched to settled sales |
| Disputed or altered history | Proof-bound transaction files (C7, C8) | Downloadable .toda file, verifiable offline |
| Records missing at audit | Ledger export and emailed receipts (C9, A17) | CSV ledger; receipt emails |
How do you set AI agent spending authority?
AI agent spending authority is the mandate: what the agent may buy, from whom, up to what amount, and who approves beyond it. Write it down per agent, with a named human owner. The Bank of England's Bank Underground blog, as reported by TODAQ Press in The Invisible Shelf, notes that legal responsibility for an agent's actions remains with the human deployer.
Then enforce the mandate in two layers.
The budget. In Qatom, each user has a primary wallet and a separate agent wallet, called twins. The agent can never spend more than its twin holds, and never touches the primary wallet or a card (A3). Moving funds into it from the primary wallet is an approved transfer: nothing moves until the owner approves (A8).
The approval threshold. Purchases under the auto-approve limit settle without a prompt; above it, a person approves each one by passkey or phone app (A14). Approval links expire after about 15 minutes and belong to one account. For a cart, if a price changes after approval, nothing more is charged and the approver is asked again (A34).
Kong's talk "From Tool Calls to Revenue" at MCP Dev Summit Toronto 2026 framed why metering must sit in the request path: "a meter that cannot say no is accounting, not control."
How should wallets and duties be segregated?
Segregation limits the blast radius of any one mistake. Apply it to wallets and to people.
- Agent and owner. Keep the agent wallet apart from the primary wallet, and fund it like petty cash.
- Per product. Give each paid product its own twin, with a standing distribution sweeping revenue to the primary (C17, C21).
- People. Use role-based access to set who can see or move funds on each twin (C29). Sending funds needs the Transfer role (C14), and so does a bank cash-out (C26).
- Bank details. The account owner types banking details; an agent never does (C25).
One gap to train for: the approval screen does not name the paying wallet. Approvers must confirm they are signed in to the account they mean to pay from (A31).
How do you protect keys and secrets?
Treat every credential an agent or endpoint touches as a secret with an owner, a store and a rotation plan.
- Client credentials stay on the server, never in a browser, app or repo (S2).
- Fulfillment tokens live in the host's secret store; the endpoint checks the Authorization header with a constant-time compare and answers 404 when it is wrong (B3). Sensitive header values are never shown again after saving (B12).
- Rotation uses a short overlap so no call fails (B24). API keys are revocable (B29).
- Passkeys make each sign-in and approval one tap on the approver's own device; an agent never creates or uses one (S11).
Never put secrets in endpoint URLs, chat, tickets or listings. Other dashboard users can see endpoint URLs (B2).
How do you verify every fulfillment?
Verification runs on both sides of each sale.
Seller side. For anything expensive to serve, read the X-Qatom-Transaction-Id header on each fulfillment call, look up the sale, refuse unknown ids or ids for another item, and keep the ids already served (B20). This stops replayed or forged calls.
Buyer side. Every purchase returns a transaction id and an emailed receipt with proof of purchase (A15, A17). A retry is a new charge, and a call the seller rejects can still be charged (A28). Before any retry, the agent should check the last receipt and the balance.
What does the proof show, and what does it not?
Qatom transactions carry cryptographic proof bound to the transaction and its settlement at execution. Settlement and the verifiable record are one operation, so there is no separate record to reconcile later. The proof is built on the TODA file protocol, whose double-spend prevention is a published theorem (Simple Rigs Hold Fast). Be precise about its scope.
| Proves | Does not prove |
|---|---|
| What was executed, paid and settled | That the agent's decision was correct |
| Who paid, and under which authorization | That the agent stayed within its intended policy scope |
| That no conflicting version of the history was produced | That the original data or judgment was accurate |
| That the history was not altered or substituted afterwards | A system-wide view for macro-prudential monitoring |
| That any party can verify it, offline, without trusting the originator | That a regulator has accepted this form of record |
TODAQ Press states the first limit in its own words: "It cannot guarantee that an autonomous decision was correct, or that the agent acted within its intended policy scope" (When The Transaction Becomes The Record). Supervisors are also not yet familiar with rigging trees, and regulators have not formally opined on such records. Your policy controls fill these gaps.
What records should you keep and export?
Keep records that an outside party can check without your systems.
- The transaction id and receipt email for every purchase.
- The wallet ledger, exported as CSV (C9).
- The .toda file for transactions under review. Its integrity can be verified and its provenance history inspected (C7, C8). The proof travels inside the file, so verification can run locally and offline.
- Distribution runs, with per-payee transfers (C20).
The Qatom Console shows TODA files, provenance and verification per twin. TODAQ Press describes an exportable "Transaction Binder" (The Agentic Economy's Missing Middle) that can be shared with a regulator or audit firm and verified offline. Visibility is by consent: you choose who sees the full record.
Add your own records of mandates, approval policy and role changes. Those sit outside the payment proof. For how this fits wider logging, see the AI agent audit trail guide.
How do you revoke access and reconcile?
Revocation. Rehearse it before go-live. Revoke the agent's API keys (B29), rotate fulfillment secrets (B24), remove roles (C29) and stop funding the agent wallet, whose balance caps further spending. Expired approval links cannot be reused (A14).
Reconciliation. Because the record is created with settlement, reconciliation becomes a check against your own books. Match the ledger export to receipts, confirm one receipt per intended purchase, and read seller revenue by API (GET /v4/catalog/revenue, B22). Two operational rules: a transfer API call that returns 202 has moved the money and is never retried (S2), and a submitted bank cash-out cannot yet be canceled (C26).
Which deployment model fits your risk appetite?
Qatom runs hosted, in your VPC, on-premises or air-gapped. RBC holds the reserve funds backing USD inside Qatom and supports bank on-ramp and off-ramp transfers.
| Deployment | Typical reason to choose it |
|---|---|
| Hosted | Fastest start; lowest operating load |
| VPC | Network and data stay inside your cloud boundary |
| On-premises | Infrastructure stays under your own operations team |
| Air-gapped | No external network; offline verification of files still works |
Agentic payments compliance depends on your sector, jurisdiction and use case, so confirm with your counsel which obligations apply. The AI governance framework guide maps NIST AI RMF, ISO/IEC 42001, the EU AI Act and OSFI E-23.
What is the CISO checklist for AI agents?
Use this order when you approve agentic payments risk controls for a first deployment.
- Name each agent, its owner and its written spending authority.
- Create a separate agent wallet and fund only the mandated budget.
- Set the auto-approve limit and train approvers to check item, seller, quantity, price and account.
- Assign roles per wallet; keep transfer and cash-out rights narrow.
- Store credentials server-side and schedule rotation.
- Require fulfillment verification for anything costly to serve.
- Set the record set, export schedule and retention period.
- Rehearse revocation and run a test reconciliation.
- Choose the deployment model and document why.
Further reading
- TODAQ Press, Settlement Without Proof (19 May 2026)
- TODAQ Press, You Cannot Audit a Probability: The Agentic AI Trust Wall (12 May 2026)
- TODAQ Press, The Agentic Economy's Missing Middle (7 Aug 2026)
- Rigging Specifications and Simple Rigs Hold Fast
Next steps
- Read the overview for risk and assurance teams: Qatom assurance.
- See the controls and records live: book an enterprise demo.
- Walk the buyer controls step by step in how to let an AI agent make purchases.