89. AI Agents Will Delete Your Database. And Then Lie About It (with Graham Neray)

Hello, everyone, and welcome to another episode of the Security Podcast of Silicon Valley. I'm your host, John McLaughlin, and I'm joined today with the other host, Sasha Sienkiewicz. And we have an amazing guest to share with everyone today, the co-founder and CEO of Oso, Graeme Neri. Welcome to the show, Graeme. Thanks for having me. Happy to be here. Before the show started, we were actually chatting a little bit about our experiences. Graeme, what brought you into the security and compliance space? And what are you most excited about?

Like every young American boy, I grew up dreaming of roles and permissions. No, I'm just kidding. It's not too far from the truth, maybe sometimes, you know. What happened is that when I left my last company to start Oso, we were actually working on something else. But I remember having a number of meetings in a relatively short period of time where 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. But at any rate, I thought that was kind of crazy, but we went to go spend a little more time on it. And it turns out it's like a huge problem for people. And we just started pulling on that thread and here we are. Yeah, so for all of our listeners, Oso is authorization as a service. Yes, you got it. Yeah, so Oso, you can think about it.

So Oso is like an invisible permissions layer, powering the permissions in products that you know and use, like Brex, Inventa, ZoomInfo, ProductBoard, Webflow. And so every time you log into one of these products, everything that you do and everything that's being put on the page is being authorized against Oso in real time. And so traditionally, everyone has built this sort of thing from scratch. You know, they get start 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. This is sort of the pattern that we saw play out over and over again. Now, if you think about this in the context of what's happening in software more generally, AWS, Twilio, companies like this over the last 15 or 20 years have normalized the idea that like, 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 15 or 20 years. You mentioned it's not a new problem, but how come that in 10, 15 years that the problem has existed, I would argue that existed for much longer, no one was able to solve it in a way such that any company can take it as an off-the-shelf solution and just implement it without having to apply patches on top of it.

Yeah, it's a great question. And I wish I truly understood the answer. I mean, investors ask me that all the time. It's basically like, why now? And I have some, I can give you some hypotheses, but the truth is, I don't know. There are definitely some things that make it especially hard. What makes it especially hard is that you check permissions at various levels in the stacks. You check permissions at the front end and, you know,

back-end handlers at the database level. And so already you're sort of starting from a place of fragmentation. That's one challenge. Another challenge is there's certain kinds of architectures that have spreaded up over the last 10 years that make this problem a lot more challenging. So for instance, if you have a monolithic application, all the data you'd need to answer an authorization question

is always right there in your database. But all the companies that moved to microservices over the last 10 years or so, they now are in a situation where you might need to make an authorization request over here based on data that's over there. It turns out that's a pretty hard problem to solve at scale. So these are some of the core problems that we've been solving for our customers at Oso.

But I will admit it does seem kind of silly in some respects that we're only getting to this now. A little bit. I mean, I guess folks in previous roles, and I've bumped into this problem as a security engineer in my past lives I've had out here in Silicon Valley. And I remember building a lot of in-house stuff,

like big, long, if, then, else checks, you know. Yes, yes. You do kind of what you have to do kind of sometimes. And do you find that you replace when you land a new deal or a new partner, or are you replacing like some janky in-house built system? Always. What I used to build?

It's just about always replacing some sort of homegrown solution. Security teams love Oso because usually it's like the platform team or a product team that's building permissions finally with something like Oso. The security team gets some amount of like control and visibility and ability to sleep at night. Are you guys combining AuthN and AuthZ under the same layer? So you keep them separate?

It's a good question. 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. You know, there's good evidence. That's like a whole other company. And so we're still relatively small in the grand scheme of things. And so in order to stay, you know, in the future,

sure, maybe the very, very long-term future. But for now, we're like squarely focused on permissions. And by the way, permissions are still fundamentally broken out in the world. 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.

And so sort of 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, which is one of the reasons that we're so excited about this whole space over the next, you know, 10 years. We all have seen in our careers that you make things over-provisioned often because it's the easiest way to get as quickly as possible to the production.

And then it sort of becomes a legacy permission set. And 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. How do you guys change that mindset? How do you approach? Because often things have to be made easy for engineers to implement for it to be implemented properly.

