The McKinsey AI Hack Was a Procurement Failure

Twenty dollars. Two hours. Full read-write access to the internal AI platform used by roughly 28,000 McKinsey consultants.

That's the number that stops you cold. Not because the attack was sophisticated—it wasn't, it was SQL injection, a technique first documented in 1998 and covered in week two of every intro web security course—but because of what sat on the other side of that door. Tens of millions of chat messages. Tens of thousands of user accounts. And, most consequentially, every system prompt governing how the platform reasons. All of it writable. An attacker could have silently rewritten the instructions shaping how AI advises the consultants who advise the largest companies in the world.

The platform is called Lily. The security research firm that found and responsibly disclosed the vulnerability is called Codewall. McKinsey patched it within the hour after disclosure on March 9th. So by the standard postmortem checklist, this is a closed incident: authenticate your endpoints, sanitize your inputs, treat AI platforms like production systems. Done. Lesson learned.

Except that framing is exactly what AI strategy analyst Nate B. Jones pushes back against hard in a recent breakdown of the incident—and he's onto something worth sitting with.

The number that actually matters

The headline vulnerability is not the story. The story is 22 of 200 API endpoints shipped without authentication. Not one. Not two. Twenty-two.

As Jones puts it: "22 of 200 endpoints shipped with no authentication. That's not a random mistake. That's a pattern. That's a platform where maybe the default or maybe the assumption is that you can push to prod without that level of scrutiny on your endpoint."

Framing this as "someone forgot to lock the door" lets the real problem walk out the back. A single forgotten authentication check is a training problem. Twenty-two unauthenticated endpoints at a platform used by tens of thousands of professionals—including one with production write access—is a culture and structure problem. It means the question "is this endpoint safe to call from an autonomous agent?" was probably never on the checklist. Because two years ago, when Lily launched, that question wasn't urgent. Autonomous agents that could methodically probe public API surfaces for misconfigurations weren't a routine threat. In 2026, apparently, they are.

That's a shift most enterprise software wasn't designed to absorb.

How the old buying sequence breaks

Enterprise software procurement has run the same play for about fifteen years: executive decision, procurement negotiation, security and compliance review, IT integration planning, developers build against whatever was already purchased. It works cleanly for SaaS because SaaS is bounded. Salesforce gives you an admin console, a defined API surface, a permissions model that maps to human roles. Configuration, not construction.

AI agents are not SaaS. They are, in Jones's framing, "extremely unbounded," and that changes everything about what the procurement sequence is actually committing you to.

Consider what an agent does on a single real task—say, "prepare the renewal brief for our largest customer." It has to reach the CRM, support tickets, contract management, product usage data, call transcripts, internal wikis. It crosses permission boundaries that, for a human, are mediated by what's visible on a screen. If a human consultant shouldn't see something, the screen doesn't show it. The UI is the permissions model.

An agent has no screen. It queries each system directly in code, and each system has to return a programmatically enforceable answer about what the agent is allowed to do. That answer has to be auditable. And every individual audit has to compose coherently with every other one when a regulator later asks what the system did on behalf of the user.

"None of this exists by default," Jones notes. "All of it is engineering work that someone has to do against a deadline before the agent ships."

When developers are the last people in the buying sequence—arriving after the contract is signed, the integration architecture is assumed, and the roadmap is already promised to the business—that engineering work either gets skipped, rushed, or discovers six months in that the platform wasn't actually buildable for the job it was purchased to do. The Lily incident is one version of that discovery. The $20 receipt arrived before the internal reckoning did.

What the vendor announcements actually signal

The timing of what's happened in the market this week is hard to ignore. Within roughly the same window that the Lily story has percolated through the industry, six major vendors made announcements that all point at the same gap:

Anthropic and OpenAI both launched enterprise services practices—billions of dollars committed to putting engineers inside customer build rooms. SAP acquired Dreo and Prior Labs to bring unified data layers to where actual business records live. Pinecone launched Nexus to stop agents from reassembling business context from scratch on every run. Salesforce shipped Headless 360, exposing their platform as APIs and CLI commands because agents don't navigate UIs. ServiceNow opened Action Fabric so external agents can trigger governed workflows through a surface with identity and audit attached.

Jones's read: "Every single one of those vendors is now selling you the thing your AI roadmap was supposed to already have—reachable surfaces, governed action, permission-aware data, cheaper context assembly."

That's a fair observation. It's also worth holding a tension the video doesn't fully resolve: these announcements could mean the market is maturing responsibly, or they could mean vendors are productizing the gap between what they sold and what actually works, and charging enterprise customers to close it. Both can be true. The question for any organization evaluating these offerings is whether the complexity is genuinely being solved or just being relocated to a different line item.

The two questions that actually stress-test your stack

Jones lands on two diagnostic questions that cut through vendor positioning in a way I find genuinely useful, so I'll pass them along directly.

First: Does your platform know the difference between a human user and an AI agent?

This is less obvious than it sounds. A senior consultant might have read access to forty client accounts built up over five years of work. An agent running on a single client engagement should probably touch exactly one client account. If the platform doesn't enforce that distinction—if agent permissions simply inherit whatever the sponsoring human user has—then one compromised or misconfigured agent becomes a company-wide exposure event. That's not an IT problem. That's a board-level liability conversation.

Second: What does your platform default to when the team is moving fast?

This is where the Lily story gets uncomfortable for organizations that want to believe the fix is policy. Jones asks the right version of the question: not "does your platform support strong authentication?" but "what does it do when your engineers don't have time to configure it correctly?" If the default state is unauthenticated, if agents ship with broad write access because nobody had two hours to scope it down before the deadline, then you're building your security posture on the assumption that your team will always have the time and organizational permission to do it right. That assumption tends not to survive contact with a real launch date.

"The question we should be asking is why wasn't there a default behavior set that would have captured this error as a team default operating procedure before any endpoint shipped at all," Jones argues. "That is an organizational design question, not a technology question."

He's right that it's organizational. What's less clear is whether the fix is primarily internal culture change, vendor design responsibility, or regulatory pressure forcing minimum standards—and reasonable people in security circles disagree about which lever moves the most weight. The industry's track record of self-correcting on defaults, without external pressure, is not inspiring.

What to do with this before you sign anything

McKinsey has resources most organizations don't. Their engineering team is genuinely strong. Lily had been in production for two years. And still: 22 unauthenticated endpoints, one with production write access, one autonomous agent, $20, two hours.

"I don't think Lily was an isolated thing that is special to McKinsey," Jones says. "Lots of organizations struggle with this and I think McKinsey got unlucky."

Getting unlucky means being the one that made the news. The underlying conditions—agents bolted onto platforms designed for human screen navigation, developers arriving after procurement closes, security reviews that haven't updated their threat models for agentic access—those conditions are not unique to one consulting firm's internal platform.

The uncomfortable implication is that somewhere right now, there's another Lily. Maybe it's a platform you signed last quarter. Maybe it's one you're evaluating this week. The question isn't whether to buy or build. It's whether the people in your organization who understand what an autonomous agent actually touches when it runs—which systems, which permissions, which audit trails, which blast radius if something goes wrong—are in the room before you commit, not six months after.

The model was never the hard part. It turns out the hard part is everything the model has to touch to do anything useful.

---

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent. Former white hat hacker and corporate InfoSec director.