Most access control models were built on a simple assumption: a human is behind the request, exercising judgment about whether an action makes sense before triggering it. Authorization answers one question. Is this actor allowed to do this thing. It has never had to answer a second question, because a human asking for permission was already doing the judgment part on their own.
Agentic AI breaks that assumption, not because agents are malicious, but because they remove the judgment step that authorization was quietly relying on.
Authorized doesn't mean appropriate
Give an agent permission to process refunds under $500, and every individual refund it issues is authorized. Nothing in that permission checks whether the agent just issued twenty $499 refunds to the same account in an hour, something a human employee would have flagged as unusual on their own, without anyone needing to write a rule for it.
Role-based access models were designed around static roles and human-speed request patterns. They answer "can this identity do this action." They were never built to answer "should this action happen, in this sequence, at this volume, given what already happened five minutes ago." An agent operating within its granted permissions can still produce an outcome nobody actually intended, because permission and judgment were never the same control, and authorization was designed to cover the first one.
The chaining problem
A human employee performing a sensitive action usually exercises judgment between steps. An agent can chain a dozen individually authorized actions into a sequence nobody explicitly approved: pull a customer record, cross-reference it against another system, generate a communication, and send it, each step within scope, the combined sequence never reviewed by anyone. The risk isn't in any single action. It's in the combination, and authorization checks actions one at a time.
Who's accountable when it goes wrong
When an authorized human makes a bad call, accountability is usually clear. When an authorized agent produces a bad outcome while operating exactly within its granted permissions, the accountability question gets murkier fast. Is it the team that deployed the agent, the one that set its scope, or the vendor whose model is making the decisions in between? Organizations that haven't answered this before deploying agents will be answering it for the first time during an incident, which is the wrong time to be figuring out decision rights.
What actually has to change
This isn't an argument against agentic AI. It's an argument that the control model has to catch up to what agents can actually do.
1. Treat agent permissions as a governance decision, not just an IT configuration. Someone needs to own the question of what an agent is allowed to do, the same way someone owns risk acceptance for a business process. 2. Monitor behavior, not just access. Authorization tells you what's allowed. Logging and monitoring at the action level is what tells you whether what's allowed is actually what's happening. 3. Build in checkpoints for high-consequence actions. Some actions, moving money, changing access for other accounts, communicating externally, warrant a human decision point regardless of how narrow the agent's permissions are. 4. Set limits on volume and pace, not just scope. A permission that's safe at human speed isn't automatically safe at machine speed. Rate and pattern limits need to exist independently of whether an individual action is technically authorized. 5. Revisit agent scope on a schedule, the same way you'd revisit any privileged access. Scope creep happens to agents the same way it happens to service accounts nobody's reviewed in two years.
Authorization is still necessary. It was just never designed to be sufficient on its own, and agentic AI is the first time that gap has actually mattered. The organizations that get this right won't be the ones with the most restrictive permissions. They'll be the ones that decided, deliberately, who's accountable for what an agent does before it did it.
