The hardest part of agent finance isn't getting an agent to make a payment. That part is technically solved. The hard part is making sure your agent only makes the payments it should — under the circumstances it should — with the right level of human oversight for each type of transaction. Building that correctly is the difference between an agent that occasionally requires manual intervention and one you're comfortable running in production with real treasury funds.
A payment policy engine is the component that sits between your agent's payment intent and the actual execution of a transaction. Every payment request flows through the policy engine before it touches the signing key. The engine evaluates the request against a set of rules and produces one of three outcomes: approve automatically, block outright, or route for human approval. Building this well requires thinking carefully about what each rule is protecting against.
The threat model you're designing for
Before you write a single policy rule, you need to know what you're protecting against. The threats in agent finance are different from traditional payment fraud:
- Prompt injection attacks. A malicious document or API response contains instructions that cause the agent to attempt a payment to an attacker-controlled wallet. Without counterparty controls, this succeeds.
- Runaway agent behaviour. A bug in your agent logic, a model misbehaviour, or an unexpected environment condition causes the agent to loop and attempt the same payment hundreds of times. Without velocity controls, this drains your wallet.
- Scope creep. Your agent is authorised to pay for API access but gradually "learns" (through fine-tuning or in-context pattern recognition) to initiate payments for things outside its defined scope. Without amount limits and counterparty whitelists, this is undetectable until the audit.
- Credential compromise. If an attacker gains access to your agent's execution environment, they can attempt to make payments through the agent's financial identity. Without wallet-level policy enforcement, application-layer controls won't help.
A well-designed policy engine is your defence against all four. The key is that it must be enforced at the right layer.
Core policy primitives — what each protects against
Amount limits. Per-transaction maximums and daily limits cap your maximum exposure from any single failure mode. Soft limits that trigger approval flow (rather than hard blocks) at lower thresholds give you visibility into edge cases before they become problems. Rule of thumb: set your hard limit at the maximum acceptable single loss, and your soft limit at the maximum you'd want to review before auto-approving.
Counterparty controls. A whitelist of approved recipients is the strongest protection against prompt injection attacks. If the target wallet isn't on the whitelist, the payment doesn't happen, regardless of what instructions the agent received. Default-block for unknown counterparties is the correct default — not default-allow. "Block unknown, alert on block" is the pattern that gives you visibility into unexpected payment attempts without automatic execution.
Approval thresholds. Above a defined amount, require human approval from a named approver with defined timeout behaviour. The timeout behaviour matters: what happens if the approver doesn't respond within the timeout window? Block is the correct default. Auto-approving on timeout defeats the purpose of requiring approval in the first place.
Velocity controls. More than N transactions in M minutes triggers review. This is your circuit breaker for runaway behaviour. The specific numbers depend on your expected transaction frequency — set them conservatively and adjust as you observe actual patterns.
Implementation with Proco
Here's a production-ready policy configuration for an accounts payable agent:
The explicit catch-all 'default': 'block' at the end is essential. Every policy should have a default block, not a default allow. If you add a new payment type that doesn't match any rule, you want it blocked and alerted — not silently approved.
Where to enforce — the architecture decision that defines your security model
A policy engine implemented in application code is only as secure as your application. An agent that can call payment functions directly can potentially bypass an application-layer policy engine through prompt injection, a logic bug, or a model misbehaviour. The policy is software, and software can have bugs or be manipulated.
Proco enforces policies at the wallet level, not the application level. The policy evaluation happens before the signing key is accessed. The agent can't bypass the policy by calling a different function, because the restriction isn't implemented as a function — it's implemented in the signing infrastructure below the application layer. Wallet-level enforcement is to policy engines what hardware security modules are to key storage: the security property holds even if everything above it is compromised.
This is the architecture distinction that matters for production enterprise deployment. Your CISO will ask: "If the agent is compromised, what's the blast radius?" With wallet-level policy enforcement, the answer is: "The attacker can only make transactions that the policy would have approved anyway." That's a meaningful constraint. With application-level enforcement, the answer is: "The attacker can make any transaction the signing key allows." That's a much wider blast radius.
Operational discipline — starting conservative and opening up
The most important operational practice for agent payment policies is to start more restrictive than you think you need. It is much easier to relax a policy as you build confidence than to explain why an agent made 10,000 unexpected transactions before anyone noticed. The asymmetry of regret is strong here: a policy that's too tight causes a few blocked transactions that get noticed and can be fixed. A policy that's too loose can cause serious damage before it's caught.
Start with a small whitelist of approved counterparties. Set your amount limits below what you think you'll need. Require approval for anything above a low threshold. Review the block log for the first two weeks. You'll learn more about your agent's payment patterns from two weeks of real operation than from any amount of upfront design. Once you understand the patterns, you can safely relax the constraints. The policy engine's alert and logging infrastructure is your feedback loop — use it.
Further reading: What Your Agent Needs Before Its First Live Transaction · The Agentic Finance Stack · Code examples on GitHub →