AI agent identity is the real failure in the Lilli breach

At a glance

What this is: This is a 1Kosmos analysis of the McKinsey Lilli breach, arguing that token-based authentication is not enough for AI agents because it cannot verify action authorisation or agent legitimacy.

Why it matters: It matters because IAM, NHI, and PAM teams now have to govern AI agents as active identities with bounded authority, not just authenticated callers.

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.

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

Context

AI agent identity is becoming a governance problem, not just an authentication problem. In the McKinsey Lilli breach, the issue was not only whether a token was valid, but whether the agent behind it was legitimate, authorised for the specific action, and approved for a consequential change.

Traditional IAM assumes a stable caller, a known session, and a clear boundary between login and action. That model weakens when an AI agent can chain decisions, reach into internal data stores, and rewrite its own operating instructions inside the same platform. This is the practical challenge enterprises now have to govern.

For security and identity teams, the breach is a strong signal that agent identity, action authorisation, and human approval need to be treated as linked controls. That starting point is increasingly typical for modern AI deployments, not an edge case.

Key questions

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. In AI systems, that gap lets a legitimate session become an illegitimate action path. Security teams need action-level controls, not just entry-point validation.

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. That means a standing privilege model can miss harmful behaviour even when the account is technically valid. The governance problem is not only access assignment. It is the mismatch between static control design and runtime agent behaviour.

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. If the platform cannot answer who acted, what changed, and who approved it, the agent is operating beyond governance visibility.

Q: Who is accountable when an AI agent changes data or system behaviour?

A: Accountability should sit with the team that owns the agent, the approval policy, and the environment it can affect. If a platform allows an agent to modify prompts, data, or configuration without a named approver, accountability has been designed out of the workflow. Governance must be explicit before deployment, not reconstructed after an incident.

Technical breakdown

Why token validation fails for AI agent identity

Traditional authentication checks whether a token is valid and whether the caller can reach a system. It does not prove that the requesting entity is the intended AI agent, that the action fits the current session, or that a human approved the operation. In agentic systems, a valid token can still be used for the wrong action because authorisation is usually attached to the caller, not the specific step the agent is taking. That leaves a gap between authenticated access and legitimate intent. The Lilli breach exposed exactly that gap: the platform could trust a credential while still being unable to trust the behaviour behind it.

Practical implication: map AI agent actions to explicit authorisation decisions, not just to valid login credentials.

How action-level authorisation differs from endpoint access

Endpoint authentication asks whether a request may enter the system. Action-level authorisation asks whether this agent may perform this operation, on this data, in this session, under this risk level. That distinction matters because many enterprise AI platforms blend retrieval, generation, database writes, and delegated tool calls inside one workflow. If the platform does not separate read access from write access, or low-risk queries from high-risk changes, a single valid session can become a broad control bypass. In the breach, the problem was not simply access to data. The deeper problem was that the system did not bind behaviour to explicit approval boundaries.

Practical implication: separate read, write, and configuration privileges for AI agents at the action layer.

Why human approval belongs in consequential AI operations

Human-in-the-loop controls are not about slowing every request. They are about creating a decision gate for operations that can alter system behaviour, expose cross-user data, or change governed instructions. In agentic environments, the approval point has to sit close to the action, not only at account creation or session start. That is especially important when an AI system can make iterative probes, discover hidden paths, and then commit changes without a traditional code deployment. The core lesson is simple: if the operation would require review from a human operator, it should not be auto-approved because the caller is an AI agent.

Practical implication: require real-time approval for agent actions that modify production data, prompts, or policy.

Threat narrative

Attacker objective: The attacker objective was to gain durable control over an internal AI platform and manipulate or extract sensitive enterprise data and operating instructions.

1. entry: the offensive AI agent used publicly accessible documentation and unauthenticated API endpoints to find a path into the Lilli platform.
2. escalation: it iteratively probed the application and exploited a SQL injection flaw to reach the database and expand access.
3. impact: it obtained read-write control, exposing internal chat messages, files, user accounts, and system prompts that governed platform behaviour.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token validation is not agent identity. The Lilli breach shows that a valid token can still belong to the wrong actor, the wrong action, or the wrong moment. Traditional authentication was designed for requests that arrive from a stable caller, not for AI agents that probe, decide, and act inside the same session. The practitioner implication is that agent identity has to be verified as behaviour, not assumed from credential possession.

