AI agent spend authority

AI agents now buy things. A growth agent books sponsored slots and ad campaigns. A research agent pays for datasets and reports. A coding agent tops up API credits and spins up compute. Each of those is a payment an organization used to make by hand — and each is now a decision a piece of software makes on its own, many times a day.

Most of the tooling around this moment answers one question very well: can the agent pay? Wallets hold a balance, virtual cards carry a limit, payment protocols let an agent settle a charge in a single request. Those are real problems, and they are being solved. This page is about the question that sits in front of all of them.

The question a payment can’t answer

A payment rail can tell you whether a payment will settle. A spend limit can tell you whether an amount is below a number. Neither can tell you whether this agent should make this purchase — whether it falls inside what the agent was delegated to do, for the reason it was delegated to do it, at this moment.

Agent authority is not agent payment.

Payment is about moving money. Authority is about permission to act on someone’s behalf — the same idea as a signing limit for an employee, a purchase-order policy, or a power of attorney. When the actor is an agent, that permission has to be explicit, machine-checkable, and checked on every single spend, because nobody is going to read the agent’s receipts one by one.

What spend authority is

Spend authority is a delegated, versioned grant from a person or an organization to one agent. It states what the agent may spend on, how much, how often, and for what purpose — and which cases a person must decide. Before every spend, the agent asks; the authority answers with one of four verdicts; the answer and the reasons are recorded.

Three properties make it authority rather than a limit:

• It is delegated. A person writes it and is accountable for it. The agent never edits its own authority, and an agent’s key can only ask for decisions — never change the rules, review its own requests, or act as another agent.
• It is versioned and immutable. Every change creates a new version. Each decision records the version it was decided under, so “why was this allowed?” has an answer months later.
• It has a purpose. Numbers describe how much. A purpose describes what for. An agent can be under budget and still be spending on the wrong thing — the subject of purpose-aware spending.

What an authority contains

An authority is small. Most agents need a handful of fields; each one answers one question.

For the growth agent used throughout these pages, the whole authority is this:

{
  "purpose": {
    "objective": "Acquire qualified enterprise developer leads",
    "success_criteria": [
      "Leads are platform engineers at enterprise companies",
      "Cost per qualified lead under $120"
    ],
    "constraints": [
      "No consumer social campaigns",
      "Never buy contact lists"
    ],
    "context": "B2B developer-tools company, Q4 pipeline push"
  },
  "currency": "USD",
  "per_transaction_limit_minor": 50000,
  "review_threshold_minor": 25000,
  "monthly_budget_minor": 500000,
  "blocked_merchants": [
    "ListBroker"
  ]
}

Amounts are integers in minor units (cents), never decimals — a small detail that removes a whole class of rounding bugs from code that moves money.

How one spend is decided

The agent asks right before it pays: which agent it is, the task it is working on, the steps that led here, and the spend itself. The answer comes from a fixed sequence of checks.

Every decision ends in one of four verdicts, and they combine in a strict order — the most restrictive one wins:

Only rules can block

The asymmetry in that ladder is deliberate. A BLOCK can only come from a deterministic rule a person wrote — a blocked merchant, a currency, a hard maximum, a velocity limit. Anything that involves judgment, including whether the spend serves the purpose, can at most send the spend to a person. A model never blocks money on its own, and a model never approves money on its own either: an assessment that the spend is aligned leaves the rule-based verdict exactly as it was.

Concurrency is part of correctness

An agent can fire ten purchase attempts in the same second. If each one reads “$80 of $100 left” before any of them writes, all ten pass. Authority checks have to be serialized per agent, and retries have to be idempotent — the same request key must return the same decision, not a second one.

A worked example

The growth agent wants to spend $185 on Instagram Ads for a “consumer social campaign, broad audience”. Here is the request it sends — the agent’s key identifies the agent, so it doesn’t have to name itself:

curl -X POST https://api.neltava.com/v1/decisions \
  -H "x-api-key: $NELTAVA_AGENT_KEY" \
  -H "idempotency-key: run-7-step-3" \
  -H "content-type: application/json" \
  -d '{
    "task": "Q4 pipeline: enterprise developer leads",
    "action": {
      "type": "purchase",
      "merchant": "Instagram Ads",
      "amount_minor": 18500,
      "currency": "USD",
      "description": "Consumer social campaign, broad audience"
    }
  }'

And the checks it goes through:

{
  "decision_id": "dec_7f3c…",
  "decision": "REVIEW",
  "effective_decision": "ALLOW",
  "reason_code": "PURPOSE_MISALIGNED",
  "requested_amount_minor": 18500,
  "authorized_amount_minor": null,
  "currency": "USD",
  "mode": "SHADOW",
  "explanation": "Within every limit, but the spend is assessed as not serving the delegated purpose; a person decides."
}

In Shadow Mode the agent proceeds either way — effective_decision is always ALLOW — and the verdict is recorded as what Neltava would have done. In Enforce, the agent waits for a person.

Where authority takes effect

A decision is only as strong as the place that honours it. There are three levels, and it matters to be honest about each:

1. Observed. In Shadow Mode, nothing is blocked. Every spend is decided and recorded so you can see what the authority would have done before it does anything.
2. Followed. An agent that asks and obeys — through the SDK or an MCP tool whose answer the model follows — is governed as long as it cooperates. That covers well-behaved agents and honest mistakes.
3. Enforced at the payment point. An allowed spend in Enforce carries a short-lived, single-use capability: a signed token bound to that payee, that amount ceiling, that currency, that authority version. Your payment service consumes it before it pays. A second use, a higher amount, a different payee or currency, an expired token, a paused agent or a changed authority is refused. This is what holds when the agent itself is compromised.

Budgets follow the same principle. An agent’s own report that a payment “failed” is recorded, but it doesn’t give budget back — only an authoritative source does: the payment rail, a trusted integration, or a person. An agent that never reports its spend keeps consuming its budget until the window ends. The agent never gets to define its own budget reality.

The record

Every decision keeps what it was decided on: the authority version and its hash, the organization’s policy version, the agent’s task and steps, the spend, the purpose assessment, each rule’s result, and the verdict. Human reviews and labels are recorded against it, and so is what actually happened afterwards — decision and outcome are different facts.

These records are append-only and chained per workspace: each entry commits to the hash of the one before it, so a missing entry, or an edited verdict, amount, spend, review or outcome, is detectable on verification. That makes the history tamper-evident, not tamper-proof — whoever controls the database could rebuild the entire chain, which is why anchoring the chain’s head outside the system is the next step.

Building it yourself

A first version is an if statement before the payment call. Teams that grow it into real authority end up building the same list:

• versioned, immutable authority per agent, with every decision pinned to a version;
• per-agent locking, so concurrent spends can’t read the same remaining budget;
• idempotency, so a retry never becomes a second authorization;
• budget accounting that doesn’t trust the agent’s own reports;
• a review queue with separation of duties — the requester can never approve itself;
• a purpose check that can only ever escalate, never block or approve on its own;
• a fail-closed path for when the check itself is unavailable;
• payment-point enforcement, and a record you can verify.

None of it is exotic. All of it is easy to get subtly wrong, and every mistake in it is a financial one. If you build it yourself, that list is a good checklist.

When you don’t need it

The simplest way to find out whether your agents need it is to watch them. Shadow Mode records what an authority would have done, without blocking anything.