Hand an intern a task in your CRM and they will stay in the CRM. Their login might also open the HR system and the finance system, but they won't go looking, because they can tell those systems have nothing to do with the job. Hand the same task and the same access to an AI agent and it will try every system, API endpoint and export it can reach until the job is done.
Our co-founder and CPO Alex Olivier used that example on Code Story (season 13, episode 10), in a conversation with host Noah Labhart about how Cerbos started, how the product grew, and what agents change for authorization. The episode runs 29 minutes. Below are the main ideas from it, with links to go deeper on each.
The intern example Alex uses for AI agent access
Alex's point is that a lot of access models in use today were never as fine-grained as they looked on paper. They worked because the people using them stayed in their lane. Someone with access to the finance system who had no reason to be there simply didn't open it, so nobody had to write a rule saying they couldn't.
Agents don't stay in their lane. They work toward a goal, and anything they can reach is fair game on the way there. He argues the whole software industry is now paying for earlier shortcuts, in authentication, in authorization, and in the audit trail that shows what actually happened. As he put it on the show, that model of trust "has now broken" once agents are doing the work.
The fix starts with identity. Every workload, function and agent needs its own identity, alongside the humans, whether those humans are employees, partners or customers. We wrote about why that matters in our guide to non-human identities, and about how agents surface existing authorization gaps faster than any person could.
Why Alex says a login check is no longer enough for AI agents
Authentication and authorization behave very differently at scale. You authenticate once and get a token that stays valid for a while. Authorization happens on every request, and often several times within a single request, so it has to be fast enough that nobody notices it is there. Alex and his co-founders had already built systems that sat in the path of every request at very large scale, so speed and observability went into the first release rather than being added later.
Agents raise the bar again. A check at login that says "this person is signed in, so they can reach everything" no longer holds. Each step needs its own check. When service A calls service B on behalf of a user, the question becomes whether service A may call service B for that particular user, and the answer has to carry through every hop in the chain. We go through how that chain gets lost, and how to keep it intact, in our post on multi-hop delegation.
Alex called this zero trust, "to use a horrible buzzword", and the idea predates AI. You stop trusting the network boundary or the VPN and move trust down to each individual API call. Zero trust authorization was good practice before agents. With agents trying every endpoint they can find, Alex sees it as the only way to build systems that hold up.
AI coding agents are a concrete example. With Cerbos Synapse, every tool call Claude Code makes, every file read, write and shell command, is checked against policy before it runs, and every decision can be logged for audit.
How Cerbos started, after the co-founders rebuilt permissions at several companies
Before Cerbos, Alex built permissions systems at several companies. At an e-commerce analytics business, customers ranged from airlines to US retailers, and each needed access split its own way. One company wanted a US team kept away from European campaigns. Another organized everything by department instead of region. Every customer's matrix was different, and the logic lived inside the application. He solved the same problem again at a supply chain company, and it bothered him every time.
As Alex tells it, there was nothing off the shelf for application permissions back then. Policy engines existed for infrastructure, but there was no product built to manage who can do what inside a SaaS application. Alex says he and his two co-founders, Emre Baran and Charith Ellawala, who had worked together for more than ten years, also saw permissions becoming a blocker for any product trying to sell to enterprises. So in 2021 they started Cerbos to take that logic out of application code and evaluate it in a separate service running alongside the application. That approach is known as externalized authorization.
Because that service sits in the path of every request, developers and architects had to trust it before anyone could talk to security or the business. Performance, integration and observability came first. Today teams run more than 2 billion authorization checks a month on Cerbos.
The first big product decision was what a policy should look like. Alex said the existing policy engines had the right idea. You send a request asking whether this identity can take this action on this resource in this context, and you get back allow or deny. But their policy languages were too complex to hand to a product manager, a security reviewer or an auditor. So Cerbos policies are written in YAML, with conditions in Google's Common Expression Language (CEL), built around resource policies that carry the rules for each thing someone is trying to touch.
Alex explained that the first dozen or so releases translated that format into Open Policy Agent under the hood, which let the team iterate on the format quickly. We tell the rest of that story in From OPA to our own engine, and how product and security teams work with the format today in can non-engineers manage policies.
What the Cerbos user community changed in the product
Anyone building developer tools learns quickly that developers have strong opinions and share them freely. Alex called that feedback a gold mine. In the Cerbos community Slack and on GitHub, large companies described what it took to run authorization across their whole stack. They needed policy changes rolled out to every place authorization decisions were made, a single place to see every decision for audit, and policy tests running in CI on every change.
That feedback shaped Cerbos Hub, the control plane where teams author, test, distribute and audit their policies, and the team has kept repeating that loop since. Alex said the thing he is proudest of is that community, the people who open issues, start threads and write their own posts about how they solved a security problem with Cerbos.
He also talked about how the team works. Cerbos has been fully remote since it started during COVID, and one of its first engineering hires was in New Zealand, as far from London as you can get. That forced a culture of written documentation and async work. There is no daily standup.
Where Alex sees agents heading, and his advice to founders
Alex sees agents as a permanent part of the stack. The goal is not to stop them but to control and monitor them, and to stop them drifting from their original goal, with a proper security boundary around everything they do.
For Cerbos that means more work on understanding how policy and behavior line up. That includes showing product managers, security teams, auditors and CISOs the current security posture, showing developers how access is actually being used, and showing the impact of a policy change across every application before it ships. Some of this is already in the platform. Cerbos Hub Insights shows what the authorization layer is allowing and denying in production.
The episode ends with advice for founders that applies just as well to anyone pitching an idea internally. Alex said he hates a perfectly rehearsed elevator pitch. Care about the problem more than the solution, he said, because that enthusiasm is what makes people want to keep talking.
You can hear the full conversation on Code Story. Thanks to Noah Labhart for having Alex on the show.
Try Cerbos to see what a policy check on every request looks like across your applications and agents, or book a call to talk through your own setup with the team.
Go deeper:
- Securing AI agents and non-human identities in enterprises (eBook), for how to give agents their own identities and scope what each one can reach
- How to adopt externalized authorization (eBook), for a step-by-step plan to move permissions out of application code
FAQ
Tagged in
