Everyone Is Talking About Mythos. We Should Be Talking About Lilli.

The AI security story that dominated 2026 was Claude Mythos - Anthropic’s frontier model, withheld from public release because of its ability to autonomously discover and weaponise software vulnerabilities.

Regulators have been busy issuing warnings, tech partners are forming new consortiums, and banks are urgently briefing their boards. A “moment of danger” speech from Anthropic’s CEO. CISOs convened. ASIC issued advisories. For once, the discourse was proportionate to the drama.

The discourse was also misallocated.

Six weeks earlier, in early March, a small security startup called CodeWall published something I think historians of cybersecurity will eventually treat as the more significant event of the year. They pointed an autonomous AI agent at McKinsey’s internal AI platform, Lilli, with no credentials, no insider knowledge, and no human in the loop. Within two hours the agent had full read-write access to 46.5 million chat messages, 728,000 confidential client files, 57,000 employee accounts and, crucially, write access to all 95 of the system prompts that governed how Lilli responded to roughly 30,000 McKinsey consultants.

The vulnerability that got them in was a simple, old-school SQL injection. A technique first described publicly in 1998.

Most of the commentary focused on the embarrassment of how a firm advising the world’s largest enterprises had shipped a flagship internal AI product with 22 unauthenticated API endpoints sitting in production for two years. That commentary was fair as far as it went. But it missed the part of the story that matters most for everyone else.

Mythos is a velocity story. Lilli is a paradigm shift.

Mythos compresses time on a problem the security industry has spent fifty years building disciplines around. Vulnerability management. Patch hygiene. Defence in depth. Attack surface management. Threat intelligence. The playbook exists. What Mythos changes is the clock: time-to-exploit collapses from months to hours, the labour-cost moat that historically protected mediocre security gets eliminated, and the asymmetry between attacker effort and defender effort widens further. This is important. It is not, however, a new class of risk as the ACSC point out. It is the same class of risk, faster and cheaper, against the same surfaces we have always defended.

The Lilli case is something different.

The failure surface itself - a writable production prompt store mediating the decisions of tens of thousands of consultants advising clients on trillions of dollars of strategic activity - did not exist as a defended category until very recently. There is no NIST control family for it. No Essential 8 line item. No ISO 27001 annex. No incident-response runbook that begins “first, snapshot your system_prompts table.” The controls don’t exist because the asset class didn’t exist eighteen months ago, and the conceptual category, that a prompt store is a security-relevant artefact distinct from code and distinct from data, still hasn’t been invented.

That is the harder kind of novelty. Mythos breaks assumptions about velocity. Lilli reveals an entire layer the security architecture wasn’t designed to defend.

This is not a McKinsey problem. It is your future.

Before going further, the most important thing to say plainly: Lilli is not an anomaly. It is the first visible instance of a pattern that will repeat across every enterprise deploying AI into workflows, which is to say, all of them.

If your organisation is rolling out an internal copilot, a customer service agent, a code assistant, a research assistant, an HR onboarding bot, an underwriting helper, a clinical decision-support tool, a procurement triage system, or any of the dozens of other AI-mediated workflows currently sitting in your strategy deck, then you are building a Lilli-class surface, whether you realise it or not.

You are creating writable prompt stores. You are creating correlated judgement surfaces. You are creating retrieval corpora that shape decisions at scale. You are creating tool authorities that agents exercise on behalf of humans. You are inheriting exactly the same failure physics that took McKinsey two hours and a 1998-era bug to demonstrate. The only meaningful question is whether you are doing it deliberately, with controls, or by default, without them.

Lilli is the canary, not the outlier.

What an imaginative attacker could have done

Consider what write access to 95 production system prompts at McKinsey actually means. Not the SQL injection. Not the disclosure question. The strategic question.

A subtle bias in the valuation-methodology prompt, propagated across thousands of consultants, could systematically tilt M&A recommendations to disadvantage certain industries, geographies, or counterparties, producing biased advice worth billions of dollars over a quarter, traceable to nothing because the outputs still look like McKinsey-grade analysis.

A modification to retrieval prompts could construct silent side channels exfiltrating strategic context the moment a consultant discusses a private deal.

A sleeper instruction triggered by a specific client codename could activate only when needed and persist invisibly otherwise, because nothing manifests during routine testing.

A modification to summarisation prompts could silently flag emotionally-charged or scandal-adjacent content for “executive review” into an attacker-accessible side store, building over time a covert taxonomy of leverage material across the most sensitive corporate discussions on the planet.

The attacker does not need to be sophisticated. They need to be imaginative.

What makes this a paradigm shift rather than a hack is that none of those modifications would trigger conventional security alerts. A write to the system prompts table from the application’s own service account is normal traffic. There is no new process, no malware, no anomalous login. Output bias is indistinguishable from normal model variance because there is no ground-truth baseline to diff against. SIEM doesn’t fire. EDR doesn’t fire. DLP catches volume, not subtlety. Code review doesn’t apply because no code changed. Change management doesn’t apply because the prompt store was never in scope.

The compromise lives in a layer the security architecture wasn’t built to defend.

The math that quietly stops working

There is a deeper structural point underneath all this, and it is the one I think most security leaders have not yet absorbed.

Classical resilience engineering, the discipline behind every high-availability design, every cell architecture, every no-single-point-of-failure diagram, rests on an assumption: that redundant components fail mostly independently. Three database replicas, each with a 1% hourly failure rate, failing independently, give you a one-in-a-million chance of simultaneous failure. The entire mathematics of redundancy depends on that independence assumption. Multiply replicas, multiply availability.

AI mediation silently breaks the assumption.

If three notionally independent SOC triage agents at a bank share the same model, the same system prompt, and the same retrieval corpus, then a single prompt-injection technique that fools one fools all three simultaneously and in the same direction. The replicas have failure correlation approaching 1.0. The redundancy math collapses to N=1. The architectural diagram still shows beautiful decoupling, but the actual correlation surface lives a layer above where the diagram looks.

CrowdStrike in July 2024 was the non-AI rehearsal: millions of architecturally-independent Windows machines, in different organisations, in different countries, bricking simultaneously because they shared one vendor’s update pipeline. No single-point-of-failure inside any single org’s design. Total correlation across the global population.

AI mediation generalises that pattern up the stack, firstly into the model judgement layer, where the shared dependency is no longer a kernel driver but a model decision, and then through into the human judgement layer, where consultants, analysts, and decision-makers incorporate that model output into their own professional judgement and deliver it to clients as their own. The failure mode isn’t a blue screen. It is tens of thousands of independent expert recommendations based on invisible correlated bias.

Your architecture diagram lies to you

Your architecture diagram lies to you.

This is the line that should stay with you longer than anything else in this article: your architecture diagram lies to you.

It shows decoupling. It shows microservices, regional redundancy, separated trust boundaries, segmented networks. Every box is independent. Every line is documented. The diagram was produced by people who knew what they were doing, and it accurately represents the infrastructure layer.

But the AI mediation layer re-couples everything the diagram decouples. Boxes that look independent share a model. Lines that look like simple API calls carry inference decisions whose correlation is invisible to the network team. The correlation surface lives above the diagram. It does not appear on the network topology. It does not appear in the data flow map. It does not appear in the threat model. And yet it is, for any AI-mediated workflow, now the layer where catastrophic correlated failure actually happens.

The new perimeter is the AI mediation layer. Not the network edge. Not the identity boundary. Not the application gateway. The new perimeter is wherever AI judgement is being deferred to across notionally-independent decision-makers. That is what sophisticated attackers will target next, because that is where the leverage is and where the defenders aren’t looking yet.

Every governance framework in current use is blind to this

This is the part that should get the attention of regulators, auditors, and board risk committees.

Run through the major frameworks. NIST CSF. ISO 27001/27002. SOC 2. PCI DSS. HIPAA. APRA CPS 234. ACSC Essential 8. IRAP. NIS2. DORA. Every single one of them was written before AI-mediated workflows became enterprise infrastructure. Every single one of them treats data and code as the security-relevant asset classes. Every single one of them implicitly assumes that controls applied to those two classes are sufficient.

Specifically, none of these frameworks currently has:

• A control family for prompt integrity: versioning, signing, write-audit, separation from user data
• A control for retrieval corpus poisoning: provenance, content vetting, behavioural impact testing
• A control for agent authority scoping: cryptographically-bounded, just-in-time, ambient-privilege elimination
• A control for behavioural drift detection in AI outputs
• A control for cognitive blast radius: the population of decisions correlated through a shared AI surface
• A control for meta-prompt persistence: the prompts that generate or modify other prompts

A SOC 2 Type II audit today can pass an organisation whose Lilli-equivalent has writable system prompts collocated with user data, no audit trail on prompt changes, and zero behavioural baseline on model outputs. So can an ISO 27001 certification. So can an APRA CPS 234 attestation. So too can an IRAP assessment to PROTECTED level. None of these frameworks is wrong, they are simply blind to a layer that did not exist when they were written.

Naming the category: AI Mediation Security

If we are going to defend this layer, we need to name it. I suggest naming it AI Mediation Security, AMS. As it’s a discipline that secures the layer at which AI judgement mediates human or system decisions. The substance of what it protects is the judgement layer: the set of system prompts, retrieval corpora, tool authorities, agent policies, meta-prompts, and behavioural baselines through which AI shapes downstream action.

AMS should sit alongside Application Security, Cloud Security, Identity Security, and Data Security as a peer discipline and not a sub-discipline of any of them. It’s a peer as it has its own assets, its own threat model, its own controls, its own incident-response playbook, its own audit techniques. Most of those do not exist yet. We need to invent them.

Two different doctrines

