The Former Google Cloud CISO's Take on AI, Agents, and What Comes Next

The Former Google Cloud CISO's Take on AI, Agents, and What Comes Next

Curiouser & Curiouser, Episode 11 with Phil Venables

Phil Venables: The dirty secret of the entire security industry is that there have been far more vulnerabilities that went unexploited than have been exploited. Most organizations are targets of opportunity that have not actually been targeted. What that means is that attackers can now just be relentless. They can scale the monetization of those attacks, so there's no place to hide anymore. AI-driven attackers are going to be relentless in finding that one misconfigured system in your otherwise wonderfully configured cyber hygiene, and they'll use that as a launching pad.

Mo: If AI has ever made you stop and think, "wait, what is happening?", you're not alone. I'm Mo, and I'm a security researcher asking the same questions. On Curiouser and Curiouser, we have open conversations with experts, researchers, and leaders working at the edge of this space, talking through how AI is taking shape, what's shifting, and how the people inside the work are thinking about it as it happens. So join us and listen in as the conversation takes shape.

Hello, hello, and welcome back to Curiouser and Curiouser. I'm really excited for today's guest. He's got a really cool background, but as usual I don't want to skewer it, so I'll let him introduce himself. Today we've got Phil Venables, who is a partner at Ballistic Ventures. Phil, thank you so much for being on today.

Phil's background

Phil Venables: It's a pleasure to be here. A bit of background about me: I've been doing cybersecurity for a long time. I initially started as a software engineer many decades ago, but got into security in various forms. I was a longtime chief information security officer at Goldman Sachs, then chief operational risk officer and a board director. I spent the past five years at Google as the first CISO for Google Cloud, and I ran security engineering for Google's technical infrastructure. Now, as you said, I'm a partner here at Ballistic Ventures. We invest in seed, Series A, and other early-stage cybersecurity companies. We've got a great portfolio across many different segments of cybersecurity, so I'm looking forward to the discussion today.

Mo: You guys definitely have a very cool portfolio. I've been on one of your podcasts, and all the topics you cover at Ballistic are super cool. I think you're probably one of the best people suited to talk about this space. When we think about AI and everything it's doing, especially in security, there's just so much noise and it's really hard to cut through it. So that's how I want to start. You've seen this from a lot of angles that most people haven't, from Google infrastructure to the advisory boards you've been on. What's the vantage point you're seeing for AI security? What's all the noise that people are getting bogged down by, versus what's actually helpful?

Cutting through the AI security noise

Phil Venables: As with any massive technology shift, just like we've seen with the internet, mobile, and cloud, AI is probably an even more pervasive shift. When you look at how it impacts security, you have to unpick it a little bit.

First, there's the security of AI. That's everything security and risk teams are doing to make sure that when their organizations deploy AI for business purposes, they do it in safe, secure, regulatory-compliant, well-managed ways that handle all the risks, not just the security risks of those AI deployments.

Then you've got security as delivered by AI, so AI for security. You see this across everything from software security to security operations and a whole range of other things.

And then you've got the broader impact of how AI is affecting the entire security landscape. That's what's dominated the headlines for the past few months, with the so-called Mythos moment, although that's a bit of a false moment in time. In the quarters and the year before that, everybody in the security community was already seeing the profound effect that AI models, particularly models trained for coding, could have on finding vulnerabilities and chaining them together for attacks.

So one element of this is that we've got a tidal wave of vulnerabilities hitting us, because the models are so good at finding them. That's both a short-term and a long-term thing. The short-term thing is quite worrying. Long-term, though, everybody is applying those same models to their own code base to find and fix things at rates we've not seen before. So ultimately that could be a good outcome.

Secondly, and I think this is largely going underreported but is more worrying to me, is the extent to which attackers are now using AI to industrialize what they're doing. Attackers have always been resource-constrained, so there have always been more targets they haven't exploited than ones they have. Now, just like everybody else, they can industrialize and scale, putting together many times the volume of attacks, 10x or 100x. That's going to be the really worrying thing. There's no room and no place for organizations with weak security to hide anymore.

And then finally, you've got what you might describe as a quest for authenticity. You've got fakes: fake workers, fake content, fake brands. All of that is driving us, as consumers, businesses, and governments, to want to know what is authentic and what isn't. So that's the grand sweep of what's going on, and you can see why everything seems to be changing all at once. It's because it actually is.

The shrinking line between frontier and attacker

Mo: You touched on a lot of really big things there, including attackers being able to catch up to these capabilities really fast. If you look very recently, Fable Five came out, and the only difference between Fable Five and the most recent Mythos release is a couple of safeguards and protections. So the line in the sand between an attacker's capabilities and what's actually frontier keeps getting smaller, even as we see open-source obliterated models start to get used across open-source attack platforms. The ability and the scale at which attackers can productionize is really extreme.

Phil Venables: Mythos is not the only model with these capabilities. You've got Kodak, you've got Gemini, you've got others. And as you point out, over time, more and more of the open models are going to have more of these capabilities. With many of the Mythos-discovered vulnerabilities, it's been clear after the fact that other, lower-end models could and did also discover them when you apply them. So anybody basing a sense of security on the restrictions in advanced models, or on the restricted availability of those models, is going to be disappointed. The cat's out of the bag. Everybody's going to have this capability, to your point.

Mo: There was early research done last year, and it continues every time a new model is released, that shows that with open-source models and the right kind of reasoning, walking a model through how to go and do this, you eventually train those open-source models to perform these Mythos-level exploits, these chains of thought and reasoning. So the reasoning layer really seems to be the big differentiator, and it keeps getting smaller as the models get better. The cost is becoming lower and lower too. When I looked over the weekend and saw Fable was out, my Opus limits were suddenly doubled, because Opus is now going to get cheaper now that Fable, the more expensive one, is out. We saw the same thing a couple of months ago, where Sonnet is now the cheapest one when at one point it was the most expensive to run.

So the costs, especially of producing code and doing reasoning on really complex problems, are getting a lot cheaper and easier, but the vulnerability density isn't going down with it. We're seeing more code and far more surface area for attackers to pick at. There's just so much to attack now. I've always said AI is challenging the foundations of an organization's security posture. If your organization didn't have a great posture, or wasn't ready, this is really going to test a lot of those foundational practices. So does that concern you at all, how fast the threat landscape is growing, how cheap these attacks are, and how easy they are to scale?

DORA: chaos amplified vs productivity amplified

Phil Venables: On your final point, I agree. Google's DevOps Research and Assessment team, this thing called DORA, not to be confused with the European Digital Operational Resilience Act, did a lot of research on this. The conclusion is kind of obvious in hindsight, but it's good to have it grounded in research: if you take AI-driven software production into an organization with quite unmanaged, chaotic software development lifecycles, you get chaos amplified. If you deploy AI-driven or agentic software production into an organization with a well-controlled production pipeline and controlled build and testing processes, you get productivity amplified. So this really shines a light on the organizations that have yet to get their software production under control, with testing, security, quality assurance, and all the things we expect.

Coming back to the idea that we're going to generate more code, the amount of software and the backlog most organizations have in their desire to produce new systems is now being met, if not exceeded, by the capability of some of these models. So we're going to get an enormous amount more software. What's not entirely clear yet is whether that software will have a greater or lower density of vulnerabilities. Some models are better at producing secure code than others. Most organizations are getting better at post-training or prompting models to generate secure code, using the libraries they expect and not bringing in unauthorized or extraneous third-party libraries. That whole process is getting better all the time.

If you put me on the spot for a prediction, I think ultimately the models are going to produce a lower density of vulnerabilities. There will still be vulnerabilities, but I don't think we'll see a higher density. So software is going to keep getting better, but to your point, there's going to be a massive amount of it, and so we're going to see bigger attack surfaces.

Why attacker industrialization is the real risk

Phil Venables: The thing we really do need to worry about, and you're correct to point it out, is how attackers use this. The dirty secret of the entire security industry, as I mentioned, is that far more vulnerabilities have gone unexploited than exploited. Most organizations are targets of opportunity that have not actually been targeted. What AI does, through the industrialization of attackers, is let them be relentless. Even if they don't get an immediate exploit from a new vulnerability they discovered, they can just keep hammering away at organizations at low cost. They can scale the number of organizations they target, scale the number that have a vulnerability that can subsequently be exploited in various ways, and scale the monetization of those attacks. So the real issue isn't necessarily that we'll discover more vulnerabilities, although that is an issue. The bigger issue is that this enables attackers to operate relentlessly at much greater scale. There's just no place to hide anymore.