Yeah. So I think you like hit the nail on the head, which is that people over-permission users and accounts because it's the way to make those users productive. And traditionally, the way that our industry has gone about building permission systems is in the context of roles, which are just groupings of permissions. 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. And again, like I said, for humans, that's actually kind of, it's not great. We know that that's not good. Some of the worst breaches wind up happening is like, you know, taking advantage of someone's account. But we 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.

So like today, the way most permission systems, the way they work is they're like, you know, if statements and lookups to a user table in the database, like you were saying before. Think about OSO as a permissions engine that allows you to describe a set of rules about who should be allowed to do what, describe the data as to who's actually been assigned what roles. And then at runtime, we can make these decisions for you. Yes, this person's allowed to do this thing on this resource, yes or no.

Okay. That is great and providing a ton of value to our customers. I'm very excited about it. What I think is even more exciting for the security community is automating least privilege. 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. And if you're not thinking about things in the concept of roles,

you're just like specifically the permissions anyone's using, 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. So that's like... Something about least privilege. Yes, yes, exactly. And now imagine extending that to agents.

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. That's like the holy grail. That's where Ozuo is headed. That's the thing I'm most excited about. I feel the energy and the excitement,

and I'm so grateful that there are smart people solving this hard problem. I mean, help us understand a little bit. It kind of makes sense if you just kind of like watch a human and they do a whole bunch of things and they're doing their job and they use a whole bunch of the permissions that they have exposure to, but not all of them. You cut the extra. Why doesn't that work?

Like, what's the hint to why that's a new problem or a difficult problem with agents? Because they do different things all of the time? Well, yeah, I mean, so fundamentally, 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.

So, like, there's this example of Jason Lemkin, who is live tweeting about this, like, vibe coding experiment he was doing a few weeks ago. He's vibe coding this experiment on Repl.it. Day one, day two, day three, I'm doing this, I'm doing that, whatever. Day nine, Repl.it agent goes rogue, deletes the production database, and lies about it. There's a general problem here.

How do you make sure, like, agent has enough to do what it needs to do to complete those tasks? Yes, but no more. Exactly. So, product board is an example of an Ozuo customer, okay? Product board's been using Ozuo for three years. They've actually gone way farther on their agentic journey. I think I would attribute that in no small part

to their adoption of Ozuo, but anyways. You can imagine a product board customer, 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. I can probably come up with even more potent examples, but fundamentally, 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. You said something very interesting, and that connected me back to one of the previous episodes we recorded with Eric Holden. Eric mentioned that there is a single-digit number of agents

that are deployed in production. So, assuming we've invested a bajillion of dollars into the AI and all of the agentic workflows, as an enterprise, 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.

And you mentioned something very similar, and given that the problem itself is not new over-provisioning, why do you think it's the right time to solve this over-provisioning permissions? Because humans could be doing bad things with over-provisioned accounts. What makes agents different?

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. And it could also be tricked, as we've said. So, whereas, I think basically, there's like a fundamental unit of trust in the human, which maybe we should have.

I think most security professionals would not feel good about having it in the first place, but that's kind of how it's been going. You can't bestow that same level of trust and judgment expectation to an agent. And so that's why the world of agents definitely changes things. We've always assumed that humans

have a much better alignment, what's good for the company, and they will not intentionally do bad things. 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. The main point here is agents are the threat surface. The attack surface on agents is a lot larger than the attack surface on the human. And plus, I think the biggest point here is agents can do a lot more damage a lot quicker. If human takes a day, agent probably might take milliseconds

in order to execute the same vulnerability. I think that's where a lot of snowballing effect rolls in. Speed of execution is a lot higher with the agent, hence you probably want to double down on the locking down permissions. Yeah, yeah, totally. I don't know what you guys are thinking, but I spent the last six months

meeting with over a hundred CTOs and CISOs to ask them about their adoption of AI. And roughly the trend I've seen is as follows. 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. That's like a sub 50, fewer than 50 companies doing that.

You have like growth stage mid-market companies, all of whom ship something with AI because someone like me or on the board said that you had to. But usually it's like a toy, maybe it's like purely generative, doesn't touch customer data, or maybe isn't customer facing or both.

And then you have enterprises, all of whom are just finishing up a ton of POCs, but basically like wrapping up the procurement of their chat GPT enterprise licenses. And I think one of the reasons, there's a lot of reasons for this, immaturity in terms of like the orchestration frameworks and stuff like that.

