AI agent identity and Lilli: what IAM teams need to know

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.

NHIMG editorial — based on content published by 1Kosmos covering the McKinsey Lilli breach: AI agent identity, authentication, and action authorisation

By the numbers:

• 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 95 system prompts.

Questions worth separating out

Q: What breaks when AI agents rely on token-based authentication alone?

A: Token-based authentication proves that a caller presented valid credentials, but it does not prove the caller is the intended agent, that the action was authorised, or that a human approved a consequential step.

Q: Why do AI agents complicate traditional IAM and PAM controls?

A: AI agents can decide, chain tools, and execute actions faster than periodic IAM and PAM processes can review.

Q: How can organisations tell whether an AI agent is acting within scope?

A: They need policy that binds each agent to a specific role, data boundary, and action class, then records whether each high-risk operation was approved or blocked.

Practitioner guidance

• Bind each AI agent to a distinct identity Replace shared service account patterns with per-agent identities that can be verified as the specific registered agent instance, not just as a valid credential holder.
• Separate read paths from write paths Classify database writes, prompt changes, and configuration edits as distinct privileged operations, then require explicit authorisation for each privileged action path.
• Require approval for consequential actions Use a human approval gate for operations that can change model behaviour, expose cross-user data, or modify production policy, even when the request originates from a trusted agent.

What's in the full article

1Kosmos's full analysis covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of the authentication chain used in the Lilli scenario and where conventional controls stop.
• Concrete explanation of cryptographic agent identity binding and how it changes trust decisions at runtime.
• Detailed examples of CIBA-style approval flow for high-risk AI agent operations.
• A side-by-side comparison of traditional token checks versus identity-bound agent authorisation in production workflows.

👉 Read 1Kosmos's analysis of the McKinsey Lilli AI agent identity breach →

AI agent identity and Lilli: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →