Short answer
A red-team AI agent reportedly accessed McKinsey’s internal AI platform, Lilli, exposing how enterprise knowledge assistants can become high-value targets. As Inc. reported, the experiment showed an AI agent exploiting weaknesses in an internal chatbot platform before the issue was patched. The lesson is clear: internal copilots are quickly becoming enterprise memory systems, and they need security, governance, and culture to match.
What happened with McKinsey’s Lilli platform?
McKinsey’s internal AI platform, Lilli, was built to help consultants search, summarize, and work with the firm’s internal knowledge. That makes it extremely useful. It also makes it extremely sensitive.
According to The Stack, a security startup called CodeWall used an offensive AI agent to test McKinsey’s Lilli platform and reportedly gained access to more than 46 million chat logs, 728,000 private files, and proprietary retrieval-augmented generation documentation. Cybernews reported that the agent found and exploited weaknesses in around two hours, gaining read and write access before the issue was disclosed and patched.
CodeWall’s own write-up, “How We Hacked McKinsey’s AI Platform”, describes the platform as a major internal knowledge system used across the firm. As with any vendor or researcher-authored account, it should be read with that context in mind, but the broader risk category is hard to ignore.
Internal AI platforms are becoming the front door to company knowledge. If that door is poorly guarded, the problem can get big very quickly.
Why should leaders care?
The McKinsey case matters because it points to a new enterprise risk pattern. This was not a traditional story of someone manually poking around a web app for days. Public reporting describes an AI agent that reasoned through the environment, discovered weaknesses, escalated access, and navigated the system at speed.
That changes the tempo of security. When offensive AI agents can automate discovery and exploitation, weak configurations, exposed endpoints, authentication gaps, and old vulnerabilities become easier to find and faster to abuse. The underlying technical issues may be familiar. The speed and scale are less comfortable.
It also matters because internal copilots are spreading fast. Large organizations are building AI assistants for search, HR, legal, finance, engineering, customer support, sales enablement, research, strategy, and operations. These tools often sit on top of emails, documents, chat logs, client materials, knowledge bases, dashboards, and historical work product.
That makes them brilliant productivity tools and very attractive targets. A single weakness in an internal AI platform may expose not one file, but the map to many files.
The enterprise memory problem
Internal AI assistants are often sold as smarter search. In practice, they can become enterprise memory engines. They help people find what the organization knows, what it has discussed, what it has promised, what it has analyzed, and what it has forgotten it still stores.
That is valuable because most companies are drowning in their own knowledge. It is risky because much of that knowledge was never organized with AI-scale retrieval in mind.
Old permissions, stale files, poorly classified documents, shadow knowledge bases, unclear data ownership, and half-finished governance models all become more serious when an AI system can search across them. Then add autonomous offensive agents that can probe these systems at machine speed, and the security model starts looking a bit too optimistic.
The question for leaders is practical: do we know what our internal AI tools can access, who can query them, what they can return, and how they behave under attack?
What organizations should do now
Organizations building internal copilots, enterprise chatbots, or AI knowledge assistants should treat these systems as critical business infrastructure. That means security testing them like high-value applications, not launching them like clever intranet widgets.
Start with access controls. Internal AI platforms should enforce least privilege, strong authentication, role-based access, and clear separation between user groups, projects, clients, and sensitive functions. If the AI can retrieve it, someone needs to understand why.
Next, test the system against real attack paths. Red-team prompt injection, exposed endpoints, API abuse, authentication gaps, RAG leakage, insecure plugins, and permission bypasses. AI platforms combine software, data, identity, prompts, models, tools, and user behavior, so the testing needs to cover the whole messy stack.
Then look at people. Do employees know what should and should not go into the platform? Do builders understand how AI changes access and exposure? Do security teams have visibility into AI usage? Do leaders have assurance that the platform has been tested before it becomes part of daily work?
Security culture matters here because internal tools often feel safe by default. They are inside the company. They have a friendly name. Everyone is excited. That is exactly when governance needs to keep its shoes on.
The Cybermaniacs take
The McKinsey Lilli exposure is a strong human risk management story because it shows how AI risk sits across technology, behavior, governance, and culture.
The technical layer matters: authentication, endpoint security, RAG design, logging, permissions, and red teaming. The human layer matters just as much: what teams upload, what they assume is safe, how quickly they deploy, whether they challenge risky decisions, and whether leaders understand the real exposure created by internal AI systems.
For Cybermaniacs, this is why AI adoption cannot be separated from cyber culture. Organizations need employees who understand how AI tools change data risk. They need technical teams trained to build and test AI systems responsibly. They need executives who can ask better questions than “when can we launch?” They need assurance that the human side of AI is being measured, managed, and improved.
Internal AI can unlock huge value. It can also gather the crown jewels into one very convenient basket. Lovely basket. Please do not leave it by the door.
FAQ
What happened with McKinsey’s Lilli AI platform?
A red-team security startup reportedly used an autonomous AI agent to access McKinsey’s internal AI platform, Lilli. Public reporting says the agent exposed large volumes of internal conversations, files, and system documentation before the issue was disclosed and patched.
Was this a traditional cyberattack?
Public reporting describes it as a red-team experiment rather than a conventional malicious breach. The important lesson is that autonomous AI agents can accelerate discovery, exploitation, and navigation inside enterprise systems.
Why are internal AI platforms risky?
Internal AI platforms often connect to large amounts of company knowledge, including documents, chats, research, client materials, and operational data. If access controls or security testing are weak, one flaw can expose a large amount of sensitive information.
What should companies do before launching internal copilots?
Review access controls, classify sensitive data, test for prompt injection and RAG leakage, red-team the platform, monitor usage, restrict high-risk actions, and train employees on safe AI use.
Why is this a human risk management issue?
People decide what data goes into AI systems, how fast tools are deployed, how permissions are granted, and whether risky behavior is challenged. Human risk management helps organizations build the culture, habits, and assurance needed to use internal AI safely.