AI agent spending controls

Controls are questions

Every spending control is a question asked of every spend. “Is it under $500?” “Is this merchant on the list?” “Is there budget left this month?” Thinking of controls this way makes two things obvious: which questions your setup asks, and — more important — which ones it never asks.

This page lists the controls an agent’s spend authority can contain, what each one answers, which verdict it can produce, and where each one stops being enough.

Every control at a glance

Notice the pattern in the last column. The controls that can BLOCK are the ones with a crisp, deterministic answer: a currency, a list, a count, a date. The ones that involve judgment or a trade-off — amounts near a limit, a doubtful purpose — send the spend to a person or cap it. That is a design rule, not an accident.

Allow, cap, review or block

Controls combine into one verdict, and the most restrictive wins:

When capping beats reviewing

Some spends can be made smaller without losing their point: ad budget, API credits, a top-up. If the agent marks a spend as limitable, exceeding a limit, threshold or remaining budget caps it instead of sending it to a person — the agent may spend the safe amount now. It can also name a minimum below which a capped spend is useless, in which case the spend goes to review instead.

import { Neltava } from "neltava";

const neltava = new Neltava(); // NELTAVA_AGENT_KEY

const d = await neltava.authorize({
  task: "Q4 pipeline: enterprise developer leads",
  action: {
    merchant: "Platform Weekly",
    amount: 900.00,
    currency: "USD",
    description: "Sponsored slots reaching platform engineers at enterprise companies",
  },
  limitable: true,
});

if (d.proceed) {
  // pay d.amount — in Enforce, through your payment adapter with d.capability
}

{
  "decision_id": "dec_7f3c…",
  "decision": "LIMIT",
  "effective_decision": "LIMIT",
  "reason_code": "LIMIT_APPLIED",
  "requested_amount_minor": 90000,
  "authorized_amount_minor": 25000,
  "currency": "USD",
  "mode": "ENFORCE",
  "explanation": "Limited: 900.00 USD requested; 250.00 USD may be spent autonomously."
}

The agent asked for $900 of sponsored slots. Its transaction limit is $500 and its review threshold $250, so it may spend $250 autonomously — authorized_amount_minor — and nothing more without a person.

Two layers: organization and agent

Controls live in two places, and the stricter one always applies:

• Organization policy applies to every agent: prohibited merchants, blocked categories, a hard maximum per transaction, the currency the organization transacts in, a trusted merchant-to-category mapping, and whether purpose evaluation is on.
• Agent authority narrows it for one agent: its limits, budgets, lists, velocity, validity and purpose.

Organization prohibitions are unioned with the agent’s — an agent can never allow what the organization forbids — and the hard maximum is the lower of the two. Both are versioned: every decision records which organization policy version and which authority version it was decided under.

Declared vs. trusted facts

Most of what a control checks comes from the agent’s own request: the merchant’s name, the category, the description. Those are claims. Controls have to be designed so that a claim can make a decision stricter, but never looser.

• Categories. A trusted category — from the organization’s merchant mapping, or a verified attribute from your own systems — decides. A category the agent merely declares can only restrict: a declared blocked category is honoured, a declared allowed one is not taken on faith, and a declared category that contradicts the trusted one goes to a person.
• Merchant names. Matching ignores case, spacing, punctuation and legal-form suffixes — “Instagram-Ads, Inc.” is “Instagram Ads” — and names containing control or invisible characters are refused outright. But a name is still a name. An allowlist is strict — anything not on it is outside authority, however it is spelled. A blocklist only catches the names on it: a merchant the agent describes differently won’t match. For payees that matter, use an allowlist.
• Payee identity. Where the payment rail has a stable id for the payee — an account, a domain — send it. In Enforce, the spend’s single-use capability binds to that id, so a different payee is refused at the payment point whatever it is called.

Budgets that don’t trust the agent

A budget is only as good as its accounting. Three rules keep it honest:

1. Unreported spend keeps counting. An allowed spend reserves its amount immediately. If the agent never reports what happened, the reservation keeps counting against the budget until the window ends — it never quietly expires back into available money.
2. The larger number wins. A spend counts at its reserved amount or its reported executed amount, whichever is larger. An agent that reports paying more than it was allowed does not get the difference for free.
3. The agent can’t give itself budget back. An agent’s report that a payment failed is recorded, but only an authoritative source releases budget: the payment rail, a trusted integration, or a person.

Concurrent spends are serialized per agent, so ten simultaneous requests can’t all read the same remaining budget, and retries are idempotent, so a retry never counts twice.

What controls can’t do

They can’t see purpose

Every control above checks a number or a list. None of them can tell that a $185 consumer campaign doesn’t serve a B2B lead-generation budget. That is what a purpose check is for.

Per-spend thresholds can be split — windowed totals can’t

A review threshold applies to each spend. An agent that makes five $200 purchases instead of one $1,000 purchase passes a $250 threshold five times. That is what windowed totals are for: “at most $500 to one payee in any 24 hours” sends the third $200 to a person, however the purchases are split. Totals are kept per payee (the rail’s payee id when there is one, otherwise the merchant’s reduced name), per trusted category — spends without a trusted category share one bucket, so a changed category claim can’t split a total — or for the whole agent.

A payee described under an entirely different name is a different payee to a per-payee total; the agent-wide total still bounds it, and an allowlist or a payee id closes it.

A starting set

For a new agent, before you know its traffic:

1. Currency, per-transaction limit and monthly budget — the minimum that bounds any mistake.
2. A review threshold below the limit, so large spends get a person without being refused.
3. Velocity — a count per hour that a looping agent will hit long before your budget.
4. A per-payee 24-hour total — so a purchase split into small ones still reaches a person.
5. A purpose — objective, success criteria, constraints.
6. An allowlist, once you know the vendors the agent legitimately uses.

Then run it in Shadow Mode for a week. The report shows which controls would have fired, and you can replay the recorded decisions against a changed authority before you save it.

When you don’t need it