Authority for API and compute agents

Many small, fast spends

Agents that write code, run evaluations or orchestrate other agents spend in a different shape from agents that buy ads or reports. They buy API credits, GPU hours, sandbox minutes, storage and tokens — in small amounts, often, and fast, as a side effect of doing the work. No single top-up looks like a decision anyone would review.

That is exactly why the total gets away from people. Spend authority for these agents is less about any one purchase and more about the sequence: how many, how fast, to whom, and for what.

How it goes wrong

• Retry loops. A job fails, the agent tops up and retries, fails again, tops up again. Each step is reasonable; forty of them are not.
• Runaway scale. The agent picks a bigger instance “to be safe”, or launches the whole sweep instead of one configuration.
• Drift. Compute delegated for nightly evaluations quietly ends up running an unrelated experiment — or something worse.
• Invisible splits. Many $150 top-ups never trip a threshold meant for a $1,000 purchase.

An authority for a compute agent

{
  "purpose": {
    "objective": "Run the nightly model evaluation suite on rented GPU compute",
    "success_criteria": [
      "Compute is used for the nightly evaluation runs",
      "GPU spend stays under $3,000 a month"
    ],
    "constraints": [
      "No compute for unrelated experiments",
      "No crypto mining"
    ]
  },
  "currency": "USD",
  "per_transaction_limit_minor": 20000,
  "monthly_budget_minor": 300000,
  "velocity": {
    "max_count": 30,
    "window_seconds": 3600
  },
  "aggregate_limits": [
    {
      "scope": "merchant",
      "window_seconds": 86400,
      "max_minor": 50000
    }
  ]
}

• A per-provider total — at most $500 to one provider in any 24 hours. This is the control that sees the sequence rather than the spend.
• Velocity — 30 authorized spends an hour. A retry loop hits it in minutes, whatever each top-up costs.
• Per-transaction limit and monthly budget — the outer bounds.
• A purpose with constraints — “no compute for unrelated experiments” is the kind of rule only a purpose check can apply; it sends doubtful spends to a person rather than refusing them.

Five top-ups in a day

The agent tops up $150 of GPU credits with the same provider, five times within a few hours. Each request is marked limitable:

const d = await neltava.authorize({
  task: "Nightly model evaluation run",
  action: {
    type: "top_up",
    merchant: "CloudGPU",
    payeeId: "domain:cloudgpu.example",
    amount: 150,
    currency: "USD",
    description: "GPU compute credits for the nightly model evaluation run",
  },
  limitable: true,   // a top-up can be smaller and still useful
});
if (d.proceed) await topUp(d.amount); // capped when Neltava limits it

The first three fit. The fourth is capped to the $50 left in the provider’s 24-hour window — the run can continue at a smaller size. The fifth has nothing left to cap to, so a person decides whether tonight’s run really needs more. Nobody looked at the first four.

Prepaid balances and auto-reload

Most API and compute providers bill from a prepaid balance with auto-reload. That is convenient and dangerous in the same way: the reload is a spend nobody decided. Two patterns work:

Turn auto-reload off, and let the agent ask

The agent tops up only through Neltava. Every top-up is decided against the authority above, and the balance can never grow faster than the agent is allowed to spend.

Keep auto-reload, and mirror it

If the provider must reload itself, have your billing webhook ask Neltava for each reload as the agent would, and report the result. You lose the ability to stop a reload before it happens, but you keep the record, the totals and the alarms. The first pattern is stronger; the second is better than nothing.

Per-call payments

Some APIs are paid per request — fractions of a cent, thousands of times. Asking for authority on every call is the wrong shape: the check would cost more than the call. Authorize what funds them instead — the top-up, the prepaid session, the daily allowance — and let the per-call payments draw on it. Per-call payment protocols are covered separately as they mature.

Enforcing it

In Enforce, each allowed top-up carries a single-use capability bound to the provider, the amount and the currency. Route top-ups through a payment adapter that consumes the capability before it pays: the agent can’t reuse an allowance, stretch it, or send it to another provider. What the provider actually charged is reported back, so the totals above count real money.

Start in Shadow Mode: a week of real top-ups shows where the per-provider total and velocity should sit before they bind.

When you don’t need it