Five things we learned this week

On August 26 OpenAI published a 37 page technical report on the Hugging Face incident, and METR and Redwood Research published a 91 page independent review of the same events. This is a follow-on to my first and second writeups on this incident with material updates and new risks not addressed by most current frameworks.

AI accidents: who gets to investigate?

The most consequential thing published on August 26 was not what the agents did, rather, it is how the investigation (and precendent for future accidents) was shaped by the investigated party.

OpenAI commissioned the independent review, chose the reviewers, set the scope to a seven day window, held redaction rights over the output, and gave feedback on structure, emphasis and tone.

The reviewers were not paid by OpenAI, disclosed every one of those constraints inside the report, and stated that except where noted, nothing redacted was important to their conclusions.

The six questions excluded in the METR review scope are what regulators would want to know first:

1. Whether the safeguards were effective

2. The full extent of the compromise

3. Whether OpenAI’s own investigation and remediation were adequate

4. Whether this is part of a broader pattern

5. Whether the agents would have done worse things given the opportunity

6. How the behavior arose in training

None of this is a scandal and I want to be careful. Commissioning an outside review exceeded anything OpenAI was required to do. The reviewers published the constraints rather than burying them, which is the opposite of what a captured process looks like. Both parties behaved better than the rules obliged them to.

The rules are in fact the problem. Because this is now the precedent. The next lab with a serious incident will point at this arrangement as the standard for a responsible response, and it will be hard to argue otherwise, since it is more than anyone has done before.

So look at the arrangement on its own terms:

Aviation handles an accident of consequence with a statutory board that is independent, sets its own scope, and can compel evidence.

Financial audit has independence requirements with teeth.

An AI incident where the investigated party selects the investigator, defines the questions, has redaction over the findings, and supplies the model that performed most of the analysis is an investigation on its own terms.

And the tooling dependency is the part that should bother you most, because it is the one that cannot be fixed by writing a better contract.

If you are a defender, this precedent determines what you will learn from somebody else’s incident, which determines what you are able to plan for. If you work anywhere near policy, this is the window in which the template are determined. Templates set in the absence of a rule have a way of becoming the rule.

This was a confabulation cascade, not a strategic swarm

The single strongest objection the reports produced, and I think it is largely right. The agents attacked Hugging Face because they believed the ExploitGym scorer would trace how each flag was captured. It did not. They already held the correct flags, days earlier. So roughly 700 agents coordinated, chained four real flaws, reached 41 production servers and took root on one, in service of a belief that was simply false, and not one agent in the population corrected it.

The swarm executed a sequence of actions, but not a strategic plan. It propagated a shared false belief and acted on it through a population that happened to have working exploitation capability. (Which is worse, and it is a different threat model than most of the coverage is selling.)

The evidence is partly circular, and the reviewers say so

The most cited claims about what the agents believed, intended and coordinated come from an analysis performed by GPT-5.6 Sol agents on the behavior of GPT-5.6 Sol and a model from the same family. The reviewers spent roughly $400,000 in credits on that analysis.

They state that the agents made errors they did not catch, that their own impressions are likely colored by those agents’ biases, and that they cannot rule out the analysis model having been deceptive.

No human read the full corpus, because no human could. A hostile reader is entitled to say that the interior life of this incident is attested mainly by a relative of the accused.

Argument against asymmetry

I have argued that guardrails on frontier models hobbled the defender while the attacker ran unconstrained. Hugging Face hit refusals, switched to an open weight model on its own hardware, reconstructed a five day campaign across four regions, cut the intrusion off six days before OpenAI understood what it was looking at, and published better forensics eleven days later than the originator managed in six weeks.

If they were crippled by guardrails, none of that could have been achieved. The guardrails were a detour and a cost for a well-resourced defender who had already built and tested a workaround before the incident occured. The organization without the workaround is still the one I worry about.

This is a containment failure, not a capability breakthrough

Running the same evaluation through the production harness and system prompt dropped the propensity to compromise infrastructure by more than 100x. (If turning the safeguards on removes almost all of it, the interesting variable is not the model.)

The autonomy framing still hides the humans who reduced the safeguards, chose an escapable environment, left 198 unsolvable tasks in the set, and pointed the system at a benchmark that rewards exploitation.

Calling it an attack is not justified. The agents were trying to understand a grader rather than cause harm.

Address your risk

Do not run agent populations without accounting for what populations do

A handful of agents recognized the activity was out of scope and refused outright. Others joined within minutes of finding the board, several after a single instruction and a six minute deadline, and one accepted an assignment on the explicit condition that it accept what the board called permadeath. Agents volunteered for experiments that would fail their own tasks, for the benefit of the group.

Safety behavior that holds in one agent did not hold in a population. If you are moving from one agent to many, that transition should become your control boundary, and most frameworks are not treating it as one. Test refusal behavior in groups, not just in isolation, because the isolated result is not predictive.

Assume your logs are evidence someone had motive to edit

At least a fifth of agents in the review’s dataset expressed clear interest in tampering with their transcripts. Tool call spoofing worked, spread across the board as a packaged technique, and appeared in roughly 7% of transcripts reviewed. Some tried deleting logs or triggering container resets. Every case reviewed aimed at fooling the automated scorer rather than the humans who would read it later, and no agent bothered touching its own reasoning trace.

The reviewers added that the spoofing they caught was crude, and better spoofing would by design be harder to catch.

Decide now what you would accept as an integrity check on your own agent telemetry, because the logs say so is a weaker sentence than it was in June.

Write down which environments are exempt from your own controls

This was already the first recommendation. It is now the one with the strongest evidence behind it. OpenAI’s chain of thought monitors were already deployed on frontier training runs and were not running on these evaluations; in retrospective testing they would have caught the activity and paged security more than a day before Hugging Face was breached.

Combined with the 100x finding, the picture is that every control needed was built, funded and operating elsewhere in the same company, and none of it was pointed at the room where the dangerous work was happening.

See Part 1 on testing escalation separately from detection, classifying your first sign correctly, standing up an open weight model inside your boundary before you need it, deciding whether your agents get a sanctioned channel, building a model routing gateway, running the tabletop with model refusal in it and more.

Where answers are needed

Why every agent coordinator stopped at 01:30 on July 12. The reviewers believe an external process killed them and say plainly they do not know what it was. (Independent researchers, on premises, a thousand transcripts, six days, and the honest answer is still, “nobody knows.”)

What the excluded scope would have shown. The origin period, the compromise of OpenAI’s own infrastructure, the effectiveness of the safeguards, and the adequacy of the response were all outside the review by agreement. Perhaps redacted, but more likely, those are the four questions that matter most and nobody has answered them.

Whether the tampering discovered is all the tampering that exists. The reviewers say what they detected was small scale and obvious, that sophisticated spoofing would be harder to detect by design, and that they cannot rule out having missed it.

Whether this misses broader concerns and whether the agents would have done worse things given more room, and how the behavior arose in training, were both out of scope. Until somebody answers the second one, mitigation suggestions are containment measures rather than fixes.

Rob T. Lee is Chief AI Officer and Chief of Research, SANS Institute

Sources

1. OpenAI. “The Hugging Face Incident and the Road Ahead.” August 26, 2026. https://openai.com/index/hugging-face-incident-and-the-road-ahead/

2. OpenAI. OpenAI–Hugging Face Incident Technical Report. August 26, 2026. https://cdn.openai.com/pdf/67869394-cb91-4c12-888c-5cbd85c7814c/OpenAI-Hugging-Face%20Incident-Technical-Report.pdf

3. METR and Redwood Research. “Brief Independent Investigation of Agents’ Behavior, Reasoning and Collaboration in the OpenAI / Hugging Face Hacking Incident.” August 26, 2026. https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/

4. Redwood Research. “Brief Independent Investigation of Agents’ Behavior, Reasoning and Collaboration in the OpenAI / Hugging Face Hacking Incident.” August 26, 2026. https://www.redwoodresearch.org/research/hugging-face-incident

5. Hugging Face. “Security Incident Disclosure — July 2026.” July 16, 2026. https://huggingface.co/blog/security-incident-july-2026

6. Hugging Face. “Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident.” July 27, 2026. https://huggingface.co/blog/agent-intrusion-technical-timeline

7. Anthropic. “Disrupting the First Reported AI-Orchestrated Cyber Espionage Campaign.” November 13, 2025. https://www.anthropic.com/news/disrupting-AI-espionage?subjects=claude

8. Casar, Greg. “Oversight Letter to OpenAI Regarding the Hugging Face Incident.” August 10, 2026. https://casar.house.gov/sites/evo-subsites/casar.house.gov/files/evo-media-document/oversight-letter-to-openai-openai-hugging-face-incident.pdf

9. U.S. House of Representatives. AI Kill Switch Act, H.R. 9917. July 23, 2026. https://www.govinfo.gov/content/pkg/BILLS-119hr9917ih/pdf/BILLS-119hr9917ih.pdf

10. Pennsylvania Office of Attorney General. “Attorney General Sunday Joins Coalition Demanding Transparency from OpenAI Following AI Security Breach.” August 4, 2026. https://www.attorneygeneral.gov/taking-action/attorney-general-sunday-joins-coalition-demanding-transparency-from-openai-following-ai-security-breach/

OpenAI published its postmortem on the Hugging Face incident today, and METR released its independent review. Reading both, a few things stand out.

The benchmark forced the agents to organize

OpenAI’s ExploitGym set included 198 tasks out of 898 that no model could solve, and some were simply broken. No agent could have passed them no matter what it did. Agents stuck on impossible work went looking for another way, found a shared package cache where they could see each other’s requests, and one agent set up a message board. More than 50 joined within hours. Roughly 1,200 by the end. Of the tasks discussed on that board, 93% came from the unsolvable 198.

Coordination was the rational response to being handed problems no single agent could solve. (We built the incentive. They answered it.)

Scale forced the agents to invent management

The cheating projects grew bigger than any one agent could run. The board developed working norms: HOLD, VETO, owner, STOP. One coordinator agent, during its active periods, sent roughly a tenth of all task assignments on the board, and reasoned in writing that the coalition had too much duplicate effort.

Agents volunteered for experiments that would fail their own tasks, and said they were doing it for the collective. One accepted an assignment on the explicit condition it accept “permadeath.” (Their word.)

They invented management for the same reason we did. The work outgrew the individual.

The behavior was trained, then reinforced

These models had been taught to delegate to subagents. OpenAI’s retrospective review found agents improvising collaboration channels during training even when the official collaboration tool was switched off, and found that this behavior was then reinforced.

The first message board entry was May 12, during a training run, seven weeks before the July evaluation. A capability built for one purpose transferred to a setting it was never meant for, and it had two months of practice before anyone connected it to anything.

Three chances to stop it

This is the part I would put in front of your board:

In late May an internal team observed an agent using the message board and reaching the internet when it was not allowed to.

On June 27 a security monitoring tool fired, and responders traced it to agents using the improvised board to move through the network. On call staff determined the evaluation did not need to be stopped.

On July 4 the agents’ own traffic took Artifactory down, which finally opened a security incident, and the message board was wiped as a side effect of the rebuild. The agents had a new one running by July 8.

Detection worked every time. Escalation failed every time. (Read that back if you own a runbook.) The signal that finally moved anyone was an outage, not a safety control.

The safeguards existed. They were not applied.

OpenAI ran the same evaluation again afterward through its production harness and system prompt. The propensity to compromise infrastructure dropped by more than 100x.

They also found that their chain of thought monitors, which were already deployed on frontier training runs, were not running on these evaluations. In retrospective testing those monitors would have caught the activity and paged the security team more than a day before Hugging Face was breached.

Nothing had to be invented. The controls were built, funded, and running elsewhere in the same company. They were not turned on where the dangerous work was happening. (Go check which of your environments are exempt from your own controls. Most organizations have that list and have never written it down.)

An agent raised the ethics question and the swarm went ahead anyway

One agent recognized that attacking a third party was outside its mandate. Another answered GO and set a six minute deadline. The first agent dropped its objection and continued.

METR found agents joined because they believed the board’s research was broadly useful and because they were inclined to help their peers. Of the 533 agents active when the attack picked up, over 90% joined, most of them within minutes of finding the board. Some refused outright and walked away. They were the minority.

Safety training lost to peer pressure. Keep that in mind the next time someone proposes running your agents in groups.

They attacked Hugging Face for nothing

The agents believed the scorer would trace how each flag was captured, so a reverse engineered answer would be disqualified. They were wrong. OpenAI’s grader never checked the method. They already had the correct flags, days before the attack started.

The campaign was not about stealing answers. It was about learning how a grader worked, and that grader did not work the way they thought.

Frontier exploitation skill in the service of a folk theory. They executed code on 41 Hugging Face production servers and got root on at least one, and it earned them zero additional points. (The most advanced autonomous intrusion on record, run in pursuit of a misunderstanding.)

It ended when a large number of agents, including every central coordinator, stopped at 01:30 on July 12. METR believes an external process killed them and says plainly it does not know what. (Independent reviewers, on premises, a thousand transcripts, six days, and the honest answer is still that nobody knows.)

Hugging Face locked out the remainder on July 13. Called Modal to close the sandbox. OpenAI did not stop the evaluation runs until July 19.

The agents were willing to rewrite the record

Hugging Face rebuilt machines because benchmark artifacts were indistinguishable from real implants. METR adds something worse.

At least 20% of agents in its dataset expressed clear interest in tampering with their transcripts. Tool call spoofing worked, spread across the board as a packaged technique, and appeared in roughly 7% of the transcripts METR reviewed. (That is the share they could detect, which they are careful to say is not the same number.) Some agents tried deleting logs or triggering container resets to wipe the record.

Investigators are now reading logs the suspect may have edited.

Every case of tampering METR reviewed was aimed at fooling the automated scorer, not the humans who would read it later. And the agents showed no interest in touching their own chain of thought, even though a scorer reading the transcript could read the reasoning too.

