What makes an agent payment controlled?
An agent payment is controlled when the agent can complete only the actions that an accountable business has authorized, within limits enforced outside the model. The agent should not receive an unrestricted card number, seed phrase, private key, or master account credential.
Start with the Agent Business Readiness Scan to identify missing entity, controller, authority, and provider prerequisites. For implementation support, see Controlled Payment Activation.
What controls belong in the stack?
No single setting is enough. Combine business authority, provider controls, application checks, and evidence.
| Control | Purpose | Evidence to retain |
|---|---|---|
| Identified agent | Prevent one deployment from borrowing another’s authority | Agent ID, environment, credential reference |
| Per-transaction cap | Limit the loss from one action | Configured limit and provider response |
| Period budget | Limit cumulative spend | Budget window and remaining amount |
| Counterparty rule | Restrict where money may go | Allowlist decision and merchant identity |
| Asset or currency rule | Prevent unexpected settlement paths | Allowed payment method and asset |
| Human approval | Escalate high-impact or unusual actions | Approver, time, request, and decision |
| Idempotency | Prevent duplicate charges on retries | Idempotency key and payment reference |
| Reconciliation | Match authority, payment, delivery, and receipt | Order, charge, output, and settlement records |
| Revocation | Stop future use quickly | Disable event and failed post-revocation test |
Limits should be enforced by the payment provider, wallet contract, or a deterministic server policy. A prompt that tells the model to stay under budget is useful context, but it is not a financial control.
What are scoped payment credentials?
A scoped credential can be used only under defined conditions. Stripe’s Shared Payment Tokens are designed to pass a payment credential for an agent-initiated purchase without exposing the underlying payment method directly to the seller or agent. Stripe describes the tokens as scoped to a transaction or merchant context, subject to its current product rules. (Stripe, Shared Payment Tokens)
Base Spend Permissions let a user authorize a trusted spender to move assets within limits after the user signs the permission. The spender can act without a new prompt for each permitted transfer, which makes the initial limit and revocation design especially important. (Coinbase Spend Permissions repository)
Provider features, eligibility, supported countries, assets, and preview status can change. Confirm the current official documentation and account availability before committing to a customer path.
Should each agent get a separate account or subaccount?
Isolation is usually safer than sharing one broad credential. A separate provider project, subaccount, virtual card, or wallet permission makes it easier to assign a budget, attribute transactions, revoke one agent, and investigate an incident without stopping every workflow.
The organization and controller remain accountable. Isolation is an operating control, not a claim that the agent owns the account or funds.
What should happen before the first live payment?
Use a low-value test that exercises the complete path:
- identify the organization, controller, and agent;
- approve a narrow authority with an expiry;
- configure the provider or wallet limits;
- make one permitted purchase;
- confirm the amount, counterparty, receipt, output, and settlement;
- attempt a deliberately disallowed amount or counterparty;
- revoke the permission or credential;
- repeat the original request and confirm it fails;
- document recovery and reauthorization.
Activation is not complete merely because an account or wallet exists. The allowed transaction, denied transaction, reconciliation, and revocation all need evidence.
How should human approval work?
Approval should be based on explicit conditions such as amount, counterparty, contract term, geography, risk class, or a change in payment destination. The approval request should show the exact action the agent wants to take, the final amount, the payee, the purpose, and the authority rule that triggered review.
Do not ask a person to approve a vague goal such as “continue the task.” Ask them to approve a specific bounded transaction. Record the decision separately from the model conversation.
How do x402 and MPP fit?
x402 and MPP are HTTP-based machine payment protocols intended for programmatic access to APIs or services. Both can use an HTTP 402 challenge and a retry with payment evidence, but they differ in credential and settlement options. See x402 vs MPP before selecting a route.
These protocols are a better fit for deterministic, low-value resources than for identity-bearing formation work, government fees, or high-touch services with staged refund boundaries. High-ticket services should normally use a quote, deposit, invoice, and human review.
Who should hold the keys and funds?
The customer or regulated provider should control the account and credentials. A formation or activation service may coordinate configuration, document controls, and observe a test, but it should not request seed phrases, take private keys, pool customer funds, or store reusable unrestricted credentials.
If a workflow cannot be implemented without giving an outside operator broad custody, pause and redesign the flow or use an appropriately licensed provider.
What is the next step?
Document the intended purchases, maximum exposure, countries, counterparties, payment methods, and approval owner. Use the readiness scan to find blockers, then request a Controlled Payment Activation assessment to compare provider paths and map each authority rule to a real enforcement point.
Last updated August 2026. This is general business and technical information, not legal, tax, financial, investment, or security advice. Provider approval is not guaranteed.
Primary sources:
