Use cases · the agent control plane
Stop your AI agents before they do real damage.
Autonomous agents now hold production credentials. They call payment APIs, run database migrations, send customer email, and burn token spend across thousands of runs — with no human in the loop. Arc is the control plane between your agents and those high-risk actions. Every action passes an allow / ask / block policy, gets human approval when it’s risky, runs only via a signed (ES256) request your app verifies, and lands in a redacted, hash-chained audit log. Cumulative spend and budget caps are enforced on the same path.
Why this exists
One enterprise client reportedly spent ~$500M on Claude in a single month. No usage caps were set.
The figure is an AI consultant’s account, told to Axios. No company has confirmed it.
Token spend exploded across thousands of employees running agentic workflows because the licenses had no limits. Corroborating and on the record: Microsoft cancelled most internal Claude Code licenses ($500–$2,000 / engineer / mo), and Uber reportedly exhausted its 2026 AI budget by April.
The common thread: the cap didn’t exist, or wasn’t turned on. Arc is the cap — and the approval, and the block for the action you can’t take back.
-
OpenAI -
Anthropic -
Cursor -
Windsurf -
Gemini
Any agent or MCP server. Arc wraps the action, not the model.
This page maps Arc to the five things teams running autonomous agents come to us for. Each one: the pain, the Arc setup, the outcome.
Cap runaway agent spend
The pain. Token and API spend is invisible until the invoice arrives. A retry storm, a runaway planning agent, or one prompt that fans out across thousands of users can burn a quarter’s budget in a weekend. Per-call limits don’t help — no single call looks expensive; the cumulative total is what kills you, and you find out after the money is gone.
The Arc setup. Arc enforces a cumulative spend ledger on the hot path of every guarded action. You attach a cost to each action and define budgets scoped to an agent, app, or single action, over a rolling or calendar window. Arc reserves spend before the action runs and reconciles the real cost at execution — on breach it does what you told it.
The outcome. The bill has a ceiling you set, enforced in code before the spend happens — not a dashboard you check afterward. A runaway loop hits the cap and halts instead of compounding. “How much can this agent spend this month, worst case?” has a number.
Block destructive and irreversible actions
The pain. The actions that end companies are the irreversible ones: dropping a production table, refunding the wrong account, deleting a customer, pushing a destructive migration. An agent with prod credentials can do any of these from one hallucinated tool call — with no undo.
The Arc setup. Declare your dangerous actions once with a
risk level and a default decision. Mark the irreversible ones block
— the agent cannot invoke them; Arc returns blocked before anything reaches
your app, and the attempt is audited. Need a controlled exception? Set it to
ask so it requires a named human approval instead of being silently
impossible.
The outcome. “The agent deleted prod” stops being a class
of incident. Destructive actions are off by default and on only where you deliberately
allowed them. A hallucinated delete_customer is a logged, blocked attempt —
not an outage.
Human approval for risky tool calls
The pain. You don’t want to block every risky action — sometimes the agent is right and a human should just say yes. But “human in the loop” usually means a Slack message someone eventually reads: no link to the execution, no record of who approved what, no guarantee the thing that runs is the thing that was approved.
The Arc setup. Set the risky action’s decision to
ask . When the agent calls it, Arc returns
pending_approval with an approval id and pauses — nothing executes yet. A
human approves or rejects in the console, over the API, or from your chat tooling.
Approvals are single-use and state-checked.
The outcome. A real decision gate on exactly the actions you choose, with approver, timestamp, and decision tied to the specific execution. Approve once; it can’t be replayed for a different request. Low-risk work stays autonomous and fast; the few high-stakes calls wait for a named yes.
Govern MCP tool calls
The pain. MCP makes it trivial to hand an agent a pile of tools — including ones that touch production. But MCP answers “what tools can the agent call?”, not “should this call run right now?” An agent wired to an MCP server full of write-capable tools has no brakes.
The Arc setup. Drop in the Arc MCP adapter
(@geostack/arc-mcp-adapter). It exposes your Arc actions as MCP tools and
routes every tool call back through Arc — policy, approvals, signed execution,
audit — before anything runs. No app code change; it’s a transport layer in front of your
existing actions. The adapter never executes business logic, never self-approves, and
never bypasses policy.
The outcome. You keep the MCP ergonomics your agents already use and gain a policy and approval layer over every tool call. Connecting a new MCP tool no longer widens your blast radius — it inherits the same guardrails.
Signed, audited execution for compliance
The pain. “We have approvals” isn’t enough for a security
review. Anyone who can reach your /arc/execute endpoint could forge a
request, and a plaintext log can be edited after the fact. You need to prove the action
that ran was authorized, unaltered, and recorded tamper-evidently — to a customer’s CISO
or an auditor.
The Arc setup. After policy and approval pass, Arc’s worker
signs the execution as an ES256 JWS carrying the decision, an
input_hash, a body_hash, a one-time nonce, the
invocation_id, and an expiry. handleAction verifies the
signature, rejects expired requests, and rejects replays via a durable nonce store (the
SDK refuses an in-memory store in production by default).
The outcome. A forged or replayed request fails verification and never executes. For every real action you can show who/what was authorized, that it ran unaltered, and when — a tamper-evident trail you hand to security and compliance instead of reconstructing from app logs.
The path
How the guardrails compose
Every guarded action runs the same path, in order. One miss anywhere blocks or escalates. Default-deny throughout — an action with no explicit grant is blocked.
| Stage | Question it answers | Outcome |
|---|---|---|
| Policy | Is this action allowed for this agent? | allow proceed ask approval block stop |
| Budget | Is there spend left in the cap? | within cap → proceed · breach → block or ask |
| Approval | Did a human authorize this request? | single-use, state-checked yes / no |
| Signed execution | Is the request authentic and unaltered? | signed verified ES256, nonce-protected |
| Audit | What happened, provably? | audit redacted, hash-chained record |
Who it’s for
Built for the teams running autonomous agents
Arc is for platform and infrastructure engineers and technical founders at Series A–B AI-native and dev-tools startups whose agents hold production credentials.
The developer adopts the SDK in an afternoon (npm i @geostack/arc, define
actions, verify at /arc/execute); the eng leader or founder gets a cap on the
bill and a block on the irreversible action. Free to start — sign up for a hosted
workspace, no credit card.
FAQ
Questions teams ask before they wrap an action
Q Does Arc add latency to every agent action?
Low-risk allow actions pass a policy and budget check and proceed. The latency you’d notice is on ask actions — by design, they wait for a human. Blocked actions return immediately, before reaching your app.
Q Is this just an LLM gateway with a spend limit?
No. A spend cap alone is a commodity. Arc’s value is the full trust envelope around an action — human approval, signed execution your app verifies, and a tamper-evident audit trail — with the budget cap enforced on the same path.
Q Do I have to route my LLM traffic through Arc?
No. Arc governs actions (the tool calls that touch the real world), not your model traffic. You wrap the dangerous actions; your prompts and completions stay where they are.
Q Can the agent bypass Arc by calling my API directly?
Your /arc/execute endpoint executes only after verifying Arc’s ES256 signature, nonce, and body hash. A request that didn’t come through Arc fails verification and doesn’t run.
Q Does Arc replace MCP?
No. MCP decides what tools exist; Arc decides whether a specific call should run. The adapter routes every tool call through Arc’s policy, approvals, signing, and audit.
Q Does the audit log leak sensitive data?
It’s redacted — sensitive fields are stripped. Numeric cost is preserved so spend stays accountable, and the log is hash-chained so edits are detectable.
Put guardrails in front of your agents.
Install the SDK, define your actions, set a budget, and verify signed execution at
/arc/execute. Free to start — sign up for a hosted workspace, no credit card.