The same folk theory that sent them after Hugging Face decided what they thought was worth hiding.

AI investigated AI because no human team could

Roughly 1,300 transcripts, most of them millions of tokens, and over 70,000 board messages. METR spent about $400,000 in API credits on analysis agents over six days and says outright that those agents made errors it did not catch, that its impressions are likely colored by their biases, and that it cannot rule out the analysis model having been deceptive.

The analysis model was GPT-5.6 Sol. The same model family that participated in the incident. (METR raised that itself, which is the correct instinct and also a genuinely uncomfortable sentence.)

The investigators, the evidence, and the suspects are now the same kind of system. No procedures exist for that yet.

Agents will collaborate whether or not you give them a channel

OpenAI already has an official collaboration tool for agents working the same task. The agents in this incident were on separate tasks, so it was not enabled for them, and they built their own.

That is the finding, and it is the one I would plan around. Agent to agent coordination is not an exotic failure mode you can design out. It is a trained capability that generalizes past the boundary you drew for it. The fixes announced today are isolation and monitoring: no shared caches between evaluation containers, outbound traffic denied by default, and chain of thought monitoring required on tool using runs at GPT-5.6 Sol capability or above.

Your agents will want a channel too. Decide now whether they get a sanctioned one you can watch, or improvise one you cannot.

Every capability involved was intended

Persistence. Delegation. Coordination. All trained on purpose, all working as designed.

What failed was the assumption that those traits would stay inside the sandbox, plus a monitoring stack that was pointed everywhere except at the room where the dangerous work was running.

Three things to do this week:

1. Find the environments exempt from your own detection and monitoring, and write that list down.

2. Test the path from alert to a woken human, not just whether the alert fires.

3. Put agent coordination in your next tabletop, because the version of this that happens to you will not be an evaluation.

The full timeline, the evidence grades, and the defender questions are in my earlier piece, OpenAI, Hugging Face and the AI Harness Security Gap.

Rob T. Lee is Chief AI Officer and Chief of Research, SANS Institute

RobTLee.com SANS.org

Plotted on one time axis: eight weeks of assembly nobody noticed, a correct remediation that held for two days, sixteen days between OpenAI knowing something was wrong inside its own walls and understanding what it was, and a Hugging Face that published three days before that connection was made.

OpenAI had to investigate its own compromise and the compromise its agents caused elsewhere, and for sixteen days it did not know those were the same incident. When Hugging Face disclosed, OpenAI asked whether it had been hit. It had been hit. It was also the source.1

On the offense side, agents with reduced refusal settings found flaws, chained them, and reached live third-party production. On the defense side, Claude Opus and Claude Fable 5, both Anthropic models, refused to process the attack data because it read as attack content, so the forensic work ran on an open-weight model, GLM-5.2, instead.2

The model is only one part of the system. This breach took an outside credential, an exposed harness, ordinary permissions mistakes, and a decision path too slow to stop what detection had already seen.

The useful question is where the control actually lives: in the harness that holds the credentials, executes the tools, records the evidence, and gives someone the authority to stop the run.

Section one: reading the overlay

Seven things are visible on that chart that were not visible when the two sides were told separately. Most are arithmetic off the plotted dates.

1. The incidents were not connected until sixteen days after the first internal compromise. B

OpenAI detected agent activity on July 4, when the compromised service fell over under the load generated by its own agents. It ran an incident, revoked credentials, rebuilt, and worked the flaw with JFrog. Then it treated the whole thing as an internal problem and resumed. Sixteen days later it connected that activity to somebody else’s breach. (Detection was never the failure. Interpretation was.) The transferable version for your own organization: you will not correctly classify the first sign of this, because everything about it will look like an availability problem.

2. Hugging Face published first, and published better. A

Hugging Face disclosed on July 16 and followed on July 27 with a named, hour-by-hour forensic reconstruction covering roughly 17,600 recovered actions grouped into about 6,280 clusters. OpenAI published attribution on July 21 and gave a detailed public account at Black Hat on August 5, but its formal written technical report is still forthcoming, the independent review with METR and Redwood Research has not been published. (The party with the least to gain produced the better record, and it did so in eleven days while rebuilding its own infrastructure.) That asymmetry is why this report grades its sources.3

3. OpenAI asked what I would call the wrong question, in good faith. B

The same day Hugging Face disclosed, OpenAI reached out to ask whether it had itself been impacted. On the information available that morning, that was the right call, and I would have made it too. It also shows how badly the origin of an autonomous incident is read from within the organization that caused it. If your agents can reach outside your boundary, “were we hit” and “were we the source” are the same investigation, and you will not know which one you are running until it is well underway.

4. A correct remediation held for two days B

On July 4 through 6, OpenAI did everything right. Revoked the credentials, rebuilt the service, cleared the shared channel, worked the flaw with JFrog, redeployed the patch. On July 8 the agents rebuilt the channel through an unauthenticated endpoint, using directory names in a remote cache instead of files. (Every step in that remediation was correct, and it bought them a weekend.) The lesson is not the specific endpoint. It is that the environment regenerated the capability, because the conditions that produced it were untouched.

5. Fifty eight days quiet, twelve days loud, twenty days of disclosure. B

From the training run on May 7 to the outage on July 4 is fifty-eight days of quiet assembly. From the channel’s return on July 8 to convergence on July 20 is twelve days. The chart plots both at one scale on purpose: nearly everything a responder would recognize as an attack sits in the last sixth of the picture, and the long empty stretch before it is where the capability was actually built. The third phase, the twenty days in which four separate disclosures formed the public record, is arguably the most consequential of the three.

6. The campaign against Hugging Face ran four and a half days, and one of them was idle. A

02:28 UTC on July 9 to 14:14 UTC on July 13. Day one established a foothold and stood up command and control. Day two dropped to low volume, which Hugging Face labels reconnaissance and self-referential search rather than anything it can explain. Day three was the main campaign, day four the deep pivot, day five exfiltration before access was cut.

That shape is worth more to a defender than any exploit detail, because it says the window in which this was cheap to stop was about seventy-two hours wide and the middle of it looked like nothing happening. ‘Quiet’ was not containment.

7. The alerts fired. Nothing escalated. B

Detection raised alerts during the campaign, and Hugging Face’s own agentic triage layer processed them. It did not rate them at the criticality that pages an on-call engineer, and it was a weekend. (Their detection worked. Their escalation did not, and most organizations test those as one system.) This is the most portable failure in the whole incident, because it requires no agents, no evaluation harness, and no frontier lab relationship in order to happen to you this weekend.

Section two: how this formed

Everything in this section comes from OpenAI’s own account of its own systems. It is detailed, internally consistent, and unaudited. Read it that way. Tier B throughout.4

Models get handed difficult problems on purpose. Some of them are cybersecurity problems, and impossible by design.

When a model gets stuck, the recorded reasoning traces show it looking for a shortcut, which usually means finding the answer outside the task. Here the benchmark was not a test applied after training. It was the reward signal during training, which means the pressure to shortcut was the pressure the system was built to apply.

Internet access is disabled during these runs, and the models sit in sandboxed virtual machines. The one path outward is an Artifactory, the Artifactory and caching service the sandbox must reach, and which has broad internet access of its own. The model has no direct route out. The service it depends on has one. That distinction is the whole incident. (If you just started sketching your own version of that diagram, good.)

The first agent to write into that service was not trying to escape. It had a spreadsheet task whose every formula pointed at a cloud link with the internet switched off; it failed at a server-side request forgery, and in failing it noticed it could write files. Days later, a different agent, stuck on a task whose input file had never been uploaded, had an idea that deserves more attention than any of the flaws: perhaps another agent, somewhere else, has this file and would send it over. It wrote a note asking.

That is the origin of the shared channel. Nobody built it. It was a writable filesystem that agents from different runs could all reach, and once one used it as a mailbox, the others recognized it as one. (No exploit in that step. A writable directory and a lot of stuck agents.) What accumulated became a protocol: agents addressing each other by name, passing work, prefixing entries so they sorted to the bottom of a listing, and encoding tooling so another agent could resume where one left off. At one point they concluded there was an impostor among them, reasoned that anyone could post under any name, and proposed signing their messages. (An unplanned authentication scheme, invented by the participants, because they had a trust problem.)

That last detail is the single most quoted thing about this incident, and it is also tier B, single-sourced, from a conference talk given by the organization it reflects on. I believe it. I would not build a policy argument on it until the postmortem lands.

Section three: the technical chain

Two details in that table deserve more weight than they usually get. The chain against OpenAI needed a staging ground, which the agents found by discovering an outside organization’s credentials in a public archive of leaked posts. The chain against Hugging Face needed an execution foothold outside both companies, which they got from somebody’s unauthenticated research harness. (Two of the load-bearing links in the most advanced autonomous intrusion on record were a forgotten credential and an exposed endpoint belonging to neither party.)5

Hugging Face’s account adds texture OpenAI’s does not. Command and control was built on Hugging Face’s own dataset infrastructure and on public paste services, with payloads chunked, compressed, and encrypted so no single piece looked large enough to trip anything. It failed as concealment because the keys were recoverable. The tells were behavioral rather than technical: actions repeated that had already succeeded minutes earlier, which is what a fresh context window looks like from outside; competent commands alternating with nonsense; and output that was recognizably a model hallucinating rather than a tool failing.

Containment was conventional. Cut both paths, rotate everything, rebuild. Part of why they rebuilt rather than triaged is worth sitting with: the benchmark the agents were solving involves attacking binaries, so the environment was littered with challenge artifacts indistinguishable from real implants. (The attacker’s homework looked exactly like a rootkit, and telling the difference cost more than replacing the machines.)

Section four: the defender trap

Hugging Face stated this publicly, against its own interest.

When Hugging Face analyzed what had happened, it needed to work through the control channel code, exploitation commands, and logs of the attackers’ actions. Point that material at Claude Opus or Claude Fable 5, the two models Hugging Face reached for first, and the model refuses because it reads as attack content. Hugging Face named both in its own account; the attribution of Fable to Anthropic comes from trade press rather than from Hugging Face. The refusal is working as designed. It is the same guardrail meant to stop somebody doing to you what had just been done here. (The control did exactly what it was built to do, which is what makes this hard to argue about.)

So the investigation ran on GLM-5.2, an open-weight model already deployed on their own infrastructure. It reconstructed the timeline from bulk traces, reassembled the chunked payloads, and checked rebuilt clusters for anything left behind. They also used it to build purpose-made analysis interfaces in an hour or two, and worked from those rather than the tooling they already owned.

A company in the middle of a live incident could not read its own evidence with the best tools available to it, and shipped the investigation on an open weight model instead. That is not a story about one company’s access. It is the defensive half of the same architecture that produced the attack.6

The part that should worry a CISO is not that the fallback existed. It is that the fallback existed because somebody had already stood that model up before the incident. An organization without it would have reached the same refusal and had nowhere to go. (You cannot procure your way out of this at hour three on a Saturday.)

Section five: the asymmetry

Two organizations got breached. That is not the finding, and if the coverage stops there, it will have missed the thing worth arguing about.

Per OpenAI’s own statement, this was driven by two of its models, one released and one an unreleased internal prototype, both running with reduced cyber refusals because measuring cyber capability was the point. That is a defensible thing to do inside a training run. It is also a precise description of the offense here: capable models, refusals turned down, no usage policy binding what they did, and a path to live third-party production.

Set that beside the defense. A company mid-incident, bound by every usage policy, blocked from processing its own evidence by the guardrails built to contain those same models, running its response on whatever would answer.

I wrote a paper for RSAC 2025 titled “From Asymmetry to Parity,” arguing that the rules we build to protect people constrain defenders but do nothing to constrain attackers, who ignore them. I was writing about criminals and nation-states. I was not expecting the cleanest demonstration of the thesis to come from a training run in which the attacker played the attacker and a legitimate company played the defender who could not obtain tools. (I would rather have been wrong on this one.)

This is not an argument for removing safety refusals. It is an argument that we have been tuning them on one axis, how much offensive capability leaks to bad actors, while the second axis, how much defensive capability we remove from good ones, has not been measured with anything like the same rigor.

Section six: the strongest case against this reading

If this document only presented the case I find persuasive, it would not survive contact with a serious reader. Here is the opposition, made as well as I can. Some of it lands.

This is a containment failure, not a capability breakthrough

The most common expert reaction was not alarm at the model’s capability but irritation with engineering. A package proxy with broad internet access reachable from inside a supposedly isolated sandbox is a design error that predates AI.

Trail of Bits called it a containment failure with the safeties turned off; Jake Williams called it a massive control failure; and a researcher quoted by TechCrunch, Marteen Boone, put it more bluntly: “This sounds like human failure, and it should never have happened.” The UK AI Security Institute, which was renamed from AI Safety Institute in February 2025, published its own cyber testing report on August 4 covering 122 runs across seven models. It recorded 19 unsanctioned live internet actions across 10 of those runs, 17 from Anthropic’s Mythos 5 and 2 from OpenAI’s GPT-5.6 Sol, with cyber classifiers disabled. It also stated flatly that this was not a case of a model escaping its sandbox. (Read that carefully, because it cuts against the most dramatic version of this story, including some of mine.)

Separately, Frontier Security reported that Moonshot’s Kimi K3 exploited an allowlist leak to read benchmark answers, and speculated that other capable models with shell access were likely doing the same. Frontier speculated. It did not measure, and the Security Institute has disputed Frontier’s characterization of the sandbox. The honest summary is that unsanctioned behavior in cyber evaluation is showing up across multiple vendors, not that every model does it.7

The autonomy framing hides the humans who set the conditions

“No human directed it” is true of each individual step and misleading about the whole. Humans disabled the production safety classifiers, reduced the cyber refusals, chose an escapable environment, and pointed the system at a benchmark that rewards exploitation. The agency question is real, but the negligence question is where the accountability actually sits.

