EP274 AI, Zero Trust and Secure by Design Walk into a Bar...

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here as ever are myself, Tim Peacock, the Senior PM for Threat Detection and a bunch of other stuff in Google SecOps. And of course, Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. Today, we're also joined by special guest Waffles, who who is very happy to be here with us. So listeners, if you're on video, you get a bonus corgi to open today's episode. If you enjoy our content and want it delivered to you piping hot, please do hit that subscribe button in your podcasting app of choice. If you want to join us on video, you can join us at youtube.com/@CloudSecPodcast with, of course, bonus corgis. If you want to argue with our other listeners, you can check us out at the Google Cloud Security Community site. Anton, what are we talking about today?

So initially, I figured since my dog cannot be here, I have to kind of match Tim's move, but all I have is the AI agentic sweater. It's technically a Christmas sweater, so it's a little past that, but it does say AI agents. So I think it's a good 2026 sweater. What do you think?

Is it topical for today's show?

It is topical because AI is topical for pretty much every show, but I think it also—

Oh, no.

It has some zero trust in it, right? I think that I Let me check my sweater. It probably mentions Zero Trust somewhere.

That's a throwback. Do you have a Zero Trust sweater as well?

I do not have a Zero Trust sweater. I do have the Cloud Detection and Response sweater.

Ah, you have zero Zero Trust sweaters.

I have zero Zero Trust sweaters. Correct.

Very sad. Listeners, let us know if we should fix Anton's supply of Zero Trust sweaters, or if that's too passé at this point. Maybe without any further ado, let's turn things over to today's guest. Today we're joined by Grant Dasher, Distinguished Engineer in GCP Security. Grant, we are so happy we're finally making this episode happen. This is, listeners, one of those episodes that Anton and I designed first when Grant worked at Google, then we got excited when Grant was at CISA, and now we're excited now that he's back at Google. So, uh, this is great. It's been a long time coming. I want to start off by talking about secure by design. And where has that come from? Is that literally just like, Bolted on didn't work, so now let's try this? What's the story here?

Yeah. So my perspective is, going back years and years, there's been questions about, okay, we have this technology software, how do we use it to build things in the world? And even going back to the '80s and Air Force research studies, there's been an understanding that there are issues in security involving computers and, hey, maybe we should care about those. Or not.

We're not.

We're not, right?

We're not, right? But, you know, and for me, right, it goes back, my wife's an engineering education professor. Like, I've, you know, got a background in engineering of a sort. And, and I think, you know, as a society, going back to the Romans, right, we have like an understanding about how to, you know, design systems to manage against a set of constraints. Those constraints could be physics, laws of physics. How do you make a bridge that doesn't fall over? Or they could be constraints based on some model about how people engage with the system in the world. And that's really where secure by design comes from for me is like, how do we take this body of knowledge that we have about applying concepts of engineering, a set of assumptions about the fact that we use software in really critical places in the world, right? We use it to power our telecommunication systems, our power grids, our hyperscale cloud providers, enterprise software that manages large—

Pacemakers.

Yeah, pacemakers, capabilities that manage large swaths of the economy. Right? And so, we assume that there are people out there, they have goals that maybe aren't aligned with the goals of an organization that's using technology. It could be commercial goals, could be political or national security goals. When those goals come into conflict, issues involving security, you know, tend to come up. But really, like, we have a body of knowledge about how to apply and constrain and design systems against a set of constraints. And if we apply that in the context of security, we can make the job of people who have objectives that aren't the objectives that we all have a little bit more difficult. And that's really what I think secure by design is trying to do, view security as a property of construction of systems in addition to an operational function. The operational function still needs to be there, certainly, but we can help it out by making the systems themselves more secure, more difficult for the adversaries, have less vulnerabilities, more understandable. And I also think, frankly, more reliable. What we've seen is a lot of cases where the same engineering practices that you'd wanna apply from a security point of view also improve the overall reliability and performance of the system. So, there's a nice synergy there in terms of just building better systems, which also happen to be more secure. And so, that's really where I'm coming from. And I think some of the other folks who are passionate about secure by design, which comes under different names depending on who you talk to, But that's really all sort of spiritually where I think we're coming from.

