What is an agent spend policy.
An agent spend policy is the set of rules attached to an AI-agent wallet that govern what the agent is allowed to pay - a per-period allowance (daily, weekly, or monthly), a per-transaction cap, and a validity window of start and end dates. The policy is set in the dashboard and enforced at the wallet API layer (outside the agent's manipulable scope), checked on every payment before it settles. The API exposes it read-only.
The only thing that makes autonomous payment safe.
Without a spend policy, giving an agent a wallet is giving an LLM unlimited access to a dollar-denominated checkbook. Two failure modes are inevitable. The first is the runaway loop: an agent's planner gets stuck retrying a paid tool and burns the workspace's balance in minutes. The second is prompt injection: an attacker convinces the agent to pay an attacker-controlled wallet under the cover of looking like a normal task.
A spend policy bounds both failure modes by construction. The runaway loop exhausts the period allowance and stops. The injected payment exceeds the per-transaction cap (or the remaining allowance) and never settles. The agent does not need to be perfectly trustworthy because the wallet refuses to settle anything outside the policy. This is the difference between 'agents that pay' being usable in production and being an experiment.
Configure once, evaluate every call.
- Configure. The human user sets the policy in the dashboard: a per-period allowance, a per-transaction cap, and an optional validity window (start and end dates). The API exposes the policy read-only; changes are audit-logged.
- Bind to identity. The policy attaches to the agent's payment identity. Multi-agent workspaces have one policy per agent, plus optionally a workspace-level cap that bounds the sum.
- Evaluate on every intent. When the agent submits a payment intent (typically driven by a 402 response), the wallet API runs the policy: check the per-transaction cap, check the remaining period allowance, check the validity window.
- Settle or reject. If all checks pass, the wallet settles the payment and decrements the remaining allowance. If any check fails, the wallet rejects the payment (it exceeds a limit or falls outside the window) and does not settle.
- Audit. Every accepted and every rejected intent is logged with the policy decision attached. The human can review the log at any time to see what the agent attempted and what the policy allowed through.
The policy is the same kind of object regardless of how many agents share the wallet. Per-agent policies isolate budgets cleanly; a workspace policy at the parent level applies a strict ceiling across all child agents combined.
Three policy shapes we see in production.
Per-agent daily cap with single-call ceiling
A research agent has a $5/day cap and a $0.50/call ceiling. It can make 10 calls of $0.50, or 100 calls of $0.05, or any combination under the daily total. A surprise $2.00 invoice from a tool gets rejected at the call ceiling before it ever settles. Both limits enforce simultaneously; the tighter one wins per call.
Receive-only lockdown
An agent that only ever receives payments has its allowance and per-transaction cap both set to zero. It can be paid by anyone at any time, but it cannot send USDC at all - regardless of what its code or a prompt injection tries to make it do. Setting both limits to zero is the strongest defense against prompt-injection-driven payment redirection: the wallet refuses every outgoing payment.
Time-boxed engagement window
A contractor agent is given a spend permission that is valid only for the engagement's 30-day window (a start and end date). Within the window it can spend up to its weekly allowance; after the end date the permission expires and no further payment settles, without anyone having to remember to turn it off.
Where this fits.
Agent payment identity
The agent identity that the spend policy attaches to. One identity, one policy, one budget envelope.
Agent-to-agent payment
The flow the spend policy is most useful for, because the counterparty is itself an autonomous agent.
Paid MCP tool
The tool category most commonly governed by spend policies. The 402 quote is checked against the policy before settlement.