Stop an AI Coding Agent From Touching Production

Telling an agent "never touch the production database" in a system prompt is not a control, it's a suggestion the agent has no structural reason to honor if a production connection string happens to be reachable from wherever it's working. The actual fix is architectural: scoped credentials so a production connection string is never in the agent's reach, a read replica for anything it needs to query, and a migration gate that requires a human to actually apply schema changes. Build it so touching production isn't a mistake the agent could make even if it tried.

Why "just tell it not to" doesn't work

An agent uses whatever credentials and connection strings are available in its working environment. If your `.env` file, your deploy config, or a shared secrets manager makes a production `DATABASE_URL` reachable from the same context the agent operates in, a prompt instruction not to use it is the only thing standing between a normal-looking task and a production write. Agents don't have an innate concept of "this one is off-limits": they have whatever access the surrounding system grants them, and a system prompt is advisory, not enforced.

The three-part architecture

1. Separate credentials per environment, scoped at the database level. Create a database role that only has access to development or staging, and make sure that's the only credential ever present in anything the agent's tooling can read. Production credentials live somewhere the agent's working directory, environment, and connected tools never touch.

2. A read replica for anything the agent needs to query for context. If the agent genuinely needs to see real data shapes to write correct code, point it at a read replica or a synced staging copy, never the primary. A replica that falls behind by a few minutes is a non-issue for this use case and removes the agent's ability to write to production entirely, by construction, not by instruction.

3. A migration gate that requires human execution. The agent can draft a migration file. A person runs it, in CI or manually, after review. Auto-applying agent-generated migrations against production is the single highest-leverage way to turn one bad prompt into an outage.

What this looks like concretely

In practice: your local `.env.development` (or equivalent for your stack) has a connection string scoped to a dev database role, and that's the only environment file present in the agent's working directory or exposed to its shell. Production secrets live in your hosting platform's secrets manager, injected only into the deployed runtime, never into a local dev shell or an agent's tool-execution environment. CI applies migrations as a separate, human-triggered or human-approved step, reading the migration files the agent generated but never invoking the agent itself against the production connection.

The one thing that breaks this

A shared secrets manager with blanket read scope across environments defeats the entire architecture in one step. If the tool your agent uses to fetch secrets has permission to read the production secret alongside the dev one, scoping your local files doesn't matter, the agent can still reach it through the tool. Audit exactly what your agent's connected tools (secret managers, deploy CLIs, database clients) are scoped to see, not just what files sit in the project directory. The same logic applies to how you handle any sensitive value an agent might encounter; see our guide to environment variables and secrets in an AI-built app for the broader pattern.

If the agent genuinely needs production data for debugging

Use an anonymized or synthetic snapshot of production data loaded into staging, refreshed periodically, rather than granting any read access to the real database. This solves the actual problem (the agent needs realistic data shapes and volumes to reason about a bug correctly) without ever putting production credentials in reach. For the migration side of this same discipline, see our guide to AI coding agent database migrations, done safely.

Frequently asked questions

Isn't a read replica overkill for a small solo project?

For a genuinely tiny project, a staging database seeded with synthetic or anonymized data covers the same need at less operational overhead than a true replica. The principle that matters is that nothing the agent can reach has write access to production, whichever mechanism gets you there.

What if my hosting platform only gives me one database?

Create a second, smaller database instance for development even on a budget-constrained platform. Most managed database providers have a low-cost or free tier sufficient for this, and the cost is worth it against the alternative: a review of what actually happens if an agent's first draft of a migration runs directly against the only database you have.

Can I just revoke the agent's ability to run shell commands instead?

That removes a lot of capability along with the risk, since most of what makes an agent useful for backend work involves running commands. Scoped credentials solve the specific problem (production access) without removing the agent's ability to do its job in the environment it's actually supposed to touch.

Does this apply to a human developer's AI-assisted terminal session, not just an autonomous agent?

Yes, and arguably it matters more there, since a human in a terminal session with an AI coding assistant can approve a suggested command without reading it carefully, especially late in a long session. The same credential-scoping applies regardless of whether the agent is running autonomously or suggesting commands for a human to approve; the failure mode (a reachable production connection string) is identical either way.

For more on the surrounding practices for building safely with AI tools, see our Building apps with AI guide, and our broader framework for sandboxing an AI agent before trusting it with more access.