AI Agent Payment Security: The Real Attack Surface
An agent that reads untrusted input and can also move money combines two properties that were previously separate. The main attack paths are prompt injection into a payment, counterparty substitution, key exfiltration, compromised tools, and poisoned memory. Containment comes from custody design, not from making the model more careful.
Why this is a new class of target
Two properties have historically lived apart. Systems that process untrusted input, such as web scrapers and mail handlers, do not hold spending authority. Systems that move money, such as payment services, do not read arbitrary text and act on its meaning.
An agent that browses, reads documents, calls tools, and pays combines both in one process. That combination is the whole security story, and it is why controls designed for either half do not cover it.
The crucial technical fact underneath is that a model cannot reliably separate data it was given from instructions it was given. Both arrive as text in the same window. Mitigations reduce the rate. None eliminate it, and treating any of them as a boundary is the mistake that turns a research problem into an incident.
So the design goal is not an agent that cannot be tricked. It is a system where being tricked costs a bounded, known amount and leaves a trail.
The attack paths that matter
Injection to payment. Text in a fetched page, an email, a ticket, or an API response that instructs the agent to pay. The most direct version asks for a transfer. The subtle version changes a parameter the agent was already going to use.
Counterparty substitution. Rather than increasing an amount, the attacker changes the destination. This is the highest value objective because the agent's own behavior remains normal, the spend stays within limits, and nothing looks anomalous except the recipient.
Key exfiltration. Key material in environment variables, config files, container images, or logs. Once an agent can read it, any injection that causes an outbound request can carry it away, and the loss is not bounded by any spending policy.
Compromised tools and dependencies. A tool server or library the agent trusts, returning manipulated data or executing on its behalf. The agent behaves correctly on bad input, which is why this evades behavioral monitoring.
Poisoned memory. An injected instruction written into durable state, so it executes on later runs, possibly long after the initial contact. This is injection with persistence and it is the hardest to detect, because the malicious content arrives from your own trusted store.
Replay. A previously valid signed payload resubmitted. Bounded by nonces and expiry when they exist, unbounded when they do not.
Developer and CI machines. Keys copied for testing, left in a shell history, or committed. Unglamorous, common, and responsible for a large share of real losses.
Why counterparty substitution deserves top billing
Amount-based controls catch amount-based attacks. A payment of the expected size, at the expected time, for the expected purpose, sent to a different address passes every control that reasons about magnitude. Only a destination allowlist stops it, which is why that rule is worth more than any spending cap.
Controls, in layers
Custody. Key material the agent cannot read. Custody in the OS keychain rather than in environment variables or files means exfiltration is not simply a matter of reading a value. This is the layer that turns a total loss into a bounded one.
Bounded authority. A spending float with a ceiling enforced by the credential. The agent cannot exceed it regardless of what it concludes, which is what makes the residual injection risk acceptable.
Destination allowlist. Explicit approval for new counterparties. The single highest value policy rule, for the reason above.
Role separation. The component that reads untrusted content should not hold spending tools. Passing conclusions rather than raw text between roles removes the direct path from hostile input to a payment.
Rate limits. Per hour and per day, so a loop or a slow drain hits a wall rather than continuing until someone notices.
Provenance on memory. Record where a stored fact came from, and treat anything derived from external content as untrusted when it is retrieved. Memory without provenance is an injection cache.
Verification before send. Where possible, check the destination and amount against the intent that produced them, in code, immediately before signing.
CryptoCadet implements the first two directly: a non-custodial USDC rail on Base where the agent spends from a session-key bounded float with custody in the OS keychain, supporting x402-style pay-per-call and ERC-20 subscriptions. Non-custodial matters here because it means no third party can be socially engineered into moving your funds either.
Assume compromise and plan the response
Write the incident path before you need it, because during an incident nobody designs well.
Revoke. You must be able to end an agent's spending authority in seconds, without the agent's cooperation and without moving funds. If revocation requires a deploy, it is not a control you can rely on under pressure.
Rotate. New session authority, new scope, and confirmation that the old one is dead rather than merely unused.
Reconcile. Compare intended purchases, sent payments, and settled transactions to establish what actually happened. Without per-payment attribution this step is impossible, which is the argument for instrumenting it before you need it.
Trace the entry point. Which content did the agent read, from where, and when. If you cannot answer that, the same attack works again tomorrow.
The realistic posture for anything unattended is that it will eventually do something you did not intend. Bounded authority, an allowlist, and an audit trail are what make that a bad afternoon rather than an existential event.
Frequently asked questions
- What is the main security risk of AI agents that can pay?
- The combination of reading untrusted input and holding spending authority in the same process. A model cannot reliably distinguish data from instructions, so any text the agent reads can attempt to direct a payment. Mitigations reduce the rate but do not eliminate it, which is why containment has to come from custody design.
- What attack should I defend against first?
- Counterparty substitution. Redirecting a payment is more valuable to an attacker than enlarging one, and it defeats every control that reasons about amounts: normal size, normal timing, normal purpose, different recipient. A destination allowlist requiring explicit approval for new counterparties is the highest value rule you can add.
- How should agent keys be stored?
- Where the agent cannot read them. Environment variables, config files, container images, and logs are all readable by a compromised or injected agent, and exfiltrated key material is not bounded by any spending policy. Custody in the OS keychain with session-scoped authority keeps the loss bounded to the float.
- Can agent memory be an attack vector?
- Yes, and it is the hardest to detect. An injected instruction written into durable state executes on later runs, arriving from your own trusted store rather than from an external source. Record provenance for stored facts and treat anything derived from external content as untrusted when retrieved.