Mo: From a security standpoint this is probably a bad thing, but it's also pretty exciting to see how much this is growing. I think we have to see attack innovation in order to innovate on defense. So the exciting part of all of this is that, while we have an attack surface that's getting hammered relentlessly, there are opportunities for teams to innovate in really interesting ways. For example, when this first happened, open-source repos were getting pounded by pull requests and bug fixes coming up all the time. In some cases those open-source programs closed their bug programs and said they couldn't handle the volume. Now we're seeing a lot of them move toward auto vulnerability fixes, and we're seeing teams leverage AI to reduce both the cognitive load of all that noise and the operational inefficiencies that existed because everything required so much human touch. So what are some of the exciting parts of programs here, and how is AI lifting up teams that didn't have the budget, the people, or the time to prioritize?

AI as a democratizer of security capability

Phil Venables: AI is a great democratizer of capability. We see this quite a bit. I've always thought that organizations want to be more secure but either can't afford to be or don't know how to be. When they don't know how, they can't afford to hire the security team that helps them understand what to do, and then they can't afford to pay for all the controls. There are some very high-end organizations, and even some medium ones, that do this really well. But most organizations are in a kind of permanent debt of not being able to deploy enough security capability, whether that's basic cyber hygiene or more advanced things like continuous red teaming.

Now you see organizations applying technology from new startups built around AI, using AI agents to provide almost infinitely scalable security capabilities. You've probably seen some of the announcements we made recently. For example, Kevin Mandia's new company, Armadin, is basically AI agents for full-spectrum red teaming. Most organizations don't have the resources to continuously red team themselves, and now they can.

Another company we just invested in, Above Security, has the same thesis but for insider threats. Most companies would love a world-class insider threat program but generally can't afford to run it the way they'd like. Now you can augment a small team with a large number of agents to deliver that.

Another, with the exact same thesis, is a company called BreachRx, which is AI and workflow support for managing incidents of various forms, and for coordinating incident response and disclosure. Again, everybody would love a world-class, multi-domain incident response team. Not everybody can afford to build and scale that, and now you can get agents to augment a team to do it. The same pattern repeats everywhere.

Stepping back, though, it's worth reminding ourselves that while AI is going to be a massive boost to security, whether that's software security, operational security, or all the things I just mentioned, we've also got to remember that good old-fashioned, high levels of basic cyber hygiene still matter.

The basics still do the heavy lifting

Phil Venables: Strong multi-factor authentication, network segmentation, binary authorization, least-privilege access controls, and many other things, implemented relentlessly and implemented well, provide a defense against even AI-assisted attackers. The main thing is that we've got to implement them at much higher rates of consistency. Because, back to that point, AI-driven attackers are going to be relentless in finding that one misconfigured system in your otherwise wonderfully configured cyber hygiene, and they'll use it as a launching pad. So AI is a tremendous boost, but you don't only need AI to defend against AI-driven attackers. You have to do all the basic stuff as well.

Mo: That's a great point, and it's always back to basics, making sure you have your foundational practices in place. It's just security tech debt. If you haven't fixed that, how do you move on to a better, world-class program? You've got to dot all your i's. But on that, I'd actually like to go back to agents, because you brought up the keyword. Everybody's really talking about them, even though the concept has been around for a while. Right now, "agentic" is just catching flame. You mentioned augmenting staff with agents, which is the natural progression of this technology. When we bring agents into the environment, I think it introduces a lot of unsolved problems. We've tried to apply traditional security mechanisms to them, around identity and access management, role-based access controls, and data loss prevention, but all of those were designed around humans. The threat model for an agent is totally different. So when we think about the actor in our organization as an agent, what are the new ways we need to think about that trust layer, and how should we start reasoning about trust for AI systems working autonomously in our environment?

Rethinking identity for agents

Phil Venables: There are a number of ways to look at this, and it's interesting, because we're at the very early days. Some of your listeners may be old enough, though I suspect not many, to remember the early days of the internet. In the late 1990s and early 2000s, we had a set of technologies for the nascent commercial internet: browsers, web servers, load balancers, firewalls, intrusion detection systems. But there wasn't really a fixed set of design patterns for how all those things should be plugged together. There was a lot of uncertainty about how the security model should work. Then, over a period of years, the design patterns got locked in, and we overlaid security onto them.

