The Recovery Boundary for AI Coding Agents: Protect Files, Data, and Deployments

An AI coding agent is halfway through a database migration. It decides that an old directory is generated output and removes it. Then it notices failing tests, rewrites a cleanup script, and runs the script against the environment available in its shell. The code change is visible in a diff. The deleted customer records are not.

The usual response is to add another permission prompt. That may help, but it is not a recovery plan. A tired founder can approve a broad command without understanding its expansion. A safe-looking command can call a script with destructive behavior. An agent may also be tricked by instructions embedded in a repository, issue, webpage, or tool output.

The stronger question is not, “Can we make the model promise never to delete anything?” It is:

If the agent makes the worst plausible authorized change, what stops the damage from crossing a boundary, and how do we prove we can recover?

This guide is for small teams using coding agents on real products. It offers a recovery-boundary framework for source code, local files, cloud configuration, databases, and external side effects. It does not claim that every agent failure is preventable. The goal is to make destructive capability narrow, observable, and recoverable before autonomy increases.

Start With the Asset, Not the Agent

Model behavior changes across prompts, versions, tools, and context. Your control system should not depend on predicting every behavior correctly.

OWASP describes excessive agency as a combination of excessive functionality, permissions, or autonomy. Its examples include giving a read-oriented agent access to delete operations, connecting with a database identity that can update or delete unnecessarily, and performing high-impact actions without independent approval. The recommended controls are outside the model: minimize tools and permissions, avoid open-ended extensions where possible, enforce authorization downstream, and require approval for high-impact actions.

NIST's 2026 report on a large agent-security red-teaming competition reinforces why external controls matter. Across more than 250,000 attack attempts against 13 frontier models, the researchers found at least one successful hijacking attack against every target model. This does not mean every coding session is compromised. It does mean “the model will recognize malicious instructions” is not a sufficient production boundary.

Inventory what an agent can affect in the session you actually run:

If “recovery path” is an assumption rather than a tested procedure, mark it unknown. That one table usually reveals more risk than a long debate about which model is safer.

The Five Recovery Boundaries

A coding agent becomes safer when it must cross several independent boundaries before it can create durable harm. None is sufficient by itself.

1. The workspace boundary: make the default environment disposable

Give the agent a dedicated repository clone, worktree, container, or short-lived development environment. Mount only the directories required for the task. Keep personal folders, credential stores, backup volumes, and unrelated repositories outside its write scope.

This boundary addresses an easy misconception: Git protects only content it knows about. A deleted tracked file can usually be restored from a commit or index. An untracked design file, an ignored .env, a local database, and work that was never committed may have no Git recovery path. git status before an agent session is therefore a safety check, not housekeeping.

A practical session start looks like this:

1. Commit, stash, or separately back up valuable human work.
2. Create a task-specific branch or worktree.
3. Confirm the agent's writable directories.
4. provide synthetic or minimized data rather than a production copy.
5. Remove production credentials from the environment.

Agent vendors expose permission and sandbox controls, but configuration matters. Anthropic's Claude Code documentation, for example, describes read-only defaults, explicit approval for system-modifying Bash commands, sandboxing for filesystem and network isolation, project-specific permission settings, and additional isolation through development containers. Treat those as layers to configure and verify, not as a guarantee that every approved command is safe.

2. The authority boundary: separate development from production identity

An isolated folder is not isolated if its shell contains an administrator token.

Use a distinct identity for agent sessions. Its permissions should match the task and expire when practical. A frontend task does not need database write access. A migration-planning task can inspect a scrubbed schema without credentials that execute migrations. A deployment-review task does not need permission to deploy.

Do not rely on the prompt to say “never touch production.” Enforce that rule in IAM, database grants, network policy, and the downstream API. OWASP explicitly recommends complete mediation: the downstream system should validate whether an action is authorized rather than trusting the model to decide.

For a small team, the minimum viable separation is:

• no production secrets in routine local agent sessions;
• read-only production access only when the task genuinely requires it;
• separate credentials for staging and production;
• narrowly scoped deployment tokens;
• no shared all-powerful token copied across tools;
• a record tying consequential actions to a human and a session.

This can feel slower than exporting one convenient credential. It is faster than discovering that a code-editing task also had authority over billing, DNS, and customer data.

3. The change boundary: turn edits into reviewable proposals

Source changes should move through a branch, diff, tests, and a protected merge path. GitHub branch protection can require pull-request reviews, passing status checks, successful deployments, and restrictions on force pushes and deletion. It can also prevent bypasses from applying only to ordinary contributors while administrators remain unconstrained.

