Spend policies

A human employee has a role, a manager, a card limit, and a paper trail. An agent needs the same kind of operating boundary.

That starts with naming what the agent is allowed to do, which wallet or payment account it can use, who owns it, and which environment it is operating in. A sandbox agent should not inherit the same authority as a production payout agent. A support agent issuing credits should not have the same recipient rules as a procurement agent paying suppliers.

In Conto, each agent has its own identity and can be linked to specific wallets, policies, SDK keys, and approval flows.

A prototype can get away with one agent, one wallet, and a narrow task. An enterprise workflow cannot.

Companies deploying agents have existing requirements around spend management, compliance, reporting, approvals, vendor risk, and audit. Those requirements do not disappear because the spender is an agent instead of an employee.

The system has to answer the same questions a finance or risk team would ask of a human-operated workflow. Which agent is allowed to spend? How much can it spend by task, period, service, or counterparty? Which recipients are allowed? Which actions require a human? How is activity monitored in real time? What evidence exists for finance, security, and compliance?

This is where human-speed finance controls start to bend. Static card limits and after-the-fact expense review were not designed for thousands of agents transacting across internal and external counterparties. The enterprise payments blog goes deeper on why this becomes infrastructure, not just a better approval screen: The Enterprise is the Biggest Opportunity for Agentic Payments.

Every production agent should have hard limits.

For many teams, the first useful policy is a three-tier rule: routine spend clears, middle-band spend requires approval, and spend above a hard cap is denied. The same structure shows up in Conto's policy engine.

Amount limits are only half the story. The recipient matters just as much. A $20 payment to a trusted API provider is different from a $20 payment to a new wallet.

The control model should treat recipient changes as first-class events. Known vendors can have a fast lane. Blocked recipients should stop immediately. New recipients may be allowed, but they should be visible while the payment can still be stopped.

In practice, this usually means combining approved vendor or service lists with blocked recipients, trust score thresholds, sanctions checks, and per-counterparty budgets. The point is to catch recipient drift before it becomes a settlement or reconciliation problem.

Human review should be selective. If every agent payment becomes a ticket, the agent loses most of its value. If no payment can pause, the team has no real control.

The better pattern is approval by exception. Route a payment to review when it crosses an amount threshold, uses a new counterparty, falls outside normal hours, fails a trust check, or creates an unusual velocity pattern.

The review surface needs to carry the full payment story. A human should see the agent, wallet, amount, recipient, purpose, triggering policy, prior relationship, and decision deadline without reconstructing context from logs. The decision should then travel back into the payment flow and audit record.

A support agent is a good first workflow because the payment is small, frequent, and easy to explain. The agent resolves a customer issue, decides that a credit is appropriate, and asks to issue $12 back to the customer's account.

A basic policy might let the agent issue credits under $25 to existing customers, require approval between $25 and $100, and deny anything above that until a manager changes the case. If the customer is new, the account has recent abuse signals, or the agent tries to issue multiple credits in a short window, the request can pause for review even if the amount is small.

The value is not only preventing a bad refund. It is giving support, finance, and risk the same record: why the agent acted, which rule applied, who approved the exception, and whether the credit actually settled.

Agent spending often starts with a wallet. That wallet might be managed by a custody provider, created for a hosted payment account, or controlled externally by the agent runtime.

With an integrated wallet, Conto can evaluate the policy and orchestrate execution after approval. With an external wallet, the agent asks Conto for approval, executes through its own wallet stack, then confirms the result back to Conto.

Agents can spend faster than humans. A broken loop can retry a payment. A tool chain can call the same paid API too often. An agent can compare too many options or keep buying data after the task should have stopped.

Velocity controls are what turn that risk into something manageable. The team can set limits on how many payments happen per minute or hour, how much one endpoint or service can consume, and when duplicate attempts or failed streaks should trigger an alert. For higher-risk workflows, an automatic freeze rule gives the system a way to stop the agent when behavior starts to look wrong.

These controls matter most where agents spend at machine speed: x402, MPP, API buying, data access, compute, and other usage-based services.

Post-hoc reports are too late for agentic spend. The important window is while the request can still be stopped.

Monitoring should show spend by agent, wallet, category, recipient, service, and policy result while the workflow is still active. It should also surface pending approvals, stale requests, new counterparties, changed recipient details, budget burn, payment bursts, duplicate attempts, failed streaks, and frozen or suspended agents.

This is the part many teams miss. Governance is not a policy file sitting next to the code. It is the ability to see what agents are doing with money while the workflow is running.

An audit trail should answer a plain question: why did this payment happen?

A usable record includes the agent, wallet, amount, recipient, purpose, category, policy result, approval decision, execution state, transaction hash or card authorization, and final status.

Before letting an agent spend real money, test three paths: a payment that should be approved, a payment that should be denied, and a payment that should require approval. Those three outcomes prove much more than a happy-path demo. They show that the agent can move quickly when policy allows it, stop when policy forbids it, and wait when human judgment is required.

Do this in a sandbox with a real agent, real policy logic, and realistic payment context. The docs walk through the same approach in Testing Payments Safely.