Why AI agents make authorization a right now problem

AI agents used to feel like eager interns. Helpful, fast, occasionally wrong, easy to forgive. That era is over. What runs inside enterprises today is closer to a super intern. One that works in parallel across every service you own, at a speed no human team can match, with a willingness to try every door in the building to finish its task.

The super intern is not inventing new vulnerabilities. It is finding the ones you already had. Cheaper, faster, and at a scale that makes them impossible to ignore.

We have been saying a version of this since we started Cerbos five years ago. Authorization was always the gap. Now, AI is just the thing that made the gap impossible to ignore.

The gap has a name now

For most of the last decade, identity was the story. Login got solved. SSO, MFA, federation, the whole identity fabric Gartner keeps writing about. That work mattered and it largely worked.

Authorization was the part nobody wanted to touch. It got hand rolled inside application code, scattered across microservices, buried in if-statements written by an engineer who left two years ago. IGA handled static roles at admin time. Access management handled coarse controls next to authentication. Fine-grained, dynamic, runtime authorization fell between the cracks.

Gartner finally gave the gap a name. They call it the Authorization Management Platform, or AMP. The category exists because every analyst covering IAM keeps running into the same observation from CISOs: we know who the user is, we just do not have a consistent way to decide what they are allowed to do, in real time, across a sprawling stack. Gartner's own framing is blunt. Overprivileged policies are open doors. More than 95% of identities use less than 3% of the entitlements they have been granted. Roughly a quarter of organizations believe more than half of their service accounts are overprivileged. Those numbers were bad before agents. They are load bearing now.

The architecture Gartner describes for an AMP is the same separation of concerns that has been around in the academic literature for years.

• PAP, the Policy Administration Point, where policies are authored and versioned.
• PDP, the Policy Decision Point, which evaluates a request against policy and returns allow or deny.
• PEP, the Policy Enforcement Point, which sits inside the relying application and enforces the decision.
• PIP, the Policy Information Point, which supplies the contextual data a decision needs.

This is not new thinking. What is new is that the industry, the analysts, and the buyers are converging on it at the same time.

Why AI makes this a right-now problem

Gartner tracked agent deployment in large enterprises going from around 11% in early 2025 to roughly 42% by late 2025. The same research has 78% of leaders naming cybersecurity and governance as the top blocker, and a Gartner prediction that through 2028 more than half of agentic AI initiatives will stall on unresolved identity and authorization questions. Only around 14% of organizations say they have adequate governance for agents today.

Put plainly, the super intern is already in the building, and most of the building does not know how to tell it no.

There is a secondary point from the same research that I think is under-appreciated. Gartner is explicit that AI should not be making runtime authorization decisions. A non-deterministic model is the wrong thing to put in the critical path of an access check. AI belongs upstream, helping humans author better policies, spot drift, and reason about risk. The decision itself has to be deterministic, auditable, and fast. That is exactly what a policy decision point is for.

This matters because it rules out the tempting shortcut of "just ask the model if this is okay." It is not okay. The access decision has to be a function you can replay, test, and prove in an audit.

The old architecture cannot survive the new traffic

Think about what changes when a super intern is the caller.

Before, a human user made tens of requests a minute against your application. Now, an agent acting on that user's behalf makes thousands, across services the user has never personally touched, chaining tool calls in ways nobody planned for. Delegation goes from user-to-app to user-to-agent-to-agent-to-service. The principal is sometimes a human, sometimes a workload, sometimes a machine identity attached to an MCP server that a developer spun up last Thursday.

In that world, the following need to be true at the same time.

1. Policies are centrally governed. One place to author, version, and review. Not fifty inconsistent copies of the rules scattered across services, each one drifting from the others.
2. Enforcement happens at every layer. API gateway, service mesh, application service, data layer. Every layer asks the same question and gets the same answer. The industry language for this is "centralized control, decentralized enforcement," and it is the right shape.
3. Decisions are deterministic and explainable. Same inputs, same output, every time. An audit trail that a regulator or an incident responder can read.
4. Policy changes propagate in seconds. Not a deploy cycle. When you revoke an agent's access, it is revoked now, everywhere. Ransomware research puts privilege escalation around the 90 minute mark in the kill chain, and some attacks execute inside 5 hours. Your policy propagation budget is measured against that clock.
5. Authorization attaches to workloads, not just people. Roughly half of organizations still lack effective controls for machine identities, and over half experienced a machine identity compromise in the past year. Agents and workloads need to be first class principals in the policy model, not an afterthought bolted onto a user directory.

If all five are true, the next model release is a feature. Point a thousand agents at your APIs. The decision point does not flinch. If any one of them is missing, the next model release is going to find the missing one for you.

What Cerbos actually is

I will keep this part short because this is a blog post, not a spec sheet.

Cerbos is a policy decision point you run next to your services. Your application sends it a request that describes the principal, the action, the resource, and the context. Cerbos evaluates that request against human readable, version controlled policies and returns an allow or deny with an explanation. Policies live in a GitOps friendly environment. Changes hot reload.

In the AMP taxonomy, this is the externalized authorization management pattern. The platform evaluates, the relying system enforces. This the most mature of the three integration modes, and it is the one we have been building toward from day one.

A few things we believe, and have believed long enough that I am comfortable defending them.

• Policy as code beats policy as config. Engineers already know how to review, test, and ship code. Policies should live in the same workflow.
• Open source matters for a decision point. If a component sits in the critical path of every request, you should be able to read it, run it locally, and audit it yourself.
• Interoperability beats lock-in. We participated in the AuthZEN standard for the PDP to PEP interface for exactly this reason. The industry needs a common wire format more than it needs another vendor silo.
• The engine should be boring. The interesting part is your policies, not the runtime. Treat authorization the way you treat your database. Pick a good one, configure it, move on.

The database analogy is the one I keep coming back to. Nobody hand rolls a B-tree because they have a table to store. You pick Postgres. Authorization is heading to the same place. It should be infrastructure. It should be dull. It should be a line item in your architecture diagram that nobody argues about.

The honest part

I am not going to pretend this is solved. Most of the prospects we talk to are somewhere between "we know we have a problem" and "we have a half-finished internal framework a principal engineer built in 2022 and nobody wants to touch." The friction is real. Migrating authorization out of application code is work. It is the kind of work that does not ship a feature, which means it competes for roadmap time with things that do.

What has changed is the cost of waiting. A year ago you could rationally defer this. Today, with agent traffic growing the way it is and with the analyst community finally pointing at the same gap we have been pointing at for five years, deferring is a decision with a price tag attached.

You do not need to rip and replace everything. Start with one service. Pull the authorization logic out. Put it behind a decision point. Prove that the policies are readable, the decisions are fast, and the audit trail is real. Then do the next one. Crawl, walk, run.

The challenge

If you can honestly say that you have centrally governed policy, executed at every layer of your stack, deterministic and explainable, propagating in seconds, and attached to workloads and agents as first class principals, then bring on the next model. You are going to be fine.

If you cannot, the super intern is going to keep finding the gaps, and the people who do not wish you well are going to keep using the same tools to find them a little faster.

If you are looking at your own stack and recognizing the hand rolled version in the mirror, I would like to hear from you. Reach out and we can walk through what a first slice looks like, what it would cost, and what it would take to get to a place where you stop worrying about which intern, human or otherwise, is poking at your endpoints this week.

Emre