The questions teams actually ask.

Something else. Arc doesn't run inference and you don't route model traffic through it. It's an action control plane: it governs the consequential tool calls an agent makes — refunds, deletes, sends, infra changes — with allow / ask / block policy, human approval, signed execution, and a hash-chained audit. Your prompts and completions stay wherever they already live.

They're the three decisions Arc returns for every agent action. Allow lets it proceed and be signed. Ask pauses it for a human to approve or reject. Block stops it outright. Arc is default-deny, so an action with no matching grant is blocked — unconfigured agents fail closed, never open.

A protected agent is an autonomous agent whose actions route through Arc before touching production. A guarded action is a single high-risk operation it attempts — a refund, cancel, delete, or send — that Arc governs end to end. They're Arc's two units of metering: you pay for the agents you put behind the guardrail and the actions they take, never for human seats.

A gateway caps aggregate dollars at the model call; it's blind to which action runs. An agent can stay under budget and still issue a wrong refund or delete a record. Arc enforces cumulative spend too, but adds the thing a gateway can't: per-action allow / ask / block, human approval, and a signed execution your app verifies. Most teams run both.

Yes — that's the point of doing it in Arc rather than by hand. The cap is enforced atomically on the hot path of every guarded action, with the reservation taken under a lock. Two agent loops can't both read the remaining budget, both pass, and both spend. A naive read-then-act budget check in your own code races exactly there.

Nothing executes. Arc returns pending_approval with an approval id and holds; the action runs only after a human approves in the console, over the API, or from your chat tooling. Approvals are single-use and state-checked, tied to that one execution and its input hash, so an approval can't be replayed for a different request. Pending approvals expire rather than silently firing.

Yes. Mark an action's default decision as block and the agent simply cannot invoke it — Arc returns blocked before anything reaches your app, and the attempt is audited. Anything you never granted is blocked by default too. When you want a controlled exception, set it to ask so a named human approves rather than the action being silently impossible.

Not if you verify, which the SDK does for you. Your execute endpoint runs an action only after checking Arc's ES256 signature, the nonce, the expiry, and a hash of the exact request body. A request that didn't come through Arc — or a replayed or tampered one — fails verification and never executes. The signature binds 'this exact action was approved' to 'this is what ran.'

Each entry stores the previous entry's hash alongside its own — computed as sha256(prev_hash + canonical_json) — so any later edit or deletion breaks the chain and is detectable. Arc writes one event per decision, approval, and execution. It's redacted: sensitive fields are stripped while numeric cost is preserved, so spend stays accountable without exposing payloads.

No. MCP decides which tools an agent can call; Arc decides whether a specific call should run right now. Arc's MCP adapter exposes your guarded actions as MCP tools and routes every call through policy, approval, signed execution, and audit — a drop-in transport layer, no app code change. The adapter never executes business logic, self-approves, or bypasses policy.

Free to start — sign up for a hosted workspace, no credit card. The free Developer tier is capped at 10k guarded actions/month, 1 agent, and 7-day audit retention so it can't be abused. Paid plans are Team at $99/mo, Business at $499/mo, then Enterprise. Pricing meters protected agents and guarded actions — never per-seat.

An afternoon. Install @geostack/arc, declare your actions with arc.defineActions (a risk level and a default allow / ask / block decision each), call agent.invoke (via ArcAgentClient) where the agent acts, and mount arc.handleAction at /arc/execute to verify and run them. The quickstart walks through one guarded action end to end in about five minutes.

No — and you shouldn't. Start with the one action that scares you most: the refund, the delete, the infra change. Wrap that single guarded action, leave everything else exactly as it is, and expand from there. Arc is designed to sit in front of the few consequential actions, not to intermediate every call your agent makes.