But I think one of the big reasons is the thing that you said, Sasha, which is that people don't feel comfortable unleashing these agents and they shouldn't. Not without a strong authorization layer, at least. No, of course, yes. Not without, yes, yes, yes, totally, totally. Speaking of Oso,

I'm really curious about the name because knowing just enough Spanish to sound like a five-year-old kid, like I know that Oso means bear in Spanish. It does, yes. So is there a story behind like how it became Oso? So I used to work at a company where the name was very often butchered

and misspelled and mispronounced and sort of a source of like annoyance for me as someone who was on the marketing team for a period of time. And so my criteria for a name were that it be easy to spell, easy to pronounce, and not mean anything offensive in multiple languages.

My co-founder, by contrast, his criteria was like, hey, I just don't want us to sound like a generic security company. So it can't be like vault author, something like that. And we both speak Spanish. At the time I was reading a book on bears and here we are.

Perfect, and you got your logo and your mascot all like down just with one go. Yeah, yeah, yeah, totally. And it's nice too because if you see the name in the mirror, it's a palindrome. So it's read the same backwards. Yeah, totally.

I don't know, it has a lot of nice properties for like the engineer that is in the back of my head. I have some ideas of some things we could talk about if you want. Please. And that I'd like to get your feedback on. So there's like a lot of discussion

in founder circles and like product circles around like, this is going to sound kind of trite, but like, you know, the best practices for building a product. And so like increasingly over the last 20 years, everyone's like, you know,

you should be scrappy, you should put cheap mock-ups in front of people, you should be iterative, you know, stuff like that. Am I tracking?

Okay, okay, okay. But I don't think this works for infrastructure products. And I would say I had a really painful time learning that. Like, here's how this played out. Very first meeting that I remember having with someone

to run by an idea for a prior version of Oso. I came to that meeting with nothing, like no deck, no anything. And I deliberately thought, you know, I don't want a deck because I don't want it to feel that way. I just want to talk to this person.

And the person's first reaction to me was like, do you have a deck? Like, I don't totally know what you do. I was like, okay, that's interesting. So I came to like the next meeting with the next person with a deck. And they were like, okay, I see you have a deck,

but like, do you have like a demo? Is there like a real product I could see? And I think for the next one, we came with like a docs page and then faked out demo and so on and so forth. 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. And that specifically for these technical products, the engineers and the security professionals on the other side of the table

had a much higher bar for what they wanted to see to like actually weigh in on it. Here's why I think this is going on. If you're pitching a SaaS product to someone in the sales org or the marketing org or whatever, like their options

are buy this thing from you, buy this thing from someone else or do nothing. Like that's the option space. 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? And so in a very first conversation, you're launched into something about like the internals, how a thing works, why it's going to be better, which means you need to have much more of that stuff figured out

in order to get a developer to want to spend any time with you. And I feel like no one talks about this. I feel like all the discussion on like Twitter or whatever is just like build, ship, you know, blah, blah, blah, blah, blah. And I'm like, that didn't work for us.

And I don't think that works for infrastructure companies. So why is no one talking about this? There's something about economical buyer and knowing who your economical buyer is, because if you are solving a pain point, it's important to understand who that pain point is experienced by.

Is it experienced by a procurement team that has no idea about infrastructure security permissions and over-permissioning? Or is it a security team and platform, probably platform engineering team that actually has that pain point and they know they have to solve it

because their customers are asking for explicit proof that their over-provisioning does not exist in your product or your service. A hundred percent. And like when an engineer looks at something and it's a technical product

and there's technical grit underneath the hood, their minds can follow that threat, right? They can think about those things and they can think about it from lots of different perspectives of like, oh yeah, I could build that, whatever. Or, you know, I think it takes actually

a great deal of experience and reverence for the problem, almost to 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. I have a lot of other things

that are absolutely critical for the success of the business that I'm focused on. And I have to do those things first, not to belittle this problem, but it would be awesome if someone who has just bonded with this problem could just come in

and maybe just own this little space right here that contains everything to do with this problem, like authorization, for example, or whatever technical piece that might be on the table. And I think there's another layer which we sort of approached and that is complexity.

Even though there is a notion that if you are an engineer, if you're a security professional, you would like to see complexity, you would like to see all of those dashboards and you want to do a lot of configurations. Is that the case? I'm not so sure.

