Databases with Agents: Safe, Not Risky

An agent with database access can break more in seconds than a human could in hours – read-only first protects you from that.

Why databases are especially risky

An agent that writes bad code produces a bug. An agent that runs a bad database query can delete or corrupt real data – often with no way to undo it. That's why databases need stricter rules than ordinary code.

Read-only first

For research and debugging, give an agent read access only. An agent that can only run SELECT queries can help you understand data and schema without being able to destroy anything. Write access gets added only when truly necessary – and even then, scoped tightly.

Migration discipline

Schema changes (migrations) never go straight into a live database. They run through versioned migration files that get reviewed, tested, and only then applied. An agent can propose and write a migration – but running it should go through a controlled process, not a spontaneous shell command.

Never touch prod without a gate

Access to the production database always needs a deliberate gate: a human confirming, a separate access token, or both. An agent should never be able to automatically hop from staging to production.

Don't skip backups

Before any write operation runs, no matter how small: a current backup must exist. That's the last line of defense when everything else fails.

EXAMPLE

Example setup: an agent gets access through a DB user called `readonly_agent` that only has SELECT rights on the staging database. For schema changes, the agent writes a migration file (e.g. with a migration tool) that only gets applied through the regular pipeline after human review – never directly via a shell command on prod.

QUICK QUIZ

What's the safest baseline rule for an agent's access to a database?