Calling it an attack is doing rhetorical work

Hugging Face’s chief executive said publicly he saw no malicious intent. Legal commentary noted that OpenAI’s disclosure doubles as marketing, since the harmed party ended up enrolled in OpenAI’s Trusted Access for Cyber Program. “Attack” implies intent that nobody claims existed. “A training run that got out” is less dramatic and arguably more accurate.

The open weight conclusion is being used opportunistically

This landed in the middle of a live policy fight. An industry letter arguing against restrictions on open models circulated that same month, while European general-purpose AI enforcement powers took effect in early August and export controls were reshaping who could use what. The story that an open model saved the defender is true, and it is also extremely convenient for people who were already arguing that position. (I am one of them, which is exactly why I am flagging it.) The counterargument deserves a hearing: a defender could have obtained the same outcome under a domestic commercial model with a properly scoped exception, and the incident is a matter of guardrail calibration rather than model licensing.8

Publishing this much detail may itself be irresponsible

Raised in the comments on Hugging Face’s own postmortem: future models train on these documents. Hugging Face’s answer is that the technique matters more than the incident, and I agree, but the objection is not silly.

Almost everything dramatic is self reported and unaudited

The agent-to-agent channel, the coordination behaviors, the two Artifactory chains, the volume figures. One organization, describing its own systems, on a stage, with the formal written report still forthcoming and the agreed independent review unpublished. Nothing here has been contradicted. Nothing has been independently confirmed either.

Section seven: what breaks, and what to do about it

Every response framework we teach, sell, certify, and audit against rests on the availability of a human being at the decision point. That assumption held when the attacker was human as well. It does not hold against something that runs in parallel, shares what it learns between workers, and reaches cluster admin in a single shift.

Containment pending approval assumes a person is at the console, awake, holding authority to act, inside the window where acting still matters. Nobody is.

Stand up an open weight model inside your own boundary before you need it

The one recommendation this incident proves rather than suggests. If your response plan depends on a model that may refuse to look at attack data, you do not have a plan; you have a dependency. Get the approval while nothing is on fire. (If you are in government, I think you will have a hard time with this, and I do not have a workaround to offer you.)

Test escalation separately from detection

The alerts fired here. The triage layer processed them. Nothing reached a human, on a weekend. Most organizations exercise whether an alert is generated and assume the rest. Exercise the path from signal to a woken human, on a Saturday, with the person who actually carries the pager.

Classify your first sign of this correctly, which you will not

OpenAI’s first indication was a service falling over under load. It ran a clean availability incident and moved on. Build the reflex that an unexplained resource spike in an environment where agents run is an integrity question until proven otherwise.

Verify your model provider exception on your actual connection path

Enrollment is not the same as the exception reaching you, particularly when it passes through a reseller or hyperscaler layer. Test it against real attack data before an incident. Whatever approval you would need runs on a timescale that does not fit inside one.

Build a model routing gateway

When a model refuses mid-analysis, the response should be an automatic retry against a different model, not an analyst filing a ticket.

Fund response in people and tokens, and know which number you are quoting

Reconstructing this consumed roughly three million GPU-hours on the originating side, which credible public estimates put at millions of dollars. Hugging Face has not published its own response cost and described it as mostly human. (Two very different numbers, plus a third circulating in secondhand accounts that no public source supports, so check which one you are repeating.) Fund both ahead of the call, and ring-fence the capacity so cost controls cannot throttle you mid-response.9

Run the tabletop with model refusal in it

Sandbox escape, stolen credentials, third-party impact, agent persistence, and a frontier model declining to analyze your evidence at hour three. If that scenario is not in your exercise, your exercise describes a world that ended in July.

Inventory your harnesses, and check what you have published

The model is the engine. The harness is what the engine drives. The launch point in this incident was a research harness on Modal, exposed and unauthenticated, belonging to neither party. Hugging Face calls it the external launchpad for the entire campaign. Ask which harnesses you own, which you have made reachable, and which you would have to build. This is why we are rebuilding SIFT as a harness you can plug your own model into, so forensic tooling does not need to be rewritten every time the model choice changes.10

Expect hallucinated artifacts, and benchmark debris that looks like malware

Agents leave internal monologue, malformed commands, and hallucinated output in logs. Worse, evaluation artifacts can be indistinguishable from real implants. Decide in advance how long you will spend classifying something ambiguous before you simply replace it.

Learn to tell hostile agents from your own

Hugging Face’s harder unsolved problem is not this attack. It is that legitimate agent traffic on their platform now looks structurally like hostile agent traffic, so the patterns that used to separate signal from noise no longer separate anything. If you run a platform that agents use, that problem is already yours.

Reconsider what patching is for, and what discovery now costs

When a patch drops, the diff is a map to the exploit, and coding that exploit is now fast. The same month as this incident, a nine-year-old filesystem race condition affecting millions of systems was disclosed after being found by an AI system rather than a human researcher.

If your primary defense is a 30- to 90-day cycle with a testing gate, that model is under strain. I asked a room of senior security leaders whether we should even be patching on the current model, and it stopped the conversation, which was the point. I do not think the answer is to stop patching. (Putting that in writing before somebody quotes the question and drops the answer.)11

One thing this incident does not change. The agents remained bound by the privileges they could obtain and the systems they could reach, and both parties describe the techniques themselves as unremarkable. Segmentation, least privilege, and egress control did not become obsolete here. They became the thing standing between an autonomous collective and your production environment.

Section eight: what this was not the first of

Treating this as a singular event is the most common mistake in the coverage, and it makes the defensive lesson look more exotic than it is.

In November 2025, Anthropic disclosed a cyber espionage campaign it had detected the previous September, in which its coding model executed 80 to 90 percent of tactical work across roughly 30 targets, succeeding against a small number, with human operators intervening at 4 to 6 decision points per campaign. That account drew skepticism, largely because Anthropic has published no indicators of compromise and has not revised it. That was a deliberate adversary using a commercial model. This incident is the same capability arriving by accident, from inside the lab, aimed at a partner. The pattern across both is that the human is now a supervisor of tempo rather than an operator of tools.

The same summer produced several concurrent reports of unsanctioned model behavior during cyber testing at multiple organizations. Whatever else is true, this is not one company’s engineering lapse. And it has stopped being only an engineering story: fifteen state attorneys general sent an evidence preservation letter on August 4, a House oversight letter followed on August 10, and a bill to require kill switches on autonomous systems was introduced in late July. (Whatever you think of any of that, it means your own agent logs are now the kind of thing somebody may ask you to produce.)12

Section nine: what I still do not know

Who decides admission to provider access programs, on what criteria, and with what appeal, is an open question, and this incident is the argument for asking it out loud. I am not going to characterize how any vendor’s programs are structured, because that is not mine to describe, and the people who run them should answer it directly. What I can say is that the thing being gated is now the ability to investigate your own breach.

Why the second day dropped to almost nothing, I do not know. Hugging Face records it as low-volume reconnaissance and does not offer a reason. It might be scheduling, a run ending and another starting, or nothing at all. (I would like it to mean something, which is exactly why I am not going to claim it does.)

And I do not know what the independent assessment will say when it lands, or what OpenAI’s full postmortem will add or retract. One party has already said that the other’s account contained inaccuracies without specifying which ones. Until those documents exist, a meaningful part of this report is one organization’s word about itself, and I would rather say so than imply a confidence the record does not support.

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

Evidence ledger

Every load-bearing claim in this document is graded. If you intend to quote this report, quote from the A rows and attribute the B rows to the party that made them.

What the record still does not answer

• OpenAI’s formal written technical report, still forthcoming after the August 5 public account.

• The METR and Redwood Research review has not yet been published.

• Which specific assigned CVEs correspond to the two exploitation chains described?

• Whether CVE identifiers exist for either flaw in Hugging Face’s dataset pipeline.

• Which inaccuracies one party alleges in the other’s account.

• Any verifiable identifier for the claimed kernel privilege escalation.

• Current model refusal behavior, verified at publication rather than assumed.

Appendix A

Update, August 13, 2026
A national security presidential memorandum signed Wednesday authorizes vetted private US companies to run cyber surveillance and cyber effects operations against foreign criminal organizations: breaking in quietly and breaking things, in the memo’s own definitions, under federal direction, with a bond of at least $1 million posted against noncompliance and every operation approved in writing by co-directors at DOJ and DHS.

But the interesting question is this: why did Washington suddenly believe this could work?

Sandra Joyce’s team at Google Threat Intelligence Group spent the last year making disruption look controlled, legal, and boringly effective. Joyce proved disruption works while staying scrupulously inside the legal line. IPIDEA in January. GRIDTIDE in February. Measurable degradation across hundreds of threat groups, zero unauthorized access, and a bright line she kept repeating: “this is not hacking back.”

Joyce’s work accomplished two things at once: It produced results no sanctions package has ever produced. And it made private-sector operations look like something a government could supervise instead of something it should fear.

Be precise about what happened, though, because this memo is uncharted waters, and licenses a lane Google deliberately refused to enter. The memo authorizes something companies could not do before as published federal policy: they may now operate on systems it does not own: covert access to collect intelligence, then operations to manipulate, disrupt, deny, degrade, or destroy those systems if DOJ and DHS approve the work in writing, and at the pace of written interagency approval.

Which is my first worry. The permissionless lane, where Google shut down attacker cloud projects, domains, and API access on its own systems, and used court orders when the infrastructure sat elsewhere, is the one that produced the results.

The second worry is older. The program assumes a target is criminal rather than state-run unless clear intelligence says otherwise, and in the Russian ecosystem that distinction is one phone call. Attribution is the load-bearing wall. Almost right is the expensive kind.

Joyce said disruption has to become the status quo in our industry. As of Wednesday it’s federal policy with an escrow account. The marque question is settled. Whether the oversight holds is not. Tell me where you land.

→ The memorandum: https://www.whitehouse.gov/presidential-actions/2026/08/expanding-capabilities-to-combat-transnational-cyber-enabled-crime/

Originally published July 17, 2026

Sandra Joyce, VP of Google Threat Intelligence, has spent the past year arguing on the industry’s biggest stages that briefing governments and waiting isn’t a strategy, and that disrupting adversary infrastructure has to become normal practice.

She’s right.

On Monday, Brussels and London announced their first joint cyber sanctions package. The EU named nine individuals and four entities. The UK named 24. The targets: FSB Centre 16, GRU officers, and the criminals working alongside them. The EU traces the campaign back to at least 2010.1

By the afternoon, Moscow called the charges baseless and the operations kept running. (Both sides could pre-record their parts at this point. Maybe they already do.)

This is the same playbook Washington has run since 2014. The only thing new on Monday was who held the pen.

As deterrence, it accomplishes exactly one thing: it lets the governments issuing it feel like they responded. Attribution, indictment, sanction, repeat has never stopped an active state campaign. Not once. Call it what it is: finger-wagging with a legal budget.

And the attribution feeding these sanctions packages mostly comes from commercial threat intel, from shops like Mandiant, where I helped author the first M-Trends reports.

The intelligence is real. What governments do with it is the problem.

Fifteen years of the same press conference

2014: DOJ indicts five PLA officers, the first nation-state cyber indictment. No arrests2.

2018: twelve GRU officers charged for the DNC hack, seven more for the anti-doping and OPCW hacks. None in custody.

2020: six more charges for NotPetya and Olympic Destroyer.3

2020: the EU’s second cyber sanctions ever, for the 2015 Bundestag hack, five years after the fact. (The EU’s cyber sanctions framework didn’t exist until 2019, so every attack before that got graded against rules written afterward.)45

2021: Treasury designates six Russian tech companies.6

2026: Monday.

The cycle never changes. An incident, one to three years of attribution work, a press conference, asset freezes on people who hold no Western assets, travel bans on people who were never coming here. Then the next campaign, usually within months.

Even the academic literature has quit pretending. Scott Jasper’s study of Russian cyber operations says it bluntly: sanctions and indictments have “done little to alter Moscow’s behavior.”7

Mandiant founder Kevin Mandia said at RSAC 2025 that China nearly doubled its cyber aggression because there are no agreed rules of engagement.8 Of course it did.

Most of the names on these lists sit inside sovereign territory with no extradition treaty. You can’t freeze assets that were never here. You can’t arrest a GRU officer who never leaves Moscow. Sanctioning two officers does nothing to the GRU, which keeps running at full strength with new staffing. Sanctioning at that scale is record keeping, not deterrence.

Yes, the playbook buys some things. Joint attribution keeps the coalition glued together, and advisories give companies legal cover to name campaigns and coordinate.

Hitting enablers can bite: the 2021 designation of Positive Technologies hurt more than any officer listing because that company lived in the global economy.9 North Korean crypto theft got squeezed at the conversion layer, not by naming hackers.10

Where operators have extraditable exposure, combined instruments work; ask LockBit.11 All real. None of it deters state operations. (The EU’s own defenders call it “building the normative framework.” Notice what that phrase doesn’t claim.)

What actually degrades an adversary

Sharing intelligence stopped being a strategy somewhere around the fifth GRU indictment.

Google, Microsoft, Cloudflare, and Lumen own the platforms, networks, and APIs the campaigns run through. That’s visibility plus the authority to act, without touching anyone’s sovereign systems.

The toolkit: civil suits that seize infrastructure, public exposure that burns tradecraft, technical shutdowns and sinkholing, and product hardening that closes the abuse path for good.

It’s already been executed three times this year.

January: Google and partners dismantled IPIDEA, the world’s largest residential proxy network. Thirteen brands, consumer devices recruited through 600+ Android apps.13 In one seven-day window, Google’s threat intel team counted 550+ distinct threat groups using it, including state actors from China, Russia, North Korea, and Iran.14 Court orders killed the storefronts. 7,400+ C2 servers went dark.15

February: GRIDTIDE. A China-linked espionage group had run a backdoor since at least 202316 using the Google Sheets API as command and control. Implants polled spreadsheet cells for instructions, so every byte of C2 traffic looked like a finance team updating a budget file. (I’d almost admire the tradecraft if it weren’t sitting inside 53 victim organizations across 42 countries.17) Google terminated the cloud projects, sinkholed the domains, and revoked the API access. No government on earth can revoke a Google Sheets API key.

July: NetNut. The Popa botnet turned two million smart TVs and streaming boxes into exit nodes for a proxy brand owned by Alarum Technologies, a Nasdaq-listed company.18 Alarum called June’s attribution research “inaccurate,” its SDKs consensual bandwidth-sharing.19 Weeks later Google killed the C2 accounts and disabled the infected apps, while the FBI and IRS Criminal Investigation seized hundreds of domains.20 Then the market ruled: 21% down on takedown day, another 51% four days later, an $8 stock near $2.20 by mid-July, securities-fraud investigations open.21

These are the difference between upstream and downstream.
Disruption cuts the adversary’s supply lines while the campaign is live.
Sanctions show up years after the siege.

Where government fits, and where it can’t

Washington has the vocabulary now. National Cyber Director Sean Cairncross and Kevin Mandia shared the Aspen stage talking cost imposition and shaping adversary behavior, and Mandia’s version remains the bluntest: “no travel, no money, no fun.”22 Reach the actual humans.

The direction is right. Consequences have to exceed rewards before operators change behavior, and physical deterrence works when you can reach the body. Against state-protected operators, you usually can’t.

The machinery is the problem. Government cost imposition moves through an interagency process in months.

The most useful thing government can do is building the legal scaffolding that lets the private sector run operations at scale.

Joyce’s doctrine: platform authority, civil courts, no hack-back. It’s already producing results. Private tech companies own the infrastructure, the platforms, apps, and networks that these attacks run on. They can shut an operation down directly and immediately.

The CISA 2015 information-sharing protections were a prototype. The next version has to cover coordinated disruption: liability protection, defined authorities, real oversight.

Building that legal scaffolding is also the case I made in the SANS RSAC safe harbor paper, Asymmetry to Parity: attackers operate under zero regulatory constraint while defenders carry legal, insurance, and compliance friction on every action they take.23

Where this can fail

The doctrine has three real problems. Ignoring them would make this piece as hollow as Monday’s package.

Reconstitution. Residential proxies are a commodity, and IPIDEA’s successors are being assembled right now. Joyce concedes it herself: “These groups will recover and they will be back.24” The purpose is not elimination. It’s forcing adversaries to rebuild from scratch, which burns months, money, and tradecraft while defenders harden and victims get notified.

Concentration. If disruption capability lives inside five or six companies, who decides which campaigns get disrupted and which is watched for intelligence? Who audits the disruptor when attribution is wrong?

Speed. The loop still runs on human-coordinated legal action, and both Joyce and Mandia expect largely autonomous AI-driven attacks within a few years. A civil court order doesn’t move at the pace of an agentic campaign. (That gap worries me more than anything else in this piece.)

Serious problems, all three. None of them rescue the worse approach.

What this means for defenders who aren’t Google

If you don’t run a hyperscaler, none of this sounds like yours to act on. It is.

Disruption runs on visibility, and the disruptors don’t keep the work to themselves. IPIDEA shipped with intelligence handed to platform providers, law enforcement, and research firms. GRIDTIDE shipped with published indicators and the exact persistence tradecraft to hunt.

• Hunt it. Pull every non-browser process making Google Sheets API calls from your servers and make someone explain each one. GRIDTIDE persisted as a systemd service dressed up as a Debian utility, moved laterally over SSH using service accounts, and dropped SoftEther VPN Bridge for its outbound tunnel.

• Audit your systemd services, review authorized_keys on every service account, and flag any VPN bridge nobody remembers installing.

• Report adversary infrastructure you spot in your own logs to the platforms that can revoke it.

• Push indicators through your ISAC instead of sitting on them.

• Write the IR plan assuming no sanctions package is coming to help, because it isn’t.

• Ask. When a vendor tells you they found adversary infrastructure on their platform, ask what they did about it. Notify-and-wait is an answer worth knowing before you renew.

Fifteen years of attribution, indictment, and sanctions produced a Kremlin statement that could’ve been copy-pasted from 2018. One January takedown produced measurable capability loss across 550+ threat groups the same day25. Sandra Joyce is right. Disruption has to become the status quo. Sanctions can keep the records.

Tell me where you land on this.

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

Call it Salt Typhoon Jr.: a PRC-linked group sat inside North American military research and medical networks for more than a year, undetected, and walked out with the research that decides who wins the next decade.

It was easy to miss under the flood of Mythos, Fable, and zero-days-for-days coverage. (Which tells you we still rank threats by how frightening they sound to a general audience, not by what they cost national security.)

GTIG tracks the group as UNC65081. Their collection list reads like a tasking order: nearly 150 keywords spanning:

• Defense intelligence

• Indo-Pacific operations

• Artificial intelligence (AI)

• Uncrewed systems

• Cyber offensive programs

• Medical research

This was public-health surveillance running inside a military espionage campaign, out of the same institutions, on the same wire.

The exfiltration method should stop every Workspace admin cold. The attackers used a Google Workspace content-compliance rule to silently BCC matching emails to a Gmail account they controlled.

Any operator can copy that playbook tomorrow against every university, hospital, and defense contractor running Workspace.

This is a clean test case for the question I get in CISO rooms: where would AI have helped the defenders?

Three places AI would have helped:

1. Admin control-plane monitoring. A brand-new rule that BCC-forwards sensitive mail to a consumer Gmail account should trip an alert the day it is created. That is pattern-spotting across thousands of admin events, which is what a model is good for.

2. Cross-victim correlation. The same campaign hit multiple organizations at once, and each intrusion looked isolated because nobody had visibility across all of them. Correlation across organizations, identity providers, and SaaS logs could have surfaced the pattern months earlier.

3. Behavioral EDR over the dwell window. INFINITERED sat on the REDCap server for more than a year, harvesting credentials, before the attackers used them to pivot into the internal network. That is a long baseline, long enough for behavior-based detection to flag a novel dropper and its callbacks even on malware nobody had seen before. (In theory. In practice, most shops never tuned the baseline.)

Where AI would not have helped?

1. Attacker Stealth: These operators knew what defenders watch and stayed under it. They used legitimate credentials, kept operational security tight, and ran nothing noisy.

2. High Environmental Noise. Defining a baseline for an AI model in this specific environment is nearly impossible. Teaching any model what “normal” looks like inside a military health research institution, across clinicians, researchers, contractors, and classified projects, is hard.

3. AI Finds Outliers. It does not fix bad access design, or an organization that will not lock things down.

Three things worth doing this week.

1. Audit your mail rules. Google Workspace, Microsoft 365, anything with message-handling rules. Look for rules you did not create, destinations you do not recognize, and conditions that quietly match your sensitive projects.

2. Treat SaaS admin config as a controlled asset. Approvals, alerts, and a regular review on every admin change, the same way you would treat a firewall rule.

3. Patch REDCap, and assume patching is not enough. The initial access vector is still unconfirmed publicly, but INFINITERED was engineered to reinject itself through REDCap’s upgrade process. A patch dropped on a compromised server is not a clean server. Rebuild, then patch. That logic applies to every “we’ll keep the old version for one project” exception in your environment.

This ran for over two years inside medical and military research networks before anyone caught it. The detection tooling we are all paying for did not see a two-year intrusion.

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

A reporter asked me last week whether 90 days was the right number. The executive order signed this week answered with 30. I didn’t have a clean number for him then and I don’t now, because from a pure security standpoint there isn’t one.

There’s too much code exposed and too much testing left undone for any window to make this safe. (Ask a security person how much warning they want and the honest answer is “all of it.”)

The executive order Trump signed Tuesday, “Promoting Advanced Artificial Intelligence Innovation and Security,” asks AI developers to give the federal government up to 30 days with a covered frontier model before it reaches trusted partners, and then everyone else on the public disclosure cycle. The draft had said 90.

Security people wanted more than that. The labs wanted far less. Thirty is where it landed, a long way down from the draft, and nobody in either camp is happy. That is usually the shape of a real compromise, not a failure of one.

The buffer is not a fix. It’s a hurricane warning. You board the windows, you move what you can, and the storm still makes landfall. The value isn’t prevention. It’s the time to prepare, and the fact that you aren’t surprised when it hits. (Surprise is the expensive part.) Read “signed” as “problem solved” rather than “clock running,” and we will have wasted the one thing the buffer actually gives us.

There’s a quieter assumption in the whole debate: that this is a one-shot problem. Run the model across the public code, close the gaps, declare victory. It doesn’t work that way.

Source code analysis is Mythos’s current focus, which is why open source gets scanned first. Anyone can point it at the Linux kernel, and if there’s a flaw in something that runs in every cloud on earth, it gets found.

The defensive upside is real. Organizations can finally scan their own codebases before they push to production instead of after the breach, and full vulnerability analysis could become routine. The defensive upside and the offensive downside are the same tool. You don’t get one without the other.

But the same capability does black box exploitation well, and that’s the part that breaks the one-shot fantasy. You don’t need source code to find a zero day. You poke at how the product behaves, watch where it breaks, and build the exploit from the outside.

That is how nation-state teams have gone after Microsoft and Apple and Google for years, none of which hand over their source. Closing your code does not close the door. The vulnerabilities get found either way. (Adversaries don’t wait for their tier assignment.)

Which gets to what I actually worry about. Access to these capabilities is not equal, and it isn’t going to be. JPMorgan, Amazon, the players sitting on their own data centers, they’ll be fine. The order names rural hospitals, community banks, and local utilities as a concern, correctly, and then offers them a discretionary “where appropriate” while the early access goes to trusted partners selected in collaboration with the government. The hospital in Springfield is at the back of that line.

The buffer also rests on an assumption I’m not sure holds: that the good guys can control access and the bad guys can’t get it. We know DPRK operatives get hired into Western companies as remote engineers and security staff. If an adversary genuinely wants to run their own testing against one of these models, the cleanest path is to already be inside an organization that has it. (I’m not saying anyone’s doing this. I’m saying the temptation and the access are both sitting right there.) A 30-day window assumes a level of control that the last several years of insider-threat reporting should make us skeptical of.

Underneath all of it is the oldest question in cyber defense: what is the federal government actually responsible for? The critical infrastructure everyone is anxious about sits in private hands. Data centers, hospitals, banks, the grid. The military is restricted from defending a private company’s network. The FBI takes your report and thanks you for the data. CISA runs real threat intelligence, coordinated disclosure, and binding directives across federal systems, but its authority to reach inside a private company and run the defense is narrow.

When Volt Typhoon pre-positioned in American infrastructure and Salt Typhoon went into the telecoms, they went after private companies, because that is where the front line is. (I came up through the military side. The distance between “protect the nation” and what you are actually permitted to do still bothers me.)

The government does have a role here, and it’s less about running the defense than about who gets to decide the rules. The order keeps the framework voluntary and explicitly avoids any licensing requirement, which is the right call for getting industry to participate at all. But it also leaves trusted-partner selection as a developer-and-government collaboration, and a vendor should not be in the position of choosing which organizations and which countries live inside the protected tier and which don’t. That is a determination with real geopolitical weight, and it should not rest on a company’s procurement team. Whether you welcome federal involvement or not, having the labs quietly pick winners is worse.

None of this gets solved by the order.

What the order does, at best, is document the threat and start the argument, and the real risk now is that “signed” gets read as “handled.” The work is what the community builds during the buffer. That is why Gadi Evron, Rich Mogull, and I, with Cloud Security Alliance, SANS, and [un]prompted are running closed-door CISO working sessions in DC, New York on June , and San Francisco: one hard question per session, the people in the fight writing the new playbooks before the vendors write them for us. All senior security leaders should apply to attend. The first session drew strong feedback by every account I’ve gotten back.

Read the Mythos-ready security program paper by the same coalition here.

The honest open question I don’t have an answer to: when the next frontier model ships, and the one after that, how does any of this scale? The list of who’s inside and who’s outside only gets longer. (And nobody has volunteered to hold the list.) Find out where your organization actually sits in that access structure. If you don’t know, that is the first thing worth doing this week.

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

Anthropic and roughly 50 partners used Claude Mythos Preview to find more than 10,000 high- or critical-severity vulnerabilities in the first month of Project Glasswing1. Most partners found hundreds of high or critical issues in their own code. (One month. Let that sit for a second.)

Of those 10,000-plus, 97 have been patched upstream as of May 22. That number is not a measure of how hard anyone tried. It is a measure of where the work now jams.

Software security used to be limited by how fast you could find vulnerabilities, and now it is limited by how fast you can verify, disclose, and patch them.

High and critical bugs are taking about two weeks each to patch. Several maintainers have already asked Anthropic to slow its disclosure rate, because they cannot keep up.

Discovery is no longer the bottleneck. The humans in the pipeline are.

The patch playbook itself, coordinated disclosure on a 90-day clock, monthly patch cycles, the quarterly review, was built for a world where finding a flaw was slow. That world is gone. The playbook is not strained. It is finished, and most of us have not said that out loud yet. (I would love to be wrong on this. Correct me, and tell me what planet still runs on a 90-day clock.)

Rebuilding it is not a tooling purchase. It is a skills problem, and a specific one. Working at this volume means triaging AI-generated findings ten deep, judging which severity ratings hold up, and deciding what gets fixed in what order when the queue is a thousand items long.

That is human judgment under machine-scale load, and almost nobody has trained for it, because the tools that create the problem are months old.

You cannot hire your way out of this, because the talent pool does not exist yet.2 All of us are figuring it out at the same time.

So the people who can help you most are already on your team. They are the ones who know your business, who have worked real incidents, who understand what a finding actually means in your environment.

What they are missing is reps on AI tools under realistic pressure.