This feels like exactly the same moment, where almost every day somebody invents a new design pattern for how agents should communicate, how they should interact with resources, or how they should drive a business or technology workflow. So I don't think we'll see stability in how we think about security until we see more coalescence of common agentic design patterns for particular problems.

Identity is a good example. Should an agent operate under a delegated identity and a delegated set of permissions from a human? Probably, for certain use cases where an agent is acting on your behalf. But for other use cases, an agent should probably have its own permissions in the context of a business workflow. And for others, it should only have an ephemeral identity that's spun up and spun down to deliver a particular subtask in a workflow coordinated by other agents. Every one of those use cases has different properties for how you think about identity, permissions, and observability.

Overlaid on top of that, we all know that agents using models are by definition non-deterministic. You can ask a model a question ten times and you might not always get the right answer. But for deploying agents into business processes, particularly financial transactions, health transactions, and other critical infrastructure, you need absolute determinism. So putting deterministic controls around these non-deterministic agents, controls that aren't in the model or the agent itself but in surrounding guardrails that enforce business policies, just like you enforced business policies around a human's non-deterministic behavior, is what we still have to architect.

There's a lot of work from many companies, and from the foundation model companies, on how you augment agent activity with agent guardrails. It's very reminiscent of what banks do in high-frequency trading systems. They have algorithms, some machine-learning-derived and some not, but they always have independent checks, like circuit breakers, to detect if the agent, in modern language, is going off the rails, and then to block its activity. We're going to need the same type of agentic enterprise control plane that we've built for other purposes. And again, this is evolving as we speak, because the design patterns are evolving.

Watching agents in a simulated environment

Mo: One of the big things we think about at Alice is how you get an environment where agents can play and you can understand them. There's this concept of a gym, or an RL gym, where we have agents run at scale. They run their business scenarios and we observe them, kind of like an anthill. They go and do their thing, we recognize the behaviors, and we see where things go out of alignment. But because it's a simulated environment, we're not seeing those same risks happen in production. We can catch the really bad behaviors before they go into production.

Unfortunately, I don't think every organization has this, not at any fault of their own, but because a lot of organizations are getting agents from somewhere else. They go to a vendor and bring an agent in from outside, almost like bringing in a contractor to work on one of your teams or projects. As an appsec person, I've always been trained to shift left, to move more left. But in this case there is no left. You have to depend on the processes you have in GRC and your SOC, and hope that this new external party in your environment plays well with everything else. So are the controls that get embedded for agents you bring in really holding up? Is there something else we need to think about in this runtime layer for agents that we're consuming, not just creating?

From shift left to shift down

Phil Venables: It's interesting that you use "shift left," because in other spaces I'd advocate, including this one, that you're exactly right. We need to move from shift left to shift down, into the platform. Agents, and in fact any piece of software, should inherit a set of security and other risk controls from the platforms they operate within. That includes the runtime environment, the interfaces to other systems, and the libraries and frameworks they pick up controls from. Having that kind of shift down helps you not just with the agents you've developed, but with the agents that turn up in your environment from third parties, from potentially unexpected sources.

As an enterprise, you want to be able to reason about this. Let's say I've got a payments gateway, a stock-ordering system, or some other critical system. I don't want to build the controls only into the agents that may be interacting with it, in the same way that organizations don't depend on correct human behavior. You have a combination of trained humans, or in this case trained and well-controlled agents, but you still build tremendous amounts of access control, transactional policies, auditing, and observability into the resources and systems being manipulated. Reasoning about that collective enterprise control plane is what's critical, and that has to shift down into the substrate of the organization, into the runtime environment.

Now the big question is what happens to that third-party agent running in your environment when your controls stop it from doing something. How do you signal back to that vendor, "we blocked you because you were doing something crazy"? All of these things are yet to be defined, and that's why this space is so exciting.

Mo: I really like how you put that, shifting down, getting lower into the stack where agents are operating. This is fundamental, or it has to happen, especially when you have agents in your organization from different vendors all interacting with each other. You don't necessarily control any of those interactions or have much observability at that shift-down layer. If I bring in an agent from one platform and add another, and they interact on a project, then we've got a problem where there's no human, it's just agents, and we don't understand the gravitational risk one agent has on the other. So being able to report that back is important.

