Docs / Overview

The kill switch for AI agents that spend money

AI agents now hold wallets and pay for things — machine-payments over x402, mandates over Google's AP2, agentic wallets on Coinbase, Turnkey, Openfort. The control story hasn't caught up: a misbehaving agent retrying a $0.06 call 1,000 times a minute burns ~$86,000 in a day, and most agents in production ship with no reliable way to stop them.

The four controls every spending agent needs

The emerging consensus is a four-element guardrail: permission (what may it spend, on what), approval (a human co-sign above a threshold), audit trail (what did it actually do), and a kill switch (stop everything, now). Most stacks ship one of the four at best.

Why the kill switch is the hard one

Single-vendor kill switches exist — revoke a session key, pause a card. The unsolved part: a serious agent fleet holds wallets on several backends, and no vendor can freeze a competitor's rail. Coinbase can't stop your Turnkey agent; Turnkey can't see your Openfort spend. "Stop my agents" has no single answer — until a neutral layer sits above the wallets.

What good looks like

• One declarative policy — caps, allow/denylists, approval thresholds — compiled down to each backend's native controls (Coinbase MPC policy, Turnkey pre-sign CEL, Openfort signer control, card spend limits), so enforcement happens at the rail, not in a proxy an agent could route around.
• Fail-closed by default. No decision, no backend response, unknown asset, unreadable state — the transaction does not execute.
• An append-only, hash-chained, signed ledger of every attempt — allowed, denied, frozen — with a public key, so trust is verification, not faith.
• One freeze that fans out to every rail at once and confirms each stop, in under a second.

How Countersign works

Countersign is that layer. You write one policy; the compiler maps each field to the strongest control the rail can express and honestly flags what it can't (the enforceability matrix). Your agent calls POST /evaluate before every spend — the pre-flight guard. One POST /freeze stops the fleet. Every attempt lands in the signed ledger.

# self-serve key — no account, no human
curl -X POST https://app.countersign.network/signup \
  -H 'content-type: application/json' -d '{"ref":"docs"}'

// one declarative policy — amounts are base-unit integer strings
import { CountersignClient } from "@countersign/sdk";
const cs = new CountersignClient({ baseUrl: "https://app.countersign.network", apiKey });

await cs.applyPolicy({ policy: {
  schemaVersion: 1, asset: "USDC",
  perTxCap: "1000000",           // 1 USDC per transaction
  dailyCap: "5000000",           // 5 USDC per rolling 24 h
  allowlist: ["0x1111…"],        // counterparties
}});

// the pre-flight guard, before EVERY spend
const d = await cs.evaluate({ agentId, amount: "400000", asset: "USDC", venue: "base-sepolia" });
if (d.outcome !== "allow") throw new Error(d.reason);

// the kill switch — every backend at once, < 1 s
await cs.freeze();

Or drop it into Claude / Cursor / any MCP client as tools:

{ "mcpServers": { "countersign": {
  "command": "npx", "args": ["-y", "@countersign/mcp"],
  "env": { "COUNTERSIGN_URL": "https://app.countersign.network",
           "COUNTERSIGN_API_KEY": "csk_…" } } } }

The proof

Three reference agents on three backends across three testnets — Coinbase on Base Sepolia, Turnkey on Ethereum Sepolia, Openfort on Polygon Amoy — plus a Lithic virtual Visa card, all stopped by one freeze, confirmed in 432–697 ms across runs, with the signed ledger re-verifying as intact afterward. Watch the loop, then falsify it yourself.

Guides

• CoinbaseMPC account policies on Base — what binds natively, what the guard adds.
• TurnkeyPre-sign CEL policy in the TEE, native consensus approvals.
• OpenfortBackend signer control — the freeze that deletes the pen.
• Cards (Lithic)A virtual Visa on the same freeze — real-time auth gate included.
• x402Guard an HTTP 402 machine-payment before your agent pays it.
• Google AP2Guard a payment mandate before the agent signs it.
• vs. single-vendor controlsWhen your wallet's own limits are enough — and when they aren't.