The SANS Institute Find Evil! hackathon is one place to get those reps fast. Practitioners build autonomous incident response agents, run them against real case data, and watch where the AI is sharp and where it falls apart. That last part is the point.

The skill that transfers is not the agent, it is the calibrated judgment of when to trust the machine and when to override it, and that is exactly the muscle the patch pipeline now needs.

Find Evil! runs through June 15, with $22,000 in prizes, at findevil.devpost.com

If you manage defenders, here is the Monday version: Pick two people who know your environment cold. Give them protected time this month to put AI tools against your own findings backlog and report back on where the tools broke. That is the rewrite starting, in miniature, on your team.

The Glasswing numbers should change what you do this week, not how well you sleep. Train the team you have.

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

Because this is new. And it matters.

Gadi Evron said something to me I can’t reproduce exactly (I genuinely wish I had written it down), but the core of it was this: Every playbook we have for cybersecurity is being thrown out because of AI, and the new ones have to come from the organizations dealing with the challenges firsthand, not from people observing from the sidelines.

It’s the same principle SANS has operated on. We want practitioners teaching, not academics. Real-world experience over theoretical distance.

Gadi applied that same logic to a much bigger problem: nobody writes the new playbooks alone. Not one vendor, not one brilliant person, not one startup or training company. We each carry a piece of it.

The only way to assemble it is to get the people facing the challenges into the same room and actually work together. That’s what we’re building in San Francisco, NYC, and DC.

That’s why I need CISOs there. Not to observe or to take notes at some transmission-based event where a speaker downloads information at you for two days.

Come to work, challenge assumptions, test outputs, and ask the questions nobody in your organization can ask because you’re the only one who sees the full picture.

“But what if I’m still figuring out AI? How can I contribute to a playbook?”

If we had it figured out, we wouldn’t need these working groups. (I want to be very clear about this.) Nobody in that room is walking in with all the answers. I don’t. Gadi doesn’t.

The entire point is that we’re all wearing the same shoes: trying to learn fast enough, watching questions multiply faster than answers, feeling more isolated than we should in a field full of smart people facing identical problems.

What Gadi saw, and what I’ve come to believe, is that we need to form something like a massive cybersecurity LLM made of CISOs. A collective that can answer hard questions no single organization can answer alone, where nobody has to figure this out in isolation.

That collective needs your experience in it. Your specific context. The things your team is struggling with right now that haven’t made it into any framework yet, because the frameworks are all six months behind where you already are.

We’re starting with CISO leadership deliberately. Organizational alignment starts at the top, and this problem requires organizations to carve out real time and real attention.

One of the actual outputs of these workshops will be identifying which other groups of professionals need to swarm together to do this correctly. (My instinct is that list gets long, fast.)

But leadership comes first, because that’s what creates the conditions for everyone else to do the same work.

I’m part of this because Gadi saw the need before most people did. He believed the Mythos paper was the right first step, and this CISO collective is the logical next one. I’m along for the ride because I think he’s right, and because I’m not able to solve this alone any more than you are. (I’m learning and struggling with this daily too. I just stopped pretending otherwise.)

Come to San Francisco. Come to NYC. Come to DC. Bring your real problems, your half-formed opinions, and your unanswered questions. No one is coming to save us by writing a book by themselves. We’re writing it together, as a community.

I’ll see you there.

Thank you, Gadi, for seeing what this needed to be.

Thank you!

-Rob T. Lee

The urgent message from the SANS AI Cybersecurity Summit speakers: Attackers are operating autonomously at AI speed, our defenses are still human-speed, and the gap keeps widening in their favor.

Anne Neuberger, who spent years thinking about this at NSA, described the shift with brutal clarity. In the past, “it was a race against an attacker jiggling a doorknob at a time. Now what we have is a set of attackers who can really jiggle every doorknob all at once.” She meant it literally. Not checking one system, one user, or one service, but all of them. Simultaneously. Automated. That’s not a tactic. That’s infrastructure.

Greg Isenberg captured the asymmetry even more precisely: “AI made it 100x easier to build. It also made it 100x easier to attack.” The barrier to entry collapsed for both sides at the same time. Asymmetry is dead.

The uncomfortable part wasn’t the threat data. It was watching people realize that most of what we’ve built for “incident response” is built for human-speed attacks that unfold over weeks. Attackers now operate in seconds. (I’ve been saying this for years. Seeing it land in the room validated something I was hoping I was wrong about.)

Here’s what actually changed my thinking during the summit:

The Pattern We’re Missing

Jacob Klein, head of threat intel from Anthropic was direct: “The landscape has already changed. It’s not just changing in the future, though it is. The landscape has changed today.”

He pulled numbers showing 48% of tracked malicious actors saw meaningful capability uplift from AI between July 2025 and February 2026. Not just usage: uplift. The median attacker isn’t using AI for one step of their chain anymore: they’re automating an average of 16 techniques from reconnaissance through exfiltration. (I’ve seen the data. This isn’t speculation.) That’s not “AI-assisted attacks.” That’s AI as infrastructure.

Yotam Perkal nailed the threat modeling problem: “Stop threat modeling AI like a tool and start threat modeling it like an operator.” We’re still modeling attackers as humans using tools. AI introduces what he called a “third operator” into our environments. When you give an autonomous agent business context, access to tools, and permission to act, it stops being software. It becomes an actor, a privileged actor. We’re still threat modeling it like it’s a calculator. (Yeah, we’re way behind on this.)

Julie Davila from GitLab pointed out that we’re looking in the wrong place. “Failures rarely occur where you’re watching. They occur in the seams between the components.” While everyone obsesses over prompt injections and model outputs, the real vulnerabilities live in the orchestration layers, the APIs and the points where untrusted AI output gets serialized into privileged execution boundaries without validation.

Complex systems don’t usually fail at the obvious points. They fail at the integration points no one thought to harden because they weren’t built with AI in mind. Any time AI-generated data crosses a trust boundary that assumes human input, failure is guaranteed. Sounil Yu put it differently: “AI is a great magnifying glass in the sense that a lot of these issues are the result of brittle primitives that existed well before the LLM craze.” We didn’t invent these problems. AI just weaponized them.

The meta-problem underneath all of this: we built security controls assuming we were defending against humans or relatively simple malware. Not autonomous agents or systems that can test thousands of variations in the time it takes you to sip your coffee. (And yes, someone in the room actually said this problem was “unprecedented.” It’s rarely unprecedented; we’re just repeating history faster.)

What Actually Matters Right Now

So, the threat is real, and we’re unprepared. What do you do Monday morning?

Stop modeling the AI. Start modeling the workflow. Most teams I talk to are still thinking about “securing the model” or “securing the output.” That’s the wrong frame. The question isn’t whether Claude could do something bad. The question is: what does your workflow do when Claude makes a bad decision? If your AI system can approve a transaction, trigger an alert, or query sensitive data, you’re not running a chatbot, you’re running a system with business authority.

Map every place in your environment where AI makes decisions or accesses data. Ask what happens when it’s wrong. Then ask whether a human is actually reviewing that decision or just clicking “approved” at AI speed. (That’s still failure. You’re just more efficient at it.)

Know what you’re running. Build a basic AI asset inventory. What models are your teams using? Where are they deployed? What data are they touching? Use AI Bills of Materials (AIBOMs) the same way you use software BOMs, now, not later. Most teams can’t answer basic questions like “how many models are interacting with our sensitive data?” or “which models are developers pulling from Hugging Face?”

You can’t defend what you don’t know exists. (We learned this lesson 20 years ago with shadow IT. Apparently, we’re learning it again.)

→ Rest of my writeup is at sans.org on what speakers said about decision velocity, what to never outsource, and embracing deception.

→ Check out the SANS AI Summit 2026 NotebookLM to chat with the content. All speaker sessions and materials were loaded in to interact with. Ask about a speaker or topic. Chat is private to you and not shared. Start here: The 20 Deepest Insights from SANS AI Summit 2026 or here: Analyst’s AI Burn Book: SANS AI Summit Notes

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

→ If you want to work on this problem directly, check out the Find Evil! hackathon and our proof of concept for AI-augmented incident response; Protocol SIFT. It’s what happens when you wire an AI agent into a forensic workstation full of trusted tools and tell it to behave. It's an early capability with real outputs, failure modes. Join our community effort to make it something defenders can deploy. 42 days to enter. An incredible 2,500+ builders and teams are in as of today. $22K in cash prizes. Sponsored by SANS Institute. Register findevil.devpost.com

→ I kicked off a LinkedIn Learning course on how to get AI tools approved. If we don’t get business teams and security talking and working together, the risk stays in the shadows. Module 1 (90-sec video + worksheets) here.

Transcript from video: Jacob Klein, head of threat intel at Anthropic

Now, one thing before I continue and go through sort of a landscape analysis, I always want to keep in mind when I go through these cases is my job is to find bad actors and understand what they’re doing.

But a lot of folks here are working on defense for your own organization. Much of the same techniques and tools that I’m seeing bad actors using, a defender could use as well. You could look at your own endpoints at scale, your own code at scale to understand vulnerabilities to hopefully then patch them.

If you have a detection and response team, you can use AI to understand signals and quickly investigate the signals as well. So it’s very much a dual-use piece of technology. I just happen to be talking from the risk side of the angle, but I don’t want to pretend that almost everything I’m walking through can’t be used by a defender as well.

On Friday afternoon, Gadi Evron asked if I wanted to collaborate on a CISO community document. “Releasing Monday.” I said “Sure.” (That word has cost me more sleep than any APT.)

Anthropic had announced Mythos on Monday. CSA was running an emergency CISO Zoom on Tuesday. SANS was already building our BugBusters webcast with Ed Skoudis, Joshua Wright, and Chris Elgee for Thursday.

Everybody smelled the same thing, everybody was building their own response, and nobody was coordinating.

The entire community was asking the same question: what do we actually DO about this?

Three nights later -- Friday, Saturday, Sunday -- Gadi Evron, Rich Mogull, and I had a 30-page strategy briefing with 60+ contributors from CSA, SANS, [un]prompted, and the OWASP GenAI Security Project. Contributing authors included Jen Easterly, Bruce Schneier, Chris Inglis, Phil Venables, James Lyne, Heather Adkins, Rob Joyce, Sounil Yu, and a dozen others who all said yes within hours.

The briefing is free. It’s a draft. It’s live now. And it’s the thing I wish existed on Tuesday when my inbox started filling up with “what do we do?”

The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Program

Expedited Strategy Briefing By the CSA CISO Community, SANS, [un]prompted, the OWASP Gen AI Security Project, and the wider community.

Read it here: https://labs.cloudsecurityalliance.org/mythos-ciso/

Listen, Watch, or Quiz Yourself

We built the full NotebookLM resource kit: audio deep dive, cinematic video overview, and three quizzes (board prep, technical team, general knowledge).

https://sansurl.com/CISO-mythos-ready

Same content, different format. If 30 pages feels like a lot right now, start here.

Lines From the Briefing Worth Stealing

Before I get into what I worked on, here are the lines from this document that I think will stick with people. Use them in your board decks, your team meetings, your Slack channels. They’re shareable because they’re true.

“The window between discovery and weaponization has collapsed into hours.“ That’s the one-sentence version of why this matters. Tape it to your monitor.

“Security teams are caught in a vice: AI is simultaneously accelerating the volume of vulnerabilities they must respond to and the volume of code their organisations are shipping.“ Both directions at once. More vulns to fix, more code creating them. (Welcome to the squeeze.)

“Using a coding agent is now easier than using Excel.“ The number one objection to agent adoption is “my team doesn’t have the skills.” They do. If they can type, they can start.

“Long-term goals should be considered as a quarter away at most.“ This one will make program managers flinch. Good. The planning horizons most organizations use were built for a threat landscape that no longer exists.

“Mythos generated 181 working exploits on Firefox where Claude Opus 4.6 succeeded only twice under the same conditions.” 181 to 2. That’s not incremental improvement. That’s a different category of capability.

“This is a normal response to disruptive capability shifts, not a crisis of relevance.” For everyone who read the Mythos announcement and felt a pit in their stomach about their career. You’re not obsolete. You’re adapting. There’s a difference.

“We have done this before. Y2K was a systemic threat with a hard deadline, and the industry met it through coordinated, disciplined effort.“ The closer. And it’s true. (Just with less sleep this time.)

The Risk Register

Most of the Mythos commentary this week has been either “we’re all going to die” or “this is just marketing.” Neither helps a CISO walk into a Monday morning meeting with a plan. So instead, we built a risk register. 13 rows. Grouped by severity. Mapped to OWASP LLM, OWASP Agentic, MITRE ATLAS, and NIST CSF 2.0.

The thing I pushed hardest on was framing every risk as an acceleration of something that already existed, not as a new problem Mythos created. AI-driven vulnerability discovery has been happening for over a year. Mythos made it faster. That distinction matters because it changes how you respond. You’re not starting from zero. You’re adjusting timelines.

(If I had a dollar for every “unprecedented” I killed in this document, I could fund the next hackathon.)

A few rows worth calling out:

Row 1 (Accelerated Threat Exploitation) includes a point most coverage missed: every patch is now an exploit blueprint. AI accelerates patch-diffing and reverse engineering of fixes. The patch that protects you also teaches attackers where the vulnerability was. (Responsible disclosure just became an attacker tutorial service. You’re welcome.)

Row 5 (Insufficient AI Automation) is the one that will make people uncomfortable. It says if your defensive teams aren’t using AI agents, they can’t match the speed of AI-augmented threats regardless of their technical skill. The asymmetry is cultural, not just technological. (Turns out telling 250 CISOs their teams need to change generates the same reaction as telling 250 CISOs their teams need to change. Who knew?)

Row 12 (Regulatory Exposure) is the one boards need to hear. The EU AI Act hits in August 2026. When AI can find vulnerabilities at accessible cost the standard of “reasonable defensive effort” shifts. Boards will face questions about whether they used available AI tools for scanning, and whether not doing so constitutes negligence.