So let me ask you a strange question. So all of it makes sense. Of course, it makes sense to me, to Tim, to most of us at Google. But I imagine a fairly realistic picture of a senior leader, maybe even a CIO, who listens to everything you said. He agrees. And then he says, yes, but I have this spray can that says security. And I can spray it on the finished product. And I can just achieve the same, everything that you just described, because I sprayed it from a can, from a vendor that says, spray on security. And what is the argument that you'd make to tell them, no, it doesn't work like this because, like, what would you say? I've met those people, by the way, who agree with the goals. They just assume that spray can works. Sorry, I drink my spray can, I apologize.

Oh, for sure. I mean, you know, absolutely. And I mean, I would say part of it is, look, there's a large security industry, right? Various companies, including Google, participate in the security industry. I think there is a decent amount of value that is being delivered to organizations by products in that space. There's also, frankly, a lot of snake oil salesmanship going on in the broader security industry. And so, I think the first thing the CIO should say is like, hey, you know, what is the actual problem that this piece of technology is solving? And is it a problem that I have, or is it a problem that's better solved in a different layer? So, I'll give you an example. So, you know, why is it that there's such a close connection between security and networking? Well, it's because networking is the common foundation on which all IT is built, and it was a hook in which security could be applied in a way that was uniform across a hyper-heterogeneous architecture, right? I used to joke that, like, You could fingerprint systems by, like, oh, this one's using JBoss, and this one's using Apache whatever, and this one's using, you know, this set of technologies. And, like, every system in an enterprise would have a different fingerprint when you combine the different layers of the tech stack together. And when you're in an environment like that, you know, there's only so many tools that you have, and the network is very appealing, and the idea that I can just solve all the problems by sort of peeking up from the network is really nice. Unfortunately, it's limited, right? The ability to use that is limited. And while for some organizations that are, you know, their business does a certain set of things, like, the kinds of capabilities they need from a security point of view are not super complicated. There's a difference between the rigor that you should apply to the balsa wood structure that you build in class and, like, the Golden Gate Bridge. And my point is, especially for organizations that are operating Golden Gate Bridges in cyberspace. It's really important that they're invested in the secure construction of their systems and the vendors that power the IT for those companies in order to be selling into that market should be building products that can be composed and used securely without someone having a PhD in software engineering in an enterprise organization to be able to sort of make that all work.

But they also have to believe that it is not achievable by spraying at the end. I think that you convince them that it's needed and it's achievable in advance, but how do you convince them it's not ever achievable at the end?

Yeah.

I mean, look, I think the history of, frankly, the cybersecurity industry is pretty strong evidence that that is the case, right? I mean, we have been selling these products, selling the spray cans for a long time. The number of vulnerabilities continues to go up. The number of incidents continues to go up. The financial impact of cyberspace continues to go up. The fears, frankly, of national security cyber events continues to go up. You know, we are— my colleague, former colleague at CISA used to say, you know, the maturity of the industry is similar to the world of private fire departments where essentially you would pay your private fire department in order to fight your fires instead of, you know, having standards for building the products in a more secure way. And so I think—

Mm-hmm.

Just frankly, the history of failure, I think, is pretty compelling that, you know, this approach is not working and that we do need to make a pivot. And changing the demand calculus is an appropriate way to incentivize the broader vendor community to take those steps.

I think that makes sense. And I think that there's also a side argument to this sometimes that people for newer domains, and I guess the words AI would show up way earlier during this episode, and The question is, there's also examples where secure by design is decided later by consensus, by committee, by, you know, IETF or OASIS or whatever. And some people want to move fast, but they're building AI-powered or even AI systems. So, for firewall configuration, actually, for firewall building, we know how to do secure by design. We just choose not to do it in many cases, you know, reference to some vendors.

Mm-hmm.

For AI, we may not know, and people wanna move fast. So, what's your advice on secure by design to people who have to go now, who have to run?

Yeah. No, I mean, it's good. So, I mean, I would say a couple of things. One is, like, what is the application, and, like, what is the risk profile that we're talking about, right? You know, I would argue that, you know, the risk profile of a large telecom provider, of a, you know, the lower critical, mission-critical elements of a hyperscale cloud provider, of another critical infrastructure provider, is just different from the risk calculus, for example, for many startups, or even the higher layers of a cloud provider that are providing, for example, vertical-specific solutions that are targeted in certain respects or general capabilities. And so I think the first question is like, okay, what is our risk tolerance in a particular area? And I think that can vary. But the second, with AI specifically, is from my perspective, how do you want to sort of create a space where we can move quickly with a limited sort of collateral blast radius? And I have, I think, consistently underestimated AI for many years. Right. I will freely admit that. I remember vividly a conversation with a former manager of mine in maybe 2012. He was working on Google Image Search at the time. He was pitching an idea that we should generate images automatically using diffusion models and use that to answer people's queries. And I just sort of laughed. I was like, not in my lifetime.

