The AI Agent Didn’t Destroy Your Database. Your Access Controls Did.

You’ve probably seen the stories: an AI agent gets loose in a database, drops all the tables, production data gone. The reaction is usually “AI is dangerous and unpredictable.”

That’s the wrong lesson.

If an agent can drop your tables, the problem isn’t the agent. It’s that someone gave it a role with permission to drop tables in the first place. That’s not an AI failure — that’s pure bad IT management.

This isn’t new. It’s the same thing IT teams have managed with database roles for decades: if something needs to read data, give it read access. If it needs to write, give it write access to specific tables. You scope the role to what the job actually requires. You don’t hand out permissions “just in case.”

You don’t give an intern access to your production database. And that’s basically what you’re doing if you let an AI agent in without scoping its role.

AI didn’t invent this risk. It just made the consequence of skipping that principle a lot more visible — and a lot more likely to happen, because now something is actually using the access you never bothered to restrict.

So when a company tells the story of “the agent destroyed our database” as a cautionary AI tale, what it’s really telling you is that nobody set up proper roles. Making it a story about AI really just exposes how bad the access management was to begin with.

The fix isn’t a new AI safety framework. It’s the boring one you already know: scope the role, limit the permissions, and don’t give anything — human or agent — more access than its job requires.