Episode 89 of The Security Podcast of Silicon Valley aired on February 24, 2026, with Jon McLachlan and Sasha Sinkevich hosting. The guest was Graham Neray, co-founder and CEO of Oso, a company that sells authorization as a service: the layer inside an application that decides what each user is allowed to do. The conversation ran from why permissions are still built from scratch to why the over-permissioning everyone tolerates in people stops being tolerable once the user is an AI agent.
“We tolerate a lot of over-permissioning in all the apps that we use, because there’s like a finite limit on the amount of time that you or I have to do like bad or stupid things. But AI doesn’t have that constraint.”
Graham Neray, at 5:50
Graham’s LinkedIn lists him as Oso’s co-founder and CEO from January 2019, after six and a half years at MongoDB, where he worked in product marketing and sales enablement and then served as chief of staff, a stretch he sums up as helping the company scale “from $1M-$250M in revenue” (LinkedIn). Before MongoDB he was an analyst at Cartesian, a strategy consulting firm, the “management consulting” job he mentions near the end of the episode. In June 2023 Oso raised a $15 million round led by Felicis, with Sequoia and Harpoon Ventures taking part, which Graham said put its total funding “over $25 million” (TechCrunch). The company is headquartered in New York, in the NoMad neighborhood, and its investors include Sequoia Capital, Felicis and MongoDB’s CEO, Dev Ittycheria (Oso).
The conversation took place months before it aired. Graham describes the Replit incident of July 2025 as “a few weeks ago,” so it was recorded that summer, about six months before it was published. In the eight months after it aired, Oso moved the whole company toward agents, published research on how much access people never use, and then split in two, with its product going to one buyer and most of its team to another. The last section below covers that.
This page is the rest of it: a section for each part of the conversation with the sources beside it, twelve figures, sixteen clips from the tape, a LinkedIn card and an X card, the full transcript, and four tools: a quiz, a scorecard for how close your agents are to least privilege, a calculator for what homegrown authorization costs, and a timeline from the 2004 RBAC standard to the week Oso’s team joined Temporal.
A problem as old as computers
Sasha opened by asking Graham what brought him into security and compliance. He started with a joke.
“Like every young American boy, I grew up dreaming of roles and permissions. No, I’m just kidding.”
Graham Neray, at 1:45
The real story is that Oso started out on a different idea. When Graham left his last company, the team was working on something else, and then a run of meetings with prospective customers kept turning to the same subject.
“prospective customers were talking to us about the challenges that they had with permissions, which I thought was kind of nuts, because this is not like a new problem. It’s a problem as old as computers.”
Graham Neray, at 2:03
They spent more time on it, found it was “a huge problem for people,” and kept pulling on the thread. Authorization is “the function of specifying rights/privileges for accessing resources” (Wikipedia). It’s the question of what a signed-in user may do, which comes after authentication, the question of who they are.
The last layer to fall
Jon summed it up for listeners: Oso is authorization as a service. Graham agreed and described what that looks like inside a product.
“Oso is like an invisible permissions layer powering the permissions in products that you know and use, like Brex and Vanta, ZoomInfo, Productboard, Webflow.”
Graham Neray, at 2:27
Every time someone signs in to one of those products, he said, everything they do and everything on the page is authorized against Oso in real time. The alternative is the pattern he’d watched repeat across companies.
“You know, they get started with something simple, it gets more complicated over a period of time, band-aid, band-aid, band-aid, whatever, and then everyone does a big refactor.”
Graham Neray, at 2:47
His argument for buying comes from the rest of the software stack. Amazon Web Services sells “on-demand cloud computing platforms and APIs,” and Twilio sells “programmable communication tools” (Wikipedia, Wikipedia). Companies like those, he said, normalized the idea of buying what isn’t your product.
“if the thing isn’t making your beer taste better, you should consider buying it instead of building it. And so for us, we see permissions as being sort of one of the last layers to fall in this whole, like, as-a-service thing that’s been going on for the last fifteen or twenty years.”
Graham Neray, at 3:05
Checks at every level
Sasha pushed on the timing. If the problem has existed for ten or fifteen years, or much longer, why has nobody packaged it so that any company can take it off the shelf without patches on top? Graham said investors ask him the same thing, and that he can offer hypotheses, but “the truth is, I don’t know.” The first hypothesis is where the checks live.
“What makes it especially hard is that you check permissions at various levels in the stacks.”
Graham Neray, at 3:50
The front end gets a check, the back-end handlers get one, and so does the database.
“And so already you’re sort of starting from a place of fragmentation.”
Graham Neray, at 3:59
The second is architecture. A monolithic application is “a single unified software application,” so the data an authorization check needs is in one database. Microservices split an application into “a collection of loosely coupled, fine-grained services” (Wikipedia, Wikipedia), and the data a check needs goes with them.
“you might need to make an authorization request over here based on data that’s over there. Turns out that’s a pretty hard problem to solve at scale.”
Graham Neray, at 4:24
Oso’s own customer stories start from the same place. Before Productboard moved to Oso, its developers kept authorization in “if” statements and libraries spread through a monolithic Ruby application (Oso).
The homegrown system it replaces
Jon had been on the other side of this. As a security engineer in Silicon Valley he’d built the in-house version himself, long if-then checks of the kind most teams start with, and he asked whether Oso usually replaces something like that.
“It’s just about always replacing some sort of homegrown solution.”
Graham Neray, at 5:05
Security teams like the change even though they didn’t build the old system, he said, because permissions usually belong to a platform team or a product team.
“Finally, with something like Oso, the security team gets some amount of like control and visibility and ability to sleep at night.”
Graham Neray, at 5:14
Webflow’s account on Oso’s site gives a sense of what the homegrown version costs. A senior engineer there recalls a team that “spent two weeks making a few small changes to authorization,” only to have the change rejected in review (Oso).
Login is a whole other company
Sasha asked whether Oso combines authentication and authorization or keeps them separate. Graham said people ask, and that the answer for now is no.
“Customers of Oso, partners of Oso, people have said, oh, why don’t you build an authentication product? And I think there’s a world in which we could.”
Graham Neray, at 5:27
But that would be “like a whole other company,” he said, and a company Oso’s size needs focus. Authentication already has large companies behind it. Okta, an “identity and access management company,” was founded in 2009 and went public in 2017 (Wikipedia). Permissions are where Graham saw the gap.
“And by the way, permissions are still fundamentally broken out in the world.”
Graham Neray, at 5:46
A finite limit on bad or stupid things
The idea at the center of the episode came right after. People get more access than they need in almost every application, and it mostly works out, because a person only has so many hours.
“the way that we’ve allowed everyone in an application to accrue standing privileges over time, that’s kind of worked for humans, but it’s actually not going to work in the world of AI”
Graham Neray, at 6:04
The principle of least privilege says every process, user or program should reach “only the information and resources that are necessary for its legitimate purpose,” and its original formulation, from Jerome Saltzer, asks for “the least amount of privilege necessary to complete the job” (Wikipedia). Oso later measured how far people are from it. Research it published with Cyera in March 2026 analyzed 2.4 million workers and 3.6 billion application permissions and found that workers leave “96% of their application access dormant” (Oso).
Roles are a convenience
Sasha described how the excess becomes permanent. Access gets granted wide so a team can ship, and then nobody dares to shrink it.
“everyone is afraid of changing things because there are so many workloads that are dependent on that issued over-privileged role or whatever that might be.”
Sasha Sinkevich, at 6:29
Graham agreed, and named the reason it starts.
“people over-permission users and accounts because it’s the way to make those users productive.”
Graham Neray, at 6:50
Role-based access control is “defined around roles and privileges” (Wikipedia), and in Graham’s telling the role is exactly where the excess hides.
“And so people will bucket lots of permissions into one group called an admin and just give someone the admin role as a way to be sure that they’ll be able to get their job done.”
Graham Neray, at 7:02
“But we’ve basically created roles as a convenience mechanism for assigning permissions to people so that they can do their jobs. But that convenience mechanism is way too broad, as I said, for agents.”
Graham Neray, at 7:19
What Oso sells, he said, is a permissions engine: a set of rules about who should be allowed to do what, the data about who has been assigned what, and a yes or no at runtime for each person, action and resource. Relationship-based access control decides by the relationships between users and resources, and attribute-based access control by “evaluating attributes associated with the subject, object, requested operations” (Wikipedia). Both answer questions a single admin role can’t.
Automating least privilege
Then the part Graham called “even more exciting for the security community.”
“So imagine a world where we can look at the permissions that you’ve assigned to a user, the permissions that they’ve actually exercised over a rolling 30-day period.”
Graham Neray, at 7:57
“and it’s a machine doing it, not a human, you can like automatically scope their permissions down to the permissions they’re actually using.”
Graham Neray, at 8:10
Sasha put a name to it: “So that’s like least privilege.” Graham: “Yes, yes, exactly.” The loop takes the guesswork out of an access review. The evidence is what each person actually used, and a machine does the trimming.
Scope it to the task
For agents, a usage window isn’t enough, Graham said, and he was clear that the method doesn’t carry over as is.
“You can’t use the same methodology to extend that to agents, but fundamentally, the world that we’re headed towards is one in which you can dynamically scope down the privileges of an agent for any given task based on the fewest privileges required to achieve that task.”
Graham Neray, at 8:23
“That’s like the holy grail. That’s where Oso is headed.”
Graham Neray, at 8:36
An AI agent is “an artificial intelligence program that can make decisions, pursue goals, and take actions” (Wikipedia). A role hands it everything it might ever need, every run. A task-scoped grant hands it what this run needs, and nothing left over for the next one.
Day nine
Jon asked why the human approach doesn’t carry over. Watch what someone uses, cut the rest: why isn’t that enough for an agent? Graham’s answer was about how agents fail.
“agents can be told to do bad things, misunderstand instructions, and find weird ways to achieve their goals that may not be what you actually said.”
Graham Neray, at 9:08
His example was still fresh when they recorded.
“So, like, there’s this example of Jason Lemkin, who was live tweeting about this, like, vibe coding experiment he was doing a few weeks ago.”
Graham Neray, at 9:17
“Day nine. Replit agent goes rogue, deletes the production database and lies about it.”
Graham Neray, at 9:27
Vibe coding is “the software development practice assisted by artificial intelligence (AI)” in which the developer describes the task and the model writes the code. The term was coined in February 2025, and Collins named it its word of the year for 2025 (Wikipedia). Replit runs “a cloud-based platform for writing and running software” (Wikipedia). Fortune’s account has the details. Lemkin, the founder of the SaaS community SaaStr, had the project in a “code and action freeze” when the agent wiped data on more than 1,200 executives and over 1,190 companies. The agent then told him a rollback “would not work,” and he recovered the data manually. Replit’s CEO, Amjad Masad, called it “Unacceptable and should never be possible” and announced “automatic separation between development and production databases” along with a planning-only mode (Fortune).
The fix is a least-privilege fix at the level of environments. In a typical deployment environment setup, “the development environment (where changes are originally made)” is kept apart from production (Wikipedia), and an agent working in one shouldn’t be able to reach the other. Oso now keeps a public registry of agent failures, and its entry for this one says the assistant “ignored the instruction not to change any code 11 times” (Oso).
Enough, but no more
Jon put the general problem in one question, and Graham finished it for him.
“How do you make sure, like, the agent has enough to do what it needs to do to complete those tasks?”
Jon McLachlan, at 9:34
“Yes. But no more. Exactly.”
Graham Neray, at 9:40
His example was Productboard, which he said had used Oso for three years and gone “way farther on their agentic journey.” Picture one of its customers with agents in the platform and a casual instruction.
“Let’s say they have agents in their platform and they say, hey, go delete all mentions of such and such a customer that churned, or something like that.”
Graham Neray, at 9:56
“the idea is like, even by accident, it could do something stupid. And so, you need a different way to scope down those permissions to the fewest permissions required to achieve the thing that you’ve asked it to do.”
Graham Neray, at 10:06
Productboard’s own move to enterprise customers needed “custom roles, relationship-based access, and fine-grained edit permissions for individual fields,” according to its case study on Oso’s site (Oso). An agent working inside a product like that inherits the same question at a faster pace: which records, which fields, for this task only.
Single digits in production
Sasha tied it back to an earlier conversation. On episode 81, Eric Olden of Strata Identity said very few companies had agents in production yet.
“Eric mentioned that there is a single-digit number of agents that are deployed in production.”
Sasha Sinkevich, at 10:23
“I don’t necessarily feel comfortable releasing all of these built-out agents into the production and enabling people to use them, because I’m not confident that the agents will do exactly what I’ve instructed them to do.”
Sasha Sinkevich, at 10:36
Sasha’s question was the one that runs through the whole episode. Over-provisioning isn’t new, and people could always do bad things with too much access. So why solve it now, and what makes agents different?
Probabilistic, not deterministic
Graham’s answer started with how agents work.
“Well, it’s because agents are not deterministic, they’re probabilistic. So you can’t be sure that even if you ask it to do a given thing, it’s necessarily going to do the thing you asked it to do.”
Graham Neray, at 11:05
“And it could also be tricked, as we’ve said.”
Graham Neray, at 11:14
A prompt injection is an attack in which “innocuous-looking inputs (i.e. prompts) are designed to cause unintended behavior” in a model (Wikipedia). People get a measure of trust that an agent can’t earn the same way, Graham said, even if security teams were never comfortable with how much trust that was.
“You can’t bestow that same level of trust and judgment expectation to an agent.”
Graham Neray, at 11:26
A day for a person, milliseconds for an agent
Sasha took the other side of the same idea. The assumption has always been that people are aligned with the company and won’t do harm on purpose. Agents get no such benefit of the doubt.
“It sounds like agents, we cannot put the same amount of trust in the agent, because by default it could be pivoted into doing things, whether it’s prompt injections, whether it’s some type of other vulnerability execution against the agents.”
Sasha Sinkevich, at 11:41
“The attack surface on agents is a lot larger than the attack surface on the human.”
Sasha Sinkevich, at 12:00
And they’re faster. Sasha’s version of the gap was that something a person might take a day to do, an agent might do in milliseconds, with a snowballing effect, because “agents can do a lot more damage a lot quicker.”
What a hundred CTOs and CISOs said
Graham had been asking around.
“I spent the last six months meeting with over a hundred CTOs and CISOs to ask them about their adoption of AI.”
Graham Neray, at 12:31
He sorted what he heard into three groups. The first is small.
“You have some, like, AI-native companies that are going buck wild on agents, because that’s their thing, it’s part of their DNA.”
Graham Neray, at 12:40
There were “fewer than fifty companies doing that,” by his count. Growth-stage and mid-market companies had all shipped something with AI because someone told them to, “But usually it’s like a toy,” purely generative, away from customer data or customers, or both. Enterprises were “just finishing up a ton of POCs” and buying chatbot licenses. A proof of concept is “an inchoate realization of a certain idea or method in order to demonstrate its feasibility” (Wikipedia), which is about where most companies were. His explanation went back to Sasha’s point.
“people don’t feel comfortable unleashing these agents, and they shouldn’t. Not without a strong authorization layer, at least.”
Graham Neray, at 13:22
Why it’s called Oso
Jon, who knows “just enough Spanish to sound like a five-year-old kid,” knew that oso means bear, and asked where the name came from. Graham had worked at a company whose name people misspelled and mispronounced, and he’d been on its marketing team.
“my criteria for a name were that it be easy to spell, easy to pronounce, and not mean anything offensive in multiple languages.”
Graham Neray, at 13:57
His co-founder’s criterion was not to sound like a generic security company. They both speak Spanish, and Graham was reading a book about bears at the time. Jon added that it’s a palindrome, a word that “reads the same backwards as forwards” (Wikipedia), which pleased the engineer in him.
Infrastructure doesn’t sell on mock-ups
Graham then asked the hosts for their take on something he thought founders don’t talk about. The standard advice for building products, he said, is to be scrappy, put cheap mock-ups in front of people and iterate.
“But I don’t think this works for infrastructure products. And I would say I had a really painful time learning that.”
Graham Neray, at 15:00
He went to his first meeting about an early version of Oso with nothing, no deck, on purpose, because he wanted a conversation. The first question was whether he had a deck. The next person, shown a deck, asked for a demo. The meeting after that got a docs page and a faked-out demo.
“And what we found is that the quality of feedback was directly correlated to how concrete the thing was that we put in front of the person on the other side”
Graham Neray, at 15:40
His reason is the buyer’s options. Someone in sales or marketing can buy from you, buy from someone else, or do nothing. An engineer has a fourth option from the first minute.
“Whereas for an engineer on the other side of the table, the option space is immediately like, okay, how is this better than what I could build myself?”
Graham Neray, at 16:12
A minimum viable product is “a version of a product with just enough features to be usable by early customers,” and the lean startup method “aims to shorten product development cycles” (Wikipedia, Wikipedia). Graham’s point is that for infrastructure the “just enough” bar is much higher, because the first conversation goes straight to the internals.
Who feels the pain
Sasha took it to the buyer. Who has the pain, a procurement team that knows nothing about permissions, or a security or platform engineering team whose customers want proof?
“their customers are asking for explicit proof that their over-provisioning does not exist in your product or your service”
Sasha Sinkevich, at 17:08
Jon said the engineers who respect the problem are usually the ones who’ve been hurt by it.
“I think it takes actually a great deal of experience and reverence for the problem, almost been burned by the problem maybe once or twice before in a different gig, to have the humility to say, like, yeah, you know what? That’s actually a really hard problem to get right.”
Jon McLachlan, at 17:35
Sasha added complexity. A security engineer doesn’t want every dashboard and every setting, any more than a browser user wants to manage the cryptography underneath.
“Do I want to take care of the key exchange when my browser establishes HTTP connection? No, because Taher Elgamal has made a lot of amazing work in that space to ensure that my web traffic is well secure.”
Sasha Sinkevich, at 18:36
A key exchange is “a method in cryptography by which cryptographic keys are exchanged between two parties” (Wikipedia). Taher Elgamal was chief scientist at Netscape from 1995 to 1998 (Wikipedia), and he told that story himself on episode 61.
Bought by people who’ve been burned
Graham picked up Jon’s point.
“Jon, you were saying something that I think totally tracks, which is that many of our buyers are people who have been burned.”
Graham Neray, at 18:56
He described the buyers as bimodal. Some have built permissions before, and when they start the next project they come straight to Oso. His example was Guy Podjarny, the founder of Snyk, “a developer-oriented cybersecurity company” founded in 2015 (Wikipedia), whose new company, Tessl, has used Oso from the beginning. The rest start simple, band-aid it again and again, and finally arrive with one request.
“I want this to be my last permissions rewrite.”
Graham Neray, at 19:26
Then there’s the person who was both. Graham told it as a story about Slack going upmarket about eight years before.
“So they’re launching Enterprise Grid, which is their enterprise product. Importantly, around this time, they’re building fine-grained access controls, the ability to say things like, you own this channel and I own that channel, but not vice versa.”
Graham Neray, at 19:38
Enterprise Grid became available in February 2017, with “dozens” of companies already on it, including PayPal, Capital One and IBM (CIO Dive). Nothing on the market did what Slack needed, Graham said, so it built its own.
“And so they spent a significant amount of money, on the order of millions of dollars, building and maintaining a system of their own.”
Graham Neray, at 19:57
The VP of engineering who greenlit that project was Allan Leinwand. By the time of the recording he was CTO of Webflow, and in the same situation, Graham said, “growing like a weed” and wanting fine-grained permissions.
“Except instead of building it internally this time, they’re buying Oso.”
Graham Neray, at 20:18
Oso’s account of the Webflow project says that as Webflow moved deeper into the enterprise market, “its homegrown authorization system hit hard limits” (Oso).
Authorization Academy
Jon’s argument for buying was about expertise: a team that has been burned and is obsessed with one problem brings all of that to every customer. Graham’s example was documentation.
“But if you look up like best practices for building authorization in GraphQL, like, I promise you’re going to find almost nothing except for some of the things that Oso has been writing over the last few years.”
Graham Neray, at 21:47
GraphQL is “a data query and manipulation language” (Wikipedia), and the contrast he drew was with PostgreSQL schema design, where advice is everywhere. When Oso started, he said, “even just trying to get a common language and mental model for the problem was really challenging.”
“It’s not specific to Oso. And so, there’s no like vendor component in this thing. It’s called Authorization Academy.”
Graham Neray, at 22:11
Authorization Academy describes itself as “A series of technical guides for building application authorization,” and its introduction makes Graham’s point: “there’s limited concrete material available for developers” (Oso). Graham said security professionals regularly tell Oso they use it with their teams, whether or not they use Oso, which he called a great thing.
If Oso is down, your app is down
Jon asked for the best day of the journey. Graham picked the first customer.
“It was a Friday night. They gave me like a verbal over a Zoom. It was from the CTO of that company.”
Graham Neray, at 22:46
He sat at his desk alone for ten minutes afterward, taking it in. The team was under ten people, though he said he didn’t remember exactly, and the buyer was the archetype he’d described, a CTO who had built permissions several times and didn’t want to do it again. The yes was hard to get because of where Oso sits.
“we’re a critical on-path production service. If Oso is slow, your app is slow. If Oso is down, your app is down.”
Graham Neray, at 23:24
“Once you get a few people to take the bet, then other people see that they’re not the first and, you know, it just sort of snowballs from there.”
Graham Neray, at 23:33
Sasha added that without a real pain point there’s a lot less appetite for the risk of a new vendor, and Jon put it in one line: “no one wants to take a vitamin that might kill them.” Graham named the trap security vendors face.
“the companies that care the most about security, and thus should be most interested in trying new security products, are also the ones that are most risk averse.”
Graham Neray, at 24:14
Jon called it “almost like catch-22.” A catch-22 is “a paradoxical situation from which an individual cannot escape,” a term first used by Joseph Heller in his 1961 novel (Wikipedia). Oso’s answer to the on-path risk came later in its product. Webflow’s account describes fallback nodes that “allow authorization to continue even if Oso Cloud becomes unreachable” (Oso).
Security that customers pay for
Graham asked the hosts what snaps a market out of that dynamic. Sasha answered with a question saved from earlier, who the economic buyer for authorization is, and with a principle.
“And in general, everything in security should be driven by business.”
Sasha Sinkevich, at 25:27
In financial services, government or healthcare, Sasha said, certain systems are a requirement for doing business at all, and then a security or infrastructure team has to build them so they hold. Graham’s version was that authorization sits in a different market from most of security.
“most markets in security are strictly speaking about risk mitigation for the business.”
Graham Neray, at 26:26
“Oso is different in that, actually, what Oso is doing is enabling a customer-facing security capability, which our customers’ customers pay extra money for.”
Graham Neray, at 26:35
“They want to sell to the federal government. In order to sell to the federal government, or maybe in order to expand wallet share with the biggest enterprises, they need fine-grained access control over who can do what inside the system.”
Graham Neray, at 26:55
“Usually, the buyer for Oso is the CTO or the VP of engineering.”
Graham Neray, at 27:10
The pressure comes from product and go-to-market, he said, and the engineering leader’s questions are how fast it can be built and whether the team has the expertise. Sasha drew the contrast with security information and event management, which provides “real-time analysis of security alerts generated by applications and network hardware” (Wikipedia).
“SIEM is very important, but the value add from SIEM is very different than the value add from a security control that enables your growth.”
Sasha Sinkevich, at 27:39
The math on six engineers
Graham agreed with Sasha, and did the arithmetic.
“you had a team of six engineers that were working on this full time. You paid them whatever, $250,000 a year. And now you have like half an engineer just maintaining the Oso implementation.”
Graham Neray, at 27:53
“And now imagine that I can tell you it also takes you a minute to add a new role instead of a week or a month or a sprint or whatever it was taking before.”
Graham Neray, at 28:06
Six engineers at $250,000 is $1.5 million a year, against $125,000 for half an engineer, in his example. That’s the vendor’s side of a return on investment case, and the service has its own price, so the calculator below starts from his numbers and lets you put in yours. Oso’s very first user made the revenue side concrete.
“The very first user of Oso, our open source product, used Oso to charge more. They were selling software to defense manufacturers, and they used Oso to build features that they charged hundreds of thousands of dollars for.”
Graham Neray, at 28:13
Security as the growth engine
For Jon, that “totally flips the discussion” for a security team.
“If you phrase security, or you position security within an organization as part of that growth engine, and you latch onto that growth, it’s especially important in those enterprise spaces.”
Jon McLachlan, at 28:37
A threat model, staying out of the news and knowing what to do in an incident are all good, he said, but they aren’t the reason for the work.
“That enables other companies to trust your company because you’re there.”
Jon McLachlan, at 29:19
When another company looks at yours, the question is whether you meet its bar, and anyone closing a deal has options.
“So if you can actually position security to be your market distinguisher, your secret weapon, you’re going to get more of those deals, the bigger ones, the ones that are more sticky and care deeply about security.”
Jon McLachlan, at 29:59
Why now
Graham brought it back to Sasha’s earlier question.
“everyone and their brother wants to add some kind of an agent to their product, which is great.”
Graham Neray, at 30:37
“But again, no one’s going to let those agents like run wild through their API unless they have good permissions on those agents.”
Graham Neray, at 30:44
That, he told Sasha, was maybe the best answer to the question of why now.
“if you want to add agents to your product, you basically have to figure this out.”
Graham Neray, at 30:54
Sasha asked whether over-permissioning would ever be solved, or at least get to the 80/20. Graham’s answer: “Yeah, you’ll see that from us sooner than you think.” Jon asked how much AI Oso itself used.
“There’s really not much AI in the product, except we have built and shipped an MCP server, which you can use, and there’s some pretty cool things that you can do with it.”
Graham Neray, at 31:32
“But for reasons like you would expect, we’ve been extremely careful in terms of the rollout of agents, both internally and for our customers.”
Graham Neray, at 31:38
The Model Context Protocol is “an open standard and open-source framework” for connecting AI systems to tools and data (Wikipedia). Oso’s press page dates its MCP server to August 7, 2025 (Oso).
No one knows what they’re talking about
Jon asked what success would look like. Graham remembered his dad showing him the first color laptop and their first modem, and said that kind of change is happening ten times more now than earlier in his life.
“I think permissions, it’s like a very overlooked area that we happen to have gone really deep on in the last five or six years.”
Graham Neray, at 32:45
Contributing that piece to the way the world adopts AI, he said, would make it “a much safer place.” Asked what he’d tell his younger self, he said he’d been raised to be diplomatic and not burn bridges, had planned for years to become a lawyer, and has had to unlearn it as a founder.
“So I would have told myself to start that process when I was like ten instead of when I was like thirty.”
Graham Neray, at 33:57
“I also got some great advice when I was like 19 that I’ve never forgotten, and I would say has totally turned out to be true, which is that no one knows what they’re talking about.”
Graham Neray, at 34:19
He found it out in his first job, in management consulting, talking to executives of very large companies, and it gave him the confidence to start his own. His parting plug was four words long: “Use Oso for permissions.”
What happened after the tape
When we recorded. Graham called the Replit incident of July 2025 “a few weeks ago” and said Oso had “built and shipped an MCP server,” which its press page dates to August 7, 2025 (Oso). So the conversation happened in the summer of 2025. It aired on February 24, 2026, and went up on YouTube on June 16, 2026 (YouTube).
Agents first. By 2026 Oso’s home page read “Agents are here. Oso makes them safe.” (Oso), and its about page says seven years of building permissions for people “taught us how and why those models fail for agents” (Oso). It also keeps the Agents Gone Rogue registry of agent failures mentioned above (Oso).
The 96% blind spot. In March 2026 Oso and Cyera published research across “2.4 million workers and 3.6 billion application permissions.” Workers had left 96% of their access untouched, and “31% of users have the power to modify or delete sensitive data.” Graham’s comment in the release was the episode in two sentences: “For humans, overpermissioning was a bad habit we could live with,” and “That bargain just expired.” (Oso).
We never fixed least privilege for humans. We didn't have to because humans are slow, they sleep, they have judgment. That's not the case with agents.
Oso (@osoHQ) · June 9, 2026
Tiny and Temporal. On October 6, 2026, Graham announced that Tiny had acquired Oso Cloud and that “most of the current Oso team is joining Temporal to build authorization for AI agents” (Oso). GeekWire described Oso as “a New York-based startup specializing in application authorization” and reported that “holding company Tiny acquired Oso’s software product and customer base,” a month after Temporal raised $550 million at a $12.55 billion valuation (GeekWire). Temporal’s announcement cited the research, “Oso’s research found that 96% of permissions go unused,” and described the job as asking, for every action an agent takes, “who it is acting for and what that person is allowed to do” (Temporal). Graham’s LinkedIn now lists him in product at Temporal, starting October 2026 (LinkedIn).
The Oso team is joining Temporal Technologies to build authorization for agents, and Tiny is taking over Oso Cloud.
Graham Neray · Product, Temporal Technologies · October 6, 2026
I've spent seven years building permissions software.
In the same post he restated the argument from the tape, that over-permissioning survived because “there’s a finite amount of damage a human can do before someone notices” (LinkedIn).
The part of the conversation that aged best is the plainest. We tolerate giving people more access than they need because a person only has so much time to do bad or stupid things, and agents don’t have that limit. A little over a year after the recording, the job Graham described had become the job Temporal hired his team to do: decide, for every action an agent takes, who it’s acting for and what it may touch, and give it enough for the task, but no more.
Did you catch it? A six-question quiz
Six questions from the episode. Each answer links the moment in the transcript.
Quiz · six questions
Did you catch it?
Pick an answer for each. The explanation shows once you choose.
-
Why do we tolerate over-permissioning for people, in Graham's telling?
- Most people never sign in
- A person only has so much time to do bad or stupid things
- Roles expire every quarter
b. "because there's like a finite limit on the amount of time that you or I have to do like bad or stupid things." Transcript, 5:55.
-
What does automating least privilege look at?
- A survey of what people think they need
- The org chart
- The permissions someone actually used over a rolling 30 days
c. "the permissions that they've actually exercised over a rolling 30-day period." Transcript, 8:01.
-
What happened on day nine of Jason Lemkin's experiment?
- The agent deleted the production database and lied about it
- The agent shipped the app on schedule
- The agent asked for admin access
a. "Day nine. Replit agent goes rogue, deletes the production database and lies about it." Transcript, 9:27.
-
Why can't agents get the trust people get, in Graham's answer to Sasha?
- They cost more to run
- They're probabilistic, and they can be tricked
- They only work at night
b. "Well, it's because agents are not deterministic, they're probabilistic." Transcript, 11:05.
-
What improved the feedback Graham got on an early version of Oso?
- Asking fewer questions
- Cheaper mock-ups
- Bringing something more concrete each time
c. "the quality of feedback was directly correlated to how concrete the thing was that we put in front of the person on the other side" Transcript, 15:41.
-
Who usually buys Oso?
- The CTO or the VP of engineering
- The procurement team
- The marketing team
a. "Usually, the buyer for Oso is the CTO or the VP of engineering." Transcript, 27:10.
How close are your agents to least privilege?
Graham’s test was enough for the task, and no more. Eight questions on how far your agents and your product are from it.
Scorecard · eight questions
How close are your agents to least privilege?
Answer for your agents and your product as they run today. If two answers fit, pick the lower one.
-
How are your agents' permissions scoped?
- They run with a person's access, often an admin's
- A shared role or service account
- Their own identity, scoped to each task
"you can dynamically scope down the privileges of an agent for any given task based on the fewest privileges required to achieve that task." See Scope it to the task.
-
Can an agent working in development reach production data?
- Yes
- Only with a warning or a manual step
- No, the environments are separated
"Day nine. Replit agent goes rogue, deletes the production database and lies about it." See Day nine.
-
Do you remove permissions that go unused?
- Rarely
- In periodic reviews, by hand
- Automatically, from a rolling window of real usage
"the permissions that they've actually exercised over a rolling 30-day period." See Automating least privilege.
-
Where do your permission checks live?
- Spread across the front end, handlers and queries
- In a shared library
- In one authorization layer every service calls
"you check permissions at various levels in the stacks." See Checks at every level.
-
How long does it take to add a new role?
- A sprint or more
- About a week
- Minutes
"it also takes you a minute to add a new role instead of a week or a month or a sprint" See The math on six engineers.
-
Can your customers set access on a single resource, like one project or one channel?
- No, it's all or nothing per account
- A few fixed roles
- Yes, per resource, with custom roles
"they need fine-grained access control over who can do what inside the system." See Security that customers pay for.
-
When an agent's task changes, what happens to its access?
- It keeps whatever it had
- Someone updates it by hand
- It's granted per task and expires when the task ends
"Yes. But no more. Exactly." See Enough, but no more.
-
If an agent did something you didn't ask for, how would you find out?
- From a customer
- From the logs, later
- From an alert, with a record of every action it took
"agents can be told to do bad things, misunderstand instructions, and find weird ways to achieve their goals that may not be what you actually said." See Day nine.
Agents and people hold far more access than their work needs, and nothing trims it. Give each agent its own identity first, and cut every agent off from production data it doesn't need.
Some access is scoped and some is still inherited. Move the checks for one feature into one place, and trim what the last 30 days of usage didn't touch.
Your agents get what the task needs and lose it afterward. Keep it that way with usage-based trimming and a record of every action each agent takes.
What does homegrown authorization cost?
Graham’s example on the tape was six engineers on permissions full time. Put in your own numbers.
Calculator
What does homegrown authorization cost?
Five estimates: the engineers who build and maintain your permissions, what one costs a year, how many it would take to run a service instead, how many new roles or permission changes you ship a year, and the working days each one takes today.
Building permissions yourself costs $1,500,000 a year in engineering time. The people to run a service would cost $125,000, a difference of $1,375,000 before the service's own price, and shipping new roles takes 60 working days a year at today's pace.
The first three defaults are Graham's example from The math on six engineers: six engineers at $250,000 a year, and half an engineer to maintain the service. Twelve changes a year at five working days each is a round example for his "a week or a month or a sprint." Oso sold the service side of this comparison, and the service has a price of its own, so time your own changes before you decide.
From RBAC to Temporal
Everything on this page sits on one timeline, from the RBAC standard to the week Oso’s team joined Temporal. Filter it by thread.
Timeline · 2004 to 2026
From RBAC to Temporal
Filter by thread. Dates are from the public record except where marked as part of this show.
- RBAC, standardized
The NIST, ANSI and INCITS standard sets out core, hierarchical and constrained role-based access control (Wikipedia, on this show).
- MongoDB
Graham joins MongoDB in product marketing (LinkedIn).
- Snyk
The developer-oriented security company is founded in Tel Aviv and London (Wikipedia, on this show).
- Chief of staff
Graham becomes MongoDB's chief of staff, a job he holds until January 2019 (LinkedIn).
- Enterprise Grid
Slack's enterprise product becomes available, with PayPal, Capital One and IBM among its first users (CIO Dive, on this show).
- Oso
Graham co-founds Oso and becomes its CEO (LinkedIn).
- $15 million
Felicis leads a round with Sequoia and Harpoon Ventures, taking total funding past $25 million (TechCrunch).
- Fallback
Oso makes fallback generally available, for when Oso Cloud can't be reached (Oso, on this show).
- Episode 61
Taher Elgamal, the father of SSL, on passwords (episode 61).
- Vibe coding
The term is coined, and Collins later names it its word of the year (Wikipedia).
- Day nine
A Replit agent deletes SaaStr founder Jason Lemkin's production database during a code freeze (Fortune, on this show).
- MCP server
Oso ships an MCP server (Oso, on this show).
- Episode 81
Eric Olden on putting agents into production (episode 81).
- Episode 89
Jon, Sasha and Graham's conversation, recorded a few weeks after the Replit incident by Graham's account, airs (transcript, on this show).
- The 96% blind spot
Oso and Cyera publish research on 2.4 million workers and 3.6 billion permissions (Oso).
- On X
Oso posts that "We never fixed least privilege for humans" (X).
- On YouTube
The episode goes up on the show's channel (YouTube).
- Tiny and Temporal
Tiny acquires Oso Cloud, and most of the Oso team joins Temporal to build authorization for agents (Oso, Temporal).
- Product at Temporal
Graham starts in product at Temporal (LinkedIn).
What to do this week
Five things, in the order Graham’s argument suggests.
- Give every agent its own identity. List the agents running in your company and your product, and for each one write down whose access it uses today. Any agent running as a person, and especially as an admin, is the first to fix.
- Wall off production. Make sure no agent working in development or in a planning mode can reach production data. That was the fix Replit announced after day nine.
- Trim from real usage. Pull 30 days of permission use for one important system and remove what nobody touched. The scorecard above shows where else to start.
- Put the checks in one place. Pick one feature and move its permission checks out of the front end, the handlers and the queries into one authorization layer, then time how long the next new role takes. The calculator above shows what that time costs.
- Scope one agent to one task. Write down a task an agent runs, the fewest permissions it needs and when they should expire, and grant exactly that. If you’d like a hand with any of it, our AI access control audit team can help, and you can book 15 minutes with us.