Your AI Didn't Go Rogue. It Used the Access You Gave It.

Every bad AI incident I have looked at this year has started the same way. Something breaks, money moves the wrong direction, or data shows up somewhere it should not, and the first sentence out of the room is always some version of the same thing. The model went off the rails. It hallucinated. Somebody jailbroke it.

Then you pull the logs.

And almost every time, the model did not go off the rails at all. It followed instructions. It called the tools it was allowed to call. It read the records it had permission to read. It did exactly what the system let it do, cleanly and confidently, and that is the whole problem. The scariest AI incidents I am seeing are not the model misbehaving. They are the model behaving perfectly, inside a permission set nobody ever really looked at.

Here is the reframe that changes how you triage these: an AI agent does not have “AI permissions.” It has your permissions. Whatever access you handed it at deployment time is the access it wields, and at deployment time scoping always feels like friction. There is a demo on Friday. The integration needs to just work. So the agent gets wired up with a service account that can reach everything, or it inherits a real person’s standing access, or it gets a token with no expiry and a scope like “read everything, write most things.” Nobody decides to over-permission the agent. It happens because under-permissioning is work and over-permissioning is the path of least resistance.

Last time out I went through the deployment mistakes I keep running into with enterprise AI. This is the one that actually generates the incident numbers, and the numbers this year are not subtle. One 2026 industry study found that AI systems deployed with excessive permissions experienced roughly four and a half times more security incidents than systems held to least privilege. The strongest predictor of whether an organization got burned was not how sophisticated its AI was, or how mature its security program was. It was access scope. The majority of organizations now admit their AI systems have more access than a human doing the same job would ever be granted. We spent twenty years learning not to give interns domain admin, and then we handed it to a process that will do whatever a web page tells it to.

In the field, over-privilege shows up in three shapes over and over. These are composites, not any one place, but if you run AI in production you will recognize at least one.

The inherited-identity agent. Someone builds an assistant on top of a real user’s access so it can act on their behalf. Convenient, until you notice the agent now reaches every system that user can reach, with no expiry, no separate audit trail, and no distinction between the human clicking a button and the agent doing something at three in the morning. When it goes wrong, you cannot even tell which actions were the person and which were the machine.

The shadow agent. A product team spins up an agent to solve a real problem. It connects to a few tools, maybe an MCP server or two, maybe an external API. It works. It ships. Security never mapped it, never scoped it, and in a lot of cases cannot see it at all. This is not a rare edge case. In a 2026 Cloud Security Alliance survey, more than 80 percent of organizations had already found agents running in their environment that no team ever signed off on, and only about one in six monitor their agents in real time. You cannot govern what you cannot see, and right now most teams cannot see most of their agents.

The over-scoped integration. This is the one that made the rounds this spring. Somebody connects an AI productivity tool to the company workspace and grants it blanket access, the allow everything checkbox, because that is the option that makes the setup flow finish. Months later the tool itself gets compromised, and now the attacker has exactly the access that checkbox granted. The agent did not get breached. The blast radius did.

This is where a lot of AI security spend goes sideways. Teams pour effort into the model layer. Better guardrails, better refusal behavior, better prompts telling the assistant not to do anything harmful with the data it has. All of that is worth doing. None of it helps if the access model underneath is wrong. “Do not do anything harmful with this data” is the wrong sentence when the honest answer is that the agent should never have been able to reach the data in the first place.

The same survey put the consequences in numbers: roughly two in three organizations had at least one security incident tied to an AI agent in the past twelve months, and the majority of those incidents came down to sensitive data exposure. Read the failure mode carefully, because it matters. The agent was not malfunctioning. It was doing precisely what its permissions allowed. That is not a model safety problem. That is an access control problem that happens to involve a model.

And this is where it connects back to the very first thing I wrote about, the attack surface of these systems. A while ago I walked through how much of an AI system is exposed to inputs you do not control: the poisoned document, the crafted email, the comment on a page an agent browses. That surface is not theoretical anymore. Researchers this year documented real injection payloads planted across ordinary web pages, sitting there waiting for an AI agent to read them and act. Here is the part people miss. An injection is only worth as much as the access of the thing it lands on. The same malicious instruction is a shrug on a locked-down agent and a catastrophe on an over-privileged one. Attack surface and privilege multiply each other. You do not get to fix one and ignore the other.

So what actually helps. Not a product, not a magic layer. Just the boring discipline we already know from every other identity we have ever managed, applied to a new kind of identity.

Scope the agent tighter than the human, not looser. The agent is faster, runs unattended, and does not get suspicious. It should have less standing access than the person it works for, not more.

Kill static credentials. Short-lived, narrowly scoped tokens over long-lived keys, every time. A large share of organizations are still handing agents static credentials, and static credentials are the thing that turns a small compromise into a long one.

Treat every agent as a first-class identity. It gets an owner, an entry in an inventory, and its own logs, separate from any human. If you cannot answer which agents exist, what each one can reach, and who is accountable for it, you are not governing them yet.

Make human-in-the-loop real. An approval step that a tired person rubber-stamps forty times a day is not a control, it is theater. Put the human in the loop only where the action is consequential enough that they will actually stop and look.

Assume everything the agent ingests is hostile. Every document, every email, every retrieved page is potential instruction, not just data. Design as if it will eventually contain something adversarial, because on a long enough timeline it will.

None of this is exotic. That is exactly why it keeps happening. We already know how to do least privilege. We just stopped doing it the moment the thing asking for access started sounding helpful and talking like a person.

So the question I would retire is “is our model safe.” The one worth asking, in every AI review, before anything ships, is simpler and much harder to answer honestly: what is this thing actually allowed to reach.

Your AI probably will not go rogue. But one day it will do exactly what you allowed it to do, and you had better hope that list is shorter than the one it has right now.