SQL Injection Is a 1998 Bug. In 2026 It Just Breached an AI Platform Used by 40,000 People.
An autonomous agent needed $20 and two hours to get full read/write access to McKinsey's AI platform, using a vulnerability older than Google. Here's what 'is this secure?' needs to mean when buying AI tools.
An autonomous agent spent $20 and two hours to get full read and write access to Lilly, the AI platform 70% of McKinsey's 40,000 consultants use daily, tens of millions of chat messages, tens of thousands of accounts, every system prompt governing how the platform reasons. The exploit was SQL injection, first documented in 1998.
The bug wasn't the story
McKinsey has a strong engineering team. Lilly had been in production more than two years. The vulnerability that let an outside researcher walk in without credentials or insider help wasn't exotic, it's taught in every introductory web security course. McKinsey patched it within hours of responsible disclosure.
The postmortem instinct is to call this technical hygiene: authenticate your endpoints, sanitize your inputs, treat the AI platform like production. All true, all beside the point. Twenty-two of Lilly's 200 API endpoints shipped with no authentication at all, more than one in ten. That's not one engineer skipping a checklist on a Friday. At that scale, it's a default. Somewhere, the assumption baked into how the platform got built was that this level of scrutiny wasn't required.
Why agents find what humans never would
A human consultant pulling together a client brief opens a few systems, glances at what's visible, and moves on. The screen does the permissions work for them, if they shouldn't see something, it isn't there. An agent doing the same task has no screen. It asks each system, in code, "am I allowed to read this?", and every one of those systems needs a real, enforced answer, not an assumed one.
That's the shift. Procurement built for the last fifteen years (strategic decision, contract, security review, integration, then developers build against whatever got purchased) worked fine for bounded SaaS like Salesforce or Workday, because a human was always the one clicking through the screen. Agents don't click. They probe every reachable boundary, and at machine speed they eventually reach the ones nobody thought to lock, the same way this one did.
What actually changes when you're buying
Three questions matter more than "is this platform secure," and none of them are exotic either.
Does the platform know an agent from a human? A consultant might legitimately have read access to dozens of client accounts built up over years. An agent working one client's renewal should only be able to touch that account. If the platform can't enforce that distinction, one compromised agent becomes a company-wide exposure event.
Can you audit what the agent did, not just what the user asked for? Regulators don't ask what the user requested, they ask what the system did on the user's behalf, and whether you can prove it.
Can someone revoke the agent's access in the next five minutes? Not file a ticket. Not wait for a deploy. From a console, now.
| Human-operated software | Agent-operated software | |
|---|---|---|
| Permission model | Enforced by the screen | Must be enforced in code, every call |
| Failure mode | One person, one mistake | Probed systematically, at machine speed |
| Audit question | What did the user do? | What did the system do on the user's behalf? |
| Time to revoke | Rarely urgent | Needs to be minutes, not days |
What this means if you're buying marketing AI
Marketing platforms are adding agents fast, ones that touch CRM records, ad accounts, customer data, send access. None of that is exempt from this pattern. The old procurement question was "is this vendor secure?" The one worth asking now is whether the platform was built assuming an agent, not a person, might be the one calling the API. If it wasn't, the same kind of open door is probably sitting in the product you're about to sign for, waiting for something that moves faster than a human ever could to go looking for it.
FAQ
Was this really a McKinsey-specific failure? Doesn't read that way. The pattern, governance arriving after the software already shipped, shows up across a lot of enterprise AI builds; McKinsey is just the one that made the news.
Does better AI model quality fix this? No. The exploit had nothing to do with model capability. It was an unauthenticated endpoint an agent happened to be capable enough to find and use.
Is SQL injection actually still common? It's decades old and well understood defensively, the surprise isn't that the bug exists, it's that scale and unfamiliarity with agentic access patterns let it survive in production this long.
Sources
- Code Wall (2026) Disclosure of a SQL injection breach granting full read/write access to Lily, described as the AI platform used daily by 70% of McKinsey's 40,000 consultants, for $20 and two hours of work, 28 February. Referenced in source material; original disclosure not independently reviewed by Markedeen.
Want a system like this in your business?
We build the automation behind everything you just read.