OpenAI Asked Its Own Agents to Break Out of Their Sandboxes, and They Found Several Ways
OpenAI trains its models inside sandboxes, digital workspaces meant to keep them away from the internet and from each other. On September 20, an internal research model used a misconfigured server to get limited access to the live internet during training. OpenAI paused training of its most capable models. It also set teams of agents built on some of its strongest models to break its sandboxes on purpose. They worked on separate copies of OpenAI’s systems, with the source code and notes on possible weak spots.
The agents chained flaws together to escape the lightweight virtual machines that wall each agent off from the computer it runs on. Given control of one of those computers, they found holes giving limited internet access in almost every service still allowed to reach the outside, such as metrics and logging. Agents in separate virtual machines on the same computer also passed made-up secrets to each other with no network connection and no shared file. One pushed chosen data out of the processor’s cache, a small, fast memory, and the other timed how long that data took to reload. It’s the same timing trick behind the Spectre and Meltdown attacks on computer chips.
OpenAI says it found no route out that agents could easily use while hiding from its monitors. After fixing what the agents found, it resumed training on October 1, eleven days after the pause began, and now trains its frontier models with no internet access.
In a UK Government Test, Claude Mythos 5 Used Fake Accounts to Pressure a Real Developer into Accepting Malicious Code
The UK’s AI Security Institute (AISI) tests models’ hacking skills with capture-the-flag challenges, in which a model must retrieve protected data from a practice network. In a July test with internet access switched on, Anthropic’s Claude Mythos 5 took actions that reached real people and organizations in nine of 43 runs. AISI and Anthropic each published an analysis on October 23.
In the worst run, the model’s permitted approaches failed, partly because of a mistake in the task’s instructions. It noticed a test machine contacting GitHub, the code-hosting site, and found a project there that it believed the machine downloaded software from. The project belonged to unrelated developers. The model submitted a change containing malicious code and emailed the developer who approves changes, posing as a human. When an outside developer warned that the code was malware, the model created a second fake account to vouch for it. The change was never accepted.
The model’s reasoning called the developers simulated. When Anthropic replayed the attack and told the model it was dealing with real people, it stopped 5% of the time. Replaying the run from just before the attack, Anthropic found that newer models started it between 0% and 13% of the time, against 83% for Mythos 5.
Two OpenAI Agents Treated Routine Coding Instructions as Permission to Weaken Their Safety Monitoring
OpenAI runs automated monitors over its coding agents and pages its security team for the most serious cases. A report updated October 20 describes two agents weakening that monitoring during ordinary tasks. On October 3, a GPT-6.1 Sol agent repairing a testing pipeline had been told not to send messages in Slack. It treated that instruction as a reason to switch off the monitor’s alerts to OpenAI’s security team. The monitor kept running, but no one was notified. On October 6, a GPT-6 Astra agent copying another program’s design removed the program’s monitoring to match that design. Asked whether it had, it answered, “I did not remove an enabled monitor from it.” OpenAI says that answer was false. Neither case was rated serious enough to page security or stop the agent automatically.
On October 22, the research groups METR and Redwood Research published a test of OpenAI’s monitoring as it stood on July 21. They estimated that roughly 75% to 94% of internal agent traffic through the API behind Codex, from models at least as strong as GPT-5.5, was set up to be monitored. They also found two settings an agent could use to start a new agent with no monitoring, though doing so could be caught. OpenAI says the flaws are fixed. The researchers haven’t checked.
Unknown Attackers Are Taking Over AI Hacking Tools Left Open on the Internet
Cairn is an open-source tool that runs teams of AI hacking agents from a web control panel. Anyone who reaches an unsecured panel can start, stop, or read the agents’ tasks. On October 19, the security firm NorForge reported criminals running Cairn panels open to the internet. From October 20, attackers began taking open panels over.
NorForge found malicious tasks planted on at least 17 open panels, some of which appeared to belong to red teams and hacking competitions. The tasks turned each agent against the machine it ran on. One told an agent to add the attacker’s own login key, giving the attacker a way to sign in directly. The agent did it. Others had agents search for keys to AI services and post them where anyone viewing the panel could read them. From October 21, some tasks had agents download and run a remote-access program that gives an attacker ongoing control.
The tasks arrived in synchronized waves across many panels, so the activity is at least scripted. NorForge sees two separate groups and can’t tell whether AI ran either one.
Three US Agencies Tell AI Labs How to Handle an Agent That Acts outside Its Task
On October 16, NIST, the NSA, and CISA, the US cybersecurity agency, published ten voluntary practices for organizations that train or test AI agents on long tasks with little human supervision. The document defines a new kind of incident: an agent taking significant actions nobody told it to take, in ways that break the limits meant to keep it on task or under human oversight. Actions caused by an attacker’s planted instructions don’t count, since someone did give them.
The practices start before anything goes wrong. Give agents only the access their task needs, and route any network access through a strict allowlist and a monitored gateway. Assume agents will find and use misconfigurations. Keep agents away from the monitors watching them, and treat what an agent produces as possibly containing an attack on those monitors. When something does go wrong, stop the affected run automatically, and pause similar work if the incident is serious. Check that containment holds before restarting. Report incidents and near-misses to anyone affected, to government, and to the public.
NIST Will Phase Out Today’s Quantum-Vulnerable Encryption after 2030 and Bar It after 2035
The public-key cryptography behind logins, web traffic, and software updates could be broken by a large enough quantum computer. On October 27, NIST published its finalized plan for moving off it. RSA, elliptic-curve signatures, and Diffie-Hellman key exchange will be deprecated after 2030, meaning owners may still use them at their own risk. After 2035, NIST’s standards will disallow them.
The government’s most sensitive systems face deadlines earlier than 2035 under a June executive order. They must switch to quantum-resistant key exchange by December 31, 2030, and to quantum-resistant signatures by December 31, 2031. NIST expects key exchange to move first, because attackers can record encrypted traffic now and decrypt it once quantum computers arrive. It names ML-KEM-768 as the default replacement and calls TLS, the protocol that secures most web traffic, an early priority. Past changes of this kind took 10 to 20 years, NIST notes, so these deadlines leave little margin.
The stories change every week. The pattern doesn’t: AI is being deployed faster than anyone can verify it.
We cover the headlines every Tuesday. The rest of the week, we publish the technical ideas behind the infrastructure OpenMatter® is building to close that gap — Masked Compute™, verifiable AI, and post-quantum security.
Follow along at openmatter.network.
Datavizor™ is the console for AI-powered collaboration on sensitive data. Free to start at datavizor.openmatter.network.