Your agent already has a credit card

Your agent already has a credit card. Not metaphorically. Not in some speculative future where payment protocols mature. Right now, in production systems you may already run, an agent can spend money through means that were never designed for autonomous software: a browser session with a stored card, an API key whose billing account is yours, a cloud console cookie that survived a handoff, a “temporary” provider account that somehow got a payment method attached.

The money moves. Then, if you’re lucky, an alert fires.

That sequence — spend first, notify later — is the default safety story of agent infrastructure in 2026. It is also the wrong shape for the problem. Alerts are for anomalies you can reverse. Domains, year-long compute reservations, and production teardowns are not anomalies. They are commitments. Treating them like token burn is how teams discover, on a Tuesday morning, that an agent bought something they cannot easily undo.

This essay names the category we think is missing, and the vocabulary we use for the structural fix. If you leave with one sentence, leave with this: governance for agent spend is not FinOps with a chatbot skin. It is policy before execution, budgets as reservations, approval on irreversibility, and a ledger that never lies by omission.

The spend path that already exists

Consider a concrete path that does not require science fiction.

A coding agent has access to a developer’s machine. The developer once logged into a cloud provider in that browser profile. The agent needs a domain for a demo. It opens a registrar, finds a name, and the checkout form autofills. Or it uses a provider MCP that already holds a billing relationship. Or it calls Stripe Projects, which launched with 32 providers and left day-2 governance as an exercise for the caller.

None of these paths are exotic. They are the natural consequence of giving software the same credentials humans use to buy things. The industry spent 2025–2026 removing friction from agent provisioning — temporary accounts, auth.md-style self-provisioning, tokenized payments, network-level agent payment rails. That work was necessary. It also made the next failure mode inevitable: agents that can acquire real internet infrastructure faster than any human can supervise the acquisition.

Gartner projected that over 40% of agentic AI projects would be canceled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. That forecast is usually read as a token-spend story. Token spend is real. It is also reversible at the margin — you stop the loop. Infrastructure spend is different. A registered domain has a renewal clock. A VPS left running is a monthly invoice. A production delete is a one-way door. The tools that emerged to govern LLM API burn (reservation, anomaly detection, attribution) do not govern the irreversible layer. They alert after tokens move. The infra layer needs something that can refuse before the registrar call leaves the building.

After-the-fact is not a control plane

Most “agent safety” dashboards share a structure:

The agent acts.
Telemetry records the act.
A threshold is crossed.
A human gets a Slack message.

That is observability. Observability is good. It is not governance.

Governance answers a different question: was this action allowed to happen at all, under whose authority, against what remaining budget, and with what undo path? If your answer depends on a human reading an alert in time, you do not have a control plane. You have a hope.

The after-the-fact pattern fails in three specific ways for infrastructure:

Concurrency. Two agents each see $40 of headroom under a $50 cap. Both buy. The cap was a suggestion. Naive “check balance then charge” accounting loses to parallel quotes the same way naive bank ledgers lose to double-spend without reservations.

Irreversibility. Some actions cannot be compensated cheaply. Premium domain registration, production teardown, transferring a name out — these need a human principal in the loop before the side effect, not a postmortem after.

Attribution without authority. A beautiful audit log of what went wrong does not restore the money or the zone. Receipts without a prior gate are archaeology.

FinOps for tokens taught the industry useful habits: budgets, attribution, anomaly alerts. Those habits are necessary and insufficient for agent-bought infrastructure. The missing piece is a governor — a service that sits between the agent and the provider and makes side effects conditional on policy, budget, and (when needed) human approval.

The structural alternative

The fix is not a smarter alert. It is a different order of operations:

Policy before execution. Every mutating call hits a policy decision point first. Default deny. Forbid wins. No code path mutates provider state without a verdict. Verdicts are three-valued: allow, deny, or require approval. “Require approval” is not a 403 with a shrug — it is a structured gate the agent can watch while a human decides.

Budgets as reservations (two-phase). A quote that policy allows places a reservation for the full amount, with a short TTL. Commit converts the reservation to spent. Expiry or cancel releases it. Policy evaluates against committed + reserved, so concurrent agents cannot each look affordable. This is boring database accounting. Boring is the point. Caps that only check at commit time are theater under load.

