A new market has formed around AI governance. Standards bodies are convening. Tooling categories are being invented. Consulting practices are positioning themselves as specialists in what agents require that other software did not. The implicit claim across all of it: deploying AI agents introduces governance requirements that didn’t exist before.
It doesn’t.
The organization that deployed an agent and discovered it had no audit trail, overly broad permissions, and no defined blast radius did not discover new problems. It discovered old ones, running at a new speed. Those problems existed before the agent arrived. The agent is why they surfaced.
The same old failures
Three failure patterns show up repeatedly in troubled agent deployments. None of them are new.
Overly broad permissions. An agent with access to everything is a service account nobody audited. Least privilege is a principle with a fifty-year documented history. The failure — granting a system more access than it needs to do its job — is an IAM failure. Adding a language model to the system doesn’t change the category of the failure. It changes the speed at which the excess access gets exercised. If your agent can read, write, delete, and exfiltrate across your entire environment, you don’t have an AI governance problem. You have a permissions model you never enforced.
No audit trail. If you couldn’t trace what your software did, you can’t trace what your agent did. The organizations scrambling to instrument their agents for “explainability” are often the same organizations that never instrumented their services for basic operational visibility. The question “what did this process touch and when?” was unanswerable before the agent. It’s still unanswerable. The agent didn’t create the gap. It made the gap consequential in a new way. Observability is not an AI problem.
No defined blast radius. If nobody defined what the agent could touch, couldn’t touch, and should never touch before deployment, that’s an incident response planning failure. It predates the agent. Teams deploying agents outside IT and security visibility are doing what teams have always done with unsanctioned tools. The difference is velocity. Blast radius is not an AI problem.
The principle
If a human can’t bring the whole thing down, neither should an agent.
Blast radius is a design constraint. It applies uniformly. An agent acts on behalf of someone: a user, a team, a process. The scope of what it can affect should be the scope of what that someone is authorized to affect. Not as a metaphor. Literally. The agent is acting in their name. Its permissions should reflect theirs.
This is access control. It predates large language models by decades. The novelty is that an agent acts faster, at higher volume, and without the friction of human judgment at each step. That makes scoping more important, not categorically different.
The sequence still applies
Threat model the agent before deployment. What can it do? What happens when it reasons incorrectly? What is the blast radius of a wrong action? How do you contain it? These are not new questions. They are the same questions you should be asking about any system that acts in your environment. The inputs are different. The discipline is the same.
“AI governance” as a product category exists because the fundamentals were not load-bearing before the agent arrived. Organizations are now paying to retrofit least privilege, audit trails, and blast radius constraints specifically for AI, because those principles were not applied broadly. Buying an AI governance tool doesn’t fix the environment. It adds a layer on top of a problem that was already there.
The governance failures that surface in agentic deployments were already there. The agent didn’t introduce them. It ran them at scale.