Topic starter
24/06/2026 7:33 pm
TL;DR: McKinsey’s Lilli breach showed that authenticated tokens do not prove an AI agent was the right actor, approved for the right action, or operating under the right identity, according to 1Kosmos. The incident is a reminder that enterprise AI security now depends on continuously verifiable agent identity and action-level authorization, not endpoint-only controls.
Editorial analysis by NHI Mgmt Group, based on content published by 1Kosmos: “McKinsey Lilli Breach (2026): What It Reveals About Agent Authentication”.
By the numbers:
- An autonomous agent exposed 46.5 million chat messages, 728,000 files, 57,000 user accounts, and 95 system prompts in the Lilli breach.
Key questions
Q: What breaks when multiple AI agents can act on the same authentication system?
A: The main failure is unresolved authority.
Q: Why do AI agents create accountability problems for IAM and NHI teams?
A: AI agents create accountability problems because traditional IAM proves who authenticated, while agent governance must prove what the actor did with that access.
Q: How should security teams govern AI systems that can act without human approval?
A: Security teams should govern autonomous AI the same way they govern other high-risk identities, but with runtime enforcement instead of periodic review.
Practitioner guidance
- Map AI agents to explicit identities Inventory every production agent, assistant, and automation that can call internal tools or data sources, then assign a unique identity to each one rather than sharing service credentials.
- Classify high-risk agent actions Define which agent operations require human approval, especially write access, cross-user data access, and prompt or configuration changes that can alter system behaviour.
- Separate behavioural policy from ordinary data storage Move system prompts, guardrails, and control logic into protected stores with stricter write controls and monitoring than standard application data.
Bottom line: The Lilli breach shows that a valid token can still belong to the wrong actor, the wrong action, or the wrong delegation path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 4:54 am
AI agent identity is the control plane that failed, not the token. The Lilli breach shows that entry-point authentication can be technically correct and still operationally irrelevant when the actor is an AI agent making consequential decisions. In this case, the security question was not whether a caller held a token, but whether the specific agent was legitimate, scoped, and authorised for the action it attempted. Practitioners should treat agent identity as a first-class governance object, not a by-product of API access.
A question worth separating out:
Q: What is the difference between authenticating an AI agent and authorising it?
A: Authentication proves the agent is known to the system, while authorisation limits what that agent can do after it is admitted. For MCP workflows, this difference matters because a valid login does not prevent overbroad tool use, data access, or action chaining across multiple services.
👉 Read our full editorial: AI agent identity is the real failure in the Lilli breach