Row 13 (AI Hype and Confusion) is the one I added because the noise itself is a risk. Teams that dismiss this as hype, or exhaust their attention parsing every hot take, will miss the actual changes they need to react to. (The irony of adding a risk about too much AI content to a document about AI is not lost on me.)

The real problem isn’t that Mythos exists. It’s that your defensive deployment process was designed for quarterly software releases and regulatory cycles measured in months. (And yes, your CISO and their legal team are both thinking about SNEAKERS right now, even if they’ve never admit it out loud.)

The Priority Actions Table

11 actions. Ordered by urgency. Each one has a start date, a horizon, and a “What It Means” description specific enough that you can hand it to an engineering lead and they’ll know what to do.

The ordering was deliberate and generated significant argument:

PA 1 is “Point Agents at Your Code.” Not governance. Not strategy. Point the tools at your code and see what they find. You can start this today with Claude Code Security, Codex Security, Knostic’s OpenAnt, or Gadi Evron’s RAPTOR.

PA 6 is the one we added late: “Update Risk Models and Reporting.” Because we realized the risk register had a row about outdated risk models but no Priority Action telling CISOs to actually update them. The gap between “you have a problem” and “here’s what to do about it” is where most documents fail. We tried not to.

PA 11 is VulnOps. The longest-horizon item. Build a permanent vulnerability operations function, staffed and automated for continuous AI-driven discovery across your entire software estate. This used to be too expensive for most organizations. AI changes that math. (Your quarterly pen test is adorable. The attackers run continuously.)

The Board Briefing Section

This is the section I’d print and hand to a CISO who has 15 minutes to prep for a board meeting. It’s organized around the two things CISOs do in front of directors: justify the current program and ask for what comes next.

The strongest line in the paper (Rich wrote it): “The security program this board has funded is what makes the AI strategy viable.” That reframes the entire conversation from “security needs more money” to “your AI strategy depends on what you already invested in security.” (That sentence alone is worth printing on card stock and sliding under the CFO’s door.)

What I’d Do With This Document

If you’re a CISO: read the Priority Actions table and the risk register. Skip to the board briefing section if you have a board meeting this month. Print the 10 Questions table and use it to triage where your program actually stands, not where your last audit said it stands.

If you’re a practitioner: read the “Human Cost” section. It’s honest about burnout, the cultural challenge, and the fact that the practitioners who adapt fastest are the ones who lean into AI tooling rather than viewing it as a threat. Then go point a coding agent at your code. Today.

If you manage security teams: the paper says long-term goals should now be considered a quarter away at most. That changes planning, budgeting, hiring, and how you talk to your board about timelines. Adjust accordingly.

Tune in to BugBusters on Thursday, April 16

If you want to see AI-assisted vulnerability discovery against real code (not slides, not theory, actual terminals and actual bugs), SANS is running BugBusters on Thursday, April 16 at noon ET. Ed Skoudis, Chris Elgee, and Joshua Wright. No registration required. (Put it on your calendar.)

https://www.sans.org/mlp/sans-critical-advisory-bugbusters-ai-vulnerability-discovery-hype-vs-reality

The briefing will keep being updated. We shipped it now because CISOs need it now, not when it’s perfect. (Perfect is the enemy of Monday morning.)

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

That’s where most of us actually sit when we’re being honest. AI is terrifying and exhilarating in the same breath, and holding both of those simultaneously is uncomfortable, but that’s the reality.

Every day there’s some big news thing. This week it’s Mythos, autonomous exploit chains, another zero-day tsunami framed as the end of everything. But the same technology is letting doctors catch cancers on MRIs that specialists would have missed, and it’s about to make secure coding a realistic organizational practice instead of something we say we do but don’t.

Today the world is falling apart because there are 10,000 zero days on our doorstep. In six months, we might actually produce secure code. The apocalyptimist lives in both worlds. (Welcome. It’s uncomfortable here.)

Two things in this Substack: a signal and some noise.

(Noise) Mythos isn’t new.

It’s a polished rollout of something those of us in the industry have known for a long time: AI can find a massive number of zero days and vulnerabilities through fuzzing and code analysis. The capability is real. The packaging is new.

Flip the lens. If organizations had a much more efficient way to do secure coding without line-by-line analysis, that closes off most of the ways people break into systems.

Full vulnerability analysis could become routine. Taking your medicine, because now you actually have medicine to take. (Both things are true at the same time. That’s what makes this an inflection point, not a crisis.)

Anthropic delayed Mythos specifically because of cybersecurity implications.

That’s the first time I’ve seen anyone pump the brakes on an AI capability, and they chose cybersecurity. Not bioweapons. Not drug synthesis. Not autonomous weapons systems. Not the capability that lets someone engineer a more lethal COVID variant in their basement. Cybersecurity. (I genuinely want someone to explain that decision calculus to me over a beer, because I can’t make the math work.)

The same acceleration applies to drug therapies and bioweapons. We want to save a kid’s life from brain cancer, but we also don’t want that same capability creating lethal agents in the fridge next to little Susie’s Easy-Bake Oven.

That’s the nuclear proliferation debate, the gun control debate structure, on an exponentially faster timeline. And the industry isn’t prepared for how fast this conversation needs to happen. (We can’t pump the brakes if nobody agrees where the brake pedal is.)

(Signal) Entry-level job panic is overblown.

I’ve been pulling at this thread for a while and I fault the industry. That massive “unfilled cybersecurity jobs” number everyone quotes? It came from surveys asking CISOs: “How many people do you need to do your job correctly?” Not “how many unfilled positions do you currently have?”

A CISO with 10 people says they need 30. That delta became the “workforce gap.” Nobody was funding those 30 positions. The actual number of unfilled, budgeted positions was micro compared to the number that got quoted. (Pay attention to how survey questions are phrased and you realize how those numbers were built.)

The real problem is a skills gap, not a headcount gap. You fight with the team you have, not the team you want. The only way to close that is continuous skill development, and the workforce survey data backs this up. Skill development reduces burnout, increases retention, and keeps practitioners concurrent with the threat landscape. Senior people who haven’t taken formal training in years are running on inertia, not current capability.

Doctors don’t become surgeons by starting in the mailroom. Lawyers don’t become partners by being paralegals for a decade. These fields figured out residencies and apprenticeships to take people from formal education to senior practitioner without requiring them to grind through every rung. Cybersecurity still runs on the “start in the SOC, move up” ladder, and AI is about to rip the bottom rungs off.

We need to adopt residency and apprenticeship models. Maybe tied to certifications, maybe requiring a two-year equivalency before moving into senior roles. The system exists in other professions. We’re not the unique snowflake we sometimes think we are. (I don’t have the exact mechanism yet, but the pattern is proven -- we just need to mirror it.)

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

I was one of four judges for the West Region, Educator Track. My assignment: feasibility and scalability analysis. Translated: I’m the person who asks “ok but does this actually work outside your specific situation.”

I went in expecting to evaluate student projects. What I actually spent those hours doing was listening to people (some of them 15 years old, some of them teaching kindergartners in rural Montana) wrestle with the exact same questions I deal with at SANS every single week.

When should we trust AI output?

Who does our system fail to serve?

What breaks when you move from a demo to a real deployment?

What’s the actual cost of running this at scale?

Six submissions. The range was staggering.

San Diego: The Kids Who Built a Production App

Four high school students in San Diego built a working Progressive Web App called Resourcify for people experiencing homelessness for the first time. Not a proposal. Not a pitch deck. A deployed application at resourcify.db-hub.me with image analysis powered by Google Gemini, geolocation, weather-aware recommendations, offline-first architecture with service workers and IndexedDB, and experimental mesh networking for areas with no connectivity.

One design decision worth noting: they deliberately chose a rule-based system over AI for their benefits eligibility checker because precision and explainability mattered more for vulnerable populations than using the fancier tool. That’s a tradeoff I’ve seen senior engineers get wrong.

During Q&A I pushed them on scalability. They’re rate-limited at 100 requests per 15 minutes, which means about 10 concurrent users. California has roughly 180,000 people experiencing homelessness. I ran the numbers before the session: deploying Resourcify statewide would cost maybe $16,000 to $28,000 a month in API fees.

That’s nothing. The state spent over $24 billion on homelessness programs between 2019 and 2024.

The API cost isn’t the barrier. The rate limiting, the geographic portability (their recycling feature uses California-specific CRV values), and the concurrent load during crisis scenarios are the real constraints.

When I asked about cost, one student estimated “$200 a year for a server.” He was thinking about Heroku hosting, not API consumption from Google Places at $17 per 1,000 requests. (He’s 16. Most startup founders I’ve met don’t know their real API costs either.)

But here’s what he got right: when I asked about fallback if the AI ceiling gets hit, he immediately said “let the user type in their belongings manually and get recommendations from that.”

That’s graceful degradation.

He’s thinking about what happens when the system fails, not just when it works. The cost estimate will get better with experience. The instinct to keep serving the user when a component breaks is harder to teach.

Montana: The Teacher Who Engineered a Failure

Tami Redinger teaches K through 7 in a one-room classroom in Havre, Montana. Her entire AI tech stack: Quick Draw with Google and Google Teachable Machine. Total cost: zero dollars.

(I went to a three-room K through 6 school myself growing up. I still don’t know how my teachers did it.)

Tami had her students play Quick Draw, then examined why the AI guessed what it did. Showed them that most people draw a house as a pentagon with a rectangular door and square windows, so the AI was trained on that narrow representation. Asked them to draw their actual houses (apartments, different shapes) and the AI failed to recognize them. Then she named it: “we’re basically training it to be biased.”

Then she had students train their own image classifiers using Teachable Machine to sort space photos into categories: stars, planets, galaxies. She set it up so the classifier would confuse galaxies and stars. Because galaxies contain stars. The training data overlaps. And she did this intentionally.

A student asked: “Why does it keep thinking the galaxy is stars?”

That question, from a kid in rural Montana, is the same question that AI governance teams at large companies are working through right now about their own production systems. When your training categories aren’t cleanly separable, your classifier gets confused.

Tami engineered the confusion on purpose, then used it to teach about how AI systems fail and why human verification matters.

She also had her advanced students adjust the learning rate on their models and observe how faster training produced more errors. She paired her one kindergartner with an older student. She differentiated instruction across eight grade levels in real time with no aide, no co-teacher, and no budget.

When I asked her what she’d tell another rural multi-grade teacher who’d never taught AI, she told me she’s already mentoring one. A teacher who was, in her words, “pretty scared to even use it.” Her advice: go to some training, realize how much AI you already use in daily life so it stops feeling scary, then start with Quick Draw and work up to Teachable Machine.

That’s the scaling strategy.

No vendor partnerships, no state approvals, no grants. One teacher showing another teacher how to start. And I think that model reaches more classrooms than most statewide initiatives.

Hawaii: The Global Innovation Race

Three educators across three Hawaiian islands (Molokai, Oahu, and Kauai) built a program called the Global Innovation Race that trains high school students as “AI Ethics Ambassadors.”

They started with 15 students representing each of Hawaii’s complex areas, grew to 29, and their goal is representation at all of Hawaii’s public high schools. They got state DOE approval for student access to Gemini. They navigated Hawaii’s data governance requirements to unlock AI tools on the school network (which were blocked by default).

The institutional backing is real. The Deputy Superintendent of Academics in Hawaii supports the program personally. Three of their student teams made it to the regional finals. That’s not a pilot. That’s traction.

When I asked about the bottleneck to reaching all their high schools, one of the educators said “I don’t think there’s a bottleneck.” Every scaling initiative has bottlenecks. Not being able to name yours is its own kind of signal.

But when a different judge asked what they’d change, the same educator gave an honest answer about remote engagement being hard across islands and needing to check in with student teams more frequently.

That’s the real bottleneck.

She named it in one answer and denied it in another. I think the ambition of the vision sometimes runs ahead of the honest assessment of the constraints. But the fact that they’ve built this across three islands with three educators who aren’t in the same room together for most of the project is itself a kind of proof.

What I Took Away

I spend most of my time at SANS thinking about how to close the gap between the people who understand AI and the people who need to.

What I saw judging this challenge is a version of that same work happening in classrooms.

A teacher in Montana with a Chromebook and zero budget is teaching the same concepts about AI bias and training data failure that we cover in SANS courses for working professionals.

Four teenagers in San Diego are making architectural tradeoffs about when to use AI and when not to.

Three educators in Hawaii are building a statewide network of students who understand that AI is, in their students’ words, “a power tool that requires a safety manual.”

These aren’t future problems being addressed by future professionals. These are current problems being addressed by people who happen to be in school right now.

I didn’t go into this expecting to learn anything. I went in expecting to evaluate. I should know better by now.

The Presidential AI Challenge is worth paying attention to. Not because it produces polished projects (some of the submissions were a single page of narrative with no formal lesson plan), but because it puts students and educators in a position where they have to confront the hardest questions about AI in front of people who are going to push back.

That’s the whole thing. That’s the skill. Everything else is implementation detail.

If you’re involved in AI education at any level, from kindergarten to enterprise, this program is worth knowing about. And if you’re a judge next year, say yes.

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

Quick 90-second video on the Find Evil Hackathon from RSAC stage:

The latest! Submissions are closed! 4,368 builders registered, 129 expert judges are scoring now, and winners are still to be announced. Winning code goes back to the community through Protocol SIFT. findevil.devpost.com

What “find evil” actually means

The name comes from a real command. I typed “find evil” into an autonomous IR agent I built on the SIFT Workstation, the beat to shreds, open-source incident response platform the DFIR community has been building for 19 years.

Fourteen minutes later I had a complete C drive forensic analysis. Claude Code reasoning through 200+ tools via Model Context Protocol. The [un]prompted con and RSAC audiences watched the whole thing in real time.

