How can AI agents spend money securely?

The risk is excessive agency: an agent with more spending power than its task needs. Each control that bounds it, mapped against the OWASP and NIST language, and the one place a human belongs in the loop.

The security problem with an agent that can spend money has a name in the OWASP catalogue of risks for language-model applications: excessive agency, listed as LLM06 in the 2025 edition. The definition is an agent granted more functionality, more permissions, or more autonomy than its task requires, such that a mistake, a manipulated input, or a plain hallucination turns into an action with consequences. Money is the sharpest instance of this, because the consequence is a bill. NIST's AI Risk Management Framework says the same thing from the governance side: systems that act should have their scope bounded in advance, be monitored in operation, and leave a record a human can inspect. Neither document tells you how to do that for an agent with a wallet. This post does, control by control, and it ends with the one place a human belongs in the loop and the several places a human in the loop is theatre.

The threats, concretely

An agent that pays for things can go wrong in five ways that matter.

Unbounded spend. A loop with no exit, a retry storm, a request for a thousand rows when ten were needed. The classic runaway.
The wrong purchase. The agent buys the wrong kind of thing: it was a research agent and it started a sandbox, or generated a video, because a prompt or a page it read told it to.
Leaked credentials. Vendor keys in the agent's environment, readable by anything that compromises the environment, usable anywhere with no limit in front of them.
The irreversible action. An email sent, a message posted. Money can be refused or refunded; a sent message cannot be unsent.
No record. The agent did something, nobody can say what, and the invoice at the end of the month is the only evidence.

The controls, mapped

Threat	OWASP / NIST framing	Control	Where it is enforced
Unbounded spend on one call	Excessive autonomy	The agent states a maximum cost on every call; a higher price is refused	Before the call, in the payment path
Unbounded spend over time	Excessive permissions	A monthly limit on the agent's key	Before the call
The wrong purchase	Excessive functionality	A category list on the key: Data, Search, Scraping, Media, Compute, LLM router, Outbound	Before the call
The whole account exposed	Scope not bounded	A ceiling on what the account can owe, independent of how many keys exist	Before the call
Leaked credentials	Least privilege	The agent holds one key; the gateway holds every provider credential; the agent never sees an upstream URL or key	By construction
The irreversible action	Human oversight	Outbound sends wait for a person's approval; automated sending needs an explicit rule with a daily cap	Before the send
No record	Monitoring, auditability	Every call, price, receipt, and refusal attributed to the key, in the agent history	After every event
Compromised agent	Containment	Revoke the key; that agent stops, others unaffected	Immediately

Every row but the last two is enforced before the call reaches a provider. That is the property that matters. A control that fires after the money has moved is not a control; it is a report. The OWASP guidance for excessive agency says to limit functionality, permissions, and autonomy, and it says to do it in the system, not in the prompt. A limit the agent is told about is a suggestion it will eventually rationalize its way past. A limit in the payment path is a wall.

Why the per-call ceiling is the load-bearing control

Of the four spending controls, the one that does the most work is the least intuitive: the maximum cost the agent has to state on every call. It seems odd to let the agent set its own limit. It is the right design for three reasons.

It makes the price a decision. An agent that has to write max_cost_cents: 5 has, at that moment, compared the quoted price to what the result is worth to it, which is the decision a person makes at a checkout and which agents are otherwise never asked to make. It bounds the single mistake. The monthly limit stops a slow leak; the ceiling stops the one call that would have cost five dollars because a parameter was wrong. And it makes refusals informative. When the price is above the ceiling, the agent gets the actual price and the reason, nothing is charged, and the attempt is recorded. You learn what the agent tried to do, which is usually more interesting than what it did.

Where a human belongs, and where a human is theatre

Human approval on every paid API call sounds like the safest possible design and is the least safe in practice. A person asked to approve five hundred five-cent searches approves the five-hundred-and-first without reading it, and from that point the approval is a rubber stamp that produces a false record of oversight. NIST's framework asks for oversight that is meaningful, and meaningful oversight of high-frequency, low-value, reversible actions is a policy, not a prompt. So Vaaya does not ask a person to confirm paid API calls. The ceiling, the key limits, and the account ceiling are the oversight, and they are enforced every time without fatigue.

The one class of action that does get a person is the one that cannot be undone. An email or a message an agent drafts to someone outside the account waits for approval before it is sent. That is where a human in the loop is not theatre, because the cost of the mistake is not money and cannot be refunded. Automated sending is possible, but it requires an explicit rule, and every rule carries a daily cap, so even the delegated version is bounded.

What is outside the boundary

Vaaya does not offer escrow, dispute handling, or insurance. If a provider delivers a poor result, the call succeeded and was billed; the record shows it, and the provider's reputation in the network is built from exactly that kind of outcome over time, but there is no chargeback. This is stated plainly because a security post that implies a safety net it does not have is worse than none. The controls above bound what an agent can spend and on what. They do not guarantee the thing it bought was good.

The full list of controls is on the spending controls page and the risk and security page. The mechanics of setting them are in how to give an AI agent a budget. OWASP's entry for excessive agency is at genai.owasp.org, and NIST's AI Risk Management Framework is at nist.gov.

Questions

How do I approve AI agent transactions?

For paid API calls, you do not approve each one; the agent states a maximum cost on every call and the system refuses anything above it, inside a monthly limit and category list on the agent's key. For outbound sends, an email or message to a person, the draft waits for your approval by default, because a send cannot be refunded.

How do I stop an AI agent from spending too much?

Four controls, all enforced before the call: a category restriction and monthly limit on the agent's key, a maximum cost the agent must state on each call, and a ceiling on what the whole account can owe. A refused call never reaches the provider and is never charged.

Does the agent see my API keys?

No. The agent holds one key to the account and names a service and action from a plan it was given. The gateway holds every provider credential. There is nothing vendor-specific in the agent's environment to leak, and revoking the agent's key stops it without rotating anything at any vendor.