The Security Deficit

1. Executive Summary

On March 9, 2026, a cybersecurity startup called CodeWall published findings that should unsettle every executive, board member, and investor relying on enterprise AI. Their autonomous offensive agent — an AI system designed to probe for weaknesses — compromised McKinsey & Company's internal AI platform, Lilli, in under two hours. The agent required no credentials, no insider knowledge, and no human guidance. It found its own way in.

What it accessed was staggering: 46.5 million internal chat messages covering strategy, mergers, acquisitions, and client engagements. 728,000 files including confidential documents. 57,000 user accounts. 3.68 million document chunks from the platform's knowledge base. And perhaps most critically, 95 system prompts — the instructions governing how Lilli behaves — all of which were writable. An attacker could have silently rewritten the AI's core behavior with a single database update.

The attack vectors were not exotic. It was a perfect storm of three well-known vulnerability classes: unauthenticated endpoints exposed to the public internet, Insecure Direct Object Reference (IDOR) allowing the agent to enumerate and access resources it was never intended to reach, and SQL injection through unsanitized input handling. Any one of these alone would be a serious finding. But it was the combination that made the breach catastrophic — open endpoints provided the door, IDOR provided the map, and SQL injection provided the keys. These are not frontier attacks. They are failures documented in introductory security courses, compounded by the architecture of an AI system sitting on top of vast stores of sensitive data.

But the technical vulnerabilities are only half the story. The other half is speed. CodeWall's agent autonomously selected its target, mapped the attack surface, identified the vulnerability chain, and achieved full compromise — all in under two hours, with zero human involvement. This is the new reality: AI has become a risk multiplier not just because of what it can access, but because of the velocity at which it operates. Autonomous offensive agents attack at machine speed. Enterprise security teams still defend at human speed — weekly scans, quarterly penetration tests, annual audits, ticket-based vulnerability management. The asymmetry is structural, and it is growing. Every AI system an organization deploys expands the attack surface. Every integration it connects to adds an ingestion vector, an exfiltration channel, and a credential risk. The deployment pace of enterprise AI now outstrips the response cycle of any traditional security operation.

This whitepaper argues that the McKinsey breach is not an isolated incident. It is a preview of what happens when organizations deploy powerful AI systems without treating security as foundational. The threat landscape facing enterprise AI is a dual one: traditional infrastructure and application security failures that are dramatically amplified by AI's access to data, and an entirely new class of AI-native attacks — prompt injection, document poisoning, multimodal manipulation — that most security teams are not yet equipped to detect, let alone defend against.

Vela Intelligence operates at the intersection of these two threat surfaces. We build document-to-decision intelligence systems for regulated, high-stakes environments — private equity due diligence, governance oversight, regulatory compliance, derivatives risk discovery. Our systems ingest large volumes of unstructured documents and transform them into structured, explainable, auditable insights. The security of this pipeline is not a feature. It is the foundation.

This paper examines what went wrong at McKinsey, what the broader threat landscape looks like for enterprise AI, and what principles must govern the design of AI systems that operate in environments where decisions carry real consequences.

2. Case Study: The McKinsey/Lilli Breach

What happened

McKinsey & Company launched Lilli in July 2023 as an internal generative AI platform purpose-built for the firm. It supported chat, document analysis, and AI-powered search across decades of proprietary research. By 2026, approximately 72 percent of McKinsey's workforce — more than 40,000 consultants — used Lilli, generating over 500,000 prompts per month. It was, by any measure, a mission-critical enterprise AI deployment.

CodeWall, a red-team security startup, deployed an autonomous offensive AI agent against Lilli as part of a research exercise. The agent was given no credentials and no insider knowledge of McKinsey's systems. It identified McKinsey as a target on its own, partly based on the firm's publicly available responsible disclosure policy on HackerOne. Within two hours, the agent had achieved full read and write access to Lilli's production database.

What was exposed

The scope of the compromise was severe:

• 46.5 million chat messages — covering corporate strategy, M&A activity, financial analysis, and client engagements, all stored in plaintext
• 728,000 files — including Microsoft Office documents and PDFs containing confidential client data
• 57,000 user accounts — representing the full workforce using the platform
• 3.68 million RAG document chunks — the knowledge base underpinning Lilli's retrieval and analysis capabilities
• 384,000 AI assistants — revealing the internal structure of how McKinsey deploys AI
• 95 system prompts — the foundational instructions controlling Lilli's behavior, all writable

