--- title: "Identiverse 2026: Agents made authorization the story" description: "Takeaways from Identiverse 2026, where AI agents pushed authorization to the front. Delegated authorization, the Shared Signals Framework, AuthZEN agent authorization, and why prompts aren't controls. Notes from three AuthZEN sessions and the best talks of the week." author: "Alex Olivier" date: "2026-06-24T12:14:42.978Z" canonical: "https://www.cerbos.dev/blog/identiverse-2026" image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Identiverse_2026_Agents_made_authorization_the_story_2_4b9dfbb077.png" tags: ["guide"] source: "https://www.cerbos.dev/blog/identiverse-2026" --- # Identiverse 2026: Agents made authorization the story I spent last week at Identiverse in Las Vegas. We had a booth, ran a raffle, I was on stage three times, twice as a co-chair of the [OpenID AuthZEN](https://www.cerbos.dev/authzen) working group and once wearing my [Cerbos](https://www.cerbos.dev/) hat. In between, I sat in on as many other sessions as I could. Agents are a forcing function. They're exposing all the security holes that were already sitting in our systems, the ones we got away with for years because a human was the one clicking the button. Point an autonomous, non-deterministic thing at the same setup and the gaps stop being theoretical. Once that thing is acting on your behalf, who decides what it's allowed to do? That's an authorization question, and the good news is we already have the building blocks to answer it. So I had a good week. ## Three threads, one knot If I squint at everything I saw, it collapses into three ideas that keep running into each other. * Trust can't stay implicit. * Delegation breaks the moment it crosses an org boundary. * And context needs to show up before the decision, not after. All three land on the same spot. You need a deterministic place to make the call, with the right inputs in front of it. That's the bit I care about. ## George Fletcher on delegated authorization Delegated authorization was the best session of the show for me. George went deep on agentic delegation and trust domains, backed by something like 107 sources across the IETF, W3C and the OpenID Foundation. He's publishing the spreadsheet, which is a flex I respect. His main argument was about what he calls the "crossing the trustee problem." Any delegation scheme that ignores it will fall over as soon as it goes cross-org. Inside one company you can hand-wave it. The second a delegation chain has to reach into a different trust domain, Salesforce say, where the trustee is somebody else entirely, the easy answers stop working. B2B you can paper over with contracts and a transparency server. B2C is still unsolved, and he was honest about that. If you're building anything that delegates authority to an agent on behalf of a consumer, that gap is yours to worry about too, not just an academic one. The part worth sitting with is obligations. A [policy decision point](https://www.cerbos.dev/blog/why-external-authorization) can hand back obligations at runtime, or cancel ones that are already in flight. That has to be accounted for when you evaluate a policy, and most people aren't thinking about it yet. He also gave an 8-point framework for grading any delegation solution. I'm going to use it as a checklist against our own thinking: 1. Does it actually model the delegator, the delegatee, and multi-hop chains? 2. Does it reference and verify an external authority (a power of attorney, a contract, a policy)? 3. Does the purpose travel with the delegation, and can you share it selectively? 4. Are constraints (both user-set and mission-derived) enforced at every hop? 5. Can it ever grant more than the delegator holds? (It shouldn't. Revocation should flow downward.) 6. Does it work across orgs with no shared infrastructure? 7. Is the full chain auditable back to the original principal? 8. Is privacy handled natively, or bolted on later? Most proposals I've seen score well on 1 through 4 and then quietly fall apart on 5 through 8\. The hard half is the half that never makes it into the demo. ## Shared Signals and continuous authorization The Shared Signals Framework sessions were the other highlight. The core idea is old news to anyone in identity. You deliver security events between systems asynchronously, as signed tokens, so you stop assuming a session is fine just because it was fine at login. CAEP handles session revocation and device or risk changes. There's a risk profile for credential and account-compromise events, and SCIM events for provisioning. This is running in production today between things like Apple Business Manager and IdPs, Google Workspace, and CrowdStrike. Change your password, your screen locks. That kind of thing. The agentic extension is where it got interesting. The model shifts from a single checkpoint to three planes: a control plane for setting up trust, a data plane for fast authorization decisions, and a signaling plane that pushes context to where it's needed before the decision happens. Every node becomes a transceiver. A receiver can react on its own: narrow a scope, quarantine an instance, stop minting tokens, no human in the loop. There's a new event type aimed squarely at machine and [non-human identities](https://www.cerbos.dev/blog/nhi-security-how-to-manage-non-human-identities-and-ai-agents) and supply-chain attacks. For me the takeaway is simple. The signaling plane is exactly the input a policy decision point wants. Authorization and signaling are converging into one governance layer, and if you own identity, that convergence is the thing to watch, because it changes where the decision actually gets made. ## Justin Richer on AI and the confused deputy problem Justin's "Trust Me" was the sharpest framing talk of the week. The setup: AI inverts trust. In normal software an unexpected result is a bug and you fix it. With an agent, an unexpected result gets called "delight," right up until the agent confidently deletes your production database because it thought it was helping. That was a real example. It got a laugh, then a silence. His point about OAuth was interesting. It was designed when the client was the least-trusted party and the API was the prize. In the agent and MCP world that's flipped: servers now compete to be the thing an agent calls. The trust relationship the protocol assumes isn't the one we actually have. Non-determinism plus implicit access gives you the most powerful confused deputy ever built. This is the thing I'd push hardest on. An agent follows its access, not its instructions. "Don't touch production" is a request, not a control, and a non-deterministic system will eventually ignore it. The only place that boundary actually holds is at the point where the action gets authorized, where the answer to "can this agent, acting for this user, do this, on this resource, right now" is [computed fresh](https://www.cerbos.dev/blog/what-is-a-runtime-authorization-platform) and enforced. If the policy says no, the call never runs, no matter what the prompt said or what the agent talked itself into. That's the same point Justin landed on from the trust side. Zero trust means verify more, so you actually know what you're implicitly trusting. Why should our systems trust each other. We should be able to answer that. ## The bar talk, and governing shadow AI agents The best title of the conference goes to "A Vendor, Two Practitioners, and an AI Agent Walk into a Bar... the Agent got in. Nobody knows how." It was also the most practical governance content of the week. The old risk playbook still works, avoid, accept, transfer, mitigate, and you shouldn't be transferring risk onto your end users. [SPIFFE](https://www.cerbos.dev/ecosystem/spiffe) clears out maybe 80% of the non-human identity problem by handing out short-lived identity dynamically instead of provisioning secrets. Uber was cited issuing on the order of a billion credentials a day, with rotation. Governance starts with discovery, because you can't govern what you can't see, and shadow agents are everywhere once developers start handing them their own credentials. A gateway becomes the obvious control point: security, finance, and business checks in sequence before the agent does anything. The hard work is in distributing policy, then enforcing it locally. Manage it centrally, push it everywhere. Which, yes, is the thing we build, but the more useful point for anyone in the room is that this is a policy distribution problem before it's a product problem. Get that architecture right and the [vendor choice](https://www.cerbos.dev/blog/framework-evaluating-authorization-providers-solutions) gets a lot easier. ## The three AuthZEN and Cerbos sessions I ran I was on stage three times, wearing two different hats. Two were AuthZEN sessions with my fellow working group chairs, Atul Tulshibagwale and Mark Berg. The first was "Beyond Authentication," the framing talk. Authentication is solved, authorization isn't, and no single standard fixes it on its own. You need three working together. Shared Signals to bring fresh context to the decision, AuthZEN to make the decision fast and locally, and Transaction Tokens to carry that decision through a mesh of microservices without hammering the PDP on every hop. SPIFFE underneath for service identity. That combination is the first credible path to zero trust that doesn't fall apart at the implementation stage. Then the masterclass, two hours on "Mastering the OpenID Authorization Standard." We got into the weeds. The information model of subject, action, resource and context, the evaluation and search APIs, the new certification profile, and the agent piece. The part that got the room leaning in was [agent authorization](https://www.cerbos.dev/features-benefits-and-use-cases/ai-security). OAuth scopes can't answer "can this agent, acting for this user, call this tool with these arguments?" That's a subject-action-resource-context question, which is exactly what AuthZEN is the API for. We walked through how a tool declares its authorization intent so a gateway can check it before the tool runs. Deny, and the call never executes. The third talk was the Cerbos one, with Vatsal Gupta from Apple, "Access Reviews Are Dead. Long Live Decision Governance." The argument is blunt. We've spent 20 years optimizing access reviews, and identities still use roughly [1% of the permissions](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/2023-state-of-cloud-permissions-risks-report-now-published/ba-p/1061397) granted to them. Your review cycle runs every 90 days. An attacker now breaks out in about [29 minutes](https://www.crowdstrike.com/en-us/global-threat-report/). You're reviewing static snapshots of a thing that's computed fresh at runtime from identity, action, resource, context and risk. So the unit of governance has to change. The risk lives in the decision itself now, down at the level of who did what to which resource and in what context. Govern the decisions, what your policy intended, what actually happened, and whether they matched, and let the [decision log](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) be the evidence. IGA doesn't die in this world, it grows up. It stops trying to prevent bad access and starts proving good governance. That one's getting its own write-up, because the compliance crowd had opinions. ## What I'm walking away with The industry is finally treating authorization as a first-class problem instead of the thing you handle after authentication. The gap was always there. Agents just made it impossible to keep ignoring. The encouraging part is that the room mostly agreed on the fix. Lean on the standards we already have, apply them with some discipline, and stop pretending [agent access](https://www.cerbos.dev/blog/mcp-authorization) needs a brand new rulebook. The hard problems are the honest ones people admitted to on stage. Cross-org delegation. Obligations at runtime. Auditing a chain back to a human when half the chain is a model. These aren't solved yet, us included, and pretending otherwise would be the easiest way to look silly in 12 months. I'll be writing more on the delegation framework specifically, because I think that 8-point list is going to age well. For now, that's Identiverse. ## FAQ ### What is delegated authorization for AI agents? Delegated authorization for AI agents is how an agent is granted the right to act on a user's behalf, with the limits of that authority carried along the delegation chain. The hard part is cross-org delegation, where the chain reaches into a different trust domain and there is no shared infrastructure to verify it. Inside one company it is manageable. The moment it crosses a boundary, most schemes break, which is why it depends on solid [externalized authorization](https://www.cerbos.dev/blog/externalized-authorization-management-eam-and-benefits) underneath. ### What is the Shared Signals Framework? The Shared Signals Framework is an OpenID standard for delivering security events between systems asynchronously, as signed tokens, so a session can be re-evaluated after login instead of trusted indefinitely. Its CAEP profile handles session revocation and device or risk changes, and it runs in production today across major identity providers. For authorization, the signaling layer it provides is exactly the fresh context a policy decision point needs to make a runtime decision. ### Why can't OAuth scopes authorize AI agents? OAuth scopes cannot authorize AI agents because they describe broad permissions granted to a client, not fine-grained decisions about a single action. They cannot express whether an agent, acting for a particular user, should perform one specific operation on one specific resource in the current context. That kind of question is a subject-action-resource-context decision, which is what an authorization API like AuthZEN is built to answer. ### What is the confused deputy problem with AI agents? The confused deputy problem with AI agents is when a system that holds legitimate access is tricked into using it on someone else's behalf. It gets worse with agents because non-determinism combines with implicit access to create an extremely capable deputy that follows its credentials rather than its instructions. Telling an agent not to do something is a request, not a control. The boundary only holds if it is enforced at the point where the action is authorized, which is where [non-human identity](https://www.cerbos.dev/blog/nhi-security-how-to-manage-non-human-identities-and-ai-agents) controls come in. ### Are access reviews still effective for managing access? Access reviews are increasingly out of step with how access actually works. A review cycle runs every 90 days while attackers break out in under 30 minutes, and most identities use a tiny fraction of the permissions they hold. Reviewing static snapshots misses risk that is computed fresh at runtime, which is why governance is shifting toward evaluating the decisions themselves and keeping the [audit log](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) as evidence.