Prevent accidental deletion by your agent

Before you delete

Use explicit approvals, code history and independent exports before risky changes. Learn what daily snapshots do and what to check before deleting data.

Updated 6 October 2026

Let your agent build this

Copy one prompt and paste it into Claude Code, Codex or Cursor. Your agent builds what this page describes and puts it online on aidrop.it.

Review this aidrop.it Project before we change it. Do not mutate or delete anything.

1. List the Services, databases and repositories involved in the proposed change.
2. Record each Service's current version and available application rollback path.
3. Identify destructive operations and explain which data or history they remove.
4. Propose an independent database export to storage I control and an isolated restore test.
5. State any recovery information you cannot verify, including snapshot availability and restore steps.
6. Wait for my approval of the exact change and export plan before proceeding.

This task comes from the aidrop.it guide "Before you delete": https://docs.aidrop.it/playbooks/stop-your-ai-agent-from-deleting-your-project. Read that page if you need more detail; it says what to ask me for, what it costs and what will not work.
Use the aidrop.it MCP tools (server: https://aidrop.it/mcp). If you do not have them, stop and tell me to connect them first, as described at https://docs.aidrop.it/quickstart#1-connect-your-agent.

See the prompt

Review this aidrop.it Project before we change it. Do not mutate or delete anything.

1. List the Services, databases and repositories involved in the proposed change.
2. Record each Service's current version and available application rollback path.
3. Identify destructive operations and explain which data or history they remove.
4. Propose an independent database export to storage I control and an isolated restore test.
5. State any recovery information you cannot verify, including snapshot availability and restore steps.
6. Wait for my approval of the exact change and export plan before proceeding.

This task comes from the aidrop.it guide "Before you delete": https://docs.aidrop.it/playbooks/stop-your-ai-agent-from-deleting-your-project. Read that page if you need more detail; it says what to ask me for, what it costs and what will not work.
Use the aidrop.it MCP tools (server: https://aidrop.it/mcp). If you do not have them, stop and tell me to connect them first, as described at https://docs.aidrop.it/quickstart#1-connect-your-agent.

aidrop.it takes daily snapshots. Before a risky change, also keep the running version of your app and an independent database export. A snapshot schedule does not mean an agent can undo every deletion or restore any point in time.

This guide helps you review a proposed change before your agent runs it. For the export commands and their limits, see Taking your work with you.

Set the rules before a change

Tell your agent what it may change and which actions need your explicit approval. Name destructive operations directly: deleting a Project, Service, repository or database; force-pushing code; dropping tables; and deleting rows. A rule in a repository helps the agent follow your intent, but does not replace access controls or an export you have tested.

Connect through your own Team membership and review the permissions that membership grants. The MCP reference explains the connection and tool permissions. Do not give an agent more access just to avoid an approval step.

Keep a way back for the application

Record the Service’s current version before deploying a change. If a new application version fails, use the Service lifecycle guide to check the available versions and roll back to a known working one. Keep an independent clone of code you need before deleting a repository.

Application rollback and database recovery are separate operations. Starting an older image does not reverse a schema migration or put deleted rows back. Check the database change before approving the deployment.

Daily snapshots and independent exports

We take daily snapshots. For an independent copy, your agent can export a small database over MCP or run a pg_dump job inside the Project and send the result to storage you control. Test restoring that export into an isolated database before relying on it for a migration.

Do not infer a seven-day retention window, a trash folder or a self-service restore command from the daily snapshot schedule. Before a recovery action, confirm the available snapshot and recovery steps with support. Keep new writes stopped if they could overwrite evidence or make the damage worse.

Review a deletion before approving it

A deletion confirmation should name the exact resource and the data it removes. Check that your export is complete and usable before approving a database deletion. Treat removal of a Project or repository as a separate action from stopping a running application.

If something has already been deleted, stop further destructive work and record the resource, time and last known working version. Contact support about the available recovery options. Do not ask an agent to recreate or overwrite the resource before you know what recovery requires.

A prompt for your agent

Paste this into your connected coding agent. It asks for a review before any change and does not assume there is a snapshot-management tool.

Review this aidrop.it Project before we change it. Do not mutate or delete anything.

1. List the Services, databases and repositories involved in the proposed change.
2. Record each Service's current version and available application rollback path.
3. Identify destructive operations and explain which data or history they remove.
4. Propose an independent database export to storage I control and an isolated restore test.
5. State any recovery information you cannot verify, including snapshot availability and restore steps.
6. Wait for my approval of the exact change and export plan before proceeding.

FAQ

Can I undo a deletion?

No such guarantee follows from a snapshot schedule. Check the available snapshot and recovery steps before relying on it. Keep an independent export before deleting data you need.

Does rolling back my app restore its database?

No. Application versions and database contents are separate. A database migration needs its own recovery plan.

Does aidrop.it take snapshots?

Yes, we take daily snapshots. Your agent can also make independent database exports to storage you control.

Are written rules enough?

A written rule helps an agent follow your instructions. Also review its permissions, require explicit approval for destructive actions and test your independent exports.

Review this aidrop.it Project before we change it. Do not mutate or delete anything.

1. List the Services, databases and repositories involved in the proposed change.
2. Record each Service's current version and available application rollback path.
3. Identify destructive operations and explain which data or history they remove.
4. Propose an independent database export to storage I control and an isolated restore test.
5. State any recovery information you cannot verify, including snapshot availability and restore steps.
6. Wait for my approval of the exact change and export plan before proceeding.

This task comes from the aidrop.it guide "Before you delete": https://docs.aidrop.it/playbooks/stop-your-ai-agent-from-deleting-your-project. Read that page if you need more detail; it says what to ask me for, what it costs and what will not work.
Use the aidrop.it MCP tools (server: https://aidrop.it/mcp). If you do not have them, stop and tell me to connect them first, as described at https://docs.aidrop.it/quickstart#1-connect-your-agent.