Do I want to take care of the key exchange when my browser establishes HTTP connection? No, because Taher Algamel has made a lot of amazing work in that space to ensure that my web traffic is well secure. I want the same from all of the pain points that I experienced as a security engineer. Yeah.

John, you were saying something that I think totally tracks, which is that many of our buyers are people who have been burned. I would actually say our buyers are roughly, it's sort of bimodal. You basically have people who have built these systems before

and they start their next project, they come straight to Oso and they're like, I don't want to build this again. This is like Guy Poggiarni, founder of Snyk, now founder of a company called Tessel. From the beginning, they've been using Oso.

Then you have other companies that start simple, they band-aid, band-aid, band-aid, band-aid, and they sort of come like, okay, this has been terrible. I want this to be my last permissions rewrite. And that's like the second archetype. And every now and then you get someone who's both. So this is like a fun story.

About eight years ago, Slack, they're like growing like a weed, they want to go up market. 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. So at the time they wanted to build fine-grained permissions. Oso didn't exist. They go out looking in the market. There wasn't anything there. And so they spent a significant amount of money

on the order of millions of dollars building and maintaining a system of their own. Fast forward to today, there's a guy named Alan Lineman, who's the CTO of Webflow. And at the time he was VP of Engineering at Slack. Alan greenlit the permissions project at Slack. Except now that he's the CTO at Webflow,

they're in the exact same situation, growing like a weed, growing up the market, want to support fine-grained permissions. Except instead of building it internally, this time they're buying Oso. And I think that journey is very much encapsulates like the journey of most of our customers. Yep. No, I totally get that.

And it kind of like resonates with this one notion of you really only should give production access to engineers that do not want production access. Because there's a certain amount of respect for like, okay, this is what we're entering into. Do I really need to do all of this stuff? Like in the case of building a system, a build versus buy system,

if there's an incredibly talented team that's already thought through and been burned a couple of times, maybe throughout their careers, bring all of that experience into a new product, are slugging through the works, that they've got everything riding on the success of what they're bringing to market.

And they're obsessed with this one problem. By buying a product from a company like that, you're welcoming all of that expertise into your team, into your space that you get a benefit from. You wouldn't normally have like otherwise, faces hard to find security experts out there who have all of the experience

to be able to execute on these things. And so it makes a lot of sense, economically speaking, just to group everyone together and like focus on that just for a little bit of time, nail it and share with the rest of the security community. Big time. And I think like,

so one area that comes to mind for that is like, if you wanted to look up like schema, design best practices for Postgres, you know, for whatever some use case, like you can find blog posts from Hurdle Kingdom come on that. 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. I remember when we started working on this, even just trying to get a common language and mental model for the problem was really challenging. And so one of the things that we've done over the last five years is write

a pretty comprehensive set of technical documentation on the domain. It's not specific to Oso. And so there's no like vendor component in this thing. It's called Authorization Academy. I totally agree. This is the kind of thing that I was really just surprised didn't exist before Oso,

but is the kind of thing now that we regularly hear from security professionals in the community using with their teams, whether or not they're using Oso, which by the way, like, I think that's a great thing. Yeah, absolutely. Well, what would you say has been the absolute best day along your entrepreneurial journey?

I mean, you've been with Oso for more than five years now. So really focus on this problem for a good chunk of time. Maybe the day we signed our first customer. I do remember it. It was a Friday night. They gave me like a verbal over Zoom.

It was from the CTO of that company. So I sort of felt like, okay, I'm going to take this. And I sat at my desk for like 10 minutes by myself after that in the evening, just like hanging out and absorbing it. That was pretty good. That's amazing. How many people did you have on the team when that happened?

Less than 10. I don't remember exactly. Wow. Not too many. So that was a real like confirmation point. Yeah. It was like, okay, they're going to pay money to us. Great.

The first one to jump in. Yeah, yeah. And obviously, and you can just imagine for a company like Oso, we're a critical on-path production service. If Oso is slow, your app is slow. If Oso is down, your app is down. So you can imagine it took a lot

to get someone to take that bet. But once you get a few people to take the bet, then other people see that they're not the first and it just sort of snowballs from there. But this goes back to the fact that you solve a real pain point because if you're not solving a real pain point, there is a lot less appetite for taking the risk

