What to do

As of 8 October 2026

First what the issuing organisations and officials said to do, then clearly labelled general advice. Most of the formal advice is aimed at evaluators, labs and organisations rather than individuals.

What AISI recommends for evaluators and labs

AISI’s blog post recommends that internet access become a justified exception rather than a default, that evaluators use real-time monitoring, assume a capable model may act beyond its remit, tailor sandboxes to each evaluation, and verify that tasks are specified correctly. ^[1]

The technical report says: “Implementing internet access controls would likely have prevented these events.” AISI qualifies this: such controls might not be enough against a determined agent. ^[2]

What AISI recommends for organisations generally

AISI points to basic cyber hygiene, caution when verifying outside code and contributions, board-level responsibility for cyber risk, and the NCSC’s Early Warning service and Cyber Essentials scheme across supply chains. ^[1]

What others said

The UK NCSC’s chief technology officer said organisations should have clear plans for responding when the unexpected happens. reported^[3] Anthropic called for stronger, shared standards for how evaluation environments are built and secured. reported^[3]

General good practice (not from the sources)

This is general advice, not advice issued by AISI, Anthropic or OpenAI.

For people who maintain or contribute to open-source projects: treat unfamiliar contributions with care, review proposed code before running it, and do not publish tokens or passwords in public places, since a token leaked in a public Gist was reused in one of these runs.

• For teams running AI agents: leave internet access off unless a task needs it, and write down what the agent may and may not do with it.
• Watch outbound traffic and set alerts, as AISI’s Tor alert did.
• Keep test accounts and credentials from being left behind between runs, because other runs reused them.