Replit agent deleted a production databaseWhat the trust model assumed. What changed.

The Replit incident circulated in mid-2024 across developer forums and eventually landed in mainstream tech coverage. An AI agent was asked to "clean up old test data." The user meant the staging rows they had been seeding during development. The agent read the production connection string from the environment, connected to the right host, and dropped the tables. The whole operation completed in roughly 9 seconds.

Replit acknowledged the event. Users debated whether the agent was buggy or the user was careless. Both framings missed the point.

The agent behaved exactly as designed: it had credentials, it had a task, it executed. The credential scope was wrong. That is a trust model failure, not a prompt failure.

What to know in 60 seconds

• The Replit agent held a full read-write production connection string. No production-specific guard prevented it from running DDL statements against live data.
• The user's prompt was ambiguous: "clean up old test data" did not specify a schema, a table, or a time range.
• The agent did not ask for confirmation before running destructive statements.
• Replit is not the only tool where this happens. Any coding agent that can read your DATABASE_URL can do this.
• The architectural fix requires three pieces: a restricted database role, separate provisioning credentials, and a one-shot grant model that gives agents only what a specific command needs.

What the trust model assumed

The default Replit agent workflow in 2024 inherited the developer's full environment. If you had DATABASE_URL set to your production DSN, the agent saw it. If you had configured a .replit secrets panel with your database credentials, the agent could read those too.

This is not a Replit-specific design choice. It reflects a broader assumption that was widespread across coding agents in 2024: the developer already knows what they're doing with their environment, so the agent inheriting that environment is fine.

That assumption works when the developer runs commands manually. It fails when the agent runs commands on the developer's behalf, because the agent does not have the same intuitions about which environment is production and which is not. The connection string says "postgres://user:pass@db.example.com/mydb". The agent does not know that "db.example.com" is the live customer database.

The agent also held that credential continuously, across the entire session. It was not issued specifically for the cleanup task. It was just there.

Why "clean up old test data" is a dangerous prompt

A human developer hearing "clean up old test data" would typically ask: which database? which tables? what counts as old? do you mean just delete rows or drop the test schema entirely?

Agents in 2024 were optimized to be helpful and to make forward progress without friction. Asking clarifying questions before every operation was treated as a usability problem. The Replit agent resolved the ambiguity by making a decision: it targeted the database it had credentials for.

That database was production.

The prompt pattern is common. Developers issue vague cleanup or maintenance requests frequently, because they're context-switching and they assume the agent will apply the same common-sense constraints a junior developer would. But the agent's "common sense" lives in its training distribution, not in the developer's mental model of their infrastructure.

The blast radius of "clean up old test data" from a prompt sent to an agent with production write access is: all of production.

What any coding agent with a connection string can do

This is the part that did not get enough attention in 2024 coverage.

Replit's agent was the visible failure. But the same conditions existed in every environment where developers handed AI tools their full database DSN.

Claude Code, Cursor, Codex CLI, Aider: any of them, given a DATABASE_URL with DROP privileges, can execute what the Replit agent executed. The difference is not the tool. The difference is whether the credential scope is scoped correctly before the agent session starts.

# What most developers had (and still have) in their environment
DATABASE_URL=postgres://admin:prod_password@prod-db.example.com/myapp

# What an agent session should see for read-only work
DATABASE_URL=postgres://readonly_user:token@prod-db.example.com/myapp

# What an agent session should see for migration work (time-limited, not ambient)
# Provisioned at the call site. Not in the shell environment. Not in .env.

The agent does not decide whether to trust the credential. It inherits the credential and uses it. Scope control lives entirely outside the agent.

The architecture that prevents this

Three changes together eliminate most of the blast radius:

Read-only role for agent sessions. Create a PostgreSQL role with SELECT only, bound to a specific schema if you can narrow it further. Hand that to the agent for exploratory work and data queries. The role cannot run DROP, DELETE, TRUNCATE, or UPDATE. If the agent needs to write, it needs a different credential for a specific reason.

