The Payment Labs Agentic Payments Control Plane governs AI agents that access financial data or initiate payments. It registers each agent, verifies the authority a person or organisation has delegated, evaluates policy and risk at runtime, issues single-use authorisations bound to the exact action, and routes approved payments to the provider on any rail.
Why AI agents that move money need a control plane
AI agents break three assumptions that payment controls rely on: a person is present when the payment is made, a credential identifies that person, and the instruction can be trusted. Six technical gaps follow, and each needs a control enforced in the payment path rather than inside the agent.
Shared, standing credentials. Agents often run under shared service accounts or long-lived provider tokens, so actions cannot be attributed to one agent and a single compromise exposes every connected account. The control plane registers each agent with its own key pair, verifies proof of possession on every request, and keeps provider credentials inside the execution gateway, never with the agent.
Human-presence controls do not transfer. Strong customer authentication and session-based approval assume a person at the point of payment, and delegation chains across user, platform, agent and sub-agent are not yet covered by a settled standard. The control plane evaluates the mandate and its limits on every request instead of trusting an earlier login.
Authority is not identity. Authenticating an agent says who is calling, not whose authority it holds or how far it extends. Mandates are purpose-bound, time-bound and revocable, intersected with organisation policy, with step-up authentication at creation. One agent credential can serve many users because each principal keeps a separate mandate.
Instructions can be manipulated. Prompt injection or a compromised tool can change a payee or an amount, and instant rails are irrevocable. The control plane applies limit, velocity, counterparty and anomaly rules deterministically before execution, denies by default, and issues a single-use, short-lived authorisation bound to the exact amount, beneficiary and instrument, so it cannot be replayed or redirected.
Retries and unreliable signals. Agents retry, and provider notifications can be forged or arrive out of order. Execution is idempotent, and a payment reaches its final state only when the provider corroborates it, never on an uncorroborated webhook alone.
Evidence and disputes. Reconstructing who authorised what, under which policy version and risk signals, takes more than application logs. Every decision is written to append-only, hash-chained evidence with reason codes, supporting audit, incident response and redress.
How the control plane works
Every request follows the same nine-step path, whether it asks to read data or to move money.
Built for every payment rail
The control plane separates the decision from the execution. It decides whether an action is permitted. Provider adapters then route it to the institution that executes on the relevant rail, so the same controls apply wherever the money moves.
Illustrative scenario: a treasury operating more than 100 agents
Without a control plane, a treasury running 100 agents can accumulate fragmented identities, credentials, data permissions, bank integrations and monitoring surfaces. With one, each agent has a defined scope:
