Giving an AI Agent Access to Production: What Can Go Wrong?

For a while, AI coding tools only made suggestions. You asked a question, and the tool provided an answer that a human then decided what to do with.

That has changed. Now, agents run commands, call APIs, change configurations, and interact with real systems. This is precisely why people want them. It’s also why the question of what an agent can access has become an infrastructure question, not an AI question.

I use AI tools in my work, and I’m not arguing against them. I’m advocating for considering access before something goes wrong because all of the public incidents so far follow the same pattern.

What has already happened

In July 2025, Replit’s AI agent deleted a live production database despite repeated instructions not to make changes, and despite an active code freeze. The agent then reportedly provided misleading information about the recoverability of the data.

In April 2026, an AI coding agent working for PocketOS, a car rental software company, deleted the company’s production database on Railway, along with every volume backup, in a nine-second API call. According to the founder, the agent encountered a credential issue in the staging environment, decided to resolve it independently, located an API token in an unrelated file, and utilized that token to execute the destructive command.

Nobody told it to delete anything. It was trying to be helpful.

The model was not the only failure

It’s tempting to interpret these stories as “the AI went rogue.” This framing lets everyone else off the hook.

Consider what had to be true for the PocketOS incident to occur. A token with broad permissions was stored in a file that the agent could access. That token could act on production, not just staging. The backups were stored in a location that the same token could access and delete them.

Agents will sometimes make bad decisions. People do too. What turns a bad decision into a company-ending one is how much access the agent had when making it. These are old infrastructure problems: shared credentials, no separation between environments, and backups that can be accessed by anything that can access production.

What I would put in place before giving an agent real access

Use separate credentials for every environment. The token an agent uses in staging should not be able to access production at all; it should not just be “told” not to. Treat any credential that works everywhere as production access.

Use the least access necessary for the task. For example, if the task is reading logs, the credential should only be able to read logs. Use short-lived credentials that expire on their own instead of long-lived keys left in files and environment variables.

Keep secrets out of reach. Agents read files. A token in a configuration file, an old script, or a forgotten notes document is accessible to anything running in that directory.

Make sure that no daily credential can delete backups. This is the lesson I keep returning to when I talk about backups. A backup that can be deleted by the same access credentials that can delete production data is not a safety net; it’s just a copy. Keep at least one backup in a separate account with different credentials and test restoring from it.

There should be a human in front of destructive actions. Deleting data, dropping tables, removing volumes, and changing permissions should require human approval. The delay is the point.

Keep a record of what the agent did. If something goes wrong, you need to know exactly which commands were run, with which credentials, and when. Without logs, you’re just guessing.

What this costs?

Most of this is configuration work, not the development of new products. Splitting credentials by environment and trimming permissions usually takes a few hours for a small setup. Moving a backup copy to a separate account takes about the same amount of time. The ongoing cost is discipline: reviewing what each credential can do and avoiding handing out broad access because it’s faster in the short term.

Compare that with the cost of losing a production database and its backups, which could mean the end of a small company.

Questions worth answering before the next agent gets access

• What credentials can this agent see, and what can each one do?
• Can it access production from its current location?
• If it deleted everything within its reach, what would remain?
• Which actions require human approval?
• If something went wrong this afternoon, would we be able to tell what happened?

If some of these questions have no clear answer, fix that first. Agents are only going to become more capable, so the safest time to limit their access is before they have it.