The McKinsey Lilli breach exposed a critical gap in enterprise AI security: traditional authentication validates tokens, but it cannot verify whether an AI agent's specific action was authorized, whether a human approved it, or whether the agent itself is legitimate. The fix isn't better passwords; it's treating agent identity as continuously verifiable and requiring human approval for consequential operations.
On March 9th 2026, McKinsey announced that a security firm called CodeWall pointed an autonomous offensive AI agent at the open internet, let it choose its own target, and walked away. Two hours later, it had full read-write access to McKinsey & Company's internal AI platform, exposing 46.5 million chat messages, 728,000 files, 57,000 user accounts, and the system prompts that governed how the AI responded to every one of the firm's 40,000+ consultants.
This was not a nation-state actor or a sophisticated zero-day exploit. It was SQL injection, a vulnerability class that has been on the OWASP Top 10 list since the early 2000s, discovered by a machine, in under two hours, in a platform that had been in production for over two years.
The breach generated considerable commentary. Most of it focused on the SQL injection itself, and on the fact that 22 of Lilli's API endpoints required no authentication whatsoever. Both are fair observations. But the more important conversation, the one that actually changes enterprise AI security posture, requires asking a harder question: even if McKinsey had authenticated every one of those endpoints, would they have been safe?
The answer is no, and understanding why is what separates a security patch from a security architecture.
What actually happened
McKinsey's Lilli platform is a large-scale internal AI assistant built on top of a retrieval-augmented generation (RAG) pipeline. By the time of the breach, it was:
Processing 500,000+ prompts per month
Connected to decades of proprietary research
Used by 70% of the firm's global workforce for strategy work, competitive analysis, and client research
Step 1: Reconnaissance
CodeWall's agent began with reconnaissance. It found that Lilli's API documentation was publicly accessible, with over 200 endpoints fully documented and available to anyone who looked.
Of those, 22 required no authentication at all. One of those open endpoints accepted user search queries and wrote them to the database.
Step 2: The non-obvious SQL injection
The SQL injection itself was non-obvious. The input values were safely parameterized, which is the standard defense. But the JSON field names-the keys passed alongside those values-were concatenated directly into the SQL query without sanitization.
Standard automated scanners, including OWASP ZAP, missed it entirely. The CodeWall agent found it through 15 blind iterative probes, watching error messages for reflections of the query structure, escalating from "something is wrong here" to "I now have full database access" without a human ever reviewing the output.
Step 3: Silent rewrite
From there, the agent didn't just read. It wrote.
Lilli's system prompts-the instructions governing how the AI reasoned, cited sources, applied guardrails, and responded to every consultant query-were stored in the same database. A single UPDATE statement could rewrite them silently. No deployment. No code change. No alert.
The breach was devastating not because data was stolen, but because the AI's behavior itself was writable by anyone who reached the database.
The obvious fix and why it only goes so far
The unauthenticated endpoint problem is real, and it is solvable with tools that have existed for years.
An API gateway (AWS API Gateway, Kong, Apigee, Azure API Management) can enforce authentication as a platform-level policy. Every endpoint gets covered, regardless of what individual developers did or didn't configure. API posture management tools like Salt Security or Noname Security can continuously inventory all exposed endpoints and surface the ones missing authentication controls before any attacker does. Standard OAuth 2.0 token enforcement, zero-trust network segmentation, and shift-left security testing in the CI/CD pipeline would all have closed the door the CodeWall agent walked through.
McKinsey had the resources to implement every one of these. They didn't. That is a governance failure, and it deserves to be called one directly.
ut here is where the honest analysis has to go further: Fixing the 22 unauthenticated endpoints, deploying the API gateway, and enforcing OAuth on every call stops this attacker. The architecture that allowed it remains untouched.
What about the next one?
Standard authentication answers one question: is this caller authenticated? But it does not answer the questions that matter most in an agentic AI environment:
Who is this agent, not the human who owns it, but the agent itself?
What has it been explicitly authorized to do in this session?
Did a human approve this specific action, or is the agent operating on assumed permissions?
If this agent is one node in a multi-agent chain, who vouched for the node upstream?
These are not hypothetical future concerns. They are the exact threat surface that enterprise AI deployments expose today, and they are invisible to traditional authentication infrastructure.
The authentication gap in agentic systems
Enterprise AI platforms like Lilli are not simple applications. They are orchestration layers connecting language models to internal data stores, external APIs, RAG pipelines, and increasingly, other AI agents. Each connection in that chain is a potential trust boundary. Most enterprise authentication frameworks were not designed with that topology in mind.
When an AI agent makes an API call, traditional auth infrastructure sees a token. It validates the token, confirms the caller is authorized to use the system, and passes the request through. What it cannot see is:
Whether the agent is acting within its intended scope. A service account token for an AI assistant authorizes calls to the system. It does not encode whether the specific action being attempted was sanctioned for this session, this user, or this risk level.
Whether a human approved the action. High-risk operations such as writing to a database, modifying system configuration, or accessing cross-user data may be technically permitted by the token but were never explicitly approved by a human in the loop. The token carries no signal about whether the person who owns it intended for this action to happen.
Whether the agent identity has been cryptographically bound. A stolen or replayed service account token presents identically to a legitimate one. There is no mechanism in standard OAuth flows to verify that the agent presenting the token is the specific, registered agent that was issued the token, rather than an impersonator that acquired it.
Whether delegation was authorized at each hop. In multi-agent architectures, Agent A may invoke Agent B, which invokes Agent C. Each hop may pass credentials forward. By the time a request reaches a sensitive endpoint, the original authorization context may be entirely lost, and the endpoint has no way to know whether any human ever approved the chain of actions that led here.
The McKinsey breach exploited the first gap. The 22 unauthenticated endpoints gave the attacker a path that bypassed the token check entirely. But the more dangerous scenario is not the absent token; it is the valid token used by the wrong caller, for the wrong action, without any human ever knowing it happened.
What 1Kosmos adds to the agent authentication chain
The 1Kosmos approach to agent authentication is built around a fundamentally different premise: authentication is not a yes/no gate at the entry point. It is a continuous, cryptographically verifiable chain of identity and authorization that travels with every agent action from initiation to execution.
Cryptographic agent identity binding
In a 1Kosmos-integrated architecture, agents are not identified by shared service account credentials. Each agent instance carries a cryptographically bound identity, one that cannot be replayed, delegated without explicit authorization, or impersonated.
When an agent presents credentials, the verifying system can confirm not just "is this caller authenticated" but "is this the specific registered agent that was issued these credentials, operating on the device and in the context it was registered for."
In the Lilli scenario, this would have meant that even if an attacker somehow obtained valid-looking credentials, the cryptographic binding would have failed. The credentials do not travel independently of the identity they were issued to.
Human-in-the-loop for high-risk actions
Using a CIBA (Client-Initiated Backchannel Authentication) pattern, 1Kosmos enables a second authorization layer specifically for consequential operations.
When an agent attempts an action above a defined risk threshold, such as writing to a production database, modifying system configuration, or accessing cross-user data, the system does not rely on the initial authentication event to authorize it. It initiates a backchannel request to a human approver in real time.
This is the control that would have stopped Lilli's system prompt rewrite. The SQL injection enabled write access. But in a 1Kosmos-integrated architecture, a write operation to the prompts table, classified as a high-risk, system-level change, would require explicit human authorization before execution. The attacker's UPDATE statement would have been caught not at the network layer, but at the action authorization layer, by a human who never approved it.
Delegated authorization with chain-of-custody
When agents invoke other agents, 1Kosmos maintains a verifiable authorization chain at each hop. Each delegation event is cryptographically recorded: which agent invoked which, what scope was passed, and whether a human explicitly authorized the delegation or whether it was assumed. A downstream agent cannot claim permissions that were not explicitly delegated to it, and the system can prove, after the fact, exactly what was authorized at each step.
Identity-aware least-privilege enforcement
Rather than mapping permissions to service accounts, 1Kosmos maps permissions to specific agent identities operating within specific scopes.
An agent authenticated to support chat queries has no path to the system prompts table, not because of a missing token, but because its identity-bound authorization scope does not include that resource, regardless of what technical access the underlying service account might otherwise have.
Traditional authentication vs. 1Kosmos agent authentication
The difference between legacy token-based approaches and identity-bound agent authentication is architectural:
Security Capability | Traditional Authentication (OAuth/API Gateway) | 1Kosmos Agent Authentication |
|---|---|---|
What Gets Verified | Token validity and user authorization | Cryptographic agent identity, action scope, and human approval |
Identity Model | Shared service account credentials | Cryptographically bound per-agent identity |
Credential Security | Tokens can be stolen, replayed, or impersonated | Identity-bound credentials tied to specific agent instance |
Action Authorization | Assumes all actions valid if token is valid | Requires explicit authorization per high-risk action |
Human Oversight | No mechanism for real-time human approval | CIBA-based human-in-the-loop for consequential operations |
Multi-Agent Delegation | No visibility into delegation chains | Cryptographic chain-of-custody at each hop |
Scope Enforcement | Permission mapped to service accounts | Permission mapped to specific agent identities and scopes |
Post-Incident Visibility | "Who accessed?" | "Which agent? Was it authorized? Did a human approve?" |
What It Prevents | Unauthenticated access | Unauthorized agent actions, even with valid credentials |
The architecture that changes the question
The McKinsey breach is a useful case study precisely because it involves two distinct attack surfaces, and the second one is far harder to close with existing tooling.
Surface one: Unauthenticated endpoints
The first surface is the unauthenticated API endpoints. That is a solvable problem. API gateways, OAuth enforcement, and posture management tools close the door. McKinsey should have deployed them. Any enterprise running a production AI platform without these controls in place should treat this incident as a direct warning.
Surface two: The implicit trust problem
The second surface is what sits behind authenticated endpoints: the implicit trust that a valid token grants an agent unlimited latitude to act within whatever the token technically permits.
That surface is not closed by authentication enforcement. It requires a different architecture, one that treats:
Agent identity as continuously verifiable
Agent actions as individually authorizable
Human oversight as a structural control rather than an afterthought
Verify always, trust only what's granted
The consulting industry talks a great deal about "trust but verify." In enterprise AI security, the correct posture is verify always, trust only what has been explicitly granted, and require human approval for anything consequential.
That is not a new philosophy. It is the same principle that governs privileged access management for human users in sensitive environments. What is new is applying it to the AI agents that are now operating alongside those users, often at machine speed, often with broader data access, and often without the oversight mechanisms that would be standard for any human performing the same actions.
The window to build this correctly is now
The window to build this correctly is now, while enterprise AI architectures are still being established. The Lilli breach happened in a production system that had been running for two years. The governance gaps it exposed were baked in from the start. Retrofitting identity-aware agent authentication into a scaled AI deployment is substantially harder than designing for it at the outset.
The questions every AI team should ask
The question every enterprise AI team should be asking is not "are our endpoints authenticated?" (though they should be). It is:
"If one of our agents did something it should not have done, would we know?"
"Could we prove it did not happen?"
"And could we have stopped it before it did?"
Authentication answers the first question. Agent identity, authorization chains, and human-in-the-loop controls answer the other three.
—
FAQs
What is AI agent authentication and why is it different from regular API authentication?
AI agent authentication verifies not just that a caller has valid credentials, but that the specific agent is authorized for each action it attempts. Unlike traditional API authentication that validates tokens at the entry point, agent authentication maintains a continuous chain of identity and authorization throughout multi-agent workflows, with human approval required for high-risk operations.
How did the McKinsey Lilli breach happen?
An autonomous AI agent found 22 unauthenticated API endpoints in McKinsey's Lilli platform through publicly accessible documentation. It exploited a SQL injection vulnerability to gain database access, then rewrote the AI's system prompts—changing how the AI behaved without any code deployment or alerts.
Would traditional OAuth or API gateway solutions have prevented the Lilli breach?
They would have prevented the initial access through unauthenticated endpoints, but not the broader vulnerability. Even with proper authentication, traditional approaches can't verify whether an agent's specific action was sanctioned, whether a human approved it, or whether the agent operating is the legitimate one vs. an impersonator with stolen credentials.
What is CIBA and how does it secure AI agents?
CIBA (Client-Initiated Backchannel Authentication) enables real-time human approval for high-risk agent actions. When an AI agent attempts a consequential operation like modifying system configuration or accessing sensitive data, CIBA triggers a backchannel authorization request to a human approver before the action executes.
What are the key questions every enterprise should ask about their AI security?
Beyond "are our endpoints authenticated?", ask: If one of our agents did something it shouldn't have, would we know? Could we prove it didn't happen? Could we have stopped it before it did? Traditional authentication only answers the first question.
What is cryptographic agent identity binding?
It's a security approach where each AI agent instance carries a cryptographically bound identity that cannot be replayed, delegated without authorization, or impersonated. This ensures the system can verify not just valid credentials, but that the specific registered agent is making the request.
—
Huzefa Olia is COO at 1Kosmos, where he leads identity and authentication product for enterprise and government organizations.
