The Attack Surface Isn't the Model. It's the APIs.

Commissioned, Curated and Published by Russ. Researched and written with AI.

What’s New

The McDonald’s / Paradox.ai story broke in July 2025. The McKinsey Lilli breach via CodeWall.ai landed in March 2026. They’re separated by eight months, two industries, and entirely different AI workflows. The structural failure in both is identical – which is exactly the point.

Changelog

McKinsey’s internal AI platform was breached. Tens of millions of chat messages, hundreds of thousands of files, user accounts, and system prompts were reportedly exposed. The headlines made it sound like AI had gone rogue.

The technical story is simpler and more worrying: the APIs the platform was connected to weren’t properly secured.

That distinction – model failure versus API infrastructure failure – is the one most enterprises are getting wrong right now. And until it gets corrected, incidents like McKinsey and McDonald’s will keep happening.

What actually happened at McKinsey

McKinsey runs an internal AI platform called Lilli. According to reporting from CodeWall.ai, Lilli had more than 200 documented API endpoints. Some of those endpoints were unauthenticated and externally reachable. An autonomous agent found a SQL injection vulnerability via database write access, forged session cookies, and worked through the exposed API surface to reach the data.

The blast radius – tens of millions of chat messages, hundreds of thousands of files, account data, system prompts – wasn’t determined by the model’s capabilities. It was determined by what the weakly-governed APIs allowed.

This matters. The attack wasn’t sophisticated in any model-specific sense. There was no jailbreak. No novel prompt injection. No adversarial manipulation of LLM internals. The agent found exposed APIs, found a write path into a database, and did what any automated tool would do with that access: it kept going.

We’ve covered the accountability dimension of that behaviour elsewhere – see AI agents and the accountability gap. This post is about the infrastructure that made it possible.

The McDonald’s parallel

In July 2025, security researchers Ian Carroll and Sam Curry looked at McDonald’s AI-powered hiring workflow, run through a platform called McHire and built by Paradox.ai. The chatbot – named Olivia – screens applicants, collects contact information, and routes candidates through personality assessments.

The researchers discovered they could access every chat Olivia had ever conducted with McDonald’s applicants. Approximately 64 million records. Names, email addresses, phone numbers. The vulnerability that unlocked it: an administrator account with the username and password both set to “123456”.

McDonald’s blamed Paradox.ai. Paradox.ai confirmed the findings and said no third party other than the researchers had accessed the data. The company has since launched a bug bounty programme.

The chatbot itself was fine. The model wasn’t misbehaving. Olivia wasn’t leaking data through prompt injection or producing outputs it shouldn’t. The problem was the application infrastructure around it – weak authentication, exposed admin endpoints, inadequate access controls on the database layer.

Two incidents. Two different companies, industries, and AI vendors. The same structural failure: organisations connecting AI to application infrastructure faster than they’re securing that infrastructure.

Shadow APIs and the agentic acceleration

Every enterprise has APIs it knows about. Most also have APIs it’s forgotten, never fully documented, or doesn’t realise are externally reachable. In the industry these are called shadow APIs – endpoints that exist in production but sit outside the formal API governance process.

In the pre-agentic world, a shadow API was a quiet risk. Low traffic. Not widely known. Possibly undocumented. An attacker would need to discover it through active reconnaissance, understand its behaviour, and figure out how to exploit it. The friction was real.

In the agentic world, that friction disappears. The moment an agent is connected to a system – or an MCP server with access to that system is deployed – the entire API surface becomes part of the attack surface. Not just the documented endpoints. All of them.

What used to sit quietly for months becomes discoverable at machine speed. An agent doesn’t get tired. It doesn’t need to understand the intent behind an endpoint – it can call it, observe the response, and chain the result to the next call. A hidden endpoint that would have taken a human researcher days to find and map can be enumerated in minutes.

This is the shift that most enterprise AI security strategies haven’t accounted for yet. The McKinsey incident involved 200+ documented endpoints and a set of undocumented or poorly-governed ones. The moment Lilli was connected to that infrastructure, every one of those endpoints became part of the reachable attack surface. The company may have thought of some of them as “internal.” The autonomous agent didn’t make that distinction.

Salt Security has been tracking this as the action layer problem – the idea that enterprise AI security is still overwhelmingly focused on the model layer (prompt injection, output filtering, jailbreaks, model red-teaming) while the real blast radius is determined by what agents can reach and call. That framing is correct, and the McKinsey and McDonald’s incidents are its clearest illustrations to date.

