How do you prove an AI agent actually stopped?

With receipts showing the stop command, the final calls winding down, and nothing after. A kill switch without proof is a button you hope worked: the dashboard says stopped, but the agent's own runtime wrote that dashboard. Verifiable execution receipts mint the stop as an event like any other, with a commitment you can check, and the absence of later receipts is itself evidence. AER-1, published as an IETF Internet-Draft, is the open format for those receipts.

Want the proof yourself? Run one free call and get a real verifiable receipt, no signup.

Need more than the free tier? $0.99 unlocks unlimited runs for 24 hours, no signup, no subscription.

Updated October 7, 2026.

The stop problem

Every serious agent deployment has a kill switch: an emergency stop for the runaway task, the looping tool calls, the agent doing something it should not. Pressing it feels decisive. The problem is verification. The system that reports stopped is usually the same system that was running the agent.

The failure modes are real. The stop signal reaches the coordinator but not a detached sub-agent. A tool call already in flight completes after the stop. A scheduled retry fires the agent back up minutes later. The dashboard says stopped while work continues, and nobody knows until the bill or the incident report arrives.

What stop proof looks like

A provable stop has four parts:

  1. The stop command as a receipt. The kill switch press itself mints a verifiable receipt: who ordered the stop, when, with what scope. The command is an event in the evidence chain, not a UI interaction that leaves no trace.
  2. Wind-down receipts. Final tool calls completing or being cancelled, each receipted. You see the agent winding down, call by call, not a cliff edge.
  3. Silence after. No receipts after the stop timestamp. Because receipts are minted by the execution layer for every call, the absence of receipts is evidence of absence of calls, not just a quiet dashboard.
  4. Scope coverage. The stop receipt names its scope: which agents, which runs. Sub-agents outside the scope show up as continuing receipt streams, which is exactly what you need to see.

Why receipts beat dashboards here

A dashboard reports state; receipts record events. State can be stale, cached, or written by the thing being stopped. Events minted by the execution layer cannot be faked by the agent, and their absence is meaningful because minting is automatic.

This is the same tamper-evidence argument applied to the most safety-critical moment: the stop. If you trust receipts for billing and compliance, the stop is where you need them most, because a lying stop is how incidents become disasters.

The tamper-evidence foundation

Stop proof rests on receipts the agent cannot rewrite. Read the tamper-proof log guide.

Designing a provable kill switch

Three design rules. Mint the command. The stop button writes a receipt before it signals anyone, so the command itself is evidenced. Scope explicitly. The receipt names every agent and run the stop covers; anything not named is not stopped. Verify the silence. After the stop, check the receipt stream for the scope: the proof is the gap.

AER-1 receipts, published as the IETF Internet-Draft draft-zambo-aer1, give you the primitives: per-call receipts with timestamps, commitments, and sequence numbers, minted by the execution layer. The kill switch becomes a receipted event in a checkable stream.

See a receipted event

Mint a real AER-1 receipt for a real tool call, free, no signup. Every event in a provable stop, including the stop command itself, looks like that receipt.

Mint an event receipt now.