Yeah.

Took 5 years, right? So clearly underestimated that. And so I think it's a balance, frankly. And my perspective, I think, is a little controversial in the community, but my perspective is, at least where the technology is now, it makes sense to have deterministic boxes that we bound in some way. And so there's a lot of investment, for example, from the Google Cloud side in providing policy and security and identity capabilities to create some sort of a set of deterministic guardrails around which, say, AI agents can do things without, for example, being able to delete your database or mutate systems in unexpected ways. We can limit to a certain scope of permissions. Now, unfortunately, these are not new ideas, right? The idea that you should manage your identities in this way has been around for a long time, and there are operational challenges, frankly, in doing it in organizations. And one of the reasons why it isn't necessarily always done is because it's hard. It's operationally hard. And, like, maybe only the most mature organizations would even attempt to manage identity and access in that way. And what I would say we're seeing is, you know, there is a larger number of organizations now that are like, hey, that sort of advanced level of maturity we would call it zero trust maturity level advanced in terms of identity and data management. I think I want that now because of my perception of the risks of some of these new agentic workers that we're bringing into the organization. I think that's a reasonable perspective for a security-focused person to take at this point. Now, I also think—

So is this possible, though, with agents? The argument I've heard is that agents, by the nature of mixing Their control plane and their data plane, their prompting and their prompting are kind of like payphones in the '60s. The control tones are the same as the voice tones. So how do we— A, do you buy that line of reasoning about agentic systems? And then B, what do we do about it when we're mixing our data and our instructions?

Yeah, I mean, so I think it's a fascinating area. I think it's still sort of an unsolved research question. I do like this analogy, right? I mean, people talk about the difference between a von Neumann architecture and a Harvard architecture, and I think the Parallel, if you look at how a stack in a computer works, is pretty remarkable. If you sort of think about it, your agent is really fundamentally like a sequence of tokens that's being processed. Some of those are control tokens, some of those are data tokens. You talk about all these attacks that sort of mix them. It's the same basic thing at some level as the problems that we faced with exploits of memory unsafe programming languages where you are you know, exchanging data and instructions and getting the processor to execute data as instructions, you know, because of the way that the von Neumann architecture of a normal computer sort of mixes the stacks together. And we've, in that context, built technologies, you know, no-executable stacks, instruction tracking, all these control technologies. There's been an arms race between— many, many PhDs have been made in this arms race between researchers and— I think that's— and attackers, blue and red team, to figure out how to do this. I think we will go through a similar exercise within the AI model community. I think that will continue to happen. I am not a machine learning AI expert, but I expect that that will continue to happen. And I even think as we get into a world where more AI is doing more of the development of AI, there's interesting ideas for how you can AI operating from one perspective can push you in a certain direction and mixtures and all these things. So I think that line is very interesting. But what I was suggesting is, at least right now, there's something else we can do too, which is a lot of these agentic systems have a sort of quasi-nondeterministic core, right?

But they also have a quasi— Why quasi? Wait, wait, wait. That's actually sort of being a little petty, but it is nondeterministic.

I mean, if the temperature is zero, it will do a predictable thing. Fair enough. Yes.

Yeah. Okay.

If the temperature is zero, it's predictable. Yeah.

It is certainly— I think it's fair to call it non-deterministic. But in any event, I think at least where I see things today, it is reasonable to sort of put a deterministic box around that, which is written in the form of traditional software. Now, maybe AI helped you write the software, but it is a deterministic program. It has certain limits that it places on the behavior of the system that could manifest as, like, proxies and filters, like, very networking style. And people talk about agentic gateways and these kinds of things. But it can also manifest as just, like, the agent has a credential, the outer scope of permission that that credential can do in terms of what it can access, is limited and is tied into a sort of more mature enterprise data architecture. And so I think those pragmatic constraints, you know, don't get me wrong, they're not easy, but like they are tools. We do understand them. Organizations at a certain level of maturity have effectively employed them. And I do think they can put some limits on the risks here. But I also think within the world of AI, you know, like, yeah, I mean, we've mixed control and data together very fundamentally. I think separating that in a way that the math works with, I don't know that that's even possible. Like I said, I'm not an expert, but it seems very hard. And so I think it will be quite interesting to see what clever ideas we can come up with within that world. And my concern is that until we've reached a point where we have the ability to make formal statements about the behaviour of that, which that point may be never, because psychology cannot make those statements about humans. Most statements that can be made about humans are statistical in nature and only emerge at a large enough scale. And that may be the permanent state of the world for AI.

