Speaker 1: Welcome to the Cyber Risk Management Podcast. Our mission is to help executives thrive as cyber risk managers. Your hosts are Kip Boyle, virtual chief information security officer at Cyber Risk Opportunities, and Jake Bernstein, partner at the law firm of K&L Gates. Visit them at cr-map.com and klgates.com.

Kip Boyle: Hey, welcome to the Cyber Risk Management Podcast. This is Episode 212. I'm Kip Boyle, and today it's just me. Jake is not here this time so you're stuck with the CISO perspective for the whole episode, but I'm not worried because I'm sure Jake will tell you in a subsequent episode if I got anything really terribly wrong.
All right. Today what I want to do is I want to talk about what happens when the AI works perfectly or good enough, does what it's supposed to do, but that the process around it doesn't do what it's supposed to do, doesn't work perfectly. I'm going to also give you the best takeaways from our AI governance training, which we're doing this year. I want you to be able to use these even if you're unable to attend the training. We're having some really great conversations with people, and we're getting some really wonderful feedback. Okay, so those are the two things I want to do today.
The first is I want to tell you something about a few recent happenings, and that'll all build up to why I decided I needed to share these lessons with you. All right. On May 14th, 2026, Microsoft published a security research report, and the title is When Configuration Becomes a Vulnerability: Exploitable Misconfigurations in AI Apps. Ugh, huge title, right? Well, in the report, they say that the biggest risk in AI apps right now isn't the generative AI at the heart. It's the way that the AI gets set up. It's things like default settings that no one changes, authentication that doesn't get turned on, and public interfaces that nobody locks down.
Okay. Now, there was another report that came out from a different research team, and they had scanned like a million exposed AI services on the public internet. So they went out looking for AI. And what did they find? All kinds of stuff. Chatbots that were leaking users' conversations, agent platforms running with no password at all, and they found credentials sitting around in plain text. So I hope you can see the pattern here. The AI is working as well as it can, but it's cited with a context, the plumbing that isn't quite right. See, the people that are losing sensitive data aren't the people who built the AI. It's the people who deployed it in a context where data was coming in, the LLM was processing it, and then data went out, and everything around it. I don't just mean the technical bits, but I also mean the people, the process, the policies. I mean the total picture here.
All right. I want to tell you a story about a real incident that I hope will kind of tie this together and make it all very clear. So March 31st, 2026, Anthropic, this is the company that makes Claude. What happens? You probably know. They accidentally published the full source code of their most important product. Again, I just want to be clear, not a snippet, not just a config file, the whole thing, the complete architecture of Claude Code. Now, this is a product that's generating about two and a half billion dollars in annual revenue. This is not a small thing, right? It's almost 2,000 files, over half a million lines of code, some 29 subsystems, the whole thing. It got shipped into a public software registry because somebody missed a build configuration file.
Okay. This is the plumbing, right? This is a company that the rest of the AI industry looks to for safety leadership. Now, I'm not saying that they're not worthy of being followed just because they had this one incident. That's not the takeaway. The takeaway is that they had built an entire internal subsystem that they named Undercover Mode. It was specifically designed to prevent their AI from leaking confidential information into public repositories. And I'm not kidding, 18 separate security modules governing, what happens when their AI runs a single shell command? They built defense in depth, multiple layers. This is the kind of infrastructure that most companies only dream about. They had it. So they're just pouring tons of resources into this, and they're trying to do the best job they can. I think that's true, but they leaked their source code anyway because a build file was wrong.
Now, sounds bad, but it actually got a little worse. This is actually the second data exposure in only five days, because the week before, confidential draft materials about an unreleased AI model were found sitting in a publicly accessible data store. Now, that one wasn't source code. It was internal documents about a model that Anthropic hadn't announced yet. So different data, different system, even a different mechanism, but it's the same company in the same week.
Okay. Now, you might want to say, "Can I have more information? Tell me more about what actually got leaked. I'm interested to know." Okay, plenty of people did that. I don't want to go there. What I want to do is I want to talk about something really valuable beyond just the sensitive data. I follow somebody named Nate Jones on Substack, and instead of cataloging and writing about all the hidden features that everybody else was talking about, what he did is he mapped the infrastructure underneath all of the Anthropic LLMs. What he found was that the large language model itself, in other words, the predictive system, the part that generates all the text, it's only about 20% of the total system. In other words, Claude, all the code, everything that makes it something that we can interact with and get work done with, we're only talking about 20%. The other 80% is what Nate called the plumbing.
Okay, so what is that? Well, it's all kinds of things. Session management, permission pipelines, crash recovery, budgeting, or budget tracking, I should say. In other words, how do we know when Kip's used all his tokens and how do we know how much to charge him for token use, that sort of thing. And observability. Now, you might say, "Well, it's kind of the boring stuff." Yeah, it is, 80% boring stuff, 20% kind of interesting stuff, right? Now, again, I know I'm repeating myself here, but think about it. The leak, these two leaks that I told you about that happened to Anthropic, didn't happen because the AI failed, although it fails in other ways, but the AI worked fine. The leak happened because the operational processes around it couldn't keep up with the speed. I think that's really what's going on here, is the cadence of the software deployment.
So Anthropic is telling us that between 70 and 90% of their code is now written by their own AI systems. That's an incredible statistic. We also know from them that their engineers are shipping five releases per day, more or less on average, and that's a lot. And they got bit by that. All this boring operational stuff, all this plumbing, it just couldn't keep that pace. They were going so fast. Again, the AI seems to be working fine, but everything around it was brittle and something in it failed.
It's not just Anthropic. I want to tell you another story. This is about a company called Mercor. So a few days before Anthropic source code leaked, there was a different AI company called Mercor, and they got breached. I don't know if you've heard of them. They're a roughly three-year-old startup. They're a unicorn, $10 billion in current valuation. Now, who does Mercor serve, and why would they deserve such a high valuation? Well, guess what? Their customers are Anthropic, OpenAI, Meta, the frontier models, so the people that are really, really building AI in a large scale.
Now, what's Mercor's business? They hire experts. So think about doctors, lawyers, writers, anybody with deep domain knowledge. And what are they doing? Well, these experts produce some very high-quality training data that the big AI labs are using to make their models smarter. So if you think about it, Mercor is sitting right at the heart of how AI agents are getting made today. So that's why they have such a high valuation. Okay, but something bad happened to them. So there's a library. It's called LiteLLM, L-I-T-E-L-L-M. It's open source, so there's no license fee and it's widely used. Now, its job is to connect an application to an AI service. So if you're building anything with AI, there's a decent chance that LiteLLM is somewhere in your tech stack, or maybe it's in your vendor's tech stack, or it could even be in your vendor's vendor's stack.
All right, where am I going with this? Well, on March 27th, there was some attackers, they called themselves TeamPCP. I don't know why. But they got hold of stolen credentials for the LiteLLM project. They published two malicious versions of the package to their public software registry, and the bad versions were posted and available for about 40 minutes before somebody noticed and pulled the malicious versions down. Now, 40 minutes, I don't know, depends on how you look at it, you might think, "Well, 40 minutes, that's pretty good incident response." But for a package that is downloaded so frequently and used so widely, 40 minutes is actually a ton of exposure, not because of the manual downloads, but because there's a bunch of automated downloads. So anyone who automatically pulled the latest LiteLLM version into their build, well, they got a backdoor that just came right along with it. And Mercor was one of the organizations that did that.
So the result was, about four terabytes of Mercor's data got stolen, and reading the reports, it seems like that the stolen data included training data sets as well as information about unreleased AI projects that Mercor's customers were working on. And as if that wasn't enough, we got a separate hacking group, Lapsus$, they've been around for a while. They claimed that they had gotten in also. So what did Mercor say? Well, they said, "Hey, we're just one of thousands of companies caught up in the same attack." Okay, think about that for a minute, thousands of companies. So Mercor is at the center of so much of what's going on in the superscalers, but they're just one of thousands, one of thousands.
All right, why do I tell you this story? Well, there's a lesson on top of the Anthropic lesson. So with Anthropic, their process failure was inside their own walls. In other words, they could control everything, a build configuration that their own team had full access to. They could change it, they could make it be anything they want. They could have caught it themselves, there was that opportunity, but Mercor's process failure was outside their walls because they don't own LiteLLM. They didn't write it, and they did not, and possibly could not, audit every commit that was made to that project. What they did is they trusted a free library that the entire AI industry trusts. So maybe there's some comfort among all of the victims, I don't know, but that library got hacked for just 40 minutes, as I said, and it was enough. It was enough to cause that much damage.
All right. This is the part that most AI governance conversations are missing. This is what I'm trying to say to you. When you buy AI, you're not just buying AI, you're buying every library that AI depends on and every vendor that that vendor depends on. So, huge supply chain here. You're also having to deal with every default configuration and every component. Your AI works because thousands of small pieces of plumbing are working, and every one of those pieces is owned by somebody who's not you. Now, this idea is not new. We've been wrestling with this for quite some time now. That's why the NIST Cybersecurity Framework has a supply chain security activity in it because this is a big deal.
But let's go back to the specifics of this episode. Again, the AI worked, but the processes around it didn't work yet again. All right, I'm telling you a whole bunch of stories, right? But these are all different companies, different mechanisms, but it's all the same lesson. Now, there's a third story that I want to tell you. I think I've really done a good job of making this point, but there's a wrinkle that this next story is going to make clear that I think is really important. So if you've heard about the Vercel breach, Vercel is a company that hosts web applications. We've got customers at Cyber Risk Opportunities that use Vercel. So if you've used a web app that's built with a popular framework, it's called Next.js, there's a good chance that Vercel ran it for you behind the scenes because they host the front end for thousands of organizations.
Now, the reason I'm telling you this story is because of something that is a new term that I started hearing recently, and it's called fourth-party risk. So we're used to third-party risk, but now we need to add a new chair because now there's fourth-party risk. Okay. So what happened? Well, in April of 2026, Vercel disclosed that they had had a security breach. I want to just quickly review how the attack chain worked because that's really kind of the essence of this new term fourth-party risk. So a few months earlier in February, there was one Vercel employee, just one, this person signed up for a small AI productivity tool, and it's called Context.ai. They authorized the signup through their own Google Workspace log. All right, so that gave Context.ai an OAuth token to read some of the Vercel employees data that was in Google. So this is a standard SaaS signup workflow. It's happening millions and millions of times every day, possibly billions. And it was quick. They set it up, probably didn't take more than a couple of minutes. They could have done it just in between meetings or something, who knows.
But around the same time that this happened, attackers infected a Context.ai system with a piece of malware, and it was called Lumma Stealer. That malware grabbed Context.ai's OAuth tokens, and that included the one that connected to that Vercel employee's Google account. All right, you're probably like, "Get on with it, man. Get to the point." But I'm going over these details because I want you to see the chain of events and how quietly these chains can link up and what it can result in.
All right. Now, the attackers used that OAuth token to pivot from Context.ai into the Vercel employee's Google Workspace. From there, they got into Vercel's internal systems, and when they got in there, they stole records for 580 Vercel employees. They got what you would expect, names, email addresses, account activity. And then they listed all that data for sale on a hacker forum, and they wanted $2 million in Bitcoin.
Okay. Now, to this point, we're just talking about third-party risk. So we got Vercel trusting Context.ai, and Context.ai got popped, and as a result, Vercel got popped. This is a very typical story. But this is the wrinkle. Here's where it gets interesting. Vercel's customers, the thousands of organizations whose web apps run on Vercel's platform, they never agreed to trust Context.ai and most of them had never heard of Context.ai, and maybe you haven't either, but Vercel's customers trusted Vercel. In turn, Vercel trusted Context.ai, and when Context.ai went down, the risk flowed all the way back through to Vercel's customers who didn't know anything about it. And that's the essence of fourth-party risk. In other words, this is the risk that you inherit from the vendors that your vendors use and that you have no knowledge about and that you've never been asked to consent to.
Now, this has probably been going on a long time already. It's just we're now starting to see that the risk inherent in that is really starting to come up. Now, there's a very technical term for what's going on here, this fourth-party risk, and it's called transitive trust. I have no doubt that you may have never heard of transitive trust, but I know you've experienced it personally. Let me give you an example. So you have a best friend that you trust. Now, your best friend trusts their cousin. You don't know the cousin, but you tell your best friend a secret, and your friend tells their cousin the secret. So now this cousin of your best friend who you don't even know, they know your secret even though you never told them that it was okay for them to share your secret with the cousin. What happened was the trust just passed through those relationships, and that's why it's transitive.
Okay. Now, the most alarming part of the Vercel story is not what was stolen. It's what could have been stolen. If the attackers had reached Vercel's deployment credentials, the GitHub tokens and the NPM tokens that Vercel uses to push code on behalf of its customers, well, they could have injected malicious code into thousands of customer applications at the same time. Vercel says that didn't happen. I say it was pretty close, and I'm not entirely sure that it won't turn out that it happened anyway. It's still kind of early. In fact, I recommended to one of our customers that they go ahead and rotate all their keys and credentials just as a precaution.
All right. Now, here's the part that matters most for AI governance, which is really what we're trying to talk about today. So the pivot point in this whole attack was an AI tool, one employee signing up for one AI productivity app. There was no central approval, no security review. Nothing was entered into any kind of a software inventory or credential inventory or trust inventory or anything like that. Now, this is what shadow AI looks like when it goes wrong. I don't know if I've used that term shadow AI yet in this episode, but if you've not heard about that term shadow AI yet, you probably need to get used to it.
All right. So I tell you all these stories, and I'll just recap. In all of these stories, it wasn't the AI that failed. It has its own failure modes. It's the processes that didn't succeed, it was the processes that failed. For the third time in this episode for all these stories that I'm telling you, the problem is that Microsoft's report, the one that I told you about at the top of the episode, well, you should probably go get it and read it because it's making all of this very, very clear. Now, I'm doing my best to make it clear in the amount of time we have for this episode, but if you really want to get into this, you got to go get the Microsoft report. I don't think this is getting any better anytime soon.
Now, here's where I need to make an important distinction. Most of the AI governance advice you hear is written for people who build AI. In fact, many of the stories that I told you today had to do with the hyperscalers, had to do with people who were either directly involved with or directly supporting the creation of these frontier models. But that's probably not you. If you're listening to my podcast, you're probably not a builder, you're probably just a buyer. Even if you do build a little bit of generative AI systems, you also purchase licenses or access to generative AI.
So what does that look like? Well, you're deploying Microsoft Copilot, maybe you've got ChatGPT Enterprise or you've got Claude Enterprise, Claude Teams, you have AI-powered SaaS tools and you've got AI features that your vendors have bundled into products that you already use. And you don't control the plumbing underneath those tools. You trust your vendor to get it right. The problem, of course, is, as we just saw, you've got Anthropic with billions of dollars in resources and arguably the most rigorous safety culture in the industry. Despite that, they had two separate data exposures in a single week, source code in one, confidential docs in the other, and again, caused by operational gaps, not AI failures.
So I don't think the question is, how do you build better AI? Although we've been talking about that as an industry now for like three years because of all the hallucinations and all the crazy stuff that you sometimes run into when you're using generative AI. But I think the question that we need to ask ourselves as cybersecurity people is, how do I govern the AI that I'm buying? So that's really why we created this course and this training, we call it AIR-MAP. This training, this method delivers something, we call it an AI Risk Management Action Plan.
Now, I'm not going to spend time trying to talk about what all that is. I want to give you the five best takeaways from our recent courses, and these are things that I think you can start doing right away. So these are very, very practical. And if you have any questions about these things that I'm going to share with you now, feel free to reach out to me. You can give me a direct message on LinkedIn, my email address, kimb@cyberriskopportunities.com. I'd love to hear from you.
All right. Takeaway number one is you can't govern what you can't see. Most organizations I talk to can name the AI tools that they bought on purpose, like traditional software, where you went through a purchase process and somebody cut a purchase order and you took possession of license keys or whatever. So Copilot, ChatGPT, enterprise, all that stuff. But what most people cannot name, because their legacy processes don't really address this, is the AI that showed up without anybody issuing a purchase order. SaaS vendors have been dropping AI features in like crazy, and most of them don't charge you extra for it or they don't make you pay before those features get activated. Another example are going to be AI assistance that your employees are installing on their own, either on systems you've provided where they have admin or they're just using it in a web browser or they're using it on their own mobile device. There's also the AI that's processing your data through browser extensions. I can't even begin to list all of those. And mobile AI apps on their BYOD that nobody in IT knows anything about or approved.
All of this is shadow AI, and it's probably the biggest AI governance gap that most organizations have right now, and it includes all this plumbing that we're talking about. So your first step is a simple inventory of the AI that's actually touching your data today. You want to inventory both the stuff that's approved and the unapproved stuff, which you're going to have to dig to get that. Listen, I am not telling you that you need a 100% accurate inventory. Don't even try to do that. That should not be your goal. You want a minimum viable inventory.
All right. Where are you going to look? So you're going to check your OAuth integrations, your API keys. You're going to want to look at browser extensions. You're going to want to sniff your network traffic. You're going to want to talk to people. Just go to people who trust you and ask them, "What are you using? I want to know. Not because I want to ban it or block it or get you in trouble. I'm just trying to understand what's all this AI that we're playing with." And bonus, you should do this as well, go to finance and pull payment records. You should be looking at anything that people have purchased over the last, say, 12 months with their company credit cards. So we're talking about recurring subscriptions that they may have purchased AI tools. And expense reports, any records you can get around where people may be spending money on shadow AI.
You're probably going to find that the gap between what you approved and knew of, compared to what you would find when you go on this shadow AI hunt, is going to be pretty big. But I don't want you to get discouraged. This is just the way it is. Look, we're at the beginning of a fundamental transformative technology event. If you were around when mobile devices first started showing up in work settings, very, very similar. When cloud first started showing up, very, very similar. There was a big burst of activity. People started using this stuff that got way out in front of IT. So that's where the shadow IT turn came from, which we've now co-opted into shadow AI. All right, that's the first takeaway. You need to do some kind of inventory. You need to go hunt for this stuff.
Now, the second takeaway is, that configuration is where your risk really lives. Configuration. So remember, Anthropic's leak wasn't about a flaw in their AI. It was a missing entry in the configuration file, an ordinary operational step that got skipped or somehow that line got deleted, I don't know. And Microsoft is making the same point in their research report. They looked at AI apps running on cloud platforms, and they found a recurring pattern: public exposure plus weak authentication. That was the pattern. So some user interface that anyone could reach and a login that wasn't enforced or was weekly enforced, or an API that didn't check who was calling it. Anyway, each one of these was a setting that somebody could have fixed, but they didn't for whatever reason.
Look, when you buy an AI tool, somebody has to configure it. They have to look at permissions, data access, integrations, user roles, API connections. It just depends on how sophisticated and how broad-based the AI tool is will determine how much of this surrounding plumbing you're going to have to know about and spend some time getting right. We've got a customer who spent something like 30 hours over 11 days figuring out what the Microsoft Copilot security configurations were and going through their deployment and getting it all put in.
Now, what's interesting is, right now, Anthropic Enterprise, if you wanted to adopt that, for better or for worse, their security settings aren't nearly as sophisticated as Copilot's. I think we can all guess why. Some people have a really strong opinion about Copilot's performance versus maybe Anthropic's. But the point is that if you're bringing these tools into your environment, you're going to find that the number of things that you can configure is going to be very limited in some cases and overwhelming in others. And that's just where we are, I think, at the beginning of this technological transformation.
Now, most AI tools, like a lot of software, ship with open defaults. They're wide open. Why do they do that? Well, to reduce the friction during the onboarding process. But once you get it onboarded, you've got to go in there and tighten it up. This is not a unique situation to AI tools. This is something that we've needed to do with software for a long, long time, no matter what it was.
All right. So what's the thing you need to do? Here's the practical thing. I want you to go look at the default permissions on every AI tool that you've deployed, the really important ones. Don't start with the small ones that aren't handling sensitive data or doing some critical function. So you want to look at the most important stuff. You want to look at where the different configuration options are. And you need to figure out what are their current settings, what should their settings be. I think most of the time you're going to find that nobody really has spent any time fitting them to your risk profile. So that's your second takeaway.
Now, there's a third takeaway, and that's, vendor AI due diligence isn't optional. If you're trusting a vendor with your data and that vendor is processing it through AI, you need to ask questions that most buyers haven't started asking yet. Let me give you an example what I'm talking about. You should ask them, "How does your AI tool handle session data? Where is it stored? For how long is it stored in those locations? And what happens to my data if your AI crashes in the middle of a task?" You need to ask, "How do you prevent your AI from surfacing one customer's information inside of another customer's view? And what's your build and release process? How many releases do you ship per week?" Those are some examples.
Now, there's a big question too that I haven't even mentioned yet, which is, "Have you had any data exposures or security incidents involving your AI products?" Now, look, if your vendor can't answer those questions clearly, that's a concern. I'm not saying you should panic, but it is a finding, and it's something you need to put on your risk register and you need to track it. Good thing I know where the cough button is. Whoa.
All right. Here's your fourth takeaway. The conversation that you need to have with your board of directors or whoever governs your organization, there's some new questions you need to bring to them. For example, the old board question was, when it came to cybersecurity, they'd say, "Are we secure?" That's a pretty common question. And an old, relatively old board conversation about AI was like, "Well, how much should we invest in AI?" All right, those questions are behind us now. The AI is already in your environment whether you deliberately chose to bring it in or whether it just seeped up through the floorboards as so much of this stuff often does. So the better question now is this: Is our AI adoption speed outrunning our ability to govern what we're adopting?
All right. Now, this isn't a fear-based question, and it's not even an AI-specific question. It's really just a management question. Every board that's lived through a technology adoption cycle where the organization moved faster than its controls will recognize this question. So if we go all the way back, 30 years, it started with the internet. There was mobile computing, cloud migration, there was Bring Your Own Device. When COVID hit, it was about all remote work all the time. AI is just the current version of that same pattern. AI is just moving faster, and it's showing up and working differently than any of those previous technological disruptors did. But look, if you just remind them that this is the same pattern that you've encountered before, that's going to help them. It's going to help them a lot because they already have thoughts, they already have ideas about what was done in order to successfully navigate those transformative technologies, and they're going to be able to see like, "Oh, okay, this isn't really about AI. This is just about good management. This is just about good governance." It's really important that you enable them like that.
Okay. Now, takeaway number five, this is the one that ties everything together. All right? Now, remember I told you that Nate Jones, a guy I follow, you should follow him too if you're interested in all this, he looked at the Claude Code data breach and he found 29 subsystems in there? Remember, he said that the AI model was about 20% of the system and the other 80% was what I think you could reasonably classify as the governance layer: permissions, session management, crash recovery, budget, all that stuff, logging.
Now, my position on this podcast to my customers and in my own head, what I've been saying for years, is that cybersecurity is a business problem. It just wears technical clothing. And I think AI governance is the same. I think the AI itself is pretty exciting. I use it. It can do some amazing things, and I think it works if you're careful, but it's the plumbing. It's the process around it. It's the discipline. That's the part that really determines whether it works safely or not. So really, it's just the same stuff that we've always needed to get right. It's just for AI, it looks a little different.
Listen, Anthropic built the most sophisticated AI safety infrastructure in the world, and they still leaked their source code because of a bad build configuration file. So I want you to realize that the governance layer doesn't just matter. It's actually what most of the system really needs to be focused on. So I don't want you to wait for the AI to fail. That's probably not going to cause you the biggest problems. I want you to focus on the process all around it because that's where you're going to find the real risk and the real gaps.
Okay, those are five takeaways. That should keep you busy for a while. Now, the training that we do takes that, it extends it. We help you build a 90-day plan. I don't have time in the podcast episode to go through that in detail. If you're able to take the training, you can go to secureworld.io/events, and you can look and see what are the trainings that we're going to offer for the rest of the year in North America. And I hope you can attend one. I'm also talking with SecureWorld about doing a virtual delivery of a course. We'll see what happens there. Most of the deliveries are in person. I really like that. I think it really helps to see everybody in the room and actually have a really good conversation, listen to other people, your peers, listen to what they're struggling with. Because again, we're at the beginning of this technological transformation that we're all learning together. And it's really good just to listen to what other people are encountering so that you can be prepared when you encounter it.
Okay. So that's it. That's what I wanted to tell you about AI governance for people who buy AI, not build. I'm sorry it's not that exotic. It's not really bleeding edge. It's just the boring discipline that surrounds any new thing that you're starting to do where you haven't built that boring discipline yet.
Listen, before I wrap up, just a couple more things. If you want to go to that SecureWorld course that I talked about, I wanted to give you the name. It's called Securing & Enabling AI: Transform Chaos into Competitive Advantage. Again, I'll put the link in the show notes so you can go figure out if you can attend that. If you do attend that, I'd love to meet you.
Now, I'm writing a book. Shouldn't be too surprising, right? It's called... I like this title. Hopefully this survives the editing process, but I call it Gears Don't Guess: The Executive's Practical Guide to Thriving in the Face of AI Hype and Risk. Big surprise, what's it about? Well, it's about AI governance for people who buy AI, not really for people who build it. All right? It's really everything I talked about today. It's the buyer's problem, the governance gaps, the five takeaways. It's all in there. Of course, I've given it a lot more depth, a lot more breadth, many, many more real-world examples. I've tried to make it as practical as I possibly can.
This is a moving target, right? So I'm also going to stand up a companion website because there's just no way I'm going to be able to keep everything in the book fresh. Although I'm working very hard to make the manuscript as evergreen as possible. I'm assuming that I can use the companion website to keep you up to date for maybe the next, I don't know, two or three years before I've got to revise the manuscript. We'll see. But I'm targeting a September 2026 launch.
Now, keep listening to the podcast. I'll tell you as that gets closer. If you want more details, I think you should consider subscribing to my email bulletin. It's called Inflection Point. If you've already subscribed to it, thank you. If you haven't, well, what I do is I send out about a 500-word message every other week, and I talk about what's going on in the world outside your four walls. Because you're heads down, you're busy, you're getting stuff done. I watch out for the threat landscape, and I tell you when something really big happens that I think is going to affect you. I don't spam you. I never share your email address with anyone. My list is not about making money. It's just about sharing what I see with you.
So if you want to try it, it's easy to turn it off if you don't like it, but I am going to provide subscribers with more details about the exact publication date. I'm probably going to pre-release a chapter or two. I'm still working on that. So anyway, I'll put the subscription link in the show notes, and you should think about subscribing. I'd love to have you.
All right, that wraps up this episode of the Cyber Risk Management Podcast. Today we talked about three stories. We talked about Anthropic source code leak where the failure happened inside their own walls. We talked about Mercor's supply chain breach where the failure happened in a library they were using that somebody else owned. And we talked about Vercel's fourth-party incident where the failure rode in on an AI tool that nobody had inventoried or knew anything about. The AI in each of these cases worked, but the process around it didn't. And I gave you five takeaways from our AI governance training. I hope that helps you. Thanks for listening. See you next time.

Speaker 1: Thanks for joining us today on the Cyber Risk Management Podcast. If you need to overcome a cybersecurity hurdle that's keeping you from growing your business profitably, then please visit us at cr-map.com. Thanks for tuning in. See you next time.