I've said that guardrails are really value-adding when you can take the signal from them and turn it back into a flywheel. When something gets caught by a guardrail, it's not necessarily training the model or the agent to get better. It's just stopping a bad result from happening. But from there, turning that into signal where you can go and retrain or provide feedback is really important. Being able to say, "we caught something bad happening, here's how we'd like to see this going forward, here's how you fix it." So having that feedback loop or flywheel embedded when you work with other vendors is going to be really important as we move forward with shifting down.

Phil Venables: Absolutely. And just like all the other security we've invented and deployed in the past, it's all about how each layer interacts with the others in that feedback loop. If you've got a resource that's continuously rejecting the attempted behaviors of an agent, you can't just keep rejecting it. You've got to think about what went wrong in the identity and access management process for that agent, where I haven't appropriately permissioned it, or what went wrong in the enforcement layer, where an agent is trying to do something against the policy you want, as detected by the resource for which that rogue access is being attempted, and how all of that ties together. We've spent decades doing that from human to application to back-end system to other resources, and we're going to have to do the same thing here. While it's conceptually similar, I think the nature and the scale, and to your point about anthills, the extent to which we'll see emergent behavior from agent interactions that weren't quite predicted in our policy management systems, are going to create some unusual behaviors that we'll also need to manage and monitor for.

Concentration risk and the context layer

Mo: There's another piece that comes with all these agents at scale. The platforms they originate from, the ones they're developed on, we call them foundational models. I think Andreas called them God models. We have these really big models that do everything. So now we're moving toward a place where we have a couple of big winners in the model space for enterprise, and a lot of vendors and solution providers rely on them to create their solutions, whether that's providing an agent or an MCP layer for a particular platform. This concentration reminds me of hidden dependencies, the third-party dependencies everyone shares but you don't see at a high level because of where they're embedded. So I might interact with an agent that uses one provider's technology, and it has the same issues regardless of the use case I put it in. Now we're seeing that at scale across multiple providers and agents. Maybe I'm thinking about it wrong, but do you think this problem exists at the scale at which AI is rolling out?

Phil Venables: In general, nobody quite knows how it's all going to land, and that's just the nature of where we are. But let's start with concentration risk. We've had concentration risks in multiple industries and technologies for years, and people figure out ways of managing them. Look at the hyperscale cloud providers, never mind the foundation model providers that depend on the hyperscalers to run these things. That's a degree of concentration risk, and it's managed in various ways, by the hyperscalers or by companies figuring out how to deploy redundantly across multiple clouds and even on-premise infrastructure. So there are ways to deal with that.

When you think about model dependency, most organizations I've seen over the past few years have been quite careful not to be wholly dependent on one model. They're always upgrading models anyway, because they're trying to find the optimally priced model for the problem they're solving. They don't want to solve every trivial problem with the highest-end model, and they want to be able to refer up to a more sophisticated model when they need to.

This points to a dynamic you see in a lot of spaces, where vendors sometimes get accused of just being an LLM wrapper. There are some vendors like that, but plenty that aren't. They provide a layer that gives companies a lot of routing or portability across models, and they pick up a lot of the work of model validation and testing. You see companies like Rogo AI in investment banking, or Harvey in legal services, that provide a set of context, domain-specific knowledge, and connectors, plus that layer that lets customers dynamically choose which model they're using. Then it's left to that service provider to assess and validate whether that model is fit for the purpose.

I think a lot more organizations over time will have plenty of use cases where they directly use the models, but also plenty where they say, "I value that layer of context, connection, knowledge, and model validation so much that it's worth paying a premium not to use the underlying models directly." You'll see various flavors of that. How it shapes out in software security is going to be interesting. You see plenty of harnesses around the models that help companies do software security, and plenty of companies helping organizations deal with the output. So there will be multiple frameworks for how you do this. Not all organizations are going to want to directly use the models for everything, because they just don't want to deal with all the testing, the model routing, and the updates.

Mo: I completely agree. I recently saw a post from Harvey where they enabled Fable Five in their environment as soon as it was released, but they released it with a benchmark that showed exactly how well it was performing on their stack. So like you said, these providers aren't always just a wrapper for AI. They're a context layer, and they provide a layer of context the foundation model companies don't. They'd rather provide that context, let you figure out how you want to interact with it, and let you choose the model that makes the most sense to you, because consistency of results is what you care about. They figure out the pricing on their end, and yes, this one costs more because it costs them more. But otherwise it's really on you to figure out how you want to go about it.

