By the end of EIC 2026, the agent question for IAM teams had narrowed from discovery to control.
Agents dominated the formal agenda and the hallway. At the Cerbos-sponsored candy bar, people would drift over for something sweet and end up in the same conversation we were hearing from the stage. Agents are moving from pilots to production, and the old access-control assumptions are not holding up.
"Are agents important?" is already answered. The useful question is what to protect first.
Identity gets the agent into the building. Authorization protects the vault.
The best framing I heard all week came from Patrick Parker: the bank vault analogy. If you are worried about bank robbers, you do not start by inventorying every possible robber. You protect the vault. The doors, the cash drawers, the transfer rails, the override procedures. You make sure that when someone reaches the point where money can move, the system knows whether that action should happen.
That is the agent problem in miniature. Yes, you need to know which agents exist. You need owners, scoped credentials, lifecycle controls, revocation, and audit. But that hygiene only tells you what exists. It does not decide whether this agent should update this record, call this tool, initiate this transfer, or act through this delegation path right now.
The line I kept coming back to all week: identity gets the agent into the building; authorization protects the vault.
The IAM model is wrong-shaped for agents
The familiar model is human-shaped. A person joins, moves roles, leaves. They authenticate, get a session, make deliberate requests, show up in access reviews. Agents do not behave that way. They run continuously, call APIs, MCP servers, tools, and data systems. They fan out. They can take different paths on different runs of the same task.
Traditional IGA is structurally wrong for that workload. If it takes 6 hours to provision a human's accounts, that is annoying but survivable. The employee is around for months. An agent might be spawned for one task and gone in seconds. A control process built around tickets, approvals, birthright access, and quarterly reviews cannot be the primary mechanism for something that may disappear before the workflow completes.
The authorization request is now a bundle of evidence
One human plus one role is not enough. Each request has to be evaluated as a bundle: human, agent, tool, route, delegated authority, action, resource, purpose, session state, data sensitivity, current risk. The path matters. The tool matters. The plan matters. Signals matter too, because the right answer can change while the agent is running.
Phillip Messerschmidt from KuppingerCole drew this in his Authorization Put to the Test session. Every access control model has to answer 4 dimensions: Identity, Action, Object, Context. Context runs as a band across the other 3. RBAC is strong on the object side, weak on action. ABAC and PBAC are strong on action, weaker on the rest. His conclusion: "You will need a combination of different ACMs."
Sessions don't survive contact with agents
A session established 20 minutes ago cannot safely govern a workflow that has changed shape 50 times since then. A role assigned last quarter cannot describe the access path an agent discovers at runtime. A quarterly review is almost comic when the workload can generate thousands of tool calls before anyone has finished their first coffee.
Messerschmidt put a name on the phase that gets skipped. He splits authorization into 4 timing stages: administration, session initialization, session management, and post-event. Most enterprises invest heavily in the first two, log the fourth, and skip the third entirely. Session management is exactly the phase agents need most.
His closing line is the framing IAM teams should take home: "Dynamic Authorization is a major IAM trend, not because it sounds fancy, but out of necessity."
Delegation has to stay delegation
The cheap version of agent access is to let the agent use the user's credential and call it done. It works right up until something bad happens, at which point the audit trail says the human did it and every interesting part of the chain disappears. Which model generated the plan? Which policy allowed it? Which tool executed it? Was the agent inside its scope? No answers, no accountability.
Reiner Mertens drew the wire-level form of this in his microservices session. A Customer Service Agent is entitled to view records "for accounts assigned to her team only." The agent calls a service. The service authenticates downstream using its own service account with "read/write access to ALL customer records." The query returns everything matching the case, regardless of team. "The service's permissions replaced the user's permissions."
His diagnosis: collapsing workload identity ("which service is this, provably?") and user-entitlement context ("what may this user do right now?") into one shared service account "is often the root cause of why current IAM models fail here." The same shape applies to agents. The moment the user disappears from the chain, the policy has nothing to anchor against.
Mertens framed two architectural answers cleanly. Option A is RFC 8693 token exchange at every hop, with audience and act claims, giving cryptographic proof of the delegation chain at the cost of an authorization server in the hot path. Option B is PBAC with standardised identity claims aligned with NIST SP 800-204B, where the ID token rides along and each service evaluates policy locally. Either beats dropping the user at the boundary and hoping.
Logs need to explain why
Most enterprises have more logs than they can use. Adding agent activity to that pile won't make agent behaviour governable. A traditional access log tells you who connected, what was touched, and when. It rarely tells you why the action was allowed.
What you need is a decision record. Which policy evaluated the request, what context it saw, what delegation was in force, which version of the rule fired, what outcome came back. "The token was valid" looks thin after an agent changes production data, transfers money, or leaks customer information through a tool nobody remembered was exposed.
Mertens nailed the per-hop record format: [ service identity ] + [ user identity ] + [ policy decision ] + [ outcome ], logged at every hop. Replace the originator with an agent and the row turns into [ agent id ] + [ ??? ] + [ policy ] + [ outcome ]. The ??? is the point. There is no standard way today to represent that the agent made an autonomous choice within a delegated boundary, or that the user actually consented to this specific action at this moment.
Jonathan Care put a deadline on that gap. His EIC session on navigating the AI landscape was blunt: "Chained sub-agent actions break every existing audit trail." EU AI Act Articles 9, 10, and 13 demand documented risk, data governance, and transparency for high-risk systems from 26 August 2026. The compliance bar he put up was concrete: reconstruct any 30-day-old action, with the prompt, the model, the tool, and the authorising human attached. Today's logs don't do that. Agent chains widen the gap.
The blocker is organisational, not technical
The sharpest claim of the week was also from Mertens: "The tools exist. The standards are mature. The room is the problem."
IAM arrives at go-live review when the architecture is already locked. Nobody owns the full API graph, so there is no surface to write coherent policy against. Token schema and policy logic get conflated, when they need different owners: central IAM governing the claims contract, service teams owning the policies that consume those claims, schema changes treated as breaking changes.
His prescription was observability first, completeness second. Deploy policies that allow broadly but log every decision centrally. Let the call graph emerge from the logs. Then tighten deliberately against what is actually happening.
That is exactly the adoption path we recommend for Cerbos: drop the PDP in alongside your services in audit-only mode, learn from the decision logs, then enforce against the call graph you actually have.
Where Cerbos fits
The booth conversations all converged on the same question. Where does the decision go once the agent starts moving? Gateway? MCP server? Tool call? Data layer? Application code?
The answer is that the decision has to happen where the action becomes real, and it can't be hard-coded into each surface. You need a runtime policy decision point that gateways, MCP servers, agent frameworks, and application code can all call when an agent action reaches the point of consequence. Policies live as code, version with the rest of your software, and evaluate against the full bundle of evidence in milliseconds.
That is what we built Cerbos for. Stateless, deployable next to the workload, called at every hop, returns a decision plus the policy basis for the audit trail. Identity, governance, gateways, and detection all need something like it to call when an agent action reaches the vault.
What to take home
Be skeptical of any pitch that doesn't say what is being protected, where the authorization decision happens, what context it evaluates, how delegation is preserved, and what evidence gets produced. "AI security platform" is too broad to mean anything operational. "Agent governance" often collapses into inventory plus dashboards. Care had the sharpest version of this test on his closing slide: "Show the clause of EU AI Act, NIST AI RMF or ISO 42001 your product satisfies, not just supports."
The IAM team doesn't need to chase every new label or build the perfect inventory before acting. Identify the vaults: the tools, APIs, data stores, workflows, credentials, and transactions where agent action can cause real damage.
Then answer two questions. When an agent reaches one of those vaults, who decides whether the action should happen? And the one Mertens left his audience with, which lands just as hard for agents as it did for microservices: how many of you have IAM represented in your API and tool design reviews today?
If those questions are uncomfortable, we are easy to find.
Tagged in
