Autonomous Agents: How to Set 3 Spend Limits They Cannot Edit

Enforce a customer-specific ceiling in an authorization service that the autonomous agent cannot configure, and reserve the maximum charge before dispatching work. The deciding constraint is whether a metered developer tool can tolerate refusing a request whose final cost is still uncertain: a hard ceiling protects the invoice but may reject useful traffic; a warning-only threshold preserves traffic but cannot promise an upper bound. Short answer: the agent may request work and observe its remaining allowance, but it must not possess the credential or administrative route that changes that allowance.

This is an architecture decision about authority, not an instruction in a prompt. A process that can both initiate chargeable work and raise its own limit can make a supposedly bounded invoice unbounded within the permissions granted to that process. The three boundaries are policy ownership, reservation before execution, and reconciliation against measured usage. Each has a distinct failure mode.

For a developer tool invoicing each customer's autonomous usage, define the billing period, customer identity, units and maximum charge independently of the agent's request. An administrative principal may set the ceiling; the agent's principal may request a reservation and read its status. Keep the credentials for those roles separate and apply least privilege to both storage and secret distribution. OWASP's Secrets Management Cheat Sheet describes access control and lifecycle concerns for secrets; a secret stored outside a prompt is still unsafe if the agent's runtime can retrieve it.

The ledger invariant is committed + reserved <= ceiling for each customer and period, under a single atomic transaction or equivalent serialization boundary. A request has one stable idempotency key across retries. Its reservation, measured consumption, release of unused allowance, and invoice entry must be attributable to that key. Record the decision and policy version alongside the request identifier so that an auditor can reconstruct why work was admitted or refused. This is an exactly-once accounting target, not a claim that a distributed worker executes exactly once. For example, consider two autonomous jobs arriving together for customer-42, with a 20-unit period ceiling and a maximum exposure of 12 units each. The first reservation leaves 8 units available, so the second must be refused even if both jobs are expected to consume only 4 units. An expected-value admission rule would admit both and have no defensible answer if both consume the full 12 units. An invoice dispute then cannot be settled by pointing to an agent's estimate; the admissibility decision must be reconstructable from the stored reservation and the version of the customer's policy that was effective at admission.

No prompt can grant that guarantee.

The units matter. If one call can consume up to 12 billable units but the gateway reserves only the expected 4, parallel agents can pass admission together and exceed a ceiling even if each ledger write is atomic. Reserve a defensible upper bound of 12, enforce a per-call maximum at the executor, and settle against the actual measured 4 when known. If the underlying task cannot be bounded or interrupted, a strict ceiling cannot be guaranteed by admission control alone. Stop there.

The choice belongs to the customer-facing policy, rather than to the agent optimizing task completion. This table assumes a fixed billing period and a trustworthy metering source; neither is supplied by an LLM response.

Do not silently convert a hard reservation into a soft alert during an outage. If the policy store or atomic ledger cannot be consulted, fail closed for the hard-ceiling tier, log the refusal with a reason, and expose a retryable status to the caller. That costs availability. It also preserves the meaning of the limit. A soft-alert tier can make a different, explicit availability choice, provided the invoice and alert semantics say so. The hard-ceiling approach has a concrete limitation: without an enforceable upper bound on each job, reservation cannot promise a cap. For uninterruptible jobs with unknown maximum consumption, choose an explicit soft policy or redesign work into bounded units; this is a policy trade-off, not an implementation detail.

The following Go example isolates the admission rule. It is an in-memory illustration, not a durable invoice ledger: production storage must serialize the same check and update across processes, persist policy changes by an independently authorized principal, and retain the settlement trail. The agent receives no method to edit Ceiling.

package main

import (
    "errors"
    "fmt"
    "sync"
)

var ErrLimit = errors.New("spend ceiling exceeded")
var ErrKeyConflict = errors.New("idempotency key reused with different amount")

type Account struct {
    Ceiling, Committed, Reserved int64
    Holds map[string]int64
}

type Gate struct {
    mu sync.Mutex
    accounts map[string]*Account
}

func (g *Gate) Reserve(customer, key string, maximum int64) error {
    if key == "" || maximum <= 0 { return errors.New("invalid reservation") }
    g.mu.Lock()
    defer g.mu.Unlock()
    a, ok := g.accounts[customer]
    if !ok { return errors.New("unknown customer") }
    if prior, exists := a.Holds[key]; exists {
        if prior != maximum { return ErrKeyConflict }
        return nil
    }
    if maximum > a.Ceiling-a.Committed-a.Reserved { return ErrLimit }
    a.Holds[key] = maximum
    a.Reserved += maximum
    return nil
}

func main() {
    gate := &Gate{accounts: map[string]*Account{
        "customer-42": {Ceiling: 20, Holds: make(map[string]int64)},
    }}
    fmt.Println(gate.Reserve("customer-42", "job-17", 12))
    fmt.Println(gate.Reserve("customer-42", "job-17", 12))
    fmt.Println(gate.Reserve("customer-42", "job-18", 12))
}

The first two calls succeed, including a retry with the same key; the third is refused because only 8 units remain unreserved.

In a real implementation the idempotency identity must also bind the customer, period, operation and maximum, and retry records must outlive the caller's timeout. This small example deliberately omits settlement: adding a naive Committed += actual operation without checking the original reservation, actual-versus-maximum bound, and prior settlement would turn a readable admission example into misleading billing code.

Put settlement in the same transactional domain as the reservation, using the meter's authenticated observation rather than an agent-supplied total. When the worker finishes, settle once against its reservation, release unused capacity, and append an immutable audit record. On a crash, reconcile reservations with execution records before releasing them; a timed-out client does not prove that the worker stopped. The ambiguity is operationally important because retrying execution may repeat a side effect even while accounting remains idempotent.

Exercise simultaneous reservations for the last available units, identical retry keys, conflicting retry amounts, late settlement, and a worker that continues after the caller disconnects. Run those tests against the actual transactional store, not only a mutex-based unit test. Check that the sum of committed and outstanding reservations never exceeds the ceiling and that each completed job produces at most one invoice line. Compare invoice totals with raw meter events at the end of each period; discrepancies need an investigation path, not automatic deletion of unmatched records.

For observability, track admitted and refused requests by policy reason, the age of unsettled reservations, meter-to-ledger lag, and reconciliation differences. Do not place secrets or sensitive customer payloads in those logs. Deployment requires a separate administrative path for policy changes with authorization, change history, and a deliberate effective time; changing a ceiling while work is already reserved must have specified semantics. A versioned policy snapshot on each decision makes those semantics reviewable later.

Rejecting traffic is the real cost of a firm limit, while temporarily reserving the upper bound is its most visible source of false refusal. If workloads cannot supply a credible per-request bound, choose a smaller interruptible work unit or an explicitly soft policy instead of calling a warning a ceiling. The rejected design here is a limit written into the agent's instructions: it remains useful as a behavioral hint for prioritizing tasks, but it cannot authorize chargeable execution because the same actor would control both the proposed work and its restraint.