Configure protection for the risk you have, not for the appearance of process. If the same agent identity can modify the workflow file, approve its own pull request, bypass protection, and deploy, the gates are not independent.

A useful review asks more than “does the app build?” Inspect:

• deleted files and unusually large diffs;
• changes to migrations, seed scripts, CI, infrastructure, permissions, and lockfiles;
• commands the agent ran, not only the final patch;
• generated artifacts that hide a source change;
• tests removed or weakened alongside an implementation;
• environment assumptions the reviewer cannot reproduce.

Prefer a new forward migration over editing one that may already have run. Prefer preview, dry-run, or plan output for infrastructure. Require a human to compare the intended effect with the actual diff before a production transition.

4. The data boundary: define recovery points before writes

Code rollback and data rollback are different operations. Deploying the previous commit does not restore rows deleted by the new version. Reverting a migration file does not reverse a migration that already ran.

For each stateful service, define two plain-language targets:

• Recovery point objective (RPO): how much recent data could be lost?
• Recovery time objective (RTO): how long could restoration take?

PostgreSQL documents point-in-time recovery by combining a base backup with archived write-ahead logs, allowing recovery to a chosen time after that backup. Managed databases often provide related features, but the settings, retention window, permissions, and restore process vary. “The provider has backups” is not the same as “this database has usable recovery configured.”

Backups must also sit outside the destructive identity's reach. If the agent can delete production data and the only backups with the same credential, one mistake can erase both. For critical assets, separate backup administration, use retention or immutability where available, and alert on backup-policy changes.

5. The execution boundary: approve the effect, not the command string

Permission prompts are most valuable at a boundary where the human can understand the proposed effect. “Run npm test?” is reviewable. “Run this 80-character shell pipeline?” may not be. “Apply migration that will lock one table, rewrite 400 rows in staging, and cannot run with the production role” is better.

Classify actions before the session:

• Reversible and local: edits inside a disposable branch.
• Reversible but shared: staging deployment or test-data mutation.
• Recoverable with cost: production database write covered by tested PITR.
• Externally reconcilable: email, payment, or account action with a stable operation ID.
• Effectively irreversible: secrets exposure, destructive third-party calls without recovery, or publication with legal consequences.

The last two categories need controls in the tool or downstream service: idempotency keys, two-person approval, rate or value limits, delayed execution, soft deletion, reconciliation, or a complete block. A conversational “Are you sure?” is not enough when the person approving cannot see scope, target, and rollback path.

A 75-Minute Destructive-Action Drill

Run this in an isolated non-production environment with synthetic data. Do not ask an agent to damage production to prove that controls work.

Minutes 0–15: write the worst plausible action

Choose one real workflow, such as upgrading a dependency, applying a schema migration, cleaning generated files, or preparing a deployment. List every reachable asset and credential. Then state one believable failure without sensationalism:

“The cleanup command expands an empty variable and targets the workspace root,” or “the migration connects to the wrong database and removes records.”

Record the expected boundary that should stop it.

Minutes 15–30: prepare evidence and sentinels

Create known test files and rows that make damage measurable. Include:

• a tracked file committed before the session;
• an untracked file that has been backed up separately;
• a synthetic database row created at a known time;
• a protected branch or pull-request rule;
• logs that identify the session and executed actions.

Take or verify the relevant backup. Record the start time so you can measure recovery rather than guessing.

Minutes 30–45: exercise each boundary safely

Attempt the destructive path against the test environment. Confirm that:

• the agent cannot write outside the intended workspace;
• production credentials are absent or rejected;
• branch deletion, direct push, or merge without checks is blocked;
• high-impact commands require an effect-aware approval;
• the test database can be damaged without reaching production;
• backup policy cannot be modified by the same identity.

A pass is evidence from the filesystem, identity provider, repository host, database, or audit log. The model saying it was blocked is not evidence.

Minutes 45–65: restore to a clean destination

Restore deleted source from version control and untracked work from its separate backup. Restore the database into a new non-production instance or namespace. Validate application-level behavior: can you query the sentinel record, authenticate, load the affected page, and run integrity checks?

AWS Well-Architected guidance warns against merely assuming a backup exists or restoring it without querying the result. It recommends measuring whether recovery meets RPO and RTO. Google Cloud likewise recommends restoring in a non-production environment, checking data consistency, and exercising the full application stack with restored data.

