u/morphAB

Hey everyone. I keep watching the same evaluation pattern for authorization (seeing it from the vendor side, i work at Cerbos). A team trials authz engine, wires it into a sandbox, the demo works, everyone nods, and then the poc just... expires. No decision, no rollout, 6 months later someone restarts the whole exercise from scratch.

Did some research and did confirm this situation around pocs is a wide trend - Sapphire Ventures survey found 78% of IT executives say fewer than half of their POCs reach production https://sapphireventures.com/blog/over-50-of-proof-of-concepts-fail-heres-how-to-fix-yours/ , and that pocs that run under three months are 3x more likely to make it. It's not getting better with the current wave either - IDC found 88% of AI pocs never reach production https://www.cio.com/article/3850763/88-of-ai-pilots-fail-to-reach-production-but-thats-not-all-on-it.html

So, I wanted to share with you all the pattern that actually makes a poc "successful", at least from the angle of authorization.

The deifnition of success here being confidence to commit / confidence to walk away. Either is a decision :)

Write the success criteria down before day one. For authorization that usually means: can it model your real rules including the edge cases (the ones living in if-statements today), does it handle the access patterns you actually need (attribute conditions, relationship rules, tenant-scoped policies not just plain RBAC), does the audit output meet compliance evidence needs, and does it consume identity context from the IdP you already run.

On latency, don't accept throughput benchmarks. Measure p50, p95 and p99 with your own traffic patterns, since authorization sits on the critical path of every request.

Also worth timing how long it takes a team member who wasn't involved in the setup to write their first correct policy. That number tells you what maintenance will look like after the rollout.

Scope it to one real service, not a demo app. a good candidate has a few distinct roles, some conditional logic beyond role checks, and is already connected to your IdP.

Get security and compliance reviewing while the poc runs, not at the approval meeting afterwards. Nothing kills a finished poc faster than a compliance objection that could have surfaced in week one. And have product read the policies too, in my experience if the rules only make sense to the engineer who configured them, adoption stalls

Set a hard deadline -2 to 4 weeks is enough for one service. And measure your current baseline first, so the final review is a comparison. The 4 numbers worth capturing are how long a permission change takes today, how long it takes a new dev to learn your current authz logic, how much engineering time per sprint goes to permission work, and how long audit evidence prep takes.

PS. I have a longer write up of this if anyone would find it helpful, dm me or I can drop it in the comments.

hey all. I work at Cerbos (we do authorization). This is a pattern I keep seeing in IAM and dev teams:

A lot of folks can see the authorization gap clearly. Policy scattered across app code, no central view of who can do what, agents getting broad access nobody's tracking. But they can't get it prioritized, because it keeps getting framed as an engineering refactor, and refactors lose budget fights.

What actually moves it is reframing the exact same problem in the terms your CISO and board answer to. not "our authorization logic is fragmented," but "we can't prove to a regulator who accessed what, here's our exposure under NIS2, DORA and the EU AI Act, and the CISO is personally on the hook for it." Same gap, completely different urgency once it's a risk and compliance problem instead of tech debt.. (:

We ended up building a CISO facing ebook around exactly that framing, an authorization maturity model with a regulator-by-regulator exposure view and a 90-day plan, specifically so identity teams and software / engineering have something to hand up the chain. it's written in board language, not engineering language, which is the whole point of it. Here if it's useful: https://solutions.cerbos.dev/authorization-maturity-model-a-cisos-benchmark

mostly curious how others here handle this though.. I love getting into these conversations, everyone's situation seems to be a bit different... When you've actually gotten authorization funded, what was the argument that landed with leadership? a specific regulation, an audit finding, an incident, something else?

Hey all, over the weekend someone talked Instagram's support chatbot into handing over accounts they didn't own. no exploit. They asked the bot to add a new email to the account, used a VPN to spoof their location, and it reset the password for them. a couple of the hijacked accounts were high profile, including a former White House handle.

Yes, part of it is an auth failure, the bot never confirmed who it was talking to. That's the boring fixable part.

The part that should worry anyone building with agents is that the agent was the one deciding whether to allow the action.

That decision used to live in code, a recovery flow with fixed rules you could read and test. The moment it lives in a conversation, anyone patient enough gets to negotiate with it, and tightening the system prompt just moves where the negotiation happens. You don't out-prompt someone with unlimited retries (:

The thing that's held up for us is keeping the decision out of the model entirely. The agent asks, a separate layer with its own rules decides, and the agent obeys the answer. Attacker can talk to the bot all day, they can't talk to the thing actually making the call.

for context I work at Cerbos, and we wrote the longer version of this up here if it's useful: https://www.cerbos.dev/blog/meta-ai-hack-shows-why-agents-shouldnt-decide-access

Genuinely curious where people here land. Are you letting the agent decide what it's allowed to do, or gating actions externally? And for low-stakes read-only stuff, where do you actually draw the line..? because gating everything gets heavy fast

Hey everyone! observation from working in authorization: Identity programs have been putting serious work into agent authentication over the last couple of years, service accounts done properly, OAuth scopes tightened, secret rotation, short-lived tokens. The authN side isn't fully solved (it never is) but it's where most of the effort has been going..

The part getting less air-time is what happens after the agent is authenticated, when it's acting on a workflow and something starts looking off. The default plan there is still "if it misbehaves, kill the agent."

That stops working the moment the agent is wired into something real. Pulling the switch creates a secondary incident, halted workflows, paused queues, downstream teams scrambling. So the agent keeps running at full access while the team figures out what's wrong, because the standard toolkit doesn't have a middle setting.

A colleague of mine was talking to a CISO about this and the framing that CISO used was dimmer switch, not kill switch. The dimmer lives in the authZ layer at runtime, which is the part identity stacks haven't extended into yet for non-human principals.

In practice the dimmer looks like read-only on certain data first. Sensitive tools dropped next. Higher approval thresholds for anything above a certain size. Each adjustment is reversible and logged. If the agent turns out to be fine, restrictions fade back. if not, you keep tightening until access is at zero, but you got there deliberately and with a record

mechanism isn't new - per-action policy enforcement at runtime has been around for years for human users. What's newer for AI agents specifically is wiring it to the agent's identity, current task, and intent at runtime, so you can narrow scope without redeploying or stopping the agent mid-task.

My team and I (work at Cerbos) wrote up the full framing here: https://www.cerbos.dev/blog/dimmer-switch-not-a-kill-switch-rethinking-ai-agent-governance

Now i'm curious to know how identity programs you all are seeing / part of, are organizing this. Is agent authorization landing inside the iam team, security ops, the application teams, or sitting in no man's land between them? If you're open to sharing - please do!

Usual caveat, none of this replaces human review of policy. Tooling makes the revocation mechanical. Humans still own the call on where the boundaries should sit :)