Kill switches stop an agent from doing more damage; they do nothing about the damage already done. Here's how to design agent actions around reversibility, with compensating transactions, state checkpoints, and autonomy tiers set by blast radius.
Table of Contents #
Here’s a question to ask your team this week. Say an agent in production spent forty minutes quietly doing the wrong thing. Maybe it acted on a poisoned document it retrieved. Maybe it misread a ticket, or maybe a tool returned data that looked valid but wasn’t. In that time it updated 3,000 CRM records, closed 140 support tickets, sent 60 customer emails, and rewrote a config file in a shared repo. Your monitoring flags it and you hit the kill switch. What happens next?
For most teams, the honest answer is a long weekend of manual cleanup. Someone pulls audit logs and tries to rebuild what the agent touched. Someone else restores a database snapshot from before the incident and throws away the legitimate work done since. Then there’s the part that can’t be taken back: the emails are sent, the tickets have already notified customers, and a downstream system may have consumed the config change. The kill switch did its job and the agent stopped. But stopping and recovering are different problems, and most agent architectures in production today only deal with the first. This is the gap the agent-security market is starting to name. Over the past ten days, vendors shipped a wave of kill switches, a frontier lab published how it monitors tens of thousands of internal agents, and a major edge-security vendor told CISOs to grant agents autonomy based on how reversible their actions are. Put together, the message is that detection and termination are table stakes, and whether you can undo an action is now the design constraint that decides how much autonomy is safe.
Why Kill Switches Solve the Wrong Half of the Problem #
The kill-switch pattern is maturing quickly. Exaforce launched AI Security on September 15 with what it calls an agent kill switch. The platform can revoke a session, deactivate a model-provider key, isolate a device, or end an agent’s process, and security teams set how much autonomy each response gets, from analyst-approved to fully automatic. Exaforce also pointed at a real forensic problem. Agents act with the identities and permissions of the people who deploy them, so when an agent rotates a key or pushes code, the audit trail points back at an employee. No single log entry looks wrong. The attack only shows up in the sequence.
That forensic point matters for recovery as much as for detection. If you can’t reliably tell which actions came from the agent and which came from the human whose credentials it borrowed, you can’t cleanly undo only the agent’s work. You end up restoring everything to a point in time, legitimate human changes included, or restoring nothing.
Cohesity said it more bluntly when it launched Agent Resilience on September 16. Its chief product officer, Vasu Murthy, put it this way: “Detection can tell you an AI agent went off course. It cannot undo the changes.” The product backs up agent memory and configuration so an administrator can pick a recovery point from before the suspicious behavior started and restore only the affected state. It also finds the databases, file systems, and vector stores the agent works with and protects those too. Each agent gets a topology map of the systems it connects to and the data it can reach. At launch it only covers AWS Bedrock agents, with general availability expected by year-end. The architecture matters more than the vendor, though: agent state and the agent’s blast radius are now treated as things you back up.
Cohesity’s survey of more than 3,200 IT and security decision-makers found that 55% said they were unprepared to detect or contain unintended agent actions. That was the question they asked. The question they didn’t ask, whether teams could reverse those actions, would probably have produced a worse number.
What Anthropic’s Monitoring Numbers Actually Tell You #
The most useful data point this month came from Anthropic’s disclosure of how it oversees its own internal agents. Per the Anthropic Institute post published September 17, roughly 30,000 agents are doing research and engineering work on its most-used internal platform at any given time. Every action passes an online monitor before it runs, usually within seconds. Across more than a billion agent decisions in August 2026, about 0.002% were blocked, roughly one in 47,000. A second, offline monitor reviews every action after the fact, flags roughly one to two transcripts per thousand for further review, and sends the highest-priority flags, about 50 a week, to a human.
The figures are self-reported and haven’t been independently audited. Even so, the architecture teaches something. Anthropic, with more reason to invest in agent oversight than almost anyone, still runs a two-layer system where one layer works after execution. That offline layer exists because some problems don’t show up in any single action. They only appear across a sequence, the same issue Exaforce described with borrowed identities. By definition, whatever the offline monitor catches has already happened.
So even a best-in-class pre-execution gate leaves a residual stream of actions that turn out to be wrong only later. At a billion decisions a month, a tiny residual rate is still a meaningful absolute number of bad actions that already ran. Your system either absorbs that residual through reversibility or absorbs it through incidents. There’s no third option.
Reversibility Is an Architectural Property, Not a Feature #
Akamai’s State of the Internet security report, released September 22, framed this well. Its recommendation is to grant agents operational autonomy based on how easily their actions can be verified and how reversible a potential failure is, and to keep humans in the loop for high-stakes actions. That’s the right mental model, and it has a direct engineering consequence: you can’t set autonomy by reversibility unless you’ve classified every tool by reversibility first.
In practice, agent actions fall into four classes, and each needs a different recovery mechanism.
Naturally reversible actions are ones where the system of record keeps history: versioned object storage, git commits, database rows with temporal tables or soft deletes, documents with revision history. Recovery here is cheap as long as you’ve recorded which versions the agent created. The main engineering work is attribution, meaning a way to tell “revert everything agent run X did” apart from “revert everything after 2:14 PM.”
Compensable actions can’t be literally undone, but a defined counter-action restores business equivalence. You can void an issued refund, reopen a closed ticket, re-add a removed permission, or cancel a scheduled meeting. This is the saga pattern from distributed transactions, and it maps closely onto agent tool calls. Each forward action registers a compensating action at the moment it runs, not later when someone is trying to reconstruct what happened.
Checkpointable state is the agent’s own memory, configuration, retrieved context, and tool registrations. This is the category Cohesity’s product targets, and teams overlook it most often. A prompt injection that writes a poisoned instruction into long-term memory keeps doing damage after the triggering session ends. Rolling back the agent’s state to a known-good checkpoint is a separate operation from rolling back the world the agent changed, and you need both.
Irreversible actions include sent emails, executed payments, messages to external parties, published content, physically dispatched orders, and data disclosed to a third party. No compensation restores the prior state. These actions should never run at the same autonomy level as the other three classes, however good your monitoring is.
This taxonomy isn’t new; it’s been standard in payments and distributed systems for twenty years. What’s new is that agents now issue these actions through general-purpose tool interfaces, so the classification that used to be built into each workflow’s hand-written code has to be declared explicitly at the tool layer.
Durable Execution Is Becoming the Substrate #
The infrastructure market is pricing this in. Temporal closed a $550 million Series E on September 14 at a $12.55 billion valuation, more than double its February valuation. The company reported processing 1.9 trillion billable actions in August 2026, up over 350% year over year, with OpenAI’s usage up 60-fold in under a year. Temporal’s pitch is durable execution: long-running workflows whose every step is persisted, so they survive crashes, can be retried deterministically, and can run compensation logic when a later step fails.
Durable execution is relevant to reversibility for a specific reason. It gives you an authoritative, ordered, replayable record of what the agent did, kept separate from the model’s own account of what it did. If the step history is the source of truth, you can walk it backwards and run registered compensations in reverse order. Without that layer, your recovery depends on reconstructing intent from LLM traces and scattered application logs, which is the manual-cleanup weekend described at the top of this post.
You don’t need Temporal specifically. Any orchestration layer that persists each tool invocation, its inputs, its result, and its registered compensation before moving to the next step gives you the same property. What you can’t do is let the model’s context window be the only record of what happened.
Decision Framework #
When you’re deciding what autonomy level to give an agent capability, work through these questions in order.
First, what reversibility class is each tool the capability uses? If any tool is irreversible, the whole capability defaults to human approval for that step, whatever its risk score. You can relax this later with evidence, but it’s the right starting point.
Second, for compensable tools, is the compensation automated, tested, and registered at execution time? A compensation that exists only as a runbook entry doesn’t count. If you can’t run it programmatically against a specific agent run ID, treat the tool as irreversible.
Third, what’s the detection window compared to the propagation window? If your offline review catches problems within an hour but the agent’s writes flow into downstream systems within minutes, reversing the source write doesn’t reverse the downstream effects. Either shorten detection or add a hold period before writes propagate.
Fourth, can you attribute actions to a specific agent run separately from the human identity it runs under? If not, you can’t do surgical rollback, and your only recovery option is a point-in-time restore that destroys legitimate work. Fix attribution before you expand autonomy.
Architecture Impact #
What changes in system design? Tool definitions gain a required reversibility contract: a declared class (reversible, compensable, checkpointable, irreversible) and, for compensable tools, a registered inverse operation. The orchestration layer moves from a stateless loop around the model to a durable step log that records every invocation with its compensation handle. Agent memory and configuration become backed-up state with recovery points, versioned the same way you version the data the agent acts on.
What new failure mode appears? The main new failure is compensation drift. The forward tool evolves (new fields, new side effects, a new downstream consumer) while its registered compensation doesn’t, so rollbacks report success but leave partial state behind. A second failure is cascade reversal: rolling back one agent’s writes invalidates work that other agents or humans have since built on, and with no dependency graph you either roll back too little or trigger a wider unwind than intended. A third is poisoned-checkpoint restore, where the “known good” recovery point was taken after an injection had already landed in memory.
What enterprise teams should evaluate:
- Platform engineering: Whether the agent orchestration layer persists a replayable step log with per-step compensation handles, and whether a full rollback of a single agent run can be executed from that log without manual reconstruction.
- Security and IR: Whether incident runbooks cover recovery rather than only termination, and whether agent actions can be attributed to a specific run instead of the human identity the agent borrowed.
- Data and application owners: Which systems of record the agents write to lack native versioning or soft deletes, and what compensating operation exists for each write path.
Cost / latency / governance / reliability implications: Durable step logging adds latency per tool call (typically single-digit milliseconds for a persisted write, more if the store is cross-region), which is small next to LLM inference but adds up in 50-step agent loops. Storage costs grow with step-log retention and agent-state checkpoints; plan retention to match your detection window plus audit requirements, not indefinitely. On governance, a reversibility classification per tool gives auditors and model-risk teams a concrete control to test, which is far easier to defend in an examination than “we have monitoring.” On reliability, the metric that matters becomes mean-time-to-restore for agent incidents, and teams without compensation infrastructure should expect it in days rather than minutes.
Common Failure Modes #
The most common mistake is treating database backups as agent recovery. A point-in-time restore is a blunt tool: it reverts every change after the chosen timestamp, including legitimate human work and other agents’ correct actions, and it does nothing about the emails, API calls, or third-party writes that left your perimeter. Backups are necessary but not sufficient.
The second is writing compensations after an incident rather than before. Teams build the inverse operation reactively, under pressure, without tests, against a production system in an inconsistent state. That’s when compensations are most likely to be wrong.
The third is classifying tools once and never revisiting. A tool that was reversible when it wrote to an internal staging table becomes irreversible the day someone adds a webhook that fans those writes out to a partner system. Reversibility is a property of the whole downstream graph, not just the tool’s own code.
Implementation Guide #
Start with an inventory, not with infrastructure. List every tool your production agents can call and assign each one a reversibility class. This usually takes a platform team a few days, and it almost always turns up one or two tools everyone assumed were harmless that turn out to send external notifications or trigger non-idempotent downstream jobs. Those tools are your immediate priority. Move them behind a human-approval step or a delayed-execution queue before doing anything more sophisticated. That one change cuts your irreversible blast radius more than any monitoring investment.
Next, make the step log the source of truth. Whatever orchestration you run, whether Temporal, a cloud-native workflow engine, or a well-built internal loop, make sure every tool invocation is persisted before execution with the agent run ID, the tool, the arguments, and a compensation handle, and that the result is persisted after. Tag every downstream write with the agent run ID wherever the target system allows it, in a metadata column, a commit trailer, or a header. That tagging is what makes surgical rollback possible later, and it’s far cheaper to add now than to retrofit after an incident.
Avoid the temptation to build a universal undo engine up front. Compensation logic is domain-specific, and a generic framework that tries to reverse arbitrary tool calls will be wrong in subtle ways. Write compensations for your top five write paths by volume and risk, test them in CI against real schemas, and add a contract test that fails the build when a forward tool’s signature changes without a matching update to its compensation. Treat agent memory and config the same way: snapshot on a schedule and before any memory-write operation above a size threshold, and keep enough history to reach back before your worst-case detection window.
You’ll know it’s working when you can run a rollback drill on demand. Pick a completed agent run in staging, trigger reversal from the step log, and check that the target systems return to their pre-run state while unrelated concurrent changes survive. Measure time-to-restore. If it takes more than a few minutes, or needs a human to read logs and decide what to revert, the architecture isn’t done. Run the drill quarterly, and add it to your agent release checklist so no new capability ships without a tested recovery path.
Over six to twelve months, teams that get this right end up with an autonomy model that’s driven by evidence rather than debated in meetings. Capabilities built entirely from reversible and compensable tools with tested rollback earn automatic execution. Capabilities with irreversible steps keep a human approval gate on exactly those steps, and nothing else. When a monitor, whether pre-execution or offline, flags a bad sequence, the response is an automated run-scoped rollback followed by a kill-switch decision, not a kill switch followed by a war room. That’s the posture Akamai described and the one Anthropic’s two-layer monitoring implies: accept that some bad actions will get through, and design the system so that when they do, they can be undone.
Sources #
- Cohesity’s new Agent Resilience lets companies roll back AI agents that go wrong — SiliconANGLE, September 16, 2026
- [Exaforce adds a kill switch for AI agents that go rogue](https://siliconangle.com/2026/09/15/exaforce-adds-a-kill-switch-for-ai-agents-that-go-rogue/) — SiliconANGLE, September 15, 2026
- [Anthropic runs about 30,000 AI agents on itself and blocks one action in 47,000](https://mixed-news.com/en/anthropic-30000-internal-ai-agents-blocks-one-in-47000/) — MIXED, September 21, 2026
- [Measuring the pace of AI development](https://www.anthropic.com/institute/measuring-pace-of-ai-development) — Anthropic Institute, September 17, 2026
- Akamai Report: Securing Agentic AI Requires Shift to Behavioral Governance — GlobeNewswire, September 22, 2026
- Temporal raises $550M at a $12.55B valuation as demand grows for reliable AI infrastructure — Temporal, September 14, 2026
- [For AI agents, it’s the best of times, it’s the worst of times](https://siliconangle.com/2026/09/18/for-ai-agents-its-the-best-of-times-its-the-worst-of-times/) — SiliconANGLE, September 18, 2026
- [AI Agents News — Week of September 23, 2026](https://aiagentstore.ai/ai-agent-news/this-week) — AI Agent Store
Enterprise AI Architecture
Want more enterprise AI architecture breakdowns? #
Subscribe to SuperML.