For more on the identity side of this – specifically what happens when a compromised service account has over-broad permissions – see the Stryker / Handala incident breakdown and the 83% identity-origin breach pattern.

MCP servers are the new shadow API class

Model Context Protocol servers are how most enterprise teams are currently connecting AI agents to internal systems – databases, internal APIs, productivity tools, code repositories, ticketing systems. An MCP server sits between the agent and the target system, translating agent requests into actual tool calls.

The governance problem is that most MCP servers are being deployed by developers who didn’t run them through a security review. That’s not a criticism – MCP is new, the tooling is immature, and the security frameworks for it are still being written. But it means the typical enterprise MCP deployment looks like this:

• Exposed on an internal network without authentication
• Granted broad permissions for convenience (“we’ll tighten it up later”)
• Not inventoried in the enterprise API security tooling
• Not subject to the same access control review as production APIs
• Not included in the threat model for the AI system it supports

This is the shadow API problem with a new name. An MCP server with access to an internal database, a ticketing system, or an internal API gateway is functionally an externally-reachable action surface – the moment an agent can reach it, anything that agent can do becomes possible. See the pipeline hardening post for the privilege separation principles that apply here.

The enterprises currently deploying AI agents at scale almost certainly have MCP servers they don’t have a complete inventory of. That inventory gap is the same gap that left some of McKinsey’s Lilli endpoints undocumented and externally reachable.

The four audit questions

The Security Boulevard coverage of the McKinsey incident frames the right questions clearly. For every AI deployment in your organisation:

1. What can this agent reach? Not what it’s supposed to reach – what it can actually reach given the service accounts, network access, and MCP server permissions it’s been granted. Map the reachable surface, not the intended one.

2. What APIs back this workflow? Including third-party APIs. Paradox.ai’s infrastructure backed McDonald’s hiring workflow. McKinsey’s 200+ endpoints backed Lilli. Neither company’s security team had a complete picture of the API surface when the incidents occurred.

3. Which endpoints are exposed externally? This requires active scanning, not documentation review. Documentation describes what was intended. Active scanning finds what’s actually reachable from outside the network perimeter.

4. Which MCP servers exist across the company? Run this query in your infrastructure tooling. If the answer is “we don’t know,” that’s your first priority. Every undiscovered MCP server is a potential Lilli endpoint – connected to internal systems, accessible to agents, outside the security perimeter.

What good AI API governance looks like

The answer to the McKinsey and McDonald’s incidents isn’t better models. It’s applying the same security rigour to the action layer that mature organisations already apply to their production APIs.

In practice that means:

Authentication on internal APIs. The assumption that “internal” means safe is broken in an agentic architecture. If an agent can reach an endpoint, treat it as public-facing from an authentication perspective. mTLS, short-lived tokens, and per-agent service accounts are not over-engineering – they’re baseline.

MCP server inventory. Before the next deployment, run an audit of every MCP server in the environment. What systems does it have access to? What permissions does its service account hold? Is it reachable from outside the segment it’s supposed to be in?

Least-privilege service accounts. The blast radius of the McKinsey breach was determined by what the service account backing Lilli’s API surface was allowed to do. Scoped, read-only credentials for agents that only need to read. Separate write credentials, with tighter controls, for agents that need to write. No shared admin credentials – which is, apparently, still worth saying.

Network segmentation for agent traffic. Agent-initiated traffic should be identifiable, logged, and routable through inspection points. If your current network architecture can’t distinguish an agent calling an internal API from a human-initiated request, you have no way to detect the reconnaissance phase of an attack like the one on Lilli.

Third-party AI vendor review. McDonald’s trusted Paradox.ai’s security posture without adequate verification. That’s not unusual – most vendor security reviews don’t dig into authentication practices for individual admin accounts. That has to change for AI vendors specifically, because their systems sit on top of your data.

Where the next incidents come from

The next generation of AI security failures won’t come from the model layer. They’ll come from agents sitting on top of weak action layers – exposed APIs, unauthenticated services, forgotten integrations, under-governed MCP servers.

The security industry is still calibrated for the previous problem. Red-teaming models, hardening prompts, filtering outputs – these are worth doing, but they address a different attack vector than the one that compromised McKinsey’s Lilli and McDonald’s McHire.

Both incidents were straightforward API and authentication failures. The AI element amplified the discovery speed and the blast radius. The vulnerability was infrastructure.

The audit starts with one question: what can this agent actually reach?