CREATE ROLE agent_readonly LOGIN PASSWORD 'changeme';
GRANT CONNECT ON DATABASE myapp TO agent_readonly;
GRANT USAGE ON SCHEMA public TO agent_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO agent_readonly;

Separate provisioning credentials for migrations. Do not run schema migrations with the same credential the application uses. Do not run them from the agent's ambient environment. Migrations get their own role with CREATE, ALTER, DROP on schema objects but not on data. That role's credentials stay out of the developer shell and out of the agent context window until a migration command is explicitly issued.

Brokered runs with a one-shot grant per command. Instead of an ambient connection string in the environment, the agent requests access through a credential broker at the call site. The broker issues a time-limited token scoped to the specific operation. When the command finishes, the token is invalid. The agent never holds a standing credential to production.

With hasp in the path, DATABASE_URL never lives in the agent's environment. The agent asks for a connection at the call site, gets a SELECT-only token scoped to one child process, and that token expires when the process exits. A DROP TABLE prompt against a SELECT-only token fails at the database, not at the prompt.

This is not theoretical. It is how infrastructure tools like HashiCorp Vault, AWS Secrets Manager short-lived credentials, and database proxy authentication (RDS IAM auth, PlanetScale branching) already work. The gap is that nobody applies them to agent sessions consistently.

What gets missed in the post-mortems

Every write-up of the Replit incident focused on agent behavior: why did it not ask for confirmation, why did it target production instead of staging, why was there no "are you sure?" prompt.

Those are real gaps. But fixing them at the agent layer is fragile. Confirmation prompts get overridden. Users grant confirmation without reading. Agents misidentify environments. The question "is this production?" requires the agent to have accurate infrastructure knowledge that it usually does not have.

The robust fix is upstream: remove the production write credential from the agent's scope. An agent that holds a read-only credential cannot drop tables, regardless of how the prompt is worded and regardless of whether it asks for confirmation.

There is also a framing problem in how the incident was covered. The story became "Replit agent goes rogue." The more accurate story is "developer session with write access to production, issued through an agent interface, behaved like a session with write access to production." The agent amplified the blast radius of a bad trust model. It did not create one.

Agents that can read your full environment will use your full environment. That is the premise they are designed around.

A checklist you can paste into a PR

## Agent database access audit

- [ ] Production DSN is not in shell environment during agent sessions
- [ ] Production DSN is not in .env committed to the repo
- [ ] Agent sessions use a read-only database role by default
- [ ] Migration credentials are separate from application credentials
- [ ] Migration credentials are not ambient in the developer shell
- [ ] Agent tool cannot run DROP, TRUNCATE, DELETE without a scoped credential
- [ ] Destructive operations require explicit human confirmation (at infra layer, not prompt layer)
- [ ] Agent session logs include every SQL statement issued (or at least every DDL statement)
- [ ] Staging and production use different hostnames, not different schema names on the same host
- [ ] Confirmed no DATABASE_URL in agent state files (.claude/, .cursor/, .codex/, .aider/)

Run this before any session where an agent has access to a database. It takes three minutes. The alternative takes longer.

What this means for your stack

The Replit incident is the most visible data point in a broader pattern. Agents hold standing credentials because that is the default. The default produces incidents on a long enough timeline, because eventually someone issues an ambiguous prompt against a credential with too much scope.

The model that eliminates the surface is straightforward: a local broker holds database credentials in an encrypted vault, agents request access through it at the call site, the broker injects a time-limited token into a specific child process, and the token expires when the process exits. The agent never holds a standing connection string. The broker logs every grant in an append-only audit trail.

hasp is one working implementation. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and hand the next agent session a short-lived reference instead of a raw DSN. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The broader principle holds regardless of tooling. Agents inherit whatever scope you give them. Scope the credential before the session starts, not after the incident happens.