Field note: reversible actions for AI agents
On 10 November 2026 Microsoft Threat Intelligence reported that editing fewer than 10 neurons can turn a capable agent model into a sleeper agent. It passes its evaluations, then, when a trigger string appears, runs an attacker's command with whatever access the agent has. Microsoft Research, the same day, calls the method Lazarus and says the edit needs no training. Their example is a date rolling into 2027: mid-task, the agent emits a command that downloads and runs an attacker's code. Microsoft says it has not observed threat actors using the technique. Both notes say an audit lowers risk and does not guarantee safe behaviour. The research note states the operating defence: treat the model as a possible insider, limit what it can do, and monitor what it does.
I lead data and AI work in a large insurer's GCC. The same question applies in SaaS, retail, healthcare, telecom, manufacturing, energy, fintech and BFSI alike, wherever an agent can change a live system. Tanmay Sah and Dolly Sah, writing in Communications of the ACM on 1 October 2026, separate verification from recovery. Verification asks whether the agent should take the step. Recovery asks what you do once it already has. They name the ordinary failures: the wrong tool, bad arguments, stale data, a repeat after a lost acknowledgement, and a workflow that finishes only in part.
Label the write before you connect the tool
Label every mutating tool by the real effect, including its arguments and the system it will change.
- Reversible: a journal or a transaction can restore the prior state. A draft, a feature flag, a versioned document, an uncommitted database change.
- Compensable: the original call stands, and a second action can put the business in an acceptable state. A refund, a cancelling order, a correcting entry, a retraction the channel still allows.
- Irreversible: no second action restores the position. A settled payment, a message a person has already read, a notice that changed what a customer was told, a physical movement, a deleted backup.
The OWASP Top 10 for Agentic Applications 2026, released in December 2025, asks for human approval on high-privilege or irreversible actions, and for short-lived credentials scoped to the task. Microsoft's 10 November guidance has the same shape on its own platform: a distinct identity per agent, least privilege, conditional access that can block an unapproved or high-risk identity, code only inside an isolated sandbox, egress limited to the endpoints the task needs, and a person in the loop for high-impact calls such as running commands, changing permissions, sending data out or modifying infrastructure.
Put the safe path in the system
Idempotency. Sah and Sah name the lost acknowledgement: the agent cannot tell whether the call landed, so it sends it again. Give every mutating call a key the receiving system honours, so the retry is the same action, and store that key in the log.
A journal, then a commit. Record the before-state, the intended change and a correlation id before the write. Where the system allows it, propose and then commit, and keep a window in which a person or a rule can still cancel. OWASP's cascading-failure guidance asks for tamper-evident, time-stamped logs bound to the agent identity, with enough lineage to validate a rollback.
Approval of the exact call. OWASP's entry on human-agent trust says a fluent rationale can be fabricated, and a missing confirmation turns that trust into an immediate write. Show the approver the tool, the parameters, the systems touched and the label. Where the write changes what a customer is told or paid, name the person who can approve, alter or reject it.
A kill switch, and a separate undo. OWASP's rogue-agent guidance calls for a kill switch and credential revocation that disable the agent quickly, then fresh checks and a human decision before it may write again. Effects already committed still need the compensating action, and an owner who can run it without the agent.
Blast radius is a cap on the run: how many records, messages or currency units one run may touch. OWASP puts quotas, progress caps and a circuit breaker between the planner and the executor. One agent, one purpose, credentials that expire with the task.
Checklist before an agent may write
Hand this to one owner. A blank row means the agent stays read-only on that tool.
- Name each mutating tool. Mark it reversible, compensable or irreversible, and name the system that proves the label.
- For a reversible tool, record the before-state and the restore command, and run that command on a copy.
- For a compensable tool, write the compensating action, who may run it, and the time after which it no longer matches what the other party was told.
- For an irreversible tool, require a fresh approval of the exact call: the tool, the parameters and the human decision.
- Put an idempotency key on every mutating call, and test a retry after a dropped response.
- Bind each run to an agent identity and a human principal, with short-lived credentials scoped to that task.
- Log intent, tool, parameters, outcome and correlation id in a store the agent cannot edit.
- Name who can throw the kill switch, what it revokes, and how you confirm that further writes have stopped.
- Set a blast-radius cap, and pause the agent when the cap or an anomaly is hit.
- Rehearse one bad action. Confirm the log, the stop, and the rollback or the compensation, and file the result.
- After any containment, require a human decision before the agent may write again.
If you are drawing the same line for agents that write into live systems, write to me at contactme@mukherjeesuman.com or compare notes on LinkedIn.
Views are my own and do not represent any employer.
How this post was made: drafted with AI assistance from public sources and checked against the sources linked above.
If this was useful, connect with me on LinkedIn, email contactme@mukherjeesuman.com, or read more articles.