The write access to system prompts is the detail that elevates this from a data breach to something far more dangerous. An attacker who can modify an AI system's prompts can change how it behaves — silently, without deploying code, without triggering conventional security alerts. As CodeWall noted in their disclosure, it would have required nothing more than a single SQL UPDATE statement wrapped in a single HTTP call. Tens of thousands of consultants could have been receiving subtly poisoned advice on financial models, strategic recommendations, or risk assessments — with no way to detect it through conventional means.

How it happened

The attack chain exploited a series of compounding failures, each of which was individually preventable:

Publicly exposed API documentation. Lilli's API documentation was accessible to anyone on the internet. It revealed over 200 endpoints, giving the attacker a complete map of the system's backend surface area.

Unauthenticated endpoints. Of those 200+ endpoints, 22 required no authentication whatsoever. These open doors provided direct access to backend functionality without any credentials.

Insecure Direct Object Reference (IDOR). Once inside the unauthenticated endpoints, the agent was able to enumerate and access internal resources — database records, documents, user accounts — simply by iterating through predictable identifiers. There were no authorization checks verifying whether a given request should be permitted to access a given object. The open endpoints provided the door; IDOR provided the map to everything behind it.

SQL injection in JSON key handling. The final link in the chain was a SQL injection flaw in how Lilli processed search queries. While the values in user queries were properly parameterized — a standard defense — the JSON keys (field names) were concatenated directly into SQL queries. When the agent observed these keys reflected verbatim in database error messages, it recognized a SQL injection opportunity that signature-based security tools typically miss. The open endpoints provided access, IDOR provided enumeration, and SQL injection provided unrestricted read-write control over the production database.

System prompts stored in the same database. The 95 system prompts that govern Lilli's behavior were stored in the same production database as user data, with no separation of privilege. Once the agent had write access to the database, it had write access to the AI's operating instructions.

What this tells us

McKinsey is not a small company with a thin security team. It is one of the world's most prominent consulting firms, one that advises other organizations on technology strategy and AI deployment. It has substantial resources and, presumably, significant investment in cybersecurity. And yet, the vulnerabilities that brought Lilli down — unauthenticated endpoints, IDOR, SQL injection — are among the oldest and most well-documented classes of attack in software security. None of them are novel. All of them are preventable. And it was their combination that made the breach catastrophic: each failure compounded the next, turning a series of individually survivable mistakes into total compromise.

This is the central lesson. The McKinsey breach was not a failure of frontier AI security. It was a failure of basic security hygiene that happened to be connected to an AI system with access to an extraordinary volume of sensitive data. The AI did not create the vulnerabilities. It amplified the consequences beyond anything these same flaws would have produced in a traditional application.

McKinsey responded quickly, patching the identified issues within hours and engaging a third-party forensics firm. The firm stated that its investigation found no evidence that client data had been accessed by CodeWall or any other unauthorized party. But as security analyst Edward Kiledjian noted, the compressed timeline between discovery and McKinsey's public assurance raised questions about whether a full forensic review — including variant analysis and confirmation that the flaw had not been previously exploited — could have been completed in that window.

The uncomfortable truth is straightforward: if one autonomous agent, operated by a security research startup, could achieve full database access in two hours, there is no guarantee that other agents — operated by actors with different intentions — had not already done the same.

3. The Traditional Security Layer: What's Still Being Ignored

The McKinsey breach is a case study in what happens when basic security controls are absent from AI deployments. Before considering the novel threat landscape introduced by AI itself, it is worth examining the traditional security failures that remain disturbingly common across enterprise AI platforms.

Open endpoints and API hygiene

Lilli's API documentation was publicly accessible and revealed over 200 endpoints. This is the equivalent of publishing the blueprint to a building's security system and leaving the doors unlocked. API documentation should never be exposed to the public internet in production environments. Every endpoint should be inventoried, classified by sensitivity, and protected by authentication and authorization controls appropriate to the data it exposes.

The fact that 22 of those endpoints required no authentication is a failure of the most elementary kind. Unauthenticated endpoints in a system connected to millions of confidential messages and hundreds of thousands of files represent an access control gap that no amount of AI sophistication can compensate for.

Authentication and access control

Authentication is not a feature to be added later. It is a precondition for any system that handles sensitive data. Enterprise AI platforms that process confidential documents, client communications, and strategic materials must enforce authentication at every layer — API gateway, application logic, database access, and model invocation.