Approval on irreversibility. The human is the principal — the person who holds the payment instrument, sets the ceiling, and decides the one-way doors. Agents may request. Agents may not resolve their own gates. If your design lets an agent approve its own spend by talking persuasively to a model-facing endpoint, you have built a loophole with an API.

Ledger always. Every mutation writes exactly one ledger entry: cost, provider references, undo information, workflow identity. Corrections are compensating entries, not edits. Silent side effects are bugs, not features. If it happened and it is not in the ledger, your control plane is lying by omission.

Optional but important: bind spend to a human-signed mandate — a cryptographic budget ceiling (we use AP2-format payment mandates) that a third party can verify without trusting your database. Platform caps and mandates dual-enforce. Proofs verify against published keys. The mandate does not replace the ledger; it makes the ceiling independently checkable.

That sequence — policy → reserve → approve (when required) → commit → ledger — is the category. Call it governed agent spend. Everything else is provisioning with vibes.

Vocabulary worth owning

Names matter because agents and auditors need a shared wire language, not a vendor thesaurus.

Governor — the control plane between agents and providers. Owns policy, budgets, approvals, and the ledger. Not a chatbot. Not a dashboard with teeth painted on.
Envelope — the response contract that makes governance legible to machines: receipt, undo, remaining budget net of reservations, next actions, and on errors a namespaced blockedBy plus a machine-checkable resolution. Field names are normative. If every vendor renames them, nothing composes.
Gate — a suspended action waiting on a human decision. The agent polls; the human decides; the agent cannot self-approve.
Mandate — a human-signed spend ceiling, cryptographically bound, optionally verifiable offline. Authority travels with the credential, not with a trust-me row in a vendor DB.
Two-phase budget — reserve at quote, commit at apply, release on expiry or cancel. The only budget math that survives concurrent agents.
Human principal — the accountable person. Not a “payment peripheral” the agent notifies. The principal is the authority the system is designed to protect and route to.

We published these as an open specification under CC BY, with a JSON Schema for the envelope and a conformance checker you can point at any deployment. SproutPad's public sandbox and signed-history pages are currently previews: their runtimes stay off until the isolation, cleanup, recovery, and retained failure drills pass. One implementation is a demo. The vocabulary is an invitation for a second.

What this is not

This is not a claim that agents should not spend. Agents that cannot spend cannot ship. The goal is spend that is authorized, bounded, attributable, and reversible where possible — and explicitly gated where it is not.

This is also not a claim that SproutPad has solved agent safety in general. Prompt injection, tool confusion, and compromised credentials remain real. A governor assumes the agent may be fallible or compromised. Nothing in the design depends on the agent being well-behaved. That is why refusal is a first-class outcome, not an embarrassment.

And this is not FinOps rebranded. If your product’s primary artifact is a chart of spend after the fact, you are in a different category. Charts are welcome. They are not the control plane.

Coming out

I am Rob Mine. I built SproutPad (the public name for the system we also call AgentInfra internally) because the provisioning layer was getting solved by platforms with distribution we will never match — and the governance layer was still a collection of alerts, per-provider caps, and hope.

We run a live service. The numbers are small. We publish them anyway. Tiny honest numbers beat large unverifiable ones. You can grade the production counters and cryptographic AP2 verify path without believing a word of this essay. The sandbox and signed conformance history will join that evidence set only after their launch gates pass.

If your agent already has a credit card — and it probably does — the question is not whether it will spend. The question is whether anything structural stands between the intent and the side effect.

Grade us. Don’t believe us.

— Rob Mine

Verify

# Live production aggregates (domains, ledger rows, gate outcomes)
curl -sS https://sproutpad.ai/transparency | jq .

# Envelope schema — the normative wire format
curl -sS https://sproutpad.ai/spec/envelope.schema.json | jq '.title, .required'

# Public proof contracts (interactive activation is intentionally pending)
curl -sS https://sproutpad.ai/sandbox | head
curl -sS https://sproutpad.ai/conformance | head

After activation, agents connected over MCP can call verify_architecture. For a shared sbp_… sandbox proof ID, verify_sandbox_proof recomputes the digest and verifies its signatures and AP2 chain. Until then both paths fail closed as unavailable; unavailable is not evidence.