EIC 2026 takeaways: the identity stack built for humans will not hold up for AI agents

Yesterday at EIC 2026 in Berlin, my co-founder Alex Olivier sat on an identity panel with Thomas Mayfield and Yash Prakash. The session was titled "Signals, Policies, and Identity Agency: A Smarter Identity Layer." The topic was how identity moves from static roles to signal-driven, real-time decisions. Here are my takeaways for security leaders.

TLDR:

1. The session-based authorization model breaks for agents and ephemeral workloads. Permissions assigned at login are too coarse for what is showing up in your environment now.
2. The standards to fix this (Shared Signals Framework, CAEP, policy-as-code, federated authorization) are mostly in place. The interesting work in the next 18 months is wiring them together.
3. The token your authorization layer issues is becoming your single point of failure. The identity foundation under your authz stack is the next risk surface.
4. Delegation is not always attenuation. The mental model most teams have for agent permissions does not match the use cases that are already happening.
5. Four questions to ask in the next 12 months. The fourth is the one that will save you in your next audit.

The slow loop is not slow enough anymore

Workforce identity runs on a slow loop. HR adds someone, IGA provisions roles, roles persist for years, access review happens once a quarter. That loop works because the identities it governs sit still long enough to govern.

Two things break that loop.

The first is ephemeral workloads. Batch jobs, serverless functions, data pipelines. They spin up, do something, and disappear. There is no 24-hour provisioning window to fit them into.

The second is agents. An agent's required scope is bound to a task, not a job title. The same agent on Tuesday morning and Tuesday afternoon needs two completely different permission sets.

The default everyone is comfortable with, pre-assigning permissions at the time an identity is created, is no longer the right default. The decision has to be made at the moment of the action, against real context.

I lived a tiny version of this at Qubit. We rewrote our authorization layer three times as we moved upmarket. And that was for humans only. The blast radius of doing that today, with agents in the mix, is hard to estimate.

The pieces to fix this are mostly in place

Yash and Alex made the same point from two angles. The standards needed for a signal-driven authorization layer are not hypothetical anymore.

You have Shared Signals Framework and CAEP for moving risk and lifecycle events around the enterprise. You have policy-as-code engines (Cerbos, OPA) for the decision itself, separated from your application code. And you have federated authorization protocols so an application can ask a decision point in real time rather than reading a stale role off a token.

The architecture you can now build:

1. Signals come in from your IdP, EDR, network, fraud systems, anywhere that has context about risk.
2. The policy engine evaluates those signals against the action being attempted, in real time.
3. The answer reflects the state of your system right now, not the state at login.

From a CISO seat, this is what "always know exactly who can access what" actually looks like in practice. Not a quarterly access review. A continuous, audit-ready decision that you can show on any given Tuesday.

Action-based, not session-based

Yash put it cleanly. We are moving from login-based to action-based provisioning.

A session token that carries the union of every permission a user might need over the next eight hours is too coarse. For an agent making five hops through other agents, MCP servers, and tools, it is dangerous. One overscoped token, one prompt injection, one confused deputy, and you have an incident on your desk.

So scope gets evaluated at every hop. Narrowed to the specific action.

Two layers make that work. The first is declarative, deterministic policy. What is allowed, given the inputs. The second is intent evaluation. What is the agent actually trying to do, and does that match the task it was commissioned for. The first is a solved engineering problem. The second is much less settled, and is probably where most of the next year of research lands.

For a CISO, the audit-trail implication is the part that matters. Every decision becomes a logged event with full context. Not "user logged in at 9:14 and did 47 things." More like "agent X, commissioned by user Y, attempted action Z on resource W with these signals, and was allowed because of this policy."

That is the kind of evidence auditors are starting to ask for. It is also the kind of evidence you want sitting in a drawer the day after an incident, because at that point your ability to reconstruct what happened, in front of regulators, is on the line.

The part that should worry you

Thomas made the argument that quietly reframes the whole conversation. I want to call it out specifically, because it is the kind of thing that does not show up on architecture slides and does show up in postmortems.

Every authorization decision ends in an issued token. That token is the identity for the next call. So the issuer of the token is your single point of failure and your primary attack vector.

The identity an agent carries needs to be verifiable. It needs to be delegated through a cryptographic chain. It needs to be revocable in real time, in seconds, not hours. Eventually it needs to be quantum-resistant. Compromise should be assumed. The question is how the system recovers.

In other words, what we built for humans is not enough for agents. Bearer credentials that can be cloned do not meet the bar.

A signal-driven authorization layer on top of a fragile identity foundation just moves the failure surface. It does not remove it. If you are budgeting for authorization without budgeting for what sits underneath it, you are in for a surprise.

Delegation is not always attenuation

There is an intuitive model where an agent acting on my behalf gets a subset of my permissions. Alex called this the happy path. He is right that it is intuitive, and right that it is not universal.

Counter-example. A US employee asks for a global sales report. Data residency rules mean that employee cannot read EU customer data directly. So they delegate to an agent running in-region, with broader access than they have, scoped to that one task. The agent does not have a subset of the user's permissions. It has a different set, justified by a different trust domain.

This pattern is already happening. The delegation chain has to carry enough context, including intent, for the policy engine to make the call. Most authorization models in production today cannot do this cleanly.

If you run a global business, this is a real audit conversation waiting to happen. Whose authority did the agent act under? What was the intent? Can you prove it?

What I would ask in the next 12 months

Four questions. Three are from the panel. The fourth is mine.

1. Is policy-as-code in place, or still on a roadmap slide? The substrate for everything else here is a decision point that you can evaluate against signals, in real time, with a full audit trail. If your authorization decisions still live inside application code, you do not have governance over them. You have hope. That is not what an auditor wants to hear, and it is not what a board wants to hear.

2. Do you have an inventory of capabilities and owners? Before you can write a policy, somebody has to enumerate what actions each system exposes and who is accountable for them. A spreadsheet is fine to start. This is unglamorous and slow. It does not go away. It is also exactly the kind of artifact your next compliance audit will ask for, framed differently.

3. What identity foundation sits under every authorization product on your roadmap? Built or bought, ask the question. If the answer is "a bearer token from a single issuer," that is the risk you are planning to carry for the next decade. Push back, in writing.

4. What open standards does each vendor support? SSF, CAEP, OpenID Federation, the authorization work coming through IETF. Interoperability is what makes this scale. Without it, every integration is bespoke and every migration is a rewrite. This is the question that protects you when you have to swap a piece of the stack in a hurry, after a vendor incident or an acquisition or a price change.

Where Cerbos sits in this

Quickly, because I do not want this piece to read like a brochure.

Cerbos is an authorization management platform. We do not issue identity and we do not generate signals. We evaluate, given an identity, a resource, an action, and a set of contextual signals, whether the action is permitted at the moment it is attempted. With a full, versioned audit trail of every decision.

That separation is intentional. The identity layer, the signal layer, and the decision layer should be independently replaceable. The shift the panel described only works if those layers are decoupled. If a vendor sells you all three in one bundle, you have a swap problem the day any one of them goes sideways.

The rest of this stack, verifiable identity, the signal mesh, runtime intent verification, is still being built. The use cases are arriving faster than the standards.

If you are a CISO and any of this is on your roadmap, I would genuinely like to hear how you are thinking about it. We are talking to a lot of security leaders right now and the patterns are still emerging. Message me on LinkedIn, or grab time on my calendar.