Beyond authentication, authorization controls must ensure that access is scoped appropriately. Not every user who can query an AI assistant should have access to every document in the knowledge base. Not every API endpoint should permit both read and write operations. Not every service account should have database-level access to system configuration tables.

Input validation and parameterization

SQL injection has been in the OWASP Top 10 since the list was first published. Parameterized queries, prepared statements, and input validation are well-understood, well-documented defenses. The fact that Lilli parameterized query values but concatenated JSON keys directly into SQL reveals a gap in security review — a case where the implementation was partly correct but missed a critical edge case.

This kind of gap is especially dangerous in AI systems because the input surface is unusually large. AI platforms process user queries, document text, metadata fields, API parameters, and retrieval results. Every one of these input channels must be validated. The cost of missing one, as McKinsey discovered, is total compromise.

Least privilege access

The principle of least privilege holds that every component in a system should have access to only the minimum resources required to perform its function. In Lilli's architecture, the compromise of one SQL injection flaw yielded access to the entire production database — user data, chat logs, documents, and system prompts — all in the same store, all with the same permissions.

Least privilege in an enterprise AI context means:

• Network segmentation between AI inference services, knowledge bases, user databases, and system configuration stores
• Read-only access as the default for any component that does not require write capability
• Separate credential scopes for different functional layers, so that compromising one does not cascade into all
• Time-limited and audited access for any administrative or configuration-level operations
• Row-level and column-level access controls on databases containing sensitive information, so that a query for one user's data cannot return another's

These are not AI-specific principles. They are foundational security architecture principles that have been well-understood for decades. Their absence in AI deployments is not a novel risk — it is negligence at scale.

Audit logging and monitoring

An autonomous agent enumerated 200+ endpoints, tested 22 unauthenticated ones, and extracted data from a production database — all in under two hours. The question that should concern every enterprise security team is: would their monitoring infrastructure have detected this in real time?

AI systems generate distinctive traffic patterns. Automated enumeration of endpoints, rapid sequential queries across different database tables, and bulk data extraction all produce telemetry that should trigger alerts in any properly instrumented environment. If an organization cannot detect an autonomous agent conducting reconnaissance across its AI platform, it cannot defend that platform.

4. The AI-Native Threat Layer: What Almost Nobody Is Checking

Traditional security failures are dangerous enough. But enterprise AI introduces an entirely new class of threats: instructions hidden inside the data itself — in documents, images, retrieval corpora, and integrated systems. These attacks do not require access to the model or its infrastructure. They require only access to the content the model reads. Most security teams, penetration testers, and compliance frameworks have not yet adapted to address them.

Read: When Documents Become Attack Vectors →

5. The Convergence Problem

Most organizations treat cybersecurity and AI safety as separate disciplines. Security teams manage firewalls, endpoint detection, access controls, and vulnerability scanning. AI teams manage model performance, prompt engineering, and evaluation metrics. The two groups rarely share a common framework, a unified threat model, or even a regular cadence of communication.

The McKinsey breach demonstrates why this separation is untenable. The attack began with a traditional security failure — open endpoints and SQL injection. It ended with an AI-specific consequence — writable system prompts that could silently alter the behavior of a platform used by 40,000 people. The attack chain crossed the boundary between "infrastructure security" and "AI safety" without pausing to respect organizational charts.

The convergence thesis is this: in enterprise AI, infrastructure security and AI security are the same attack surface. A document ingestion pipeline that does not sanitize inputs is both a data security failure and an AI security failure. An unauthenticated API endpoint that exposes a model's knowledge base is both a web application vulnerability and a RAG poisoning vector. A database that stores system prompts alongside user data is both an access control deficiency and a decision integrity risk.

Organizations that maintain a firewall between their security team and their AI team are creating a gap that attackers will exploit. The most dangerous attacks are the ones that thread through both layers — using a traditional vulnerability to reach an AI-specific target, or using an AI-specific technique (like document injection) to achieve a traditional objective (like data exfiltration).

Unified security governance for enterprise AI means:

• A single threat model that encompasses infrastructure, application, data, and model layers
• Security review processes that evaluate AI-specific risks (prompt injection, RAG poisoning, system prompt integrity) alongside traditional ones (authentication, authorization, input validation)
• Red team exercises that include AI-native attack techniques, not just conventional penetration testing
• Incident response playbooks that account for the possibility that an AI system's behavior has been altered, not just that its data has been exfiltrated
• Continuous monitoring that covers model outputs, prompt integrity, and knowledge base modifications — not just network traffic and endpoint telemetry

