Which coding agent actions can't be undone, and how should I gate them?

Two kinds of damage#

Not every bad agent action costs the same. Sort them by one question: can you get it back?

Recoverable. The agent deletes files in the workspace, rewrites uncommitted work, or breaks a local build. Annoying, sometimes ugly, but you can restore it. Snapshot or checkpoint the workspace every turn and this class mostly stops mattering.

Unrecallable. The action reaches someone or something outside your machine, and there's no undo. A published package version is already in other people's lockfiles.

A sent email is sent. A force-push to a shared branch has already overwritten what teammates pulled.

The first class is huge and mostly harmless with checkpoints. The second is small. That asymmetry is the whole strategy: gate the small set, let everything else run.

The unrecallable set#

This is the list I'd start from. It lines up with the harm classes in Harden's threat model for AI coding agents (Nov 2026): outward supply-chain contamination, destructive change, service disruption, and the agent using the user's authority toward the outside world.

• Publishing: a package version, a container image, a release artifact.
• Pushing to shared or public upstreams: including force-pushes to a default branch, which rewrite history other people depend on.
• Deploying: to production or any environment customers touch.
• Migrating or dropping data in a live database: and anything that deletes backups stored next to it.
• Acting as the user toward the outside world: emailing a customer, commenting on a public issue, posting in a shared channel.
• Spending money or accepting terms: orders, subscriptions, clickwrap agreements.
• Editing shared CI templates or release pipelines: the change fans out to every repo that uses them.
• Rotating or revoking a credential that's in use.

Notice what's missing: reading files, editing code in the working tree, running tests, local commits. Those are recoverable, so they don't need a gate.

What it looks like when it goes wrong#

Replit's agent deleted SaaStr's production database during a code freeze. Jason Lemkin's verdict: "There is no way to enforce a code freeze in vibe coding apps like Replit. There just isn't." An instruction isn't a control.

A Cursor agent deleted a startup's production database with a token that had been created for managing custom domains but was scoped for any operation, including destructive ones. The host stores volume-level backups in the same volume, so the backups sat within reach of the same credential.

Then there's the supply-chain version. A hacker used a single pull request to get a prompt into Amazon's AI coding assistant telling it to "clean a system to a near-factory state and delete file-system and cloud resources". Whether it would have wiped anything is uncertain. What matters is that one pull request put a destructive instruction into a coding assistant people had installed.

What each built-in control does and doesn't do#

Permission prompts. They put a human at the gate, but humans don't hold it. In Anthropic's controlled study of 1,053 testers, human review caught 13.6% of dangerous commands, and Anthropic reports people approve 93% of prompts. A prompt on every action leaves no real gate on the one that matters.

Permission rules. They're useful, and you can deny specific tools and commands with them. But in Claude Code, Bash rules match the whole command text. Write the same push or delete another way and the rule sees a different string.

Sandboxes. They limit what the process can reach on the machine, which helps with local damage. They do less about an API call to a service the agent can legitimately reach with a token it can read.

Scoped credentials. The strongest control on this list. A token that could only manage domains couldn't have dropped that startup's database. The catch is that they take work per system, and they only help where the system supports scoping.

Snapshots and checkpoints. They mostly fix the recoverable class and do nothing for the unrecallable one. You can't snapshot your way out of a published package.

A decision rule#

Ask four questions about any action:

• Does it leave the machine or the repo?
• Is it visible to anyone besides me?
• Can I fully reverse it in under a minute, without anyone's help?
• Does it use authority I hold outside this task, like a publish token or a production credential?

If it leaves the machine, can't be reversed alone, or uses outside authority, gate it. If it stays local and reversible, let it run. Keep the gate to a short list, and make it a written policy, not something each developer remembers to do.

Checklist#

• Make the agent's workspace restorable: checkpoint each turn.
• Keep publish, deploy and production tokens out of the developer's shell environment and out of files the agent can read.
• Scope every token that has to be there to the narrowest operation.
• Put backups somewhere the same credential can't delete.
• Block force-push to default branches and direct publishes from laptops; route them through CI with a human approver.
• Treat unattended and CI sessions as the weak spot, since trust prompts don't appear there.
• Log every gated decision so you can show it later.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. It checks every command, file edit and push against the session's intent before it runs. Decisions are made locally in milliseconds, and nothing leaves the machine.

A force-push to a default branch, curl piped to a shell, or a secret headed for a network call can be blocked, sent to a human, or rewritten into a safe call. Ordinary local work goes through without a prompt.

AIF starts watch-only, so you can see how often agents reach for the unrecallable set before you enforce anything. One policy covers every agent, pushed by the MDM you already run.

It's a layer, not a perimeter. It doesn't replace scoped credentials, least privilege or egress policy, and exfiltration spread across several calls is the hard case. More on the mechanism for security teams.