The database and the agent

What the agent can reach

An editor agent runs in your project folder with your permissions. It can read .env. If .env holds the production connection string, because you tested a migration against production once and never changed it back, then every command the agent runs has the power to drop every table.

Nothing in the tool stops this. The agent is not going to decide to destroy production; it is going to decide to “reset the database to fix the migration error”, which is the same command with a better reason. The protection is not a rule the agent reads but an arrangement where the credential is not there to be used.

The arrangement

Local .env holds a development database. SQLite, a Docker Postgres, or a free hosted database that exists for development only. The production string lives on the host’s settings page and in your password manager and nowhere on your disk.

Production gets a branch for the agent. Neon, Supabase and PlanetScale can create a copy-on-write branch of the production database in seconds: same schema, same data, separate: writes to it never reach the original. An agent working against a branch can run every destructive command it likes and the cost is deleting the branch. For an app with personal data, the branch inherits it, so the anonymising script from the seed lesson applies before an agent reads it.

Roles that can only read. Postgres lets you create a user that can SELECT and nothing else:

CREATE ROLE reporter LOGIN PASSWORD '...';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO reporter;

That role’s connection string is safe to hand to a tool for reports, dashboards or a database MCP server that lets the agent query live data. A DELETE from that role is refused by the database, which does not care what the rules file said.

The forbidden list, database edition

For the rules file, in addition to the git ones:

Database rules:
- Never run migrate reset, db push --force-reset, or any command that drops tables.
- Never run DELETE, UPDATE or TRUNCATE without a WHERE clause, and show me any
  DELETE or UPDATE before running it.
- Never edit files under migrations/ that have already been applied.
- Ask before adding a migration; show me the generated SQL.

These are a second layer, not the first. They stop the routine cases where the agent would otherwise reach for a reset; the credential arrangement stops the case where the rule was not read.

Give it the schema

The agent needs the schema to write anything useful, and the schema is not secret: it is a file in your repository. Point the rules file at it. An agent that has read schema.ts writes queries that match the actual columns; one that has not invents booking.customerName when the column is customer_id and spends twenty minutes on the resulting error.

What it does not need is rows. Most database work (a new query, a migration, a fix to a join) is done correctly against a seeded development database with forty rows. Real data is needed only when the question is about real data: why a particular report is wrong, what a slow query is doing at scale. Those are the moments for the read-only role on a branch.

Reading generated SQL

Before any query the agent wrote runs against anything that matters, read it, and look for three things.

A DELETE or UPDATE with no WHERE. It affects every row, and an ORM’s .delete() with no filter chained on is the same statement in disguise.

A query with no user scope. SELECT * FROM bookings WHERE status = 'pending' returns every user’s pending bookings; the user_id = ? from the session is missing, and the reading block taught you how to find the query behind the page.

String concatenation building the SQL. "WHERE name = '" + name + "'" is the injection hole the security block demonstrates; it looks like a shortcut and it is a door.

The recovery path, again

This lesson exists because the sequence agent, credential, reset has happened to enough people that it has a shape. The three layers (no production credential on disk, the forbidden list, a rehearsed backup) each catch what the others miss. Set them up in the first week, when there is nothing to lose, because the week when there is something to lose is the week you will not have time.