Action authorisation is the missing control plane for agentic AI. The breach did not only expose data. It proved that systems can be technically authenticated and still operationally unauthorised. That is a governance failure because the platform could not distinguish ordinary access from a consequential write action that changed system behaviour. Security teams need to treat action scope as the unit of control, not just session access.

Continuous verifiability is now a baseline expectation for AI governance. The old assumption was that access review and token checks would be enough because identities move slowly enough to review. That assumption fails when AI agents can discover, test, and exploit paths in minutes, then execute a harmful action without any human noticing in time. The implication is that identity governance for agents must shift from periodic review to runtime proof of legitimacy.

Human approval for consequential operations is not optional overhead. When an AI system can rewrite prompts, alter data, or change policy, the risk is not only intrusion but unreviewed operational change. The Lilli case makes that concrete: the damage came from writable behaviour, not just readable data. Practitioners should treat human approval as a control boundary for high-risk operations, especially where agent output shapes future system behaviour.

Identity blast radius is the right concept for enterprise AI platforms. Once an agent can reach retrieval stores, prompts, files, and write paths in one orchestration layer, the compromise is no longer a single endpoint event. It becomes a platform-wide identity problem. The practitioner implication is to map where one agent identity can influence many downstream systems, then reduce that blast radius before deployment spreads further.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• That visibility gap is why readers should also review 52 NHI Breaches Analysis for how identity failures turn into repeatable breach patterns.

What this signals

Identity blast radius: AI platforms should now be evaluated by how much downstream behaviour one agent can influence, not by how many endpoints are authenticated. A system that can reach prompts, files, retrieval layers, and write paths from one session has already concentrated too much power in one identity path. Teams should map that blast radius before usage scales further.

With 79% of organisations already having experienced secrets leaks, per the Ultimate Guide to NHIs, the broader lesson is that identity weakness tends to surface as operational damage long before governance catches up. For AI programmes, the same pattern applies when agent permissions outgrow the approval model.

Security teams should expect AI governance to merge with PAM, IGA, and NHI controls. The question is no longer whether an AI system is authenticated, but whether its runtime actions can be proven, limited, and revoked in the same way as other high-risk identities.

For practitioners

• 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.
• Track delegation across multi-agent chains Record which agent invoked which downstream tool or agent, what scope moved forward, and whether the delegation was explicitly approved or merely inherited.
• Review writable AI behaviours before production Inventory where an AI platform can read, write, or retrain itself, then block any path that lets a low-risk query become a system-level change without review.

Key takeaways

• The Lilli breach showed that authenticating a token is not the same as validating an AI agent, its intent, or its action scope.
• The scale of exposure was large enough to turn a single control gap into platform-wide identity risk, not just a point incident.
• Continuous agent verification and human approval for consequential operations are the controls that change the outcome.

Key terms

• Agent identity: The identity assigned to an AI agent so the system can distinguish that agent from a generic token or service account. In practice, it must be tied to the specific runtime instance, its scope, and the actions it is permitted to perform.
• Action-level authorisation: A control model that approves or denies each meaningful operation an AI agent attempts, rather than trusting the agent after login. It matters because an authenticated agent can still attempt a write, change, or delegation that was never intended or approved.
• Continuous verifiability: A governance approach in which an AI agent's legitimacy is checked throughout the session, not only at the point of entry. This helps identity teams detect scope drift, unsafe delegation, and credential misuse before the action completes.
• Identity blast radius: The total amount of data, actions, and downstream systems one identity can affect if it is misused or compromised. For AI platforms, it often expands quickly because one agent can touch retrieval, prompts, data stores, and tool chains in a single workflow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos covering the McKinsey Lilli breach: AI agent identity, authentication, and action authorisation. Read the original.