Podcast Episode 104
Why a16z’s CISO doesn’t trust the approve button
with Yash Kosaraju · a16z
Watch on YouTube Listen on Spotify, Apple Podcasts, Podbean, Player FM
Episode 104 of The Security Podcast of Silicon Valley. Host Jon McLachlan, co-founder of YSecurity and Cyberbase.ai, talks with Yashvier Kosaraju, who goes by Yash, Chief Information Security Officer of a16z and previously the first CISO of Sendbird. They cover when a startup makes its first security hire and why it isn't a head of security, why the accept-this-action prompt stops defending against prompt injection around the third click, and why his team never says no. Published September 22, 2026. About 38 minutes.
Episode notes
Yashvier Kosaraju, who goes by Yash, is the Chief Information Security Officer (CISO) of a16z, 4 months into the job when this was recorded, which by his own measure feels like about a year. The job covers the firm’s corporate environment, its cloud controls and its pitch decks, and the part that makes him useful to this audience is that a16z sits close enough to its portfolio companies that founders bring him their security problems directly.
So host Jon McLachlan starts there. When does a startup make its first security hire, and when does that become a head of security? Yash separates the two hard. The first hire is a staff or senior staff engineer who can work independently, someone in the code and the infrastructure rather than someone building a team, and the trigger is a risk decision about what data you hold and what happens if it walks. Headcount has nothing to do with it. Where that person sits matters as much as when you hire them, because an engineer without enough context and access can’t execute. The head of security comes much later, when the company is big enough to need a dedicated leader in the seat.
Then the sales version of the same question, which is the one founders feel first. A big client asks for a call with your security leader, or for a named contact they can reach in an emergency. Yash’s answer is that this is the wrong moment to go hire a head of security, and he lays out the 2 routes he’d take instead. Fractional CISOs come up, and he calls them a good resource for jumpstarting a program.
The middle of the episode is AI, and he does neither the optimistic version nor the doom version. The security market is saturated with vendors, he says, where every feature of what ought to be one suite is its own company, and for the first time in his career he can’t tell you how long consolidation will take. On offense, AI is good enough at working through known vulnerabilities, the published Common Vulnerabilities and Exposures (CVE) list, to overwhelm a defense, and the cost per exploit is falling for the attacker. His forecast is 12 to 18 months of painful catch-up, after which whole classes of vulnerability and whole categories of tooling stop being necessary. What he wants gone specifically is code security. Static application security testing (SAST) and software composition analysis (SCA) exist because humans write insecure code, and if agents are writing most of it, he’d like them writing it securely by default.
His real worry sits outside the valley. The rate of AI adoption here is nothing like the rate anywhere else, and attackers ramping up on AI don’t have to come to Silicon Valley to use it. The companies that haven’t adopted, or that can’t afford the tokens to build a defense, are the ones on the other end of that curve. He puts it plainly. The cost of not adopting AI is higher than the cost of not adopting anything that came before it.
Jon takes it to agents, and this is where the episode earns its title. Prompt injection is unsolved. The defense everybody points at is the accept-this-action prompt your coding agent throws up before it does something, and his read is that it stops functioning around the third click, when people click through without reading. So a16z adopts AI fast and scopes it deliberately instead. For an AI tool, the vendor review he cares about starts with what the tool can reach, and whether that connection writes back or only reads. The pen test and the questionnaire still get run, and on an AI tool they aren’t where the risk sits.
The other half of that is a rule about how his team answers requests. They don’t say no, because a no costs you twice. Whoever asked stops asking you, and uses the thing anyway.
Also in this one. Why the security teams of the next 2 years live much closer to the code, and what changes when a finding stops being a list of packages to upgrade and becomes a pull request one agent opens and another reviews. Where testing goes once the code layer is handled, and why business logic is the part AI is worst at. The return on investment conversation nobody has solved, including his own example of the same task costing wildly different amounts depending on how fast you asked for it. Why he doesn’t expect the frontier labs to be the ones who show you that price. What a16z’s actual AI mandate was, which had nothing to do with spending more. One cryptography course in India that turned into a master’s at Johns Hopkins and 15 years in the field. Why his proudest moments are other people’s promotions, and the correction he makes when Jon calls that giving back. The job he left in under 2 months. And why he’d decline the meeting with his younger self.
He’s hiring, and he says so on his way out.
Hosted by Jon McLachlan — co-founder of YSecurity.
Watch the full interview
Topics in this episode
Key takeaways
-
Your first security hire is a staff engineer.
Yash Kosaraju's rule is that the first security hire at a startup is a staff or senior staff engineer who can work independently in the code and the infrastructure. The timing is a risk decision about what data you hold, how many customers you have and what's at risk, and the head of security who builds a team comes much later.
-
Treat the buyer's call as a sales signal.
When a big client asks for a call with your security leader or a named contact for emergencies, Yash ties the hiring decision back to what's at stake, the data you hold and the access you have into the customer's environment. By the time deals get that large he'd ideally have a team, then grow the head of security into the CISO role or bring in a field CISO, and he calls a trusted advisor or a fractional CISO a good resource for jumpstarting a program.
-
Nobody reads the third permission prompt.
Prompt injection is unsolved, and the defense everyone points at is the accept-this-action prompt an AI agent shows before it acts. His read is that people stop reading it around the third click.
-
Scope what the tool can reach.
For an AI vendor, the review he cares about asks what data the tool can access, how it accesses it, and whether the connection is read-write or read only. The pen test and the security questionnaire still run, and on an AI tool they don't answer that question.
-
His team never says no.
A no leads to 2 things, in his words, the person never comes back to you and they find a way to use the tool anyway. So the team works out the use case and defines access to the right data for it, with a proof of concept getting a subset of test data.
-
12 to 18 months of pain, then whole categories of tooling go away.
AI is good enough at working through known vulnerabilities to overwhelm a defense, and the cost per exploit is falling for the attacker. His forecast is a painful catch-up period after which classes of vulnerability and classes of tools stop being necessary. The one he most wants to see go away is code security, because he wants coding agents writing secure code by default.
-
Silicon Valley is a bubble.
The rate of AI adoption in the valley is nothing like the rest of the country or the world, and attackers don't have to target the valley to use it. The companies that haven't adopted, or can't afford the tokens to build a defense, are the ones he worries about.
-
Nobody has solved what an AI task should cost.
His example is the same task finishing in 10 minutes for around $250 or in 15 minutes for around $50, depending on the model and the mode, and he doesn't think the frontier model providers have the incentive to show you that price before you run it.
Pull quotes
“It's mostly a staff level, senior staff level engineer that can be independent, but isn't your true head of security person who's building the team.”
“You could get either an advisor that you trust or a fractional CISO who can come in and jumpstart your program.”
“The security space is saturated with vendors. We at some point need a consolidation to a very few ones that do more than just one feature.”
“I'm looking forward to the day where all these coding agents write secure code by default.”
“My hope is that we have this next 12 to 18 months of pain where again we are playing catch up, but much more rapidly.”
“We are here in the Silicon Valley and that is a bubble. The rate of adoption of AI is very different here than the rest of the US, than the rest of the world.”
“The cost of not adopting AI today is much more than the cost of not adopting any other previous technologies.”
“Prompt injection is an unsolved problem. After the third click, you don't really read what's in there and you just start clicking through.”
“The bigger issue here is what data do you have access to? How do you access it? And is it a two-way read-write or just a read?”
“Not to say no when people request for something. That'll lead to two things. One, they'll never come back to you. Two, they'll find a way to use it anyway.”
“I'm not doing it to give back. That's what gives me the satisfaction from my job.”
“There is one way of finishing the same task in 10 minutes that might cost you $250. Or it could take you 15 minutes and cost you only $50.”
About the guest
Yashvier Kosaraju, Chief Information Security Officer, a16z
Yashvier Kosaraju, who goes by Yash, is the Chief Information Security Officer of a16z (Andreessen Horowitz), based in the San Francisco Bay Area. He joined a16z in 2026 after 4.5 years at Sendbird, where he was the company's first CISO, and before that he led product and infrastructure security at Twilio and worked in application security and penetration testing at Box. He holds a master's degree in security informatics from Johns Hopkins University. His team is hiring.
a16z ↗ LinkedIn ↗ Open roles at a16z ↗
About the host
Jon McLachlan is co-founder of YSecurity, the on-demand cybersecurity team for startups, and of Cyberbase.ai. The Security Podcast of Silicon Valley is hosted by Jon McLachlan and Sasha Sinkevich. Jon McLachlan on LinkedIn ↗
Context and sources
- Yash Kosaraju's LinkedIn headline reads CISO@a16z and lists Andreessen Horowitz and The Johns Hopkins University. Jon introduces him as the CISO of a16z at 1:22 and he doesn't correct it. Source ↗
- His own LinkedIn post of April 2026 marks the end of 4.5 years at Sendbird. Source ↗
- A K logix profile lists him as Sendbird's first CISO, after almost 4 years at Twilio, where he rose from manager to interim director of product and infrastructure security, and more than 3 years at Box in application security, penetration testing and vulnerability management. It also names his master's in Security Informatics from Johns Hopkins and the college cryptography course that got him into the field. Source ↗
- Twilio's blog author page describes him as interim Director of Product and Infrastructure Security at Twilio. Source ↗
- He mentions at 36:27 that he's hiring. a16z's own jobs page lists two security roles in San Francisco, a Staff Security Technical Program Manager and a Staff Security Engineer for the AI and Security Platform (checked September 23, 2026). Source ↗
- Prompt injection as the term is used on the show follows the OWASP Top 10 for Large Language Model Applications, entry LLM01. Source ↗
- The CVE list he refers to at 11:39 is the Common Vulnerabilities and Exposures program. Source ↗
- Black Hat, mentioned at 7:46 and 8:13, is Black Hat USA, held in Las Vegas each August, and the CISO Summit is its executive track for security leaders. Source ↗
Transcript
Generated automatically from the episode audio and lightly edited for names, terms and readability, with the sponsor messages left out. Timestamps match the player above and the YouTube video. If a line matters to you, check it against the audio.
Read the full transcript 5,557 words
[Sponsor message from YSecurity]
Hello everyone and welcome to another episode of The Security Podcast of Silicon Valley. I'm your host, Jon McLachlan, and today we have an amazing guest joining us, Yash Kosaraju, the CISO of a16z. What a treat to have you on the show.
Thanks, Jon. Thanks for having me.
So, at a16z, you're responsible for actually locking down and securing all of the corporate environments and all of the sensitive information and all of those juicy pitch decks. And responsible for those corporate security controls, and I'm sure all of the cloud security controls. And I bet that keeps you super busy, huh?
Yes.
And I know a lot of our listeners here are very familiar with a16z, for sure. A lot of our listeners are founders themselves, interested in the investment community, the security community in general. How long have you been with a16z?
Technically, it's been 4 months, but it feels like about a year.
Startup years, right? Like, something like that.
Yeah.
What's the energy like over there in a16z right now?
It's very high, electric energy. Everyone's excited. I get to build on security with all the new technology that's coming up. So, it's a great time to be here.
Do you get a lot of inbound, you know, asks of, hey, are you a test bed for any of the a16z investments or the portfolio companies in the security space or anything?
I wouldn't call them test beds, but we are close partners for our portfolio companies. So, we do work very closely with them, and we could be customers. But either way, be it as a customer or as an adviser or just helping them make the right hires, think of the problem space in the right way, we are there to help.
What's one of the more common questions that maybe a founder might have for you?
It ranges. Again, in the short time I've been here, I've had a wide variety of conversations with founders. If they're in the security space, it's helping view the product from an enterprise security team or security CISO lens and talk through that. Other portfolio companies could be from hiring their first CISO, hiring the first security hire, helping them prepare for a big customer security audit, your traditional compliance audits, anything. It's a long list.
So there's a lot of B2B business deals being made, it sounds like.
That's the hope.
And so what's that signal? What does that look like for, you know, it's time to go hire your CISO? It's time to bring in that first security hire?
Those two are very different. So let's cut this down, right? So when you look at the first security hire, it's mostly a staff level, senior staff level engineer that can be independent, but isn't your true head of security person who's building the team. This person's more in the weeds, in the code, in your infrastructure, hardening things, building things out. That comes fairly early. I'd say it's a risk decision between what data do you have, how many customers do you have, and what's at risk. And that drives how early on you need to hire your first security engineer. And where this engineer sits is also something you need to decide. Could be within the infrastructure team, any other engineering team, right? So again, put them in a place where they have enough context and access to just execute. Moving on to your first head of security, that comes much later, right? Like, as your team grows, where you decide you need a dedicated presence of security within the organization and you need a leader in that space, and that's when you start thinking about head of security roles.
Are there certain signals that maybe come in from your sales team, or that you can listen for in the market, that are sort of those trip wires of, like, oh, this is the time, where's that CISO?
That's a great question. So you will have your sales signals. Some of the bigger clients would definitely ask for one, either a call with your security leader or a dedicated point of contact that they can reach out to for emergencies, and just sort of showing that you have a mature security posture does require somebody with that title. However, that's probably not when you're hiring for your head of security. That's somebody who would build that team for you. So, I'd still tie that back to what are you protecting, what's at risk, what's at stake, what data, the volume of data, type of access you have into your customers' environment, and sort of balance those two out. Ideally, you have a team, and maybe a head of security, by the time you get to these multi-million, really large-scale deals where they do start asking for a CISO. And then you can decide whether you want to build your head of security into that CISO position, or maybe get a field CISO to answer some of those questions.
Do those fractional CISOs often come up as a possibility, too? Or is that a common place to start for a lot of entrepreneurs, to maybe pull someone in part-time?
That's a great resource. You could get either an advisor that you trust or a fractional CISO who can come in and jumpstart your program as well.
What's the most exciting portfolio company in that security space that you've got the honor and pleasure to have collaborated with a little bit? Is there any in particular that really...
There are a lot of them that are in the security space, and they're all in different levels of maturity. It's hard to pick one, but there's a lot of ones that are sort of taking on either existing problems or new ones, and putting a different spin and a different lens on how they want to try and solve it. And it's always refreshing to see newer, better, user-friendly solutions to age-old existing problems.
Yeah, I get very excited about using new technologies and interesting new ways to help make the world a better and more secure place. You know, when you look at the landscape out there of new technologies, AI comes, like, screaming top of mind, right at the top. And I don't know if you were at Black Hat. Did you go to Black Hat?
I was at the Black Hat CISO Summit.
Amazing. Amazing. There seems to be a lot of competition, but a lot of really great work out there in the intersection between security and AI.
There are really great... there are definitely great companies, but on the flip side, what I'm seeing is the security space is saturated with vendors. We at some point need a consolidation to a very few ones that do more than just one feature. Today, each feature of a bigger suite of features is one company. I'd like to see a world where we don't need so many vendors to do all of those things.
Yep. What do you think the timelines are for all of those consolidations to just, like, converge?
I mean, before AI, I could give you a number that I would trust myself to sort of back up, but now with AI, everything's accelerated. So, it's all up in the air.
So, it's going to be faster than we've ever seen before. If it hasn't already begun, it will. In terms of the AI, you know, that intersection between AI and security, what do you think will be the first problems that we solve as a security community?
We are taking a stab at multiple problems. However, the one that I'm interested to see completely go away is your code security, right? Like, you've had this whole secure SDLC pipeline with SCA and SAST and a bunch of other things in there. Now, with AI writing most of your code, I'm looking forward to the day where all these coding agents write secure code by default, and you don't need some of these features.
Okay, I love that. I love this direction. I was at a little CISO dinner here in San Francisco a few weeks back, and the tone of the entire dinner was just, like, assume breach, you know? Because AI is just a tool, and you can use it as an evil person or a good person. And when you use it as an evil person, like, okay, the foundation models are extremely powerful, can have a look at the code base, can have a look at third-party libraries that everyone's code is dependent on in some form or another, and start dropping in exploits and start dropping in zero days. And the tone in the room, you know, when I was at the dinner, was just very bleak. It's very like, oh, you have to assume that there's breaches that are going to happen and that the people are already inside your systems. And then, you know, forget your firewalls. They're going to breach the perimeters and the boundaries and all of that stuff. Anything exposed to the internet basically is going to break, if it hasn't already. It will, because the capabilities are, you know, democratizing, essentially, like breaking into software, breaking the application layer. And so I'm super happy to hear that you're excited about the other side of that equation, which is, like, the defensive position. Like, how do we use the same tools to actually fix things?
They're not wrong, by the way, right? Like, the whole thing where... well, there's two aspects to it. One, AI is really good at using all the different CVEs and exploits out there at a very fast pace, and sort of try and overwhelm the defenses to get in. So that's completely true. The other thing is the cost per exploit, or cost per breach, that as an attacker you have to then sort of be aware of, with AI would be going down. So the economic balance is going out of whack. However, my hope is that we have this next 12 to 18 months of pain where, again, we're playing catch-up, but much more rapidly. But once that evolves, you get to a place where some of these classes of vulnerabilities, or even some of these classes of tools that you have, would be redundant and not necessary, and it would become second nature to build a defense-in-depth, multi-layered approach. And everybody gets there together, screaming and kicking, but eventually you get to a point where we're much better off than today.
Yeah. And I imagine, like, a good chunk of that is just going to be, you know, using the latest and greatest foundation models and technologies to actually help us write code.
A lot of it will be, right.
Yes. 'Cause the vulnerabilities that are in the code, the application layer, you know, exploits, those are all, like, bugs, essentially, that have consequences in foundation models in the security space. But I'm not sure what percentage of software that's running has been written by, you know, foundation models or AI in general.
So, that's true. Yeah, there is a big journey everybody needs to go through. The thing that worries me, though, is we talk about all of these, but we are here in the Silicon Valley, and that is a bubble. The rate of adoption of AI is very different here than the rest of the US, than the rest of the world. So as the attackers ramp up their capability with AI, they don't necessarily have to target everybody in the valley, right? Like, the valley is going to catch up in its defenses relatively quickly. The rest of the world, the companies out there that haven't been embracing AI, or maybe don't even have the financial resources to spend on tokens to build their defenses, like, that's what I'm worried about next.
Maybe there are companies out there that are specifically geared towards helping those legacy or those long-tail, you know, adopters accelerate or defend their perimeters. But maybe not. Maybe that's where the challenge is, you know? But that's where most of the technology lives.
The cost of not adopting AI today is much more than the cost of not adopting any other previous technologies. And from a cyber lens, it's much more intense, what you're missing out on and how you need to protect yourself using AI.
And as this wave of adoption happens, it also feels like there's now another layer to the security cake, if you want to call it that, where there's now an AI layer on the very top of it, right? So if my coding agent, you know, is searching the web, is reading up on some API somewhere and executing, essentially, things on my local development environment, whether that be some remote thing in the cloud as an agent running on my behalf, or my local dev machine, maybe the agent is essentially now taking instructions from the internet, throwing them into a prompt, into an engine that has access to whatever it is that I have access to as a developer, and running it. And it just feels like a very familiar problem that browsers solved a long, long time ago, just by saying, you know what, anything that comes in from the internet, let's just treat it as untrusted. But now agents are doing this, and agents are treating it as a mixed bag, like levels of trust, and there's this human-in-the-loop discussion that's going on. I'm super curious, how do you see and think about it, as a CISO who's responsible for the security of an organization, a16z, who is no doubt, I'm sure, adopting AI very aggressively, right, and trying out all of the new things?
Yeah.
So how, as a CISO, do you approach that?
So you're right, prompt injection is an unsolved problem. The one perceived defense we have is sort of Claude or OpenAI giving you those prompt or user sort of interfaces that say, do you accept this request, or do you accept this action? The problem with that, though, after the third click you don't really read what's in there, and you just start clicking through. And that's the sort of defense we think is there, but not really. The way we are approaching it is being very careful of how we adopt AI. So we are adopting AI at a massive pace, but also very deliberately: the systems that it has access to, the systems that it can write to or read from, and what it can do. And sort of have your own vendor due diligence that obviously everybody does, but also, the bigger challenge with AI tools is not your vendor due diligence of, like, do you have a pentest or do you have a SOC 2, and all of those questionnaires. The bigger issue here is what data do you have access to? How do you access it? And is it a two-way read-write or just a read? So that's the bigger problem, and that's the bigger part of the review we do, because, as you know, AI is only as good as the data it has access to.
Context is everything. No, that's super interesting. And so it almost sounds like, instead of trying to control what's coming in into the space, you know, into the AI, and through inference calls, and ending up inside agents essentially doing things, like, scope what that thing is doing. Scope that. So define and be deliberate around, like, what that agent is allowed to touch within your organization, within your security boundary.
Yes. One thing we're very deliberate about at a16z, especially within the cyber team, is not to say no when people request for something. That'll lead to two things, right? One, they'll never come back to you. Two, they'll find a way to use it anyway, right? Rather than that, what we try to do is work with them, see what they're trying to do, and then define access to the right set of data for that use case. If it's a POC, that can have a subset of test data. If it's something else, then, you know, we work with them to see what kind of data is necessary to get to the point where they're going, but also keep the firm safe.
No, that sounds like a great approach. There are two different types of security folks in the world. You can walk into exactly the same meeting. Like, one type can walk into a meeting, and everyone in that meeting room will go, "Oh no, so-and-so is here," and they're going to say no to everything, and they're going to push the timelines out, and they're going to tell us we have to, like, do all of these strange requirements for these certifications that we have to uphold. And then the second person can walk into exactly that same meeting room with exactly those same people, and maybe even have exactly the same impact on security for the organization, but the people in that room will say, "Oh, I'm so happy that Yash is here. He's going to help us, like, understand what are our security commitments to our in-house goals and our customers, and how we can move quickly together as partners," instead of, you know, just saying no to everything and pushing timelines.
Exactly. That's the goal.
Yep. Yep. Culture means so much in the security space, especially if you want to be taken seriously, you know? So, I love that. I'm curious, though. You know, it's been my experience, you have to be a little bit crazy to get into security. You know, there's always a story there or something. What's your story? How did you get into security?
Mine's probably the most boring story you'll ever hear. You know, you'll hear all these crazy stories of, like, I hacked into something, or I did something, I got in. I went to college for security.
That's not crazy. That's not crazy. So your interest in security was there before you started at college.
So I did my bachelor's in electronics, and we had one course, cryptography, like, you know, the art of hiding data in plain text and so on, and that kind of got me hooked. And this was back in India. So from there, I came here to the US, went to Johns Hopkins for a master's in cyber, and from then, that's when I kind of got hooked into it. And that's been more than 15 years ago, and I'm still here, and the rest is history.
Wow. I'm sure you've seen a lot of crazy things unfold in your long and interesting career, maybe even at Johns Hopkins in graduate school.
Yeah, those 18 to 24 months were probably the toughest sort of 18 months that I had to go through.
I'm curious if you might be open to sharing what's been your proudest moment along your journey in the security space.
That is a deep question, and probably not something I was prepared to answer. Let's see. You know, that has changed over time, but there's a consistent theme to it. I'm more proud of instances where somebody in my team achieves something versus I achieve something. And that's why I still like building teams, building people, growing their careers. So when I see somebody who either used to work for me, who's now a CISO, or somebody's in a director-level position and they're doing great things, that makes me proud.
No, that's spectacular. That's one of the most rewarding pieces of, you know, being able to give back to the security community and being a leader like yourself. I'm also curious... Go ahead.
I'll be honest. I'm not doing it to give back. That's what gives me the satisfaction from my job. I do it for a very purely personal reason. I am selfish in that sense. But again, it is what it is.
No, that's great. That's healthy. I think it's important that we know what we want in this world and that we go for it. Like, that's what ambition is, right? I feel like there's maybe a reference there to some Ayn Rand philosophy.
No, not quite. Yeah, I went through this sort of old thought process of, like, am I doing this for somebody else? Is this my way of giving back? And at some point I realized, no, this is what helps me get meaning from my life, right? And that is helping others. So, like, even though it does seem like I'm giving back, it starts from a purely selfish reason.
Yeah. No, it's important to know who we are and to know what we want, and I respect that. That's very important, because if you love what you do, you're never going to work a day in your life.
Yes.
You absolutely can enjoy it, and you'll make everyone's life better around you. It'll just happen naturally if you're enjoying what you're doing and you really sink your teeth into it and you dedicate yourself to something. So, it doesn't need to be security, right? Could be anything.
I appreciate that.
I'm curious if you would be open to maybe venturing through your long and interesting, you know, career in security, and might be open to sharing what was maybe one of the more challenging moments.
I did take on a stint after my time at Box that I was there for a very short period of time. Again, these are things that I didn't go deep into in the interview process. So when I joined, I quickly realized that is not what I expected. It was very different, and it was a very tough and honest conversation to have with the team there, but I was there for about less than 2 months. And that was challenging, because it was a big process to go through, leave a team that I trusted at Box, and then go there, and then have to get out of it, and then figure out what's next.
Oof. Yeah, those can be tricky situations, but props to you for not letting it dangle. Like, 2 months, that's very fast to go for the realization and the process and acceptance, and moving on to the next thing. I'm very curious what you think the most challenging problem that the security community might face in, you know, the next 5 to 10 years.
5 to 10 years in the age of AI is probably a question that's around 20 to 30 years on a normal day. So let's cut that back, right? Next year, next one to two years.
Yeah.
So, yeah, the amount of visibility security is getting these days, just because of how AI is able to exploit all the CVEs, that's going to evolve how engineering, security and the rest of the organizations work. So the security teams will have to evolve from what they have been to much more proactive, much more in the weeds. You know, I don't think we can, as an industry, still come up with a list of, here's all the... as an example, here's all the packages you need to, I don't know, upgrade because of the vulnerability. We'd have to evolve to a much more close-to-code state, where you find them, you figure out if it's vulnerable, exploitable, reachable, all of those things, create a pull request, and then make sure it's also not breaking anything. And then probably your agent does this, and then the engineering agent reviews it and patches it, and, like, that's the stage we need to get to, where a lot of it's much more automated. We've talked about a lot of DevSecOps or SecDevOps, like, pick your term for that, but this goes much deeper, much more autonomous in that sense. And a lot of testing today is more at the code level. I believe that will now go into your build and test level, right? Because your agents will take care of most of these patches. But once the code's in dev or stage and you need to, like, test those out, that's going to come back again, where a lot of those testings, a lot of those business logic flaws, which AI isn't as good at as it is with your code, that's where the bigger focus is going to be on.
Yeah. Yeah. I couldn't agree more. And, you know, to put that into context a little bit, one of the big things that I see when organizations are considering adopting AI is the cost, and sort of articulating the business case for the ROI, and the expectation, managing expectations, and the token cost and all of that stuff. And like we mentioned before, context, context is king. Context is going to determine, like, how successful you can be, but it's also a direct impact on your cost, too. And so I'm curious, like, how do you think that's going to play out? Do you think, like, the ROI and the expectations are going to have to be throttled back in the short term? Or are you seeing, like, adoption being more aggressive, to take more risks with the ROI being factored in?
My hope, like others, is that the token cost would come down. But on the flip side, what I'm seeing is we're not good at estimating what each task we're giving an AI agent would take. The way I'm looking at people use AI is, one, they want the latest and greatest model. Two, they want the fast mode and not the slow mode. So there is one way of finishing the same task in 10 minutes that might cost you $250, or it could take you 15 minutes and cost you only $50. So we need to get better at estimating what it takes to get something done and what the associated dollar value will be, and making that decision of, like, is it worth that amount that I'm spending, and sort of tweak and balance it out, where the return on investment actually makes sense for the economic resource you're spending to get that thing done.
It's almost like, pick your favorite AI tool, maybe, like, Claude Cowork, just as a crazy example. If there was a little dollar sign that told you how much that prompt was going to be before you clicked it, if you chose, like, whatever your model, whatever your context engine, how much crap you had in your chat, a little dollar sign that made you, like... like you're buying something, 'cause honestly, that's what you're doing. You're buying something. You're buying some compute, right?
I don't think the frontier models have the incentive to do that for us.
Of course not. Of course not. They're going to hide it. They're going to let all of the engineers and all of the business leaders and the MBAs and the CISOs just use this amazing new tool that magically spits out these pretty good answers, you know, honestly. And then just invoice at the end of the month, like a nice 10-figure invoice. You're like, "What? Excuse me?" [laughter] Yeah, that's funny. But yeah, that's something that I've noticed in the world of AI adoption. If you're a founder and you're building an AI thing, you have to talk about ROI. It's part of the equation now for getting your thing adopted in the security space, or any space, really.
A lot of the tools that have AI baked in, they get extremely expensive, too. I do see a world in the nearby future where they would have multiple sort of models to choose from. Maybe the one that came out 2 months ago is only 95% as accurate, but 50% cheaper. So giving that toggle to the end user to sort of pick and choose between those parameters, where the cost can come down drastically than what it is today. And that could be between your different sets of frontier models, or maybe even open-weight models that the vendor has hosted on their infrastructure, and that way the cost would come down.
Yeah. Yeah, it's interesting. We'll see what happens. I've always thought of problems being solved, you know, or at least being motivated first by the people who feel the pain directly. And so the people who feel the pain directly are the financial people. Like, that's going to be internal friction between finance and engineering, as opposed to, like, maybe a more bottom-up model where engineering could feel the pain. It'll be really interesting to navigate and see what happens in that space. How do you keep your org under control? Because I'm sure, like, you use a bunch of AI to help solve a lot of the problems, and have an amazing team that I'm sure is accelerating themselves with all sorts of AI.
Yeah. Not only just my organization, but the whole company is very AI-forward in that sense, and we have started talking about how do we start measuring ROI? How do we start educating people on what the right model, the right speed is for certain tasks? And that's something we have started talking about within my teams as well: how do you balance what you need versus how long does it take versus what does it cost, and get to a middle ground where you can say, well, if I know it's costing me X dollars to get Y done, then I, as an engineer, can then make that decision whether it's worth that Y dollars or not.
Yeah. And in organizations that I would call, like, aggressive adopters, conversations usually are, like, more along the lines of, hey, why aren't you using AI more? Could you please spend more? Which is backwards, I think, from what companies will usually ask, right?
That's been the very interesting thing with AI. But a16z was never that way. We gave people all the tools to experiment, but the mandate was not token maxing or go spend money. The mandate was, here's a bunch of next-generation tools. Try them out, use them, see where they can add value. And it's pretty much the same thing, but said in different ways. And just that change of words gives you a different perspective. The mandate is not to just use it for no reason, but try and see what actual value you can get out of it.
Yep. Yep. Exactly. Value-driven use, and identifying that ROI, cashing in on it. I'm super curious, if you would be open to venturing into the past, and you could imagine having an opportunity to meet your younger self. I'm curious if you would meet your younger self, and if you would take that opportunity, what advice you might have for your younger self?
This is not the first time I've been asked that. I've had different answers every time that question came up. I guess today, what I would say is, maybe I wouldn't meet my younger self. And even if I did, I wouldn't give any advice, because every mistake I've made, every decision I've taken is what has led me here today. And changing any of those, even for the better, you don't know what implications that has.
That's a beautiful sentiment of self-acceptance and embracing, like, the amazing person that you are today.
I am fortunate to be in a very good place in life right now. I have a great job. I have a great family. I'm healthy. So again, I wouldn't change anything.
Well, very good. Very good. Thank you so much for your time today. This has been an absolutely wonderful discussion. Thank you for the honesty. Would you leave our listeners with any final words of wisdom? We do have a lot of entrepreneurs, and I'm sure, like, you'll get a lot of lessons from folks bubbling around with different ideas, interested in the security space.
I am not an entrepreneur, so take this with a grain of salt. But it is a great time to be building, and whatever you do, pursue your hard work. Those will get you through all the tough times. And good luck.
Huge thank you, Yash, for joining, and a huge thank you to all of our listeners for tuning in to another episode of The Security Podcast of Silicon Valley. If you are so inclined, if you enjoyed this episode, please comment, share, like, if you feel so inclined and you feel it's worthwhile, and all the gratitude in the world. Huge thank you.
Thanks, Jon. Oh, I'm also hiring, by the way, so please do look at the jobs and apply.
Yeah, please check out Yash's team over at a16z and send your resume to him. Connect on LinkedIn. We'll put all of the good links in the show description for everyone's convenience. This has been a YSecurity production, and stay tuned for the next episode. Thanks, everyone.
[Sponsor message from YSecurity]
FAQ
Questions this episode answers
- When should a startup make its first security hire, and who should it be?
- Yash Kosaraju, CISO of a16z, says the first hire is a staff or senior staff level engineer who can work independently in the code and the infrastructure, hardening and building, rather than a head of security who builds a team. The timing is a risk decision driven by what data you hold, how many customers you have and what's at risk, and the engineer should sit wherever they get enough context and access to execute.
- What should a founder do when an enterprise buyer asks to speak to their security leader?
- Yash treats the request as a sales signal and ties the hiring decision back to what's at stake, the data you hold and the access you have into customers' environments. By the time deals get that large he'd ideally have a team, then grow the head of security into the CISO role or bring in a field CISO, and he calls a trusted advisor or a fractional CISO a good resource for jumpstarting a program.
- Why does the accept-this-action prompt stop working as a defense against prompt injection?
- Prompt injection is an unsolved problem, Yash says, and the one perceived defense is the interface that asks whether you accept a request or an action before the agent proceeds. After the third click people stop reading what is in the prompt and click through, so the defense everyone assumes is there isn't doing the work.
- What should a vendor security review of an AI tool check?
- Yash's bigger question for an AI vendor is what data the tool has access to, how it accesses it, and whether the connection is two-way read-write or read only. The pen test and the questionnaire still run, and on an AI tool he treats access scope and write-back as the risk that matters, because AI is only as good as the data it has access to.
- Why does the a16z security team never say no?
- Yash Kosaraju's team is deliberate about never saying no to a request, because a no leads to 2 things. The person never comes back to you, and they find a way to use the tool anyway. Instead the team works out the use case and defines access to the right set of data for it, so a proof of concept gets a subset of test data.
- How is AI changing the economics of attack and defense, and how long will the catch-up take?
- Yash says AI is good enough at working through known vulnerabilities, the published Common Vulnerabilities and Exposures (CVE) list, to overwhelm a defense, and the cost per exploit is falling for the attacker. His hope is 12 to 18 months of pain in which defenders catch up much faster than before, after which whole classes of vulnerability and categories of tooling stop being necessary.
- Why does he say Silicon Valley is a bubble on AI risk?
- The rate of AI adoption in Silicon Valley is very different from the rest of the country and the world, Yash says, and attackers ramping up on AI don't have to target the valley to use it. The companies that haven't adopted, or can't afford the tokens to build a defense, are the ones he worries about, because the cost of not adopting AI is higher than for any previous technology.
- How much should one AI agent task cost, and why is it so hard to estimate?
- Yash's example is the same task finishing in 10 minutes for what might be $250, on the latest model in fast mode, or in 15 minutes for what could be $50. People are bad at estimating what a task will take, he says, and when Jon asks for a dollar sign next to the send button, Yash doesn't think the frontier model providers have the incentive to build it.