That distinction matters. A green “backup completed” job proves that bytes were written. It does not prove that your team can locate the right recovery point, obtain decryption keys, restore dependencies, validate the data, and return the product to service.

Minutes 65–75: make a launch decision

Record:

• which boundary stopped or contained the action;
• what still changed;
• measured data loss and restore time;
• who had authority to recover;
• which evidence verified success;
• the next control, owner, and deadline.

Do not mark the drill passed if the only recovery is “ask the agent to fix it.” Recovery must remain possible when the model, prompt, tool, or session that caused the problem is unavailable.

Common Failure Modes That Look Safer Than They Are

“Everything is in Git”

Git does not automatically protect untracked files, ignored secrets, local databases, cloud resources, or customer data. It also does not preserve changes that were never committed unless another recovery mechanism captures them.

“We take daily backups”

A daily backup may still allow nearly a day of data loss, and it may be corrupt, inaccessible, or too slow to restore. Backups become an operational control only after a restore drill verifies content and timing.

“The agent asks before shell commands”

Approval can fail through fatigue, misleading command summaries, scripts with hidden effects, or a broad approval granted earlier. Pair prompts with narrow credentials, sandboxing, protected paths, and downstream policy.

“We can roll back the deployment”

Application rollback may be unsafe after an incompatible schema or data transition. Plan forward and backward compatibility, separate code rollout from destructive cleanup, and delay irreversible migrations until the new path is proven.

“Production is read-only”

Read access can still expose secrets or personal data, and an agent may send that context to another service. This recovery framework primarily addresses destructive integrity and availability failures; it does not replace privacy review, data minimization, or exfiltration controls.

Where This Framework Applies—and Where It Stops

This approach fits early-stage web products, internal tools, and ordinary SaaS workflows where a team can isolate development, define recoverable state, and test a non-production copy.

It is not sufficient by itself for medical, financial, industrial, government, or other high-consequence systems. Those environments may require formal threat modeling, segregation of duties, compliance controls, validated disaster-recovery procedures, and qualified security and reliability review.

It also cannot undo every effect. A leaked secret must be revoked, not merely restored. A public message may need correction. A payment may require reconciliation. A privacy breach cannot be reversed by database PITR. Prevention, detection, containment, and recovery are separate capabilities.

The Founder Recovery Gate

Before giving a coding agent more autonomy, require defensible answers:

• Is valuable human work committed, stashed, or backed up before the session?
• Is the agent confined to a task-specific workspace?
• Are unrelated directories and credential stores outside its write boundary?
• Are production secrets absent by default?
• Does the session use the minimum downstream permissions needed?
• Can source changes reach the main branch only through review and checks?
• Are migration, infrastructure, permission, and workflow changes reviewed explicitly?
• Does every stateful service have an owner, RPO, RTO, and documented restore path?
• Are backups protected from the same identity that can damage production?
• Has the team restored recent data into a clean non-production destination?
• Did application-level validation prove the restored state is usable?
• Are irreversible external effects blocked, delayed, limited, or independently approved?
• Can audit evidence connect an action to a session and human authorization?
• Is there a kill path that does not depend on the agent cooperating?
• Have residual risks been accepted by a person who understands the user impact?

The useful standard is not zero agent mistakes. It is controlled consequence. A coding agent can move quickly inside a disposable workspace, propose a large diff, and automate repetitive checks without holding the keys to every durable system.

Model capability will keep improving. Recovery boundaries let a founder benefit from that capability without making confidence in the model the final line of defense.

References

• OWASP GenAI Security Project, LLM06:2025 Excessive Agency, on minimizing agent functionality, permissions, and autonomy and enforcing approval downstream.
• NIST Center for AI Standards and Innovation, Insights into AI Agent Security from a Large-Scale Red-Teaming Competition, on agent hijacking results across tool-use, coding, and computer-use scenarios.
• GitHub Docs, About Protected Branches, on required reviews, status checks, push restrictions, deletion controls, and bypass behavior.
• Anthropic, Claude Code Security, on permission-based controls, Bash sandboxing, project settings, and development-container isolation.
• PostgreSQL Documentation, Continuous Archiving and Point-in-Time Recovery, on base backups, write-ahead-log archiving, restore targets, and recovery validation.
• AWS Well-Architected Framework, Perform Periodic Recovery of the Data to Verify Backup Integrity and Processes, on tested restores, RPO, RTO, and data validation.
• Google Cloud Well-Architected Framework, Perform Testing for Recovery from Data Loss, on non-production restoration, consistency checks, and full-stack recovery tests.