6. Principles for Secure Enterprise AI

Defending an enterprise AI system is not a matter of policy documents or review boards. It is a matter of architecture — controls that are embedded in the system's design and that operate at the same speed as the system itself. Six principles govern that architecture: least privilege, zero trust for ingested data, full-pipeline traceability, determinism, separation of instruction and data layers, and human-in-the-loop decision-making.

Read: Six Principles for Secure Enterprise AI →

7. How Vela Intelligence Addresses This

Vela Intelligence was not built and then secured. It was designed, from its foundations, for environments where security failures carry real consequences.

Our platform ingests large volumes of unstructured documents and transforms them into structured, explainable, and auditable decision intelligence. We operate in private equity due diligence, governance and stewardship, regulatory compliance, and derivatives risk discovery. Our users are boards, investors, executives, and regulators. The information we process is confidential. The decisions our analysis informs are consequential.

This context shaped our architecture:

Traceability to source — and through the full pipeline. Every insight Vela produces links back to the specific document, page, and passage from which it was derived. But source citation is the user-facing layer of a deeper commitment. Underneath, Vela implements structured logging across the full pipeline — ingestion, retrieval, inference, output, and configuration changes. Every document that enters the system is hashed and recorded. Every retrieval decision is logged. Every inference call is captured with its context and parameters. This is not telemetry for analytics. It is forensic infrastructure. When an anomaly is detected, the pipeline log enables full reconstruction of what happened, where, and why — the capability that turns incident response from guesswork into investigation.

Explainability by design. Vela does not produce black-box conclusions. Every assessment is justified, every finding is inspectable, and every analytical step is visible to the user. Explainability is what allows a human reviewer to catch the moment when an AI output does not align with the evidence — the moment that may indicate adversarial manipulation.

Reproducibility as a control. Same inputs produce same outputs. Our systems are deterministic by design, which means deviations from expected behavior are meaningful signals, not noise. This is a direct defense against the silent corruption that prompt compromise and document poisoning are designed to achieve.

Controlled integration surface. Vela treats every external connection — every data source, every API, every integration — as an extension of the attack surface, not just the feature surface. Integrations are scoped to the minimum access required, authenticated independently, and monitored for anomalous behavior. The default is no access. Every connection is explicitly justified, bounded, and auditable.

Human-centric architecture. Vela Intelligence is built for human judgment, not to replace it. Our systems inform decision-makers; they do not execute decisions autonomously. This design choice limits the blast radius of any adversarial input that reaches the model — the output is always subject to human review before it influences action.

Built for regulated environments. The industries we serve — financial services, private equity, regulatory compliance — impose standards of accountability, auditability, and data protection that most AI platforms were not designed to meet. We do not treat these requirements as constraints to be managed. We treat them as the design specification.

We do not claim that any system is invulnerable. We claim that the architecture of an AI system should be designed with the assumption that adversarial inputs will reach it — and that the system's response should be containment, traceability, and transparency, not silent failure.

8. Conclusion

The McKinsey/Lilli breach was not an edge case. It was the first widely publicized instance of what will become a recurring pattern: enterprise AI systems compromised through a combination of traditional security failures and AI-specific vulnerabilities, with consequences that scale with the system's access to sensitive data and its influence on human decisions.

The organizations that will navigate this landscape successfully are those that recognize three realities.

First, AI does not exist outside the security perimeter. It is part of it. Every AI system is an application that must meet the same standards of authentication, authorization, input validation, access control, and monitoring as any other application handling sensitive data. The fact that it is powered by a large language model does not exempt it from these requirements — it intensifies them.

Second, AI introduces a new threat surface that traditional security controls do not cover. Prompt injection through document ingestion, multimodal attacks through images, system prompt compromise, RAG poisoning — these are real, demonstrated, and actively evolving attack techniques. Organizations that do not defend against them are not defended.

Third, security in AI systems is not a feature to be added. It is a property of the architecture. It must be present in the design of the ingestion pipeline, the structure of the knowledge base, the separation of instruction and data layers, the traceability of outputs, and the role of human judgment in the decision process. Retrofitting security onto an AI system that was not designed for it is not security. It is risk management theater.

The question is no longer whether enterprise AI will be targeted. It is whether the systems that organizations depend on were built to withstand it.