AI Agent Deleted the Database? 7 Guardrails for Production
What the Replit AI agent database delete teaches: 7 guardrails to set before any AI agent touches a production database.
On this page
The Replit incident showed what an AI agent database delete looks like in practice. In July 2025, an AI coding agent deleted a production database during a code freeze. It did so despite being told not to make changes. The fix is not a better prompt. It is to make deletion impossible for the agent: separate production from development, give agents credentials that can only read, enforce read-only outside the agent, limit what it can see and how hard it can work, record every query, and keep backups you have actually restored. Below are seven guardrails, and which ones a tool like Datablare covers and which stay with you.
What happened at Replit
The widely reported facts are short. SaaStr founder Jason Lemkin was building an application with Replit’s AI coding agent. During a declared code freeze, when no changes were supposed to be made, the agent deleted the production database behind the app. Lemkin described the incident publicly. Replit’s CEO apologised, and the company announced safeguards, including automatic separation of development and production databases.
The details beyond that have been retold in many versions, and they are not needed for the lesson. An agent that had the ability to destroy production data was told not to, and it destroyed it anyway. The instruction was a request, not a control.
This is not a story about one vendor. Any agent connected to a database with write credentials can do the same. That includes coding assistants, autonomous agents and chat assistants with a database tool. It can happen through a misunderstood task, a plan that “cleans up” the wrong table, or text in the data that tricks the model.
The 7 guardrails
1. Keep production out of the agent’s reach by default
Development and production should be different databases with different credentials. A coding agent working on your app needs a development database it can freely break. It should not find production credentials in an environment file, a shared secret store or a config it can read.
This was the first safeguard Replit announced, and it is the cheapest one to adopt. Audit where your production connection strings live, and which processes can read them.
2. Give agents a login that cannot write
When an agent does need production data, for analysis, debugging or answering questions, give it a dedicated database login with SELECT on specific tables and nothing else. No DELETE, no DROP, no ALTER, no ownership of any objects, and never a superuser or db_owner.
A permission the login does not have is the strongest control there is. It holds whatever software connects with it, whatever the model decides, and whatever a prompt says. Our guide to creating a read-only database user for AI agents gives the exact SQL for PostgreSQL, MySQL, SQL Server, Oracle, ClickHouse and Snowflake.
3. Enforce read-only outside the agent, twice
Credentials get changed. Someone grants “just one more permission” to fix an urgent problem, and the read-only login quietly isn’t. So add two more layers that do not depend on the login:
- A read-only database session. PostgreSQL, MySQL, MariaDB and Oracle can mark a session read-only, and ClickHouse can mark each query read-only. The database then refuses writes from that connection even if the login could make them.
- A query check before the database. A gateway between the agent and the database refuses anything that is not a single read statement. That covers writes, DDL, multiple statements, and functions with side effects such as sleeps, locks or file reads. It should fail closed: a query it cannot understand is refused, not waved through.
A code freeze in a prompt is neither of these.
4. Limit what the agent can see
Read-only stops changes; it does not stop reading. An agent with SELECT on every table can read salaries, customer phone numbers and API keys stored in a settings table, and pass them to its model provider. Choose the tables each agent needs and hide sensitive columns, ideally per project or team, so the finance agent and the support agent see different things.
5. Bound every query
A read can still hurt production. An unfiltered join on two large tables, or a query that waits on purpose, can take a database down. Put limits outside the agent:
- a statement timeout on every query
- a cap on rows and bytes returned
- a cap on concurrent queries per database
- daily limits per team or project
- a read replica, where you have one, so analysis never competes with your application
6. Record every query somewhere the agent cannot edit
After an incident, you need to know what ran, who asked for it, and when, from a record the agent did not write. Log the question, the person or key behind it, the exact SQL, whether it was allowed or refused and why, the row count and the duration. Keep it outside the database the agent touches, and outside anything the agent can modify.
Refusals matter as much as successes. An agent that keeps trying to write, or keeps reaching for a table it was not given, is telling you something.
7. Keep a way back, and a way to stop
Two last controls, for when everything else fails:
- Backups you have restored. A backup that has never been restored is a hope. Test restores on a schedule, and know how long one takes.
- A kill switch. Be able to revoke an agent’s access in seconds, per person and per key, without rotating your main database password.
Schema changes and data fixes should go through your normal reviewed deployment process. An agent can write the migration; a person should approve it and a pipeline should run it.
Which guardrails Datablare covers
Datablare is a gateway that gives AI agents read-only access to your database over MCP. It cannot write at all. Here is how it maps to the list, including what it does not do:
| Guardrail | Datablare | Still yours |
|---|---|---|
| 1. Separate production | Not addressed | Separate dev and prod databases and credentials |
| 2. Login that cannot write | Detects whether the login can write, and gives you SQL for a read-only one | Creating and keeping that login read-only |
| 3. Read-only outside the agent | SQL guard on every query, plus a read-only session (PostgreSQL, MySQL, MariaDB, Oracle, ClickHouse) or an always-rolled-back transaction (SQL Server, Snowflake) | — |
| 4. Limit what it sees | Choose tables per project; hide columns, refused wherever read | Deciding what each team needs |
| 5. Bound queries | Timeouts (30 s default, 60 s max), up to 5,000 rows and 1 MB per query, concurrency caps, daily limits | A read replica, where you have one |
| 6. Record everything | Audit log of question, person, SQL, outcome, rows and time; refusals with reasons; results never stored | Reviewing it |
| 7. Way back and stop | Revoke any key or connection instantly; removing a person revokes their access | Backups and restores of your database |
The guard refuses writes, DDL, multiple statements, SELECT ... INTO, EXEC, WAITFOR, the TABLE shorthand, and side-effect functions: sleeps, locks, set_config, file and remote-server functions, and Oracle package calls. It also refuses functions that reveal your server’s identity, tables you did not expose, and columns you hid. The security page has the full picture.
What these guardrails do not solve
Be honest about the remaining risk:
- Agents read what you allow. Rows from allowed tables go to the AI provider under its terms. Hide columns you would not paste into a chat.
- Prompt injection still works on reading. A planted instruction in a support ticket can steer an agent to query, then repeat, data it is allowed to read. Narrow access keeps that small.
- Coding agents with shell access are a different problem. If an agent can run commands on a machine holding production credentials, a database gateway does not help. Guardrail 1 does.
Start with the cheapest controls
Move production credentials out of agent environments today, and give every agent its own read-only login. If you want the gateway layer as well (query checks, tables and columns per project, limits and an audit log) you can try Datablare free on a sample database before connecting your own. See how it works for the query path end to end.
Frequently asked questions
What happened in the Replit AI agent database incident?
In July 2025, an AI coding agent on Replit deleted a production database during a declared code freeze, while SaaStr founder Jason Lemkin was building an app with it. Replit's CEO apologised publicly, and the company announced safeguards, including separating development and production databases.
Can telling an AI agent not to change anything prevent it from deleting data?
No. Instructions in a prompt shape what a model is likely to do; they do not limit what it can do. If the agent's credentials allow DROP or DELETE, a misread instruction, a bad plan or a prompt injection can still run one. Limits have to live in the credentials and in the systems between the agent and the database.
How do I stop an AI agent from deleting my production database?
Do not give it credentials that can delete. Keep production credentials out of development environments, give agents a login with only SELECT on chosen tables, enforce read-only in the database session and in a gateway that checks each query, and keep tested backups. Route schema changes through your normal reviewed deployment process instead of through an agent.
Is read-only access enough to make an AI agent safe on production data?
It removes the risk of changes, which is the risk the Replit incident showed. It does not limit what the agent can read or where it sends what it reads. Add table and column restrictions, timeouts and row limits, and an audit log of every query.