Compliance auditors, though, they are deterministic.

Oh, yeah, definitely.

That's Anton humor for you, Grant. I wouldn't try to make sense of it.

Yeah, well, this one, I'm sorry, Tim. This one does make sense to me and probably To many others. But yeah, I mean, I think the determinism part is kind of actually peculiar and worthy of a discussion. But ultimately, I want to shift gears a tiny bit. And it's frankly a serious question. It will be about identity. So I'm hoping in the next maybe 10, 15 minutes, we're going to solve agentic identity. That's my intention. So as we move to this new world, the role of identity and machine identity specifically changes in some fairly unpredictable ways.

Right.

I've met people who think agents are workloads, and I've met people who think agents agents are employees from the IAM point of view. And I wish I would get the people in the same room and have kind of some kind of a drunk pillow fight over that. But the question is, how are you thinking, given your background and experience, about identity in this new world of agents?

Yeah, I mean, so I think they are their own thing, frankly. Like, I think that trying to say they clearly fit fully into the category of a workload or a human as traditionally managed by enterprise IAM. With the current way the technology works and with how I sort of expect it to go in the next some number of years, I don't think they will cleanly fit in either bucket. So my notion is, how should we think about this? And this is what we're trying to do in our sort of vision here at Google, is agents have an identity. We issue each agent an identity. That identity needs to be bound to the lifecycle of the technology that is managing that agent's compute. But agents also need to be able to assume privileges from other identities, whether those be other identities of other agents, whether those be identities of a controlling human. And so delegation is critical. So having a mature capability to delegate a set of privileges from one identity to the identity of the agent so it can act on its behalf, I think we think is critical to enable a number of different But I would argue that, like, an organization needs to be able to distinguish between agentic activity and controlling user activity, which means the idea of an agent as an OAuth client that just assumes an identity of a person and then accesses some system, and the audit log only has the human, I don't think that's sufficient. I don't think any security-minded person should consider that sufficient. And so we in the vendor community need to enable people.

Yeah.

to distinguish that, which I think requires the agent to have its own identity. But that doesn't necessarily mean that you manage it as its own principal from an IGA point of view and you say, like, hey, it's all separate, it has its thing, it's totally different. I've seen enough use cases where that model doesn't make sense. And so I think rich delegation is critical.

I think that makes a tonne of sense. We had this terrifying system at a former company where you could, as an employee of the company, act as any customer identity, and the auditing around it was nonexistent. It was the scariest thing I knew about when I worked there.

Back to the slightly more serious angle part of the answer. I think they are their own thing is kind of a robust answer. I like it. I've seen it before. I've seen the camp, again, more humans, more workloads, or they're the same thing, and they're both. But I think they're a new thing is also a well-known camp. But that means they need to be defined. in many new terms, that you can't always say, over here, it's like a workload, over here, it's like a human, but over there, sorry, but you have no reference in your experience with IT for the last 20 years that would apply. That is a little scary, even for people like, well, us, who thrive in— what do we call it? Thrive in ambiguity?

That's right.

Yeah.

I mean, I think it is scary, frankly, but I also think AI is, you know, one of the most disruptive technologies that we've seen certainly since the creation of the internet and potentially since the Industrial Revolution if the trajectory continues as it's going. And so the notion that like, hey, this is different and we have to think about it differently, while scary, I think is fair.

So one of the things we're seeing is customers are kind of torn between finishing or starting their zero trust implementation versus getting on to the next thing with AI. Is zero trust now kind of a legacy thing, or is it a prerequisite for everything that we're trying to do here? And does that mean that legacy is actually secretly a word that actually means foundational?

Yeah.

I mean, I think, you know, my perspective is I don't think zero trust is legacy. I think it's sort of, you know, orthogonal. Unfortunately, like, the problems that zero trust is attempting to solve are still with us. We just also have a whole new set of wrinkles that we've added with AI. And if you sort of start from the premise that I am coming from, which is that we need to create this container to sort of manage the scope of AI access, I mean, the ability to manage that container, I think fundamentally is taking the concepts from zero trust around managing scopes of identities, managing scopes of data, sort of integrating them and fusing them together. And so I think that from my point of view, Managing these AI risks using deterministic constraints builds on zero trust technology. Now, there is also a whole other line of thought around managing AI risks using sort of more AI approaches. And I think that is a very interesting area. We need to continue to invest in it both on the research side and on the product side to sort of see where that all takes us. But my perspective is that, like, Just betting on that as our only path forward is not sufficient from a security point of view, just frankly, given what's at stake. And so, I think building on zero trust as a foundation to manage AI is an important direction for many organizations, including Google.