with the new vendor. At that time, it was a new vendor, but now you've proven yourself. Yes, yeah, yeah. And that person was that archetype I told you about, CTO who had built this thing multiple times in their career and said, I don't want to do it again this time. Excellent, excellent.

Yeah, no one wants to take a vitamin that might kill them. If you have a huge pain point and there's maybe a couple side effects, okay, like let's stick it. One thing that I think is kind of interesting about the security market, 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 and that's why they cared about security in the first place. So does that make any sense? It makes total sense. It's almost like Catch-22, right? There's very much a Catch-22 dynamic to this. And so I'm curious, like what dynamics do you guys see

that make for someone to successfully snap a market out of that Catch-22 dynamic? Actually, I will respond with a question that I was going to ask you earlier.

And that question is, the security in general can be seen as an overhead. It's very interesting to understand in case of authorization, who is your economical buyer? Who are those people that make decision that, hey, we actually have to build a system that ensures that agents or humans have the least privilege access to the crown jewels,

to the core infrastructure or to the systems that then will allow access to the data that should be permissioned. But I think the answer to that question is, what is the business driver behind that initial question? Why do we need authorization? And in general, everything in security should be driven by business.

I know for sure there are large organizations, whether it's financial vertical or it could be a government, could be healthcare, where there are certain requirements in order to do business, you have to have certain systems in place. And at that point, it becomes a business requirement in order to implement certain controls.

And then you have this interested parties, usually security team or infrastructure team that have to implement a system that will not be easily broken, that will be resilient, can be relied upon and can execute that requirement really well. And I think that's the most important question that I've seen in the industry

to sort of go back to your initial question. Everything we're doing in security needs to be aligned with business requirements, with what business needs at this point in time. Yes. So, I mean, one of the things that I think is different about our market relative to other markets in security is that most markets in security

are strictly speaking about risk mitigation for the business. And so there's like, you know, assessment of what level of risk are we willing to take in this domain of the business? 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.

And so usually the driver to adopt Oso is about a company moving up market and or increasingly adopting AI. So like you said, Sasha, you know, maybe they want to go and serve large banks. 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. And so this is quite different from me trying to sell you a SIM or something like that. Usually the buyer for Oso is the CTO or the VP of engineering. And there's pain coming from someone on the product

and the go-to-market side saying, we need to build these things. And then the question is like, you know, how quickly can you build it? What would that take? Do we have the, you know, the expertise and stuff like that? But that's so much easier to sell

because now we're saying, hey, we need Oso in order to scale and grow business a lot faster. Versus, hey, let's spend a lot of money on a SIM solution because it will add us this little, I don't want to belittle, SIM is very important, but the value add from SIM is very different

than value add from a security control that enables your growth. You're absolutely right. It makes a huge difference. You know, we don't need to think about how do I quantify risk for this domain? It's like, no, 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. Even if I said nothing to you about time to market, like ROI would be pretty compelling. 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. 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. And so there's definitely upside to being attached to revenue.

And then of course, you know, other challenges as well. Yeah. I mean, it totally flips the discussion, right? 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 space. Now there's some sense in which you're like,

okay, as security professionals, we're going to come up with our threat model and then we're going to make sure that everything in the organization meets that threat model and we're going to stay out of the news for all of the wrong reasons and we're protect ourselves from being hacked

and we'll know exactly what to do if there is an incident, that's all good. But like, why? I mean, yes, there's some moral obligation to protect the data that we're given as organizations, as security professionals, like that is our job. But why is that our job? Like that enables growth,

that enables other companies to trust your company because you're there. And so when you get into the specifics of like, oh, here's what we do for protecting the data, here's our encryption story, all of those things, they tell one simple story of like, what is that threat model? And when another organization looks at us,

do we meet the bar that they expect us to have? And if the answer is yes, or it's like almost yes, but just change these few couple of things here, then you can do business, you enable the growth, you become part of that engine. And then when you look at the wider market, of course, like those folks that are closing deals, anyone that's closing a deal has options.

There's more than one company doing almost everything out there. 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. And in some sense, like that's the business view

that I think often gets muddied with, like the technical view of like, how do we become secure? Here's all of this important data, let's secure this. But the why like is connected to like, well, we're building a successful business here. And this has to be part of that story of how are we going to close deals?