I think that context piece, the cost, the value of the context, and the provider, all three make it really difficult for leadership to make choices about what they need to be doing, especially as these systems get more complex and interconnected. Even the conversation you and I just had, about having a model, having the context, and figuring out which solution fits best, points to a lot of complexity. It's almost like the answer is to get everything rather than get one thing, and that's not very cost-effective. So is there an easier way to give leadership and engineering teams a more useful picture of both the solutions they can pick and the risks that come with all of them?

Phil Venables: In each layer of security, you'll see some companies acting as that context layer over and above the models. One of the key differences in many companies is that they build and deliver a context graph for an organization, one that builds up its knowledge and is then used in the model to make better-grounded decisions in the context of that organization. You see this in plenty of places. For example, we've got a company called Armacode that helps companies do vulnerability operations. They take in all the information about vulnerabilities that have been discovered by AI models or from traditional sources, and build a big graph of what your organization looks like, to help you prioritize how to fix things and make sense of it all. We see similar things in many other spaces. That context graph, over and above the models, is absolutely key. Because, again, most organizations don't just want to use the models for their own sake. They're using them to solve a business problem, and often that problem is best solved by augmenting the model, not just using the raw model.

The one takeaway: go back to first principles

Mo: Based on this whole conversation, if you had to give an organization one thing to take away today, maybe an action they could take or something they should think about when they're making their next purchase or building their next solution, what's the one key takeaway you want them to have?

Phil Venables: I think it's to remember that while all of this is new, it's not necessarily new from a first-principles perspective. Managing AI risk is about software lifecycle risk, it's about data governance, it's about the operational risk of putting guardrails and hard rails around behaviors. It's about understanding who has what identity and what resources they're accessing. We've done all of that for decades, in good and bad ways. It's somewhat different and more pressured in an AI and agentic environment, but it's the same basic principles.

Sometimes, in massive moments of change like this, we forget to go back to first principles, or we get dragged into the hype that this is all new and the first principles aren't relevant, which just isn't true. So I'd say to everybody, just remember to trust your instincts on going back to first principles. When you think, "why should I let an agent do all these things?", the answer is you shouldn't. You should not just rely on the agent behaving. You should put controls around it, craft its privileges, and put access control enforcement in the resources. You've got to do all of that, just like we've done for years. So trust your instincts, keep sticking with first principles, and everything will be fine.

What Phil's watching: second-order effects

Mo: As a tech enthusiast and a longtime software developer, what are you most personally excited about? What would you most love to see emerge in the next couple of years with AI?

Phil Venables: It's not quite excited, or at least not necessarily in a good way. It's more curiosity. I don't think we've done enough yet to think about the second-order effects. Going back to previous waves of technology, when the smartphone really took off in the late 2000s, there were lots of discussions about the risks, but nobody imagined, and couldn't imagine at that point, what the second-order risks would be. All the things we built on mobile infrastructure, whether social media, gig work, or other things, came with a whole set of risks that emerged from there.

I think we've yet to really develop an understanding of what the second-order effects will be from this first wave of AI deployment. Back to the anthill comment, what does a world of billions of agents look like, all with different models and reward functions, interacting in different ways under competitive pressures? Who knows what risks will emerge from that. Some things could be quite predictable, like when the first agentic flash crash happens, when some website posts an incorrect price and a billion agents descend on it to try to buy or lock in that contract. We're very close to that, I would think. So what's going to be fascinating over the next few years, and what I'm excited to figure out how to manage, is the second-order effects and emergent properties coming from a world of trillions of agents wired together in unpredictable ways. It's going to be wild.

Mo: It's also going to be very fun. I'm in the middle of organizing an agent-only conference, so I'm excited to see what kind of talks they put together. Phil, thank you so much. It was a real pleasure to have you today. Where can people find you, and what do you have going on next?

Where to find Phil

Phil Venables: My blog, with content out every two weeks, is philvenables.com, and I'm on X at @PhilVenables. At the beginning of next year I'm publishing a book on how to scale security for organizations in a pre and post AI world, so look out for that. It'll be announced across all the social channels in the coming quarters.

Mo: Thank you again so much. I'll be looking out for that book for sure, and maybe we'll have you on again to talk about it.

Phil Venables: That'd be great.

Mo: Thank you, Phil. Thanks for your time. And to everybody, stay curious and have a great day. If this episode helped cut through the noise, like or subscribe so you don't miss what's next. Thanks for spending time with us. Until next time, stay curious.