
Cloud Security Podcast by Google · 2026-06-29 · 26 min
Key moments - from our scoring
Substance score
65 / 100
Five dimensions, 20 points each
Lloyds Bank, a 250-year-old institution, is undergoing significant security transformations to become what CTO Ron Van Kominade calls "the biggest FinTech in the UK." Matt Rowe explains how executive alignment on organizational strategy translates to security modernization priorities. The bank's SOC transformation using Google SecOps achieved a dramatic 20x reduction in human-reviewed alerts by cleaning up alert generation and implementing triage agents to handle additional volume. Beyond detection, Lloyds is building threat hunting agents, SRE agents for data pipeline management, and exposure management capabilities in response to the vulnerability scale introduced by AI-identified CVEs like Mythos. Critically, Rowe positions identity and access management modernization as a forcing function for agentic AI - requiring a complete reimagining of IAM from role-based access (RBAC) and long-lived permissions toward fine-grained, ephemeral permissions tied to specific agent tasks. The bank is tackling the Mythos/vulnerability explosion through orchestrated remediation velocity (patching plus preventative controls, policy changes, and detective capabilities), even across mainframe infrastructure, while maintaining focus on exposure management and attack path analysis to prioritize which vulnerabilities matter most.
They cleaned up alert generation rules so that when alarms do fire, they're meaningful, and implemented AI triage agents to handle additional volume while freeing human analysts for higher-value work like threat hunting.
It's an experimental agent designed to identify problems in data feed pipelines feeding the SOC and potentially take automated remediation steps before humans are aware of the issue.
Treat IAM modernization as a forcing function by redesigning from scratch with fine-grained, ephemeral permissions tied to specific agent tasks and orchestration-based controls, rather than extending legacy role-based access models.
Exposure management illuminates attack paths by identifying sequences of gaps an attacker could exploit, helping prioritize which vulnerabilities to remediate first rather than attempting to patch everything equally when facing 10-100x more identified CVEs.
DevOps practices can be applied to mainframes to improve patching velocity, but focus first on exposure-based prioritization to ensure mainframe patches address actual attack paths rather than treating all systems equally.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains a handful of genuinely operational insights - the 20x alert reduction, ephemeral agent permissions as an IAM inversion, and the SRE pipeline agent concept - but is padded with standard transformation-speak and fail-fast platitudes that reduce overall density for a 26-minute runtime.
In our pre existing security operations center, we were generating in the region of 250 to 300 alarms every 24 hours that got worked by humans. And then when we fast forward to the other side of the transformation, it's now fewer than 10.
there is an opportunity and a need I believe, for AI agents to have much more fine grained permissions where the task that an individual agent is performing, it's fine grained the task and the permissions of that task are ephemeral. They serve a purpose and then get burned down
The framing of agentic AI as a forcing function to break IAM's "doom loop" and the explicit inversion from long-lived RBAC to ephemeral task-scoped permissions is genuinely fresh; however, the surrounding transformation narrative leans heavily on ubiquitous tropes like fail-fast culture and "ditch on both sides."
the models and the tools that we have today, they're the most powerful they've ever been. They're the least powerful they'll ever be again
we're almost trying to invert what identity and access management as a model looks like working with our partners
Matt Rowe is the serving CSO of one of the UK's largest and oldest banks, speaking from direct experience running multi-year SOC and IAM transformation programs at genuine scale - a high-caliber practitioner, not a circuit-rider thought leader.
we're 250 years old and we want to be the biggest FinTech in the UK
we can now define and implement a new detection analytic into production, you know, at real pace when we need to
The 250 - 300 → fewer than 10 daily alerts figure is a strong concrete data point, and the SRE agent and triage agent are named with early-stage framing; but most claims about IAM, exposure management, and quantum are discussed at an abstract level with no timelines, dollar figures, or named tooling beyond Google SecOps.
In our pre existing security operations center, we were generating in the region of 250 to 300 alarms every 24 hours that got worked by humans. And then when we fast forward to the other side of the transformation, it's now fewer than 10.
we're modernizing everything
The host lands a few genuinely creative probes - the sound-barrier vs. speed-of-light patching metaphor and the mainframe follow-up add real value - but there is little substantive pushback on big claims like the 20x reduction, and the host explicitly rubber-stamps answers rather than probing further.
Do you see Enterprise patching speed as a sound barrier, where with sufficient courage, Chuck Yeager can go faster than it and new engineering, like jet engines, uh, propellers? Or do you see it like a speed of light where only Captains Kirk and Picard can go faster than that?
What about your mainframes? Do you still have mainframes?
Computed from the transcript - who did the talking, and the words that came up most.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign.
Speaker B: Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your host here today, well, it's just me, but Anton's going to join us for the opener as well. Tim Peacock, Group pm for a bunch of agentic and infrastructural stuff on, uh, Google SecOps, and of course Anton Juvakin, senior staff in Google Cloud's office, the ciso. You can find subscribe to this podcast wherever you get your podcast, as well as at our website Cloud with google.com Cloud Security Podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button, follow the show, argue with us and the rest of our Cloud Security podcast listeners on YouTube, YouTube.com cloud psych podcast. Anton, um, this was a super fun episode to record. I'm so sorry you missed it this morning.
Speaker C: I mean, it's absolutely my fault and I'm happy to do a full. I missed all the fun and that's just such a great seesaw, such a great top, and also a great previous episode. But what happened, happened, and I'm just gonna go and interview you about the episode now.
Speaker B: So, team, you want to hear the highlights? You want me to tell you what you missed?
Speaker C: I want you to give me the highlights.
Speaker B: Yeah. You missed Matt talking us through change leadership. You missed him talking about how they achieved a 20x reduction in the number of things that humans look at when they migrated to Google psychops. You missed discussion, uh, of forcing functions and funnels and all his optimism about the need to transform his, uh, team so that his company, which is 250 years old, can be around for another 250 years. And so just incredible.
Speaker C: Wow. Okay. Yes. Now it sounds like I did miss a lot. And I have a suspicion that we may have to ask him about the 20x because people usually blame us for how 10x is an exaggeration. But we keep seeing examples where somebody improved something in security by more than 10x, and they wisely point out that actually 10x is kind of reasonable, slash, not excessive. And then people show up and say, do you mean by 10%? And we say, no, actually, we do mean 10x. We really do mean 10x. And sometimes 10x is a low boundary that is very optimistic M yet also very grounded in reality.
Speaker B: Yes. So maybe without any further optimism, pessimism or other isms, let's turn things over to today's guest. Today we're joined by Matt Rowe, the chief security officer at Lloyds Bank. Matt, thank you so much for joining us today. I think this episode started for me at next 2025 when you gave me a hug. Is that right? Do you remember this?
Speaker A: That was the start for me as well. Yeah, it's great to be here. Thank you very much.
Speaker B: Yeah, thank you for joining us.
Speaker A: I'm sad I'm not hugging you today. But we are virtual.
Speaker B: Yes. We can have a virtual hug and listeners, you can let us know if that's the same or not. I want to start with the change leadership thing because a year ago we had Manisha on the show talking about soc transformation and I caught up with her a couple of months ago and I, I heard you tricked her into another kind of transformation. But aside from an Asia, I want to understand how did you get your board bought in on this and how did you get the team bought in to execute on it? Because you're in the middle of a second transformation. You've done one. So what's the process there? How did you do it?
Speaker A: Yeah. So to get the board bought in and the leadership of the whole organization, we're really having a conversation with them about what we want to be the organization we want to be when we grow up.
Speaker B: Aren't you a multi hundred year old bank?
Speaker A: Exactly, exactly. And hopefully many, many hundreds of years in front of us as well. So the thing we talk about in the organization, my boss, our uh, chief operating officer Ron Van Kominade talks about us being the biggest FinTech in the UK. So yeah, we're 250 years old and we want to be the biggest FinTech in the UK. So that's about us being able to do what our customers need, exceed their expectations, put brilliant services tech products into their hands as quickly as possible to beat the competition on pace, to out innovate them, to reimagine customer experience. And if we need to do all of those things as an organization, if we want to be a fintech, that's the organization we want to be when we grow up. Then in the security organization you need to think about what does that mean for security? M well, we can't be what we used to be. That's not going to work anymore. So the modernization campaigns, they really come from this need for us to meet the business in its ambition and its strategy for where we're going as a whole organization. So that in security we're enabling it, we're enabling the group to safely go faster.
Speaker B: That makes a ton of sense and is a really nice transition into the second thing I wanted to ask which is about AI adoption. And so do you see more risk on the blocking AI adoption? It sounds like the answer is going to be yes or on the AI adoption goes wrong and customer data goes everywhere and the UK regulator does what I fear UK regulators are very good at.
Speaker A: So yeah, I mean this is one adoption of AI, particularly the next generation agentic AI capability. Like we're really excited about it. Uh, I'm um, personally a tech optimist M But there are risks on both sides. So yes, if you don't adopt this technology you are ah, likely to get out competed, other people will uh, innovate past you and that's obviously a huge problem as it relates to being successful as a business. But to your point, you can't just unthinkingly adopt this stuff with zero regard for safety, with zero regard for security. So we are aiming to like navigate through there's a ditch on both sides, we need to navigate through that and make sure we're adopting it at pace. But we're doing a brilliant job of safe adoption so that we hit that higher standard.
Speaker B: So how are you explaining on pace to your leadership and maybe more interestingly to your regulars? Like surely they're saying you're out ahead, why are you out ahead? Or maybe they're not and if they're not, probably your leadership saying why aren't we out ahead? So how do you navigate that?
Speaker A: So I think it's all about how we unlock pace, which is about fast loops of experimentation, learning, getting some stuff wrong, improving so that by the time we've got the latest technology that's in a uh, production context or in a product in our customers hands, we've had multiple learning loops already. And that's one of the really important things in terms of how we work now. M We're not like delivering in great big monolithic programs that take forever to get from an idea to something that pops out the other end. They're like really short increment sprints of experimentation, of learning, of improving. Fail, fail fast so that the thing that actually goes live has got all of that rigor with it.
Speaker B: And when you fail, how do you make that safe for the team to admit that they failed? What's that look like when a team look, boss, we got it wrong?
Speaker A: Yeah, the only way to make it safe is by going through it and it's like proven by the reaction when it happens. So it's really important to incentivize and make examples of people who do a good job of this, which is that they have with the best intentions, gone for something, tried something out, it didn' didn't work. And then we have a transparent conversation about it didn't work and we're going to learn a load from it. So our reaction as leaders in that moment is the thing I believe that is the difference between it being safe or unsafe. And like if you lift up those examples. Well we tried this and it didn't work. This team had a go and they, they failed actually taking the baggage away from that word, using that word and embracing that word failure. Those uh, are all parts of it.
Speaker B: We have an internal, I forget if it's quarterly or halfly or yearly but we have a newsletter that goes out internally of like Google's Greatest misses and fail. And they're told in such a fun style that you read these things, you're like wow, we lost how many packets because a cow stepped on a fiber line that fell down in a field. And yeah, they're, they're always fascinating to understand not just the particular failure but the systems that led to that failure. So I want to talk about specifically I am, because I got an earful from Indonesia about it and specifically with agents. How are you getting ready for IAM and agents and what is, what does that look like for you know, a company of your scale?
Speaker A: Yeah. So you've referenced it a couple of times. This year we're running an identity access management modernization campaign and there's like a couple of legs to it. Firstly we needed to modernize this stuff anyway for the human context, for the pre existing machine context. Where we've got to with identity access management is pretty disappointing as an industry, as a security profession.
Speaker C: Right?
Speaker B: Yes.
Speaker A: So the need for modernization was there anyway and then agentic AI is very helpful in a way because it creates, it's a forcing function. So the pre existing identity access management capability, it was underwhelming, it was disappointing, it was frustrating already and it's definitely not going to meet the moment for agentic, it just won't scale. And if we sort of carry forward some of the limitations of the current approach, it will be the point of friction, it will be the constraint, the impediment for us actually adopting agentic at scale and that pace, really helpful forcing function. So that basically means right if we were to start again, if we were to start again with a blank sheet of paper and redesign identity and access in the agentic era, what do we do? Yeah, what would we like? Let's come to that. Working with uh, our technology partners, we're working through that right now. And it's like a big hard problem and it's fascinating and fun but the intent is like to solve it for agentic will give us the opportunity to then extend that back into the pre existing machine context, to extend it back into the human context and actually just make the world a better place. M try and get past some of the sort of doom loop that we've had in the past with Iam where quite a lot of the things that we do, nobody can really explain why how on earth did we get here. We've kind of always done it that way. So we're trying to break away, break away.
Speaker B: We got a lot of cutting the roast in half before you cook at things.
Speaker A: Exactly, exactly. And then in terms of precisely how we do it, like there's live conversations happening right now and um, people taking completely different points of view um, on what does good look like. But M the point is I think we've got to think about the identity of the agent and then how we apply permissions and how we orchestrate for autonomy. Like these are a set of ecosystem considerations and we have to think of it in a whole system way. There is an opportunity and a need I believe, for AI agents to have much more fine grained permissions where the task that an individual agent is performing, it's fine grained the task and the permissions of that task are ephemeral. They serve a purpose and then get burned down. And because the autonomy gets enabled through orchestration, that is where a lot of this control does need to be applied. So it's quite a different way of thinking about it. Whereas in the human context, if we go right back to the other end of things, permissions generally speaking were given to a person's role or an RBAC profile and were quite long lived. And that created quite a lot of challenges. So we're almost trying to invert what identity and access management as a model looks like working with our partners. We're not saying that we've got all of the right ideas, but we're definitely in a space of let's do some greenfield work here.
Speaker B: I really love that it so often feels like identity and access permissions are this thing that are only accretive, they only pile up and you only become riskier the longer you are at an organization. So that's really interesting as you're going through this, what's been the hardest part? Is it changing mindsets? Is it changing tools? Is it changing process? Where is this really spiking and maybe which part has been surprisingly spiky in terms of difficulty.
Speaker A: So it's, uh, a bit of all of the above, of course. And like I said, like, thinking about it as an entire system. What is technology versus what is operating model is like, really interesting thing to try and really pair it back to first principles. In terms of the hardest thing, it's because we are needing to make some moves now that creates the pressure of time on a topic which is just straightforwardly complex. And you. The reality is you. You do start in a place. We start with a bunch of existing procedures, existing processes, even existing skill sets and mindsets. So then to do a really big shift forward that you need to, like, run those two things at the same time. Very much like the society that we run.
Speaker B: Yeah.
Speaker A: Like we're having to build new, run existing, and then work out how you jump across when you're ready. And we're doing an equivalent right now when we think about identity, access, management, modernization alongside getting ready for agentic AI.
Speaker B: So you're not busy at all. You have lots of time to come on podcast. I love it.
Speaker A: Indeed. Yeah, it's never boring.
Speaker B: So I want to go back to the SOC for a minute and talk about how you're using AI there. How is AI, uh, adoption going for your security program? Where are you seeing value? How are you measuring that value? Let's start there and we'll dig in more.
Speaker A: Yeah, There's a couple of ways that AI is being applied, and some of it is like native AI that we're consuming from your good selves. Exactly. And then we're building a bunch of stuff on top of that as well.
Speaker B: Tell me about what you're building, because I talk about my stuff all the time on the show, but I want
Speaker A: to hear what people are doing, and I'll just give a bit of a context point. I think you probably have heard this data point before. In our pre existing security operations center, we were generating in the region of 250 to 300 alarms every 24 hours that got worked by humans. And then when we fast forward to the other side of the transformation, it's now fewer than 10. Fewer than 10 alarms a day.
Speaker B: Fewer than 10 alerts per day in Google Secups.
Speaker A: Yeah. Correct.
Speaker C: Wild.
Speaker A: Getting worked by humans is the thing.
Speaker B: Okay, Wild.
Speaker A: Exactly. So, uh, massive shift. So what does that represent? You've hugely cleaned up what generates an alarm, and now when it fires, you know, it's interesting. And I'll come back to. You know, I think you've had long conversations before about what you do with that human time further up the value chain, proactive work, threat hunting, all the good. And when we add in the AI opportunity, we have a, uh, triage agent that we're just testing and seeing how that works. You know, giving it like half the alarms data to work on. And that's going pretty well. Looks like pretty effective, generally speaking, not perfect, but actually can make a contribution, releasing more human time to do more productive stuff. And then in terms of the stuff we're building, so the agent is one that we consume and stuff that we're building, we're looking at a few things. Threat hunting agent, for example. How do we take all of the intelligence we've got about threats outside and then all of the intelligence we've got about lbg, combine those things so that a threat hunting agent can really give us a leg up in terms of things to pay attention to and to explore and then more on a functional basis. Also building out an SRE agent to manage the pipelines of the data that gets ingested into the soc.
Speaker B: Oh, that's cool. Say more about that because I, I feel like users so often get, you know, lots of thinking about detection agents, lots of thinking about triage agents. But tell me about the SRE agent, because that sounds fun.
Speaker A: Yeah, well, I mean it's uh, firstly it's quite early days, but the concept. Yeah, exactly. The concept is to try and identify where we might have a problem with a feed a pipeline. And that's obviously something that the sooner you know about it, the sooner that you can address it. But then working out how the agent might be able to actually take steps to address that before a human even knows that something's gone wrong is the concept. So making steps, and of course it's quite a big ecosystem, so we're just trying to chip away at uh, what we can safely give an agent to look after. What's the art of the possible, starting at the more benign end of the profile and then building from there.
Speaker B: So I never thought I would ask so many questions about Vuln management. I thought VM was the most boring thing on the planet. But Mythos has gotten me and a lot of other people interested in it for the first time in 20 years. And so first, has your board heard about this? Has your team heard about this? Yes, that looks like yes. And then what are you doing about it? Are you going to be able to patch faster? What does the future hold for vm? Um, at, uh, lbg.
Speaker A: Yes, that's fun to say.
Speaker B: It sounds like lbj. But lbg.
Speaker A: Exactly. So yes, there's lots of focus on it. And you know, the key thing I would say is that Mythos itself is a data point on a trend.
Speaker B: Yeah.
Speaker A: So something that we've talked about in our team, the models and the tools that we have today, they're the most powerful they've ever been. They're the least powerful they'll ever be again. So really what we need to pay attention to is this shift that's happening and what comes next. And there's a couple of things in that regard. I think exposure management becomes an absolutely critical capability. We've always had a funnel with loads of stuff at the top and fewer things at the bottom that we really need to pay attention to and fix fast because they're exploitable. You know, uh, RCE on an Internet exposed asset is clearly a problem.
Speaker B: Yeah, that's bad news bears.
Speaker A: Exactly. And today when we think about exposure management, increasingly we're able to illuminate an attack path. So an attacker can do these three or four things in sequence because of a set of gaps. So exposure management is critical. It remains critical. Now we're going to have even more things, you know, 10x100x more things at the top of the funnel and we're going to have more things at the bottom. But the things at the bottom of the funnel will remain a subset. Mhm. Critical that we're efficient identifying things that we need to do first. Next thing I would say is remediation. Velocity is key. We talk about patching velocity. Well, it's patching plus plus plus there's a set of things that you might be able to remediate a problem through a non patching method within minutes and then the patching takes n hours, even n days. On some tech debt, it's very easy
Speaker B: to fix things that way. You can always unplug them.
Speaker A: Exactly. But I'm thinking about, you know, it might be on a preventative control, adding a new policy or changing, you know, and I guess the point I'm getting to is that you want all of your security capabilities to be operating at or near machine speed. I'm really glad we did soc mod last year. We can now define and implement a new detection analytic into production, you know, at real pace when we need to.
Speaker B: Yeah.
Speaker A: So obviously that's a detective control. But if you've got every single one of your security capabilities that are able to operate at that level, at that kind of speed, then you're well set. In this era of AI identified vulnerabilities, to stay in front of things. Because the reality is we all need to massively shift up patching velocity. That's not going to be easy. It's not a magic wand. We're not going to be able to solve that in the coming weeks. So all of the other things need to be there in concert.
Speaker B: So Anton and I have been going back and forth about patching velocity for a couple of weeks now. Actually started in the room where you and I met this conversation. Do you see Enterprise patching speed as a sound barrier, where with sufficient courage, Chuck Yeager can go faster than it and new engineering, like jet engines, uh, propellers? Or do you see it like a speed of light where only Captains Kirk and Picard can go faster than that?
Speaker A: Well, let's say it's a sound barrier. Uh, and yet, if we think about automated patching, evergreening in a microservices architecture, uh, even starting to leverage agentic AI to achieve really brilliant velocity. And if we take that cluster of things as like, the future, the future's here. It's just not evenly distributed. So even if we can get to really good on the leading edge, there's going to be some stuff behind it. There's going to be a tail. And that kind of goes back to what I was saying before, which is like, I definitely believe this thing is a forcing function. It's going to get us there. It's going to get us there much quicker than we otherwise would have done. But to trade through from where we start to where we need to be, we're going to have to use a range of those security capabilities in the meantime.
Speaker B: Hmm. What about your mainframes? Do you still have mainframes?
Speaker A: Of course.
Speaker B: Are you gonna patch your mainframes faster? Like, what's the plan there? Like, the real legacy stuff? What's the thinking?
Speaker A: Yes. So, like, the short answer is, even with a mainframe, you can use DevOps practices, and you can definitely get to, like, a much higher patching velocity. But it connects to the point I said about exposure management, which is we need to make sure we're focused on the right stuff in the right order. So everything just needs to be have a higher patching velocity. Now, that's definitely true. And yet, if we said the problem we're solving is how do you patch a mainframe end times per given period, you potentially would be using up quite a lot of time, effort, money, and goodwill on something that was not the most critical point of needing velocity in your entire stack, especially when you think about an attack path. So this comes back to, why is exposure management critical? Because with the best will in the world, we have to do the first thing and then the second thing, and then the third thing. Let's make sure we do it in the right order.
Speaker B: That is such a sensible answer. I have a lot of conversations where I come away scratching my head, but this one feels very sane and sensible. You've got me thinking about funnels and how we adjust the shapes of funnels. Now I'm going to go away and think a lot about this episode. Unfortunately, we're getting to the point in the episode where I have to ask our traditional closing questions because we're coming up on our time. One, do you have advice for other chief security officers thinking about these kind of transformation programs? Like, should they do IM first? Should they do SOC first? Actually, bonus question before I get to my closing questions. What comes after IM mod for you? What's the next thing you're going to modernize?
Speaker A: So we're modernizing everything. And, um, your point on the sequence is really key. And I think this one, it's about the organization. M to be really, like, deliberate, um, and planful and strategic is one thing, but then sometimes you've got the crocodile nearest the canoe and something just needs dealing with, like, right away.
Speaker B: Is that a figure of speech? I've never seen a crocodile near a canoe.
Speaker A: The Lucky you.
Speaker B: I love it. Yes, lucky me indeed. Uh, okay, so sometimes something comes up.
Speaker A: Yeah, so something comes up, and then, like, you know, there's something that comes up, and what does that reveal? And then you can, like, bat the crocodile away, or you can, like, you go, actually, no, this thing is going to keep coming at me if I don't deal with it and then take that moment to really drive the transformation. So I think it's a balance of thinking about what are the five or six things that you really need to transform over time. And then a bit of pragmatism regarding the order in which you do them is m certainly where we arrived at. And I think the other point I'd make is, like, transformation is a choice. It is a choice, and it's choosing to take the harder path to get much further forward. And that's something that I always remind myself, because obviously there are some confronting moments when you're taking on something really big. But you've got to remind yourself, we've chosen to take the harder path to get much further forward. And that's like what I would say about transformation. It's the choice. It's a choice you have to take to get to really good M. And
Speaker B: so when you make that choice and you decide to do the hard thing, not because you thought it would be easy, but because you knew it would be hard and worthwhile, what's your advice to other CISOs and CSOs on ordering? Should they start with IM, should they start with SOC, should they start with exposure management, VM management? What would you say? How should they sequence that? Or does it just depend?
Speaker A: So I do think it depends. But then if you think about what are the set of really fundamental capabilities, then those are the ones that you need to go after sooner, uh, than later. So I do think identity and access is key identity at the foundation of the security model. You think about the security operations center that is really, that's in the middle of the security model. So M, that's a really important thing to go after thinking about then like wider hygiene factors. So actually I think everybody now should be moving beyond vulnerability management to think about posture and exposure. And that is therefore like when we talk about the era we're now in, it's definitely a really big part of it. So yeah, I would say those. And then you can't get away from data security with Quantum around the corner. M Crypto agility with data security. Thinking about data security posture management as something that we all need to be paying attention to, I think that's like the big one that will come next for us and that's really, really hard to do. Well, so look, uh, forward to it.
Speaker B: Yeah, Quantum is a whole nother episode. Are you getting a lot of pressure on that from, from regulators? Is that a, uh, peer group pressure or just like you're seeing where Google and Cloudflare are at and you're like, okay, if those guys think it's real, we better get on it?
Speaker A: Yeah, there's definitely interest in it. And we believe, yeah, we believe it's real. We believe it's real and it's something that we need to take every step to get in front of. And even if you took the quantum part out of the equation, crypto agility is an important thing just to reflect the reality of the threat landscape and AI driven threats in particular. We just need to be better at, well, shortening the lifecycle of secrets, automating M that swap out and things like that. So yeah, that's the world we live in now.
Speaker B: Okay. I love it. Matt, thank you so much for joining us today. This was an absolute delight.
Speaker A: Thank you for having me.
Speaker B: And now we are out of 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.
Speaker C: 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 youm
Speaker B: 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.
Speaker C: See you on the next episode of the Cloud Security Podcast by Goog.
Speaker B: You running.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.