Cerbos

Most teams start with roles. Admin, editor, viewer. It works right up until someone asks for "editors can only edit the documents they created," or "managers can approve expenses, but not their own." You can't express that with roles alone. So you add more roles, then per-tenant variants, and a few months later you're staring at a list like CompanyA_Editor_ReadOnly and wondering how it got this bad. That's the moment fine grained access control stops being a nice-to-have. Every real decision is the same shape: given this user, this action, this resource, and the context around the request, allow or deny. The interesting part isn't writing one clever condition. It's deciding where that logic lives. Bury it in your services and every rule change becomes a deploy across every service. Pull it out behind a decision point and the rules stay consistent no matter how many services call them. We wrote up what it actually takes to get fine grained right, with the trade-offs and policy examples. https://lnkd.in/e2pJuwQw

Agents don't follow instructions. They follow access. That was the thread running through Identiverse last week. Our co-founders Alex Olivier and Emre Baran were both there, with Alex on stage three times, twice as a co-chair of the OpenID AuthZEN working group and once for the Cerbos talk, and Aram Andreasyan with them on the ground. If you own identity, you already know who your users are. What's harder to see is the authorization logic that decides what they, and the agents acting for them, can actually do once they're in. It lives scattered across application code, outside your governance reach. A non-deterministic agent will use whatever its credentials permit, regardless of what the prompt told it. "Don't touch production" is a request, not a control. The boundary only holds where the action gets authorized at runtime. The encouraging part of the week was how much the room agreed on the fix. The standards already exist. Shared Signals to bring fresh context to the decision, AuthZEN to make the decision, SPIFFE underneath for service identity. What nobody claimed to have solved came up just as openly. Cross-org delegation. Obligations at runtime. Auditing a chain back to a human when half the chain is a model. Thank you to everyone who stopped by and chatted with us over the week, it was great to catch up. Thanks too to everyone who entered our raffle, and congratulations to Samantha Thomas, who won 🎁 ! Alex's full write-up on the conference: https://lnkd.in/eMRBk9A2

Cerbos Synapse lets you shape what flows through your Policy Decision Point. Enrich a principal with attributes from a database before the decision runs, map an incoming HTTP or Envoy request onto a check, or stand up a custom endpoint under /ext/ that does exactly what your app needs. We just shipped a skill that builds those extensions for you. You describe what you want in plain terms, something like "enrich the principal with the user's department from Postgres before the check runs," and it picks the extension kind and runtime, scaffolds the files, wires the config, writes a test suite, and runs it against a local PDP. You get a working extension to drop into your own project, not a blank file. It covers all five extension kinds and writes them in CEL, Starlark, or WASM in Go, TypeScript, or Python. It pairs with our policy skill too. One writes the rules, the other extends the pipeline that enforces them. Works with Claude Code, Cursor, Codex, and most other agents. 👉 https://lnkd.in/eA5QZjxu

Thank you to everyone who came to Alex Olivier's three sessions at Identiverse this week, on decision governance, the authorization frontier, and the AuthZEN deep dive. The conversations afterward kept circling the same shift. 🤖 ❓ Autonomous agents are requesting access and making decisions inside infrastructure that was built for humans, not machines. Giving an agent access was never the hard part. The hard part is what it can reach once it is in. An agent operating beyond its intended scope, across thousands of machine identities nobody is tracking closely, is exactly how a breach starts now. And it is the CISO who answers for it. That control lives in the authorization layer, the part of the stack that decides what an identity can actually do. At most companies that layer was never built to carry the weight it now carries. Alex, our CPO and co-chair of OpenID AuthZEN, wrote a benchmark for getting ahead of this. A 4-stage model to find where your authorization program actually stands, your exposure across NIS2, DORA, SEC and the EU AI Act, and a 90-day plan to start closing the gaps before they are exploited. If you are still at the show, come find us at 🔸booth 925🔸. 📘 🔗 You can get the Authorization Maturity ebook here: https://lnkd.in/ewR-SVGB #Identiverse #IDV26 #Identiverse2026 #IdentitySecurity

We are at Identiverse in Las Vegas this week! 🌎 🔸 Booth 925 🔸 is open for conversations about authorization, whatever you're working through. Alex Olivier, Emre Baran, and Aram Andreasyan are all there, so come find us. We've also teamed up with 1Kosmos on a 🎁 raffle, and there's an Apple Watch up for grabs at each booth. Stop by booth 925 (Cerbos) and booth 319 (1Kosmos), get scanned at both, and you're entered. Winners get picked Wednesday. If you want to go deeper on where authorization is heading, Alex is speaking across three sessions worth catching: ✔️ Joined by Vatsal Gupta from Apple for "Access reviews are dead. Long live decision governance" https://lnkd.in/e_tDupMx ✔️ On the panel "Beyond authentication: Updates from the authorization frontier" https://lnkd.in/eMYevHQd ✔️ Running the "AuthZEN Deep Dive: mastering the OpenID authorization standard" with Atul Tulshibagwale and Mark Berg https://lnkd.in/e-RzFg9A Come say hi! #Identiverse2026 #IdentitySecurity #DigitalTrust #CRAEvents #LasVegas

Most e-commerce authorization starts the same way. You add a roles table, give vendors a "vendor" role, customers a "customer" role, and ship it. It works right up until the first real requirement shows up. A vendor should only edit their own products, not every listing on the platform. A support agent should only see cases assigned to them, and only update one when the priority is high. A customer can change an order, but only while it's still pending. 👆 🔻 None of that fits in a role. So it leaks into application code, one if-statement at a time, until nobody can say with confidence who can do what. We wrote up three of these scenarios as worked examples, customer data access, vendor product management, and order lifecycle control. Each one starts with the business rule in plain English and ends with a policy you can actually run, including a 24-hour hold on order edits expressed as a single time-based condition rather than a background job. The part that matters for anyone dealing with GDPR or PCI DSS, every decision is backed by a policy rule and an audit log, not buried in a handler somewhere. 🔗 https://lnkd.in/exUZqeAA

📣 Discover the latest from Cerbos in our monthly newsletter! Subscribe 👉 https://bit.ly/3Xnmzl4 to get future updates directly & on the day they come out. #Cerbos #CerbosNewsletter #Authorization

I've been playing around a lot recently around how to put deterministic controls around non-deterministic agents by binding them to the task they are operating on to prevent drift using policy Combining sandboxes, SPIFFE (Secure Production Identity Framework For Everyone), agentgateway, Model Context Protocol, token exchange, OpenAI/Anthropic's Agent SDK with Cerbos, I've landed on an architecture which is meeting a lot of requirements we are hearing. Keen to hear your thoughts https://lnkd.in/eyjziwWu