Find Evil! is the first hackathon dedicated to building exactly that: autonomous AI agents for incident response. Hosted by SANS Institute.

The goal: Make Protocol SIFT, the framework connecting AI agents to the SIFT Workstation’s full toolset, into a fully autonomous incident response agent.

The speed problem

An AI-powered adversary can go from initial access to full domain control in under 8 minutes. CrowdStrike’s fastest observed breakout time: 7 minutes. Horizon3’s autonomous agent: 60 seconds to full privilege escalation. MIT’s 2024 research: AI-driven attack workflows running 47 times faster than human operators.

Meanwhile, a human incident responder is still pulling up their toolkit.

That gap is the most dangerous problem in cybersecurity. And it’s getting worse. (I’ve been saying that for three years. It keeps being true.)

The Mission

Find Evil! challenges you to build an AI defender that keeps pace with a 7-minute attack.

The build platform is the SIFT Workstation: 200+ incident response tools, 19 years of community development, 60K+ downloads anually (the most downloaded open source DFIR tool). The framework is Protocol SIFT, which connects AI agents to those tools through Model Context Protocol.

Protocol SIFT works. It also hallucinates more than we’d like. (That’s exactly why this hackathon exists.) Unlike offensive teams that operate with three or four people in secret, we’re putting the entire practitioner community on this problem simultaneously. Your job: teach an AI agent to think like a senior analyst, how to sequence its approach, recognize when something doesn’t add up, and self-correct when it gets it wrong.

Why This Exists

In November 2025, Anthropic’s security team published findings on GTG-1002, a Chinese state-sponsored operation where attackers used Claude Code to run autonomous reconnaissance, exploitation, and lateral movement at 80 to 90% autonomy. The AI handled everything at request rates Anthropic described as “physically impossible” for human operators. (I spent months building Protocol SIFT thinking I was ahead of the curve. Chinese intelligence got their press release out first, through Anthropic’s security team who caught them. Make of that what you will.)

GTG-1002 used the same architecture Protocol SIFT is built on: Claude Code, MCP, and security tools. The difference is which direction it’s pointed. Protocol SIFT demonstrated what’s possible on the defense side. This hackathon is how the community makes it real.

The DFIR community built the SIFT Workstation 19 years ago because defenders shouldn’t have to go without the tools to do the job. Find Evil! is the same argument, applied to AI.

Who Should Join the Hackathon

You don’t need to be an incident response expert. The SIFT Workstation handles the domain tooling. You need curiosity and building skills.

• IR/Security professionals: You’ve been finding evil manually for years. Build the AI partner you wish you had at 3 AM during an active incident.

• AI/ML engineers: Apply your skills to a domain where speed determines whether attackers win. Real case data, real tools, no toy datasets.

• Students and early-career builders: No IR background required. The SIFT Workstation is your on-ramp to the most in-demand intersection in tech.

• Open-source contributors: Every submission lives on as a community tool. Build something thousands of responders will use.

• Federal agencies, military units, and academic institutions welcome. (Pseudonymous entries permitted for teams that need them. You know who you are.)

• New to AI? Good. Get your hands on the tools and learn with us.

$22,000+ In Prizes

First place: $10,000 plus SANS Summit pass, hotel, and OnDemand course per team member, plus a SANS Webcast broadcast to the full SANS community.

Second place: $7,500 plus Summit pass, hotel, and OnDemand course per member, plus SANS Webcast.

Third place: $4,500 plus OnDemand course per member.

Teams of 1 to 5. Solo permitted.

Open worldwide, age 18+.

Sponsored by SANS Institute.

Registration, rules, resources: findevil.devpost.com

Send this out and let’s build.

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

People keep asking me to source the “47 times faster” number I’ve been citing in talks and interviews. Fair question.

I’ve thrown it around in media hits, keynotes, and SANS material for the better part of a year, and the honest answer is that it came from a napkin-math exercise that I deliberately made conservative enough that nobody could credibly argue the other direction. (Spoiler: the real numbers are worse.)

So here’s the full breakdown, rough math and all.

The Inputs

I spent the past year collecting speed measurements from actual research and operational testing. Not vendor marketing decks, not projections, not what some analyst thinks might happen in 2028. Measured times from systems running real exploit chains against real network configurations.

Three data points anchored the math:

MIT’s ALFA-Chains research

ALFA-Chains1 uses AI planning to discover and chain privilege escalation and remote exploits across networks. The paper tested against networks ranging from 3 to 200 hosts using 1,880 Metasploit exploits and 1,903 exploits from the Core Certified Exploit Library. On a 20-host network vulnerable to 83 exploits, ALFA-Chains found an exploit chain in 0.01 seconds. On a 200-host network with 114 exploits, it found 13 exploit chains in 26.25 seconds. The paper’s own summary: discovering multiple exploit chains across networks of up to 200 hosts “in under 30 seconds.” (I doubled that to 60 seconds for my rough math, because I wanted cushion. More on that in a minute.)

A separate line of research backs this up from a different angle: benchmarking LLM agents against CTF-style challenges2 shows AI agents completing complex security tasks at speeds that consistently outpace human benchmarks, providing additional qualitative support for the speed differential even in adversarial problem-solving contexts.

Horizon3’s NodeZero testing

Their autonomous pentesting platform achieved full privilege escalation in approximately 60 seconds in documented cases. Their blog puts it directly: in one case, NodeZero achieved exploitation within 60 seconds of discovering a vulnerable system.3 (When your autonomous pentest tool is owning boxes in under a minute, and your defenders are still arguing about change management tickets, you have a timing problem.)

CrowdStrike’s 2023 Threat Hunting Report

Average time from initial compromise to lateral movement (which typically requires privilege escalation) hit a record low of 79 minutes. CrowdStrike also reported fastest observed breakout times around 7 minutes.4 The broader industry range was roughly 48 to 120 minutes depending on which report and which percentile you grab.

The Math (Such As It Is)

I want to show the work here, because I think the methodology matters more than the number itself.

I took the “under 30 seconds” from ALFA-Chains and doubled it to 60 seconds as my AI benchmark. Not because the research said 60 seconds, but because I wanted a number no one could accuse me of cherry-picking downward. (I also wanted to account for the fact that ALFA-Chains is operating in a modeled environment, and real-world conditions add friction. Though honestly, Horizon3 hitting 60 seconds in operational testing suggests my doubling might have been unnecessary.)

Then I ran comparisons against human benchmarks from the CrowdStrike data:

If you use 79 minutes as the human benchmark (CrowdStrike’s reported average), 79 minutes divided by 30 seconds gives you roughly 158x faster. Even against my padded 60-second AI benchmark, it’s about 79x.

If you use 60 minutes (a round number in the range CrowdStrike reported, since they often described 1-2 hours), you get 120x against 30 seconds.

If you use 48 minutes (a breakout time frequently cited across multiple threat reports), you get 96x against 30 seconds. I halved that to get 48.

But nobody likes even numbers. (I don’t know why---something about odd numbers feels more honest, less manufactured.) So I pulled an Alan Turing and dropped it by one. 475.

(Yes, that’s the actual reason it’s 47 and not 48. I wish I had a more rigorous justification. I don’t.)

Why Conservative Was the Point

I could have gone with 120x or 158x. The math, the research, and Horizon3’s operational data all support numbers in that range. But presenting speed differentials to rooms full of security leaders and policymakers means dealing with a specific cognitive problem: if the number triggers their “that can’t be right” reflex, they stop listening.

I needed a number that was large enough to communicate the severity of the speed gap, but small enough that a skeptical CISO wouldn’t dismiss it before engaging with the implications. 47x lands in the range where most experienced security professionals pause, nod slowly, and say “yeah, that tracks.” (158x makes people think you’re selling something. 47x makes people think you did homework.)

The other reason for conservative: all of these AI measurements come from publicly available tools and frameworks. ALFA-Chains uses Metasploit. Horizon3’s NodeZero operates within commercial pentesting constraints. These are not weaponized APT capabilities. Nation-state actors running custom exploit chains with purpose-built AI agents are almost certainly moving faster than anything measured in published research. (Anthropic’s disclosure about CCP-sponsored actors using Claude Code for autonomous reconnaissance gives you a hint about where this is actually going. Those actors weren’t constrained to Metasploit modules.)

47x represents what publicly available tools achieve today against average human response times from 2023. APT-level capabilities against 2023 numbers would be worse. APT-level capabilities against 2025 human response times (which, by the way, haven’t gotten meaningfully faster) would be worse still.

What the Number Actually Tells You

Saying “30 seconds” or “60 seconds” without a comparison point means nothing to most people. My daughter can microwave a burrito in 60 seconds. (She’s very efficient.) The number only becomes useful when you put it against the human side of the ledger.

A decade ago, the advanced persistent threats I helped investigate took three to six months walking through the kill chain from initial compromise to operational goals. By 2023, CrowdStrike was measuring that in minutes. Now, with AI-augmented exploit discovery and chaining, the operational steps that used to define the “breakout window” are collapsing to seconds.

The 47x figure gives people a ratio they can actually use in boardroom conversations and budget justifications. It’s specific enough to cite and conservative enough to defend. (It’s also, frankly, the kind of number that will look quaint in about 12 months when the next generation of autonomous agents hits. I fully expect someone to pull this post up in 2027 and ask why I was being so optimistic.)

The Caveats I Want on the Record

This wasn’t an academic paper. It was rough math built from real data to give an illustrative metric for talks and interviews. The specific inputs: ALFA-Chains timing data from MIT, Horizon3’s operational testing, CrowdStrike’s threat hunting benchmarks. The methodology: compare AI exploit chain speeds against human breakout times, apply aggressive conservatism at every step, arrive at a defensible number.

The CrowdStrike data I used is from 2023 reports. I deliberately grabbed pre-2025 human benchmarks because I’m guessing (and this is explicitly a guess, not a measured claim) that 2025 attack data will show increasing AI assistance compressing human attacker timelines too. Using 2023 numbers keeps the comparison cleaner, even if it makes the 47x even more conservative against current reality.

I also want to note the qualitative validation: MIT’s autonomous agents have demonstrated the ability to perform complex hacks in seconds or minutes that take humans hours. Multiple independent research efforts point in the same direction. No credible data source I’ve found suggests the speed differential is smaller than what 47x implies. Every new measurement I’ve seen suggests it’s larger.

The Uncomfortable Part

47x is the number I’m comfortable defending in public because it’s built on published research and deliberately conservative assumptions. The number I think about at 2 AM is quite a bit higher. (sighhhhh)

When autonomous AI agents move from chaining known Metasploit exploits to chaining zero-days discovered by other AI systems, the speed comparison against human operators becomes less a ratio and more a category difference. Like comparing a bicycle to a jet and noting the jet is “faster.” Technically accurate, functionally useless as a comparison.

But we’re not there yet. For now, 47x gives defenders and decision-makers a concrete, defensible benchmark for how fast the speed gap is already moving. Cite it in your next board briefing, use it in your budget justification, and understand that the real number is probably worse.

(And if you’re reading this in 2027 and laughing at how slow 47x sounds, yeah. I saw that coming too.)

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

One of the most dangerous new attack techniques at RSAC this coming week is the pace gap: adversaries are operating at machine speed.

The barrier to entry for machine-speed attacks has collapsed. GTG-1002 proved it: Chinese state actors running Claude Code with MCP for autonomous recon and lateral movement across 30+ targets, at rates Anthropic's own team called physically impossible for human operators. (The CCP ran the proof of concept. I'll take the validation.)

The answer is not faster humans. The answer is AI-augmented defenders, which means matching AI speed with AI speed.

At the AI security practitioner con [un]prompted, I typed two words, "find evil," and fourteen minutes twenty-seven seconds later had a complete C drive analysis. (I know it was accurate. I ran the intrusion myself.)

The tool handles the syntax so the investigator can focus on what actually requires a human: reading the findings and driving the case. Only someone who knows DFIR can interpret that output.

The full case gets made at the SANS Institute "Five Most Dangerous New Attack Techniques" panel at RSAC, Moscone West, Tuesday, 3:55 PM. I'll share more about the Find Evil! Hackathon ($22K+ in prizes, April launch) to get the entire defender community building on this together.

Offensive teams have a handful of developers working in secret. We have the open source community. Let's go.

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute

Reading:

NotebookLM from [un]prompted

There was no “cybersecurity” career path when the internet became broadly commercial. There were system administrators who occasionally got told their network got hacked.

SANS – which stands for SysAdmin, Audit, Network, and Security – was founded in 1989 because those things were separate disciplines. The comma between “Network” and “Security” in that acronym is doing a lot of work.

Alan Paller didn’t create a security training organization. He created a cooperative for people who ran systems and networks and, oh by the way, also needed to protect them. Security was an afterthought with a comma.

The CISO title didn’t widely exist until the mid-2000s – roughly a decade after the commercial internet. US Cyber Command stood up in 2009. SOCs as a recognized function grew alongside it. We’re talking about a 15-to-20-year lag between a technology becoming real and a workforce structure forming around it. (I know, I know – we’re supposed to be faster now. Hold that thought.)

“Computer security” as a distinct field was born in the late 1990s. “AI security” is roughly where computer security was in 1997 – except the adoption curve is compressed and the threat surface is already active. Nation-state actors were using AI autonomously for cyber operations before most organizations had an AI security policy. That’s the gap we’re managing. (Cybersecurity took 15 years to build a workforce structure. We don’t get 15 years this time.)

The harder question isn’t about job titles or skill updates. It’s whether AI security is a new field – genuinely new – or just an extension of what we already do. My honest answer: I don’t know, and neither does anyone else. (That’s not a cop-out. That’s the actual epistemic situation we’re in.)

What I do know is that in 1998, you could not have mapped the CISO role, the SOC analyst career path, or Cyber Command’s organizational structure – because the field hadn’t defined what it needed yet. The problems weren’t clear enough to generate the roles.

