Authorization for AI Agents: What to Build Before the EU AI Act Deadline | Cerbos<br>🛡️ IAM security checklist for 2026 ➔Download it here

Guide<br>Authorization for AI agents: What to build before the EU AI Act deadline<br>AAlex OlivierJune 01, 20267 min read

There's a line from Jonathan Care at KuppingerCole that's been bouncing around in my head since I heard it.

Frameworks govern what models say. Almost nothing governs what agents do.

That's the gap. The teams I've been talking to keep landing on it from different angles, which is usually a sign a category is forming. Some show up because their CTO wants agents in production and security won't sign off. Some show up because the EU AI Act is making someone in legal nervous. Same gap underneath.

Here's how I'd carve it up.

Three gaps, only one of them named

There are three layers, each with an emerging acronym attached. The acronyms matter less than the shape underneath.

The first is identity. Every agent needs its own identity, per instance, not per class. Short-lived credentials scoped to a single tool call. Lifecycle tied to a named human sponsor. Most enterprises today are issuing one long-lived API key per "the agent" and treating every spawned instance as the same actor. That stops working the moment one agent spawns another. (We've written about this under non-human identity and the sponsor-tied lifecycle pattern.)

The second is audit. Once an agent delegates to a sub-agent, every existing audit trail breaks. Who consented. What was the original purpose. Did the consent survive the hop. Today's logs answer none of that. They tell you a service account did a thing. They don't tell you which human authorized it, through which chain, for what purpose, on what data. The chain of custody is the bit that's missing, and it's a bigger deal than people are giving it credit for.

The third is the one with no mature category yet. Care calls it orchestration. The agent-to-agent and agent-to-tool layer. Tool gating outside the agent. Inter-agent trust enforcement. Fail-closed runtime when the policy plane is unreachable. Today this layer is just whatever the agent framework chose to expose. Often the agent itself decides what tools it can call, which is the security model of asking a child whether they're allowed dessert.

The first two are problems the IAM industry knows how to think about, even if the implementations aren't there yet. The third is the one nobody has been naming as its own category. I think naming it is the moment it becomes real, and the runtime layer for agent traffic is where most of the architectural work is about to happen.

What "runtime policy at the orchestration layer" actually means

This is the layer I work in, so I'll be specific.

Every agent-to-tool call is a decision. Should this agent, acting on behalf of this human, in this context, be allowed to invoke this tool with these arguments. The agent shouldn't be the thing making that decision. A separate policy engine should, sitting outside the agent's reasoning loop, evaluating the call before it goes through.

That's a runtime policy engine for agent-to-tool calls. It's the same externalized authorization pattern I've been writing about for years, just with the agent slotted in as a new principal type and the tool slotted in as a new resource type. Decoupled. Externalised. Fail-closed if the engine is unreachable. Same PEP/PDP shape, agent-shaped surface.

The reason this matters for governance is that without it, every other control sits inside the agent. Prompt-level guardrails. Framework-level allowlists. System prompts saying "do not call the refund tool." All of that lives in the same probabilistic system you're trying to constrain. Controls on the inmate, written by the inmate.

Take the policy out of the agent and you get something a security team can reason about. Same engine across all your agents. Same audit log. Same change management. Same rollback story. The agent loses the privilege of deciding what it can do, which is exactly what you want.

The August deadline, and why it's the smaller story

The reason this is suddenly urgent is the EU AI Act. Article 9 covers risk management. Article 10 covers data governance. Article 12 covers automatic record-keeping over the system's lifetime. Article 13 covers transparency to deployers. Together they form the operational core of what a high-risk AI system has to demonstrate.

These obligations sit on the AI system provider, not on Cerbos and not on any other infrastructure vendor in the agent stack. I want to be careful about that, because the "AI compliance" marketing pile is already getting deep. We do not satisfy Article 9 for you. We do not make you AI-Act-compliant. Anyone telling you that is selling you a story.

What Cerbos does help with is the part that's almost impossible to demonstrate without working runtime controls in our layer. A risk management process that doesn't enforce decisions at the agent-to-tool...