Blog
Security
Mar 16, 2026

The McKinsey Lilli Breach: Why AI Security Must Move to Runtime

Yash Prakash
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

The recent breach of McKinsey’s internal AI platform, Lilli - uncovered by researchers at Codewall - is a reminder that AI security is not just about "prompt injection." It highlights a structural misalignment in how enterprises secure the next generation of applications.

The attack itself was not sophisticated. There were no stolen credentials, phishing campaigns, or complex supply chain compromises. Instead, an autonomous offensive agent simply mapped the attack surface, discovered 22 exposed APIs, and exploited traditional application flaws to move laterally. Within minutes, it gained read and write access to the underlying database, including the system prompts governing the platform’s behavior.

The lesson here is universal: This could happen to any enterprise. However, the takeaway is urgent. Because AI systems are designed to be autonomous and highly integrated, the impact of a breach is disproportionately higher than in traditional apps. For these systems, security can no longer be a perimeter check; it must move to runtime.

Anatomy of the Breach: A Familiar Chain with a New Impact

The Codewall research describes an attack chain that followed a familiar progression, but with a uniquely AI-centric "prize" at the end:

  • Discovery: The agent identified 22 undocumented API endpoints lacking authentication. These were accessible over the internet, providing a direct "front door" to backend services.
  • Exploitation: A blind SQL injection vulnerability allowed the attacker to manipulate backend queries, gaining visibility into the database structure.
  • Lateral Movement: The attacker exploited an Insecure Direct Object Reference (IDOR) to cross user boundaries, exposing search histories and internal data of other consultants.
  • The AI "Kill Chain": The final step was the most critical. Because system prompts were stored in the same backend environment, the attacker could modify the instructions governing the AI’s behavior.

At this point, the attack moved beyond data exposure. The attacker gained the ability to influence how the AI platform operated for thousands of users, essentially hijacking the system's "personality" and logic.

Why Traditional Controls Failed the AI Test

Most enterprise architectures rely on a combination of Identity Providers (IdP), API Gateways, and hard-coded application logic. While these work for predictable, monolithic applications, AI platforms introduce dynamic variables that break static security assumptions:

  • Exploding API Surface Area: Large AI platforms accumulate hundreds of internal APIs. Developers often assume authentication is "someone else’s problem" upstream, leading to the unprotected endpoints.
  • Fragmented Authorization Logic: When authorization lives inside application code, it is implemented inconsistently across services. This is where IDOR and privilege escalation vulnerabilities hide.
  • High-Value AI Assets: Organizations are used to protecting databases. They are not yet used to protecting system prompts, model configurations, RAG pipelines, and vector stores. Compromising these doesn't just leak info; it changes what the system does.

The Disproportional Risk of the AI Attack Surface

To secure these systems, we must view them through their operational architecture. A modern AI platform is an ecosystem: Users talk to Agents, Agents invoke MCP Servers and Tools, and Models query Vector Stores for context.

In this environment, the impact of a single vulnerability is magnified. A compromised agent doesn't just stay in its lane; it uses its broad permissions to misuse tools and extract corporate knowledge. Securing this requires governing the interactions between these components, not just the identity of the person at the keyboard.

The Solution: Shifting to Runtime Enforcement

The central lesson from this breach is that security decisions must occur at the moment of interaction. Identity systems tell you who is making a request. They cannot tell you if a specific agent action is safe in a specific context. In an AI platform, thousands of these "mini-decisions" happen every minute. Embedding this logic into code leads to the exact fragmentation that attackers exploit.

Runtime Authorization interrupts the attack chain by externalizing these decisions:

  • Default Deny: Every API request must pass through a centralized policy evaluation point. No identity or context? No access. The 22 exposed endpoints would have been neutralized instantly.
  • Object-Level Governance: Policies determine which agent or user can access which specific object at runtime, rendering IDOR exploits useless.
  • Resource Integrity: Critical assets like system prompts and vector indexes are placed behind strict, immutable policies. Only authorized service accounts can modify them, with every attempt logged and audited.

The Shift for Security Leaders

The Lilli breach isn't an isolated incident; it’s a preview of the "Agentic" attack surface. As enterprises rush to build AI-native systems, the risk of a breach is high, and the impact could be devastating.  

Security leaders must move away from treating authorization as an implementation detail buried in code. Instead, it must be treated as a governed runtime capability. This shift is the core of our work at Reva.AI. We are building the runtime adaptive access control plane that governs how agents, APIs, and data models interact. In an AI-driven world, security is no longer just about credentials - it’s about governing every decision the system makes in real time.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.