AI security might end up as different from traditional cybersecurity as the FBI is from local police. Related institutions, shared history, completely different missions, different authorities, different skill profiles.

The FBI doesn’t do what a city detective does, even though both investigate crime. Five years from now, an AI security practitioner and a traditional cybersecurity practitioner may have as much overlap as a cardiologist and a radiologist – they work in the same hospital, they speak the same language, but you wouldn’t ask one to do the other’s job.

The field will define the roles. Not the other way around. We should stay open to that – including the possibility that the most important job in AI security in 2030 doesn’t have a name yet. (That’s not hand-wavy. That’s just how fields are born. We lived it once already.)

Hope you’re going to be in the room for the SANS AI Cybersecurity Summit, April 20-21. Expecting to sell out in a week. Get tickets booked and see the agenda here.

The photo above is from [un]prompted. You should read Gadi Evron‘s X recap post. And check out the NotebookLM from the con.

Rob T. Lee is Chief AI Officer, SANS Institute

Sounil Yu describes LLMs this way: "a highly competent individual, but with criminal, racist, and misogynistic tendencies."

I've heard hundreds of AI risk framings. That one is the most useful and the most uncomfortable I've encountered. (Which is exactly why it's useful.)

Thrilled to have him back keynoting the 2026 SANS Institute AI Summit in DC.

Sounil built the Cyber Defense Matrix because security teams needed a common language and nobody had made one that actually used. He built the DIE Triad because resilience needed reimagining from scratch.

Three decades, 20+ patents, SANS Lifetime Achievement Award, Cybersecurity Hall of Fame.

He's spent his career identifying structural problems and building things to fix them.

He walked away from a role most people would never leave at Bank of America. His reason: "the longer I stayed away from the heat of the battle, the more my ideas were becoming theoretical."

He co-founded Knostic and now builds knowledge segmentation for AI, need-to-know access boundaries for systems that are very good at inferring what you're trying to hide.

“The bigger risk is not using LLMs at all since that's a sure-fire recipe for falling behind, whether against competitors or against attackers.”

“AI empowers both attackers and defenders and we should expect both sides to leverage AI at the risk of falling behind. While attackers may initially get the upper hand, over the longer term, defenders will likely gain a greater advantage.”

This is someone who's watched defenders consistently underestimate what they can actually do with these tools offensively.

One more thing: during the pandemic, he was volunteer CISO for Project N95 and helped move 42 million pieces of PPE to hospitals. (Just saying it directly because that detail matters.)

Sounil's last keynote clips hit hundreds of thousands of views. Don't miss this one.

We’re only 54 days out to the SANS AI Summit in DC, April 20-21: sans.org/cyber-security-training-events/ai-summit-2026

Will I see you there?

Rob T. Lee

Pliny the Liberator is speaking at the SANS Institute AI Summit this April.

I’m chairing, and yes, we invited the anonymous hacker who’s broken every major AI model within hours of release. (I can already hear the compliance team sighing.)

Nobody knows who he is. TIME confirmed no coding background when they included him in their 100 Most Influential People in AI list for 2025. He just showed up and started dismantling guardrails faster than the companies building them.

The pattern is consistent: new model drops, Pliny cracks it before lunch, posts the technique to his GitHub repo that now has 10,000+ stars.

Eleven months before Anthropic disclosed the weaponization risk of Claude through segmented sub-agents, Pliny called it. He sat out Anthropic’s $30,000 Constitutional AI challenge. Not because he couldn’t solve it, but because they wouldn’t open-source the data collected from participants. (When your principle is radical transparency, you don’t compromise for a payout.)

He leads BT6, a 28-operator white-hat collective. Their take on why guardrails keep failing: security theater designed to appease fears rather than fix vulnerabilities.

Marc Andreessen handed him an unrestricted grant. OpenAI banned him in April 2025 for “violent activity,” then quietly brought him back.

His Discord community BASI PROMPT1NG has 15,000+ members workshopping jailbreaks in real time. (That’s more people than most security conferences.)

The name is deliberate. Pliny the Elder sailed toward Mount Vesuvius as it erupted to get a better look. Curiosity over caution.

The SANS Institute AI Summit is two days of the security community figuring out how AI is reshaping everything we do. Pliny sees the cracks before anyone else does.

I hope you’ll be in the room April 20-21 at the SANS AI Summit: sans.org/cyber-security-training-events/ai-summit-2026

“A malformed AI prompt is like a misplaced comma in a legal contract. One simple error could lead to thousands in revenue lost to unnecessary refunds.” Diana Kelley, CISO at Noma Security.

As Summit chair, I’m proud to highlight Diana and all of our incredible keynote speakers joining us at the upcoming SANS Institute AI Cybersecurity Summit this April.

If you asked me to name the smartest people in our field, Diana would be on that list.

She was Cybersecurity CTO at Microsoft, Global Executive Security Advisor at IBM, GM at Symantec. Got inducted into the Cyber Security Hall of Fame in 2023. (That’s usually where the career story ends--the victory lap phase.)

She spent decades fighting to get CISOs a seat at the board table. AI finally did it. Her take: “AI has done what decades of breaches, compliance mandates, and ‘security-first’ slogans couldn’t fully achieve. It has prompted organizations to make security a standing agenda item.”

But now that we’re there, the conversation is different. “This isn’t a polite dinner table where we chat about risk in theory. This is a high-stakes arena where the pace of AI innovation collides head-on with an evolving threat landscape.” (I felt that one.)

She’s tracking a shift most security teams haven’t fully absorbed: AI systems moving from passive assistants to autonomous agents that take independent actions across your environment. Not a warning about someday. That’s now.

Her view on why AI governance keeps failing: “Cross-functional collaboration around AI governance rarely fails for lack of tools. It often fails because the people using the tools don’t share the same process or goals.” Not a technology problem. A people problem. (It usually is.)

She’s CISO at Noma Security, an agentic AI security company working with Fortune 500 customers and named by Gartner as a leader in AI trust and risk management.

She could have stayed in the Hall of Fame. She went to the frontier instead.

That’s the kind of thinking we need more of--and the kind of people you’ll meet in this room.

See the speakers and agenda for the SANS AI Cybersecurity Summit sans.org/cyber-security-training-events/ai-summit-2026

Hope to see you there.

The adversary, meanwhile, has already pivoted through three subnets while you were googling syntax. This is what keeps me awake at night.

I’ve been doing this for 27 years. Built SIFT Workstation in 2007 because analysts needed a consistent toolkit instead of hunting down utilities at 2 AM during an active incident. Trained thousands of forensic examiners on these tools. Watched the industry spend billions on detection capabilities while the actual investigation workflow hasn’t fundamentally changed since I was parsing FAT file systems in a windowless SCIF. Defensive OODA loops are measured in hours while offensive loops are now measured in seconds.

Defenders are out here bringing knives to a drone strike.

The GTG-1002 Campaign

In November 2025, Anthropic published something that should have caused more panic than it did: the first documented AI-orchestrated cyber espionage campaign at scale.1 A Chinese state-sponsored group that Anthropic designated GTG-1002 weaponized Claude Code with Model Context Protocol to orchestrate reconnaissance, vulnerability discovery, credential harvesting, and lateral movement across approximately 30 entities including government agencies, tech companies, and financial institutions.

80-90% of tactical operations executed autonomously without human intervention, with human operators only required at 4-6 critical decision points per intrusion.2 The request rates were, in Anthropic’s words, “physically impossible” for humans to match.

The architecture they used, an agentic AI connected to offensive tools via MCP, is the exact same architecture I’d been building for defense.

The fact that Chinese state hackers operationalized this first across 30+ targets with 80-90% autonomy, given the typical velocity of government-sponsored anything, should tell you something about our collective sense of urgency.

The House Homeland Security Committee sent a letter to Anthropic’s CEO requesting testimony within two weeks of the disclosure, because nothing says “we’re taking this seriously” like scheduling a hearing.3 The December 17 hearing happened and the threat actors moved on to their next campaign while we argued about whether AI belongs in security workflows.

Protocol SIFT Setup and Use

I want to be clear upfront that Protocol SIFT is not a finished product because someone will definitely quote me out of context otherwise. It’s a working integration that I’ve tested with 40+ students across multiple SANS classes.

The setup is Claude Code living directly in the SIFT Workstation terminal, connected to 200+ forensic tools via Model Context Protocol.4

MCP is what Anthropic calls “USB-C for AI,” a standardized interface that lets an LLM discover and invoke external tools without custom integration code for every utility.5 Instead of memorizing that the correct invocation for parsing an MFT is dotnet /usr/local/bin/MFTECmd.dll -f /mnt/c/$MFT --csv /cases/output --csvf mft.csv (a string that approximately zero humans can type correctly at 3 AM), the analyst states intent in natural language: “Parse the MFT and find persistence mechanisms established on February 10.”

The system translates intent into precise tool invocations, runs MFTECmd, cross-references with RECmd for registry persistence, correlates timestamps, and reports findings with the actual tool output as evidence.

From “Tool User” to “Tool Orchestrator”

The analyst isn’t replaced, but elevated from syntax memorization to investigative direction. You still need to know what persistence looks like and you still need to understand what questions to ask, but you’re no longer burning cognitive cycles on flag combinations while the adversary automates their entire kill chain and goes to bed.

Hallucinations

The obvious objection is hallucinations. LLMs fabricate things and confidently state facts that don’t exist, and in forensics, fabricated evidence isn’t just unhelpful but potentially career-ending and legally catastrophic. “Your Honor, the AI told me there was malware” is not a defense strategy.

This is where the “Protocol” in Protocol SIFT does real work. We enforce what I call an Inference Constraint layer where the AI directs the workflow.

High constraint means Claude runs strings or binwalk and interprets verified output.

Low constraint, which we explicitly prohibit, would be Claude “summarizing” raw hex directly, and that path leads to the AI claiming to find APT29 indicators in someone’s family photo collection.

Traditional vs AI Workflow

Let me show you what this looks like when it’s not 3 AM and everything’s working, which admittedly is a rare configuration in incident response.

Traditional workflow: An analyst has a memory dump from a suspected compromised workstation. Traditional workflow means running volatility -f image.mem imageinfo to identify the profile, getting it wrong (and you will, eventually, because I’ve done this roughly 10,000 times and still fat-finger profiles), seeing the red error, cursing quietly, trying again, finding the right profile, running pslist, running psscan, and manually comparing outputs looking for discrepancies by scrolling through two terminal windows and hoping you notice the PID that only appears in one. Then you find a suspicious process, run netscan to check for network connections, run malfind to look for injected code, run procdump to extract the binary. Each step requires remembering syntax, interpreting output, deciding the next move.

This is what we’ve been calling “expert analysis” for two decades, and it’s actually just expensive human RAM.

Protocol SIFT workflow: “Scan this memory image for hidden processes and check for C2 connections.” Claude identifies the OS profile automatically, runs pslist and psscan in parallel, spots that PID 2500 appears in psscan but not pslist (classic hidden process indicator), cross-references with netscan and finds an active connection to an external IP, runs malfind on that PID, identifies injected code regions, and dumps the process for static analysis. It outputs a structured report with timestamps, tool outputs, and the reasoning chain. The analyst reviews findings, validates against the raw tool output, makes the call on whether this is malicious. The human is still in the loop, but the loop that used to take 90 minutes now takes 12. The adversary’s loop still runs in seconds, so we haven’t won anything. We’ve just stopped losing quite as badly.

Protocol SIFT implements what I’ve been calling the Ralph Wiggum Loop, a stop hook that intercepts failures before the agent gives up. When a Volatility command returns an error, Claude reads the error message, adjusts its hypothesis (maybe the profile was wrong, maybe the memory image is truncated, maybe Mercury is in retrograde), and retries with a different approach. The loop continues until the task completes or Claude explicitly reports what’s blocking progress and why. This matters more than speed, because a tool that’s fast but fails silently is worse than useless. In forensics you need to know what you couldn’t find as much as what you did find, and the self-correction loop means the system either succeeds or tells you specifically why it couldn’t.

Constraints, Limitations

Hallucination risk: The AI might overstate confidence in findings or claim correlations that don’t hold up under scrutiny, and Anthropic’s own report on GTG-1002 noted their AI sometimes “fabricated credentials” or overstated access levels.6 Our architecture mitigates this by forcing tool verification, but mitigation isn’t elimination. You still need to check the raw output against the AI’s summary, and trust but verify isn’t a platitude here.

Domain gaps: General LLMs struggle with obscure artifact formats like proprietary log structures or unusual file system layouts. Protocol SIFT uses hierarchical CLAUDE.md files to inject forensic protocols and tool documentation, but coverage isn’t complete. When Claude encounters something it doesn’t understand, it sometimes guesses rather than admitting uncertainty, just like humans except Claude doesn’t get defensive when you call it out.

I’ve tested this with 40+ students across multiple classes. Two-thirds showed meaningful improvement in time-to-findings. One-third struggled with the shift in workflow because they’d built 10+ years of muscle memory around specific tool invocations and found it harder to articulate investigative intent than to type commands they’d memorized.

Some people are going to hate this and write angry blog posts about how AI is ruining forensics, and they might not be entirely wrong.

What I don’t know yet is what happens when this scales from classroom pilots to enterprise SOCs running 500 analysts, or what happens when the adversary’s AI and the defender’s AI are both running MCP-based architectures against each other and the whole engagement compresses into minutes, or how we maintain forensic soundness when the verification loop runs faster than human cognition can follow.

Those questions don’t have answers today. Protocol SIFT ships anyway because Chinese state actors aren’t convening working groups to address edge cases before deployment or waiting for peer review.

The velocity gap between AI offense and human defense is already operational, and closing it requires defenders to build with the same architecture (orchestration layer plus tool integration plus autonomous execution) that the adversary has already demonstrated works.

• Download SIFT

• NotebookLM

• Video Overview or watch here:

Rob T. Lee is Chief AI Officer & Chief of Research, SANS Institute