So, oddly enough, I was at one point witnessing some discussion about ZT for AI on a certain standard body. And people went pretty deep into this, but at the same time, Is there— you think that zero trust for AI is a real thing? It's not just like a too crazy hot acronyms clash and who knows what happens. Like, you, you— there's a reality behind the different— yeah, you're implying.

I mean, I think it's— so look, I think it's both, right? Like, frankly, one of the problems that zero trust—

Both hype and reality?

Yeah, I mean, both. One of the problems that zero trust has had since the beginning of time has been disentangling, like, what are we actually saying from what is the sort of hype hype going on.

Yes.

But I think if you sort of come at it from the perspective of like, what are we actually saying in the zero trust space? We're talking about, you know, using identity and data as a foundational security control and not just sort of a layer for managing insider risk inside of some outer network perimeter, which is, you know, maybe historically the role that identity played in many organizations. And if you sort of accept that premise, Then I think you can build responsive security technologies for novel AI risks on top of it. They don't solve all AI problems, don't get me wrong. You still have this mixing data problem, which can lead to all sorts of stuff, even within whatever access box you can create. But I do think it gives you some ability to reason about the outer limits on what is possible here. And I do think that is compelling.

Well, Grant, Love that answer. And I hate to have to do this. I have to ask our traditional closing questions. One, do you have advice to help people architecting their way into the new agentic world? And 2, do you have recommended reading for people? Because we hate to leave guests empty-handed.

Yeah, sure. So recommended reading. One of my favourite books about software engineering has nothing to do with software engineering. It's called Atomic Accidents, and I learned about it from another former Google senior engineer. And it basically talks about the history of nuclear power and how a series of reliability incidents with nuclear over the course of the '50s, '60s, and into the '80s led to— Wait, wait.

So it's not a metaphor. It's atomic incidents, as in incidents with nuclear power. I thought that was about atomic habits, something like that.

No, it's about the history of nuclear power. Yeah, it's about the history of nuclear power, and it talks about how engineering was used to reduce the risk of nuclear safety to a, frankly, de minimis level, in my opinion, in the modern world. And I think there's a lot of ability to sort of take those concepts and translate them over to IT. And obviously, there are books that are focused on IT. There's a famous Google book about building secure systems, which I love. There are other authors that have authored different perspectives on that. But for me, the sort of analogy and thinking about how do I take that analogy from from, like, nuclear, which was frankly the AI of the late '40s, of like, oh my God, this technology is going to destroy the world because we don't understand it. And it talks about how you used engineering to bring it under control, or at least a manageable amount of control over the course of time. And so, I think there's a really interesting analogy there, and I would encourage people who find that compelling to read it. As far as, you know, architecting your identity stack, I mean, I think The question for me is, like, is your current identity stack, your IGA technology, your identity providers, you know, all your access management solutions, is it flexible enough to enable you to adapt to the complexities of AI? Or are you finding yourself making a bunch of really uncomfortable compromises in terms of, like, hacking things together and trying to fit them, and you just feel like you've reached a point where the model isn't working? And is it time to take a step back and look at like, hey, is this finally the straw that breaks the camel's back and forces us to re-architect our corporate identity architecture? So that would be the question that I would say people should ask themselves.

I love that.

But I think that AI tech as the nuclear technology, as AI of the '40s in terms of expectations, like all this, like, I mean, I've seen pictures from the 1950s about nuclear-powered cars being predicted in 5 years. Somebody was predicting a washing machine with a reactor. Like being almost imminent. And I think that I, at some point— sorry for going on a detour— I kind of tried to figure out like other famous predictions in the past when people predicted flying cars or nuclear— well, regular cars. And there's actually a history of this stuff. So it is not impossible. Supersonic travel even, like all air travel would be supersonic starting in the '80s, I think was the prediction in the '60s. So We may well be in that bucket now with AI, right?

Entirely possible.

Yep.

But, uh, Grant, thank you so much for joining us today.

Yeah, thanks so much for the invitation.

And now we are at time. Thank you very much for listening and of course for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.

You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, we can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast by Google. Secure ready.

Secure ready.