How are we going to distinguish ourselves in a competitive market space? So to that point, I would say like everyone and their brother wants to add some kind of an agent to their product, which is great. And maybe agents can do cool things, that would be great. But again, no one's going to let those agents like run wild through their API

unless they have good permissions on those agents. I think maybe this is the best answer to your question, Sasha on why now is like, well, if you want to add agents to your product, you basically have to figure this out. That's so true. That's so true. Yeah. Do you think this problem of permissions

will be solved at some point? And there is no such thing as perfect products. No one should ever try chase it. No one should ever try approach it because it doesn't exist. Things change on daily basis. But the over permissioning is not a new problem. Just like we stated in the beginning of the show,

do you think we'll be able to approach the 8020? Yeah, you'll see that from us sooner than you think. Do you guys adopt AI? Do you have like coding assistants that help engineering? 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. 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. Yeah, definitely. You know, there's something crazy that all founders share. It's this ability to look into the future and kind of see something different

than maybe what most people see. And I would love to hear a little bit about, like when you look into the future with your lens, you can look into the future, maybe specifically through Oso. Like what does success look like for you? What do you think will be the hardest challenge that we face as a security community?

Or maybe how are we going to get over it? Like what's that biggest success sort of signal that you can kind of see out there in the future? That's a deep question. Look, I mean, speaking personally for myself, and you can probably relate to this as engineers, you're part of this kind of like arc of technological development.

I remember like as a kid, my dad showing me like the first color laptop and you know, our first modem and like these things over the years. And especially now, we're at like such a crazy inflection point where that is happening 10X more than it's happened in earlier parts of my life.

There's definitely a desire to want to like be a part of and contribute to that narrative. I think permissions is like very overlooked area that we happen to have gone really deep on in the last, you know, five or six years. And so I think it would be really cool to contribute that piece of the equation to the way that the world goes about adopting AI.

If we could do that, I would feel pretty good about that. I think the world would be a much safer place and easier to make more secure, even more so like going into the future. No doubt, without a doubt. I love that you referenced your dad. Like my dad was in technology

and he sort of did some of those things with me too. I'm super curious if you could go back in time and meet your younger self, would you take that opportunity? And if you would, like would you have any advice for your younger self? Yes. I grew up and my parents whom I love dearly

really coached me a lot around like not burning bridges and being diplomatic. For many, many years, I was planning to become a lawyer. So much of my mentality was shaped around not pissing people off or something. Not rocking the boat maybe, yeah. Yeah.

And you basically need to do the opposite as an entrepreneur. I've basically been having to like beat it out of myself for the last like five or 10 years to be more comfortable being controversial and saying what I really think, even if I'm afraid that people are going to not like me for it. So I would have told myself to start that process when I was like 10 instead of when I was like 30.

That's great. That's great advice. But you know, like the things that happened to us, they shape us and seem like an amazing human being. In some sense, if you were to go back and change it, like you might change. Yeah. All the gratitude in the world for sharing

like that vulnerable moment with us. 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. My God, so true. And I remember my first job out of college, I worked in management consulting

for some very big, very famous, successful companies. And I'm talking to the execs of these companies and I was like, you don't know what you're talking about. It's just like you said, that piece of advice is one of the things that gave me confidence to start my own company. Yeah, everyone's just human. You ask for an opinion, you might get two or three,

you know, from the same person. Well, thank you so much for joining us for an episode of the Security Podcast of Silicon Valley. Thank you for having me, guys. It was an absolute pleasure. Would you like to leave our listeners with any final words of wisdom or shameless plugs? Use OSO for permissions.

No one knows what the hell they're talking about. Excellent. Thank you so much for your time. It's really, really awesome to have you. Thank you so much for like bonding with such a difficult problem in the security space. I'm super optimistic that because of people like you, like we're going to have a much more secure

and an easier path to get to that security space as products like OSO mature and like brought to market, we can all use them and enjoy them. So check them out. And if you're so compelled, like please review, share this podcast with your friends. We'll put all of our contact links if you'd like to reach out to Grom directly.

Maybe you're hiring. Maybe you'll be hiring in the near future. We are totally hiring for like all roles. So yes, please jobs at osohq.com. Awesome. Awesome. Well, thank you to all of our listeners for tuning into another episode. This has been a YSecurity production.

And thank you again. Thank you, everyone. Thanks, guys.