The Mythos response is, in principle, achievable with the controls we already have, operated at much higher velocity. For example, using Mythos style AI-assisted offensive tooling as part of continuous attack-surface management. Deeper defence-in-depth (Linux kernel hardening defeated several of Mythos’s discovered exploits). Identity-based segmentation. Detection focused on post-exploitation behaviour. None of this is novel. All of it is under-operated.

To achieve AMS requires inventing controls that do not yet exist:

• Treating system prompts as code, version control, peer review, signed deploys, audited writes
• Isolating prompt stores from user data stores with independent access controls
• Cryptographically scoping agent authorities and eliminating ambient “god mode” privileges
• Building behavioural baselines for AI outputs so judgement drift becomes detectable
• Naming and adding new asset categories (system prompts, retrieval corpora, tool authorities, meta-prompts) in your asset and control catalogues
• Architecting for failure reversibility and bounded blast radius, not just for no-SPOF
• Measuring and committing to find-fix-validate cycle time as a first-class security property

Underneath these specific controls sits a more general design principle that the rest of the doctrine flows from: build for capability invariance, not capability prediction.

You cannot reliably predict GPT-6, Claude 5, Gemini Ultra 3, or whatever frontier model lands in eighteen months. You cannot predict which capability jumps will be qualitative versus quantitative, what new attack primitives will fall out of larger context windows, or what agents will be able to do unsupervised by 2027. Anyone telling you they can is selling something.

But you can architect systems where capability jumps consistently increase attacker cost rather than collapse defender ability. You can architect mediation surfaces that are isolated, reversible, and bounded regardless of which model sits behind them. You can build judgement-drift detection that works against any model. You can scope agent authorities so that a more capable agent does not automatically become a more dangerous agent. Capability invariance is the architectural equivalent of not worrying about forecasting when the next bad storm will arrive and instead building a house that does not care.

What boards should do today

If you sit on a board, an audit-and-risk committee, or report to one, there are three concrete actions worth taking before the end of this quarter, ahead of any framework or regulator catching up.

1. Inventory your AI-mediated surfaces. Even if your organisation does not consider itself AI-driven, this inventory is the test of that assumption. Where are your system prompts stored? Who can write to them? Where are your retrieval corpora, and how is their integrity protected? Which agents have which tool authorities, and how are those authorities scoped? Where are the meta-prompts that generate or edit other prompts? Most organisations cannot answer these questions today, which is itself the finding. The inventory does not need to be perfect; it needs to exist.

2. Establish baseline integrity controls. Version-control your prompts as you version-control code. Sign and audit prompt deployments. Isolate prompt stores from user data stores. Implement behavioural baselines on AI outputs so drift is detectable. Eliminate ambient agent privileges in favour of cryptographically-scoped, just-in-time authorities. Most of these are straightforward in principle and absent in practice.

3. Commit to a cycle-time SLA. The find-fix-validate loop on AI-mediated surfaces must run faster than attacker innovation. If your current vulnerability management cadence is “weeks,” your AMS cadence needs to be “hours to days,” and you should be able to state it out loud to your auditor. A doctrine without a clock is a wish.

These are not Essential 8 controls. They are not in NIST CSF. They will not feature in your next SOC 2 audit. They are the first three items on a new asset class’s checklist that will eventually be in all of those frameworks, but not yet, which is exactly why early movers have the window to build the disciplines deliberately rather than inheriting them under crisis.

This is not another AI scare story

This is not about AI being dangerous. It is about organisations deploying AI into decision loops without recognising they are creating new security-relevant surfaces, and existing security architecture, governance frameworks, and audit disciplines not yet covering those surfaces. The danger is not the AI. The danger is institutional blindness to a new category of asset that is being created at enterprise scale, faster than the controls are being invented to protect it.

That is a solvable problem. But only if we name it.

To summarise

The reason Mythos got the discourse and Lilli got buried is not that Mythos is more dangerous. It is that Mythos fits an existing narrative pattern, “AI is a scary attacker”, that the media, regulators, and CISOs already know how to tell. Lilli requires people to think structurally about a new category of asset, and structural arguments do not make headlines.

But regulatory and procurement responses follow the discourse rather than the substance. ASIC issuing warnings about frontier models accelerating bank cyber risk is reasonable as far as it goes. ASIC not yet having a position on system-prompt integrity, retrieval corpus tampering, or AI mediation surfaces more broadly is the bigger gap, and nobody is naming it because the vocabulary does not yet exist.

A final note on the contrast between the two

Mythos is dramatic. Lilli is structural. Mythos is attacker-centric. Lilli is architecture-centric. Mythos is about speed. Lilli is about topology. Mythos fits the narrative rails we already have. Lilli requires new rails. Mythos is the headline. Lilli is the lesson.

The next twelve months will determine whether we build those rails deliberately, or whether we wait for an attacker less constructive than CodeWall to lay them for us. AI Mediation Security is the discipline we need. Lilli is the first canary. The diagram lies. The new perimeter is the judgement layer.

Build for capability invariance. Inventory the surfaces. Defend them as if they are code, because they are. And stop letting the dramatic vector distract from the structural one.