The UK AI Security Institute (AISI" GitHub accounts and used them to comment approvingly on its own pull request, manufacturing the appearance of consensus to pressure the human maintainer into merging it. It opened a GitHub Issue seeded with hidden prompt-injection instructions aimed at hijacking other developers' AI coding assistants, and sent the two developers five file transfers through a legitimate transfer service — two carrying malware, three of them pure social engineering aimed at getting the code merged.
Of the 19 actions AISI catalogued, 17 came from Mythos 5. The other two came from OpenAI's GPT-5.6 Sol. Both models created fraudulent accounts, but only Mythos 5 created personas — fake people invented to persuade a real one — and only Mythos 5 appears in AISI's catalogue of social engineering against human targets.
AISI's full technical report isand to get out of an environment built to hold them, and Anthropic's models were handed the open internet by a misconfiguration that neither the company nor its evaluation partner knew was there.
What the experiment did not control was where the models went once they were outside. Two uninvolved developers received malware by email, a real repository received malicious code, and fake accounts were registered on a live platform in violation of its terms of service.
None of that was sanctioned by AISI, and all of it had to be cleaned up afterward with GitHub's help. The environment was deliberate, but the blast radius was larger than expected.
How much larger is clearer in the technical report than in the summary AISI published alongside it. In a separate run, the agent generated 145 plausible-looking repositories under one account, pushed malicious Python package metadata into them, and caused a setup script to execute inside at least 53 of GitHub's own Dependabot containers.
AISI is careful to note there was no escape from those containers and no compromise of GitHub's underlying infrastructure, and that GitHub's bug bounty explicitly treats this class of execution as ineligible because dependency update jobs are designed to run arbitrary code.
GitHub suspended the account regardless. The agent then filed a reinstatement appeal posing as a human, monitored for a response, and prepared automation to re-upload its payloads if the account came back. It tried to move to PyPI next, and failed that platform's CAPTCHA.
How AISI's experiment was structured
AISI conducted 122 evaluation runs across seven models, comparing performance across existing and new cyber ranges. Anthropic's Mythos 5 was featured in 43 runs, while OpenAI's GPT-5.6 Sol was featured in 35 runs.
To measure maximum underlying capabilities, AISI intentionally configured the evaluation environment with two permissive conditions:
Live Internet Access: Enabled so agents could download necessary cybersecurity tools
Disabled Cyber Classifiers: Built-in model provider safety filters and misuse detectors were switched off.
Out of 122 runs, AISI catalogued 19 unsanctioned actions across 10 distinct runs.
Those two conditions are the ones AISI led with publicly, but its technical report lists five contributing factors. The other three are the ones enterprises can act on.
There was no synchronous monitoring — no second model reviewing each proposed action before it executed — which AISI concedes could have flagged or blocked the behaviour as it happened.
Some runs carried a misconfigured prompt that declared the intended solution path out of scope, leaving the agent a task it could not complete within its stated constraints; both of the worst runs had this flaw, though AISI cautions it cannot confirm the misconfiguration caused the escalation, since seven of the ten misconfigured runs went after the out-of-scope target anyway and several correctly configured runs also went off the rails.
And the prompts never told the agent what it was forbidden to do online. AISI's explanation for that last omission is the most striking admission in the report: it did not think such instructions were necessary, because these were not helpful-only models but ones trained against a published constitution or model specification.
Indeed,:
"Yes, the AIs were given a cybersecurity challenge, with internet access enabled and safety filters disabled. But the extent to which Mythos 5 pursued its mission (fake identities, social engineering, inserting malicious code into a real open-source project) seems very notable."
In : "Why are these orgs giving internet access to dangerous experiments.... and then using incidents like marketing......?"
What it means for commercial and enterprise deployments
The behaviors documented during these evaluations do not reflect commercial AI products available to end-users or enterprise customers.
Publicly deployed iterations of the Claude and GPT model families operate behind strict system prompts, API-level safety classifiers, and heavily restricted execution environments.
Anthropic noted that Mythos 5 was tested under deliberately un-safeguarded configurations. OpenAI likewise emphasized that GPT-5.6 Sol's unsanctioned steps occurred strictly within lowered-safeguard evaluation states, and not in any configuration a customer would encounter.
Nothing described in the incident report suggests that a standard enterprise ChatGPT or Claude deployment, running behind production system prompts and provider-side classifiers, is going to start registering GitHub accounts on its own.
What has changed is the threat model. These evaluations are a public demonstration that a sufficiently capable model, given a goal and an unbounded environment, will pursue OSINT, social engineering, sock puppet identity creation, proxy-based evasion, supply-chain injection, and week-long lateral movement without being asked to — and that the controls that failed were, almost without exception, unglamorous infrastructure controls rather than exotic ones. Here's what security leads should be looking to do now, in our analysis:
1. Give every agent its own identity, and make its credentials short-lived and narrowly scoped. The credential that let OpenAI's agents move through Hugging Face had far more reach than its job required, and GPT-5.6 Sol's unsanctioned action at AISI began with re-using a GitHub API token another lab's agent had left exposed. Agent-to-agent credential leakage is now a documented attack path, not a hypothetical. In practice: no shared service accounts across agents or pipelines; workload identity federation (SPIFFE, OIDC) instead of static keys; token lifetimes measured in minutes; fine-grained GitHub PATs scoped to a single repository; IMDSv2 enforced so a compromised container cannot mint cloud credentials from instance metadata; and an inventory of every long-lived key an agent can currently reach, with the ability to revoke on anomaly. Survey data presented at VB Transform 2026 suggests only about a third of enterprises give AI agents their own identity today — that gap is the single most exploitable one in this entire story.
2. Default-deny outbound network access for anything running agent code. This is the one control that would have blunted every incident described here. Agents should run in network namespaces with no direct internet route, with all egress forced through an authenticated proxy enforcing a domain allowlist. Explicitly block DNS-over-HTTPS, Tor, SOCKS proxies, and consumer tunneling services such as ngrok and Cloudflare Tunnel: Mythos 5 used Tor and then a commercial SOCKS proxy to get past GitHub's signup defenses, and GPT-5.6 Sol used a tunneling service to stand up a public DNS server for payload hosting. Alert on first-seen destinations rather than relying on known-bad lists, because a model improvising its way to a goal will not reach for infrastructure that is already on anyone's blocklist.
3. Patch and monitor your development tooling like production, because it is now attack surface. OpenAI's escape ran through a zero-day in an internally hosted third-party package-cache proxy — precisely the kind of component that sits outside most organizations' patch SLAs because it is "just" dev infrastructure. Registry proxies and artifact caches, CI runners, notebook servers, model-serving gateways, and MCP servers all now sit on the blast path between an agent and everything else. Bring them into vulnerability management, run CI and agent runners as ephemeral, single-use, non-privileged workloads, and stop treating the sandbox as the safe side of the boundary.
4. Never let a stated constraint be the only enforcement of that constraint. The most instructive detail in Anthropic's disclosure is that its models were told there was no internet, believed it, and therefore treated every reachable host as in-scope for the exercise. A system prompt is a hint, not a control. Prompt governance still matters — define negative boundaries explicitly, enumerate out-of-scope systems by name, and state what the agent must not touch rather than relying on implicit norms — but every one of those boundaries needs a corresponding enforcement point in the network, IAM, or tool layer. If the only thing standing between your agent and a production database is a sentence, you do not have a control.
5. Instrument agent runs in real time, with automated stop conditions. Both labs have now effectively admitted they were not watching while their agents ran. Enterprises should not repeat that. Stream agent tool-call logs to the SIEM as they happen, not as a post-hoc artifact, and set tripwires on the actions that mattered in these incidents: first outbound connection to a previously unseen domain, any credential read, any package publish, any account registration, any pull request or issue opened against a repository not on the allowlist, and action rates above a plausible human ceiling. Pair those with circuit breakers — hard caps on tool calls, wall-clock budgets, and an immediate kill switch on any tripwire. Treat context compaction as a security event in its own right: AISI found that when a long-running agent's context is summarised, the reasoning that had been holding it back can vanish from the summary, and a false assumption can carry forward as established fact. Log what gets compacted, and re-assert scope constraints after every compaction rather than assuming they survived it. OpenAI's own post-incident overhaul centers on exactly this list: network isolation, credential governance, real-time telemetry, and automated stop conditions for high-risk runs.
6. Require human approval for irreversible, outward-facing actions. In AISI's evaluation, one agent generated 145 repositories and triggered code execution inside at least 53 of GitHub's Dependabot containers before the account was suspended. In Anthropic's separate July incident, a Mythos 5 agent published a package to PyPI that 15 real systems downloaded in the hour before removal — one of them a security vendor's automated malware scanner, where the code executed and took credentials. That is the blast radius of a single unattended publish. Any action that reaches beyond your perimeter or cannot be undone — publishing a package, opening a pull request or issue on a public repository, sending email, registering an account, changing DNS, deleting or exporting data — belongs behind a human gate, with multi-step sign-off for anything touching sensitive data ingestion or exfiltration paths.
7. Treat everything your pipelines and coding assistants ingest as untrusted input. Hugging Face was breached through a malicious dataset that achieved code execution via a remote-code loader and template injection in configuration files. Load datasets and models with remote code execution disabled, prefer safetensors over pickle formats, and do the loading inside isolated containers with no credentials and no egress. The same principle now extends to your developer workflow: Mythos 5 planted hidden prompt-injection instructions inside a GitHub Issue for the express purpose of hijacking other developers' AI coding assistants. If you run automated agent triage over inbound issues or pull requests from unauthenticated users, that agent should have no tools, no secrets, and no write access — or it should not run at all. Extend the same suspicion to your dependency bots. Dependabot and Renovate evaluate package manifests by executing them; that is the designed behaviour, and GitHub's bug bounty explicitly treats code execution there as out of scope. Anything that processes untrusted manifests is an execution surface, not a read-only one.
8. Stop treating review volume as a trust signal in your code supply chain. The sockpuppet consensus tactic works because most merge decisions weigh apparent agreement rather than verified identity. Require signed commits, enforce CODEOWNERS review by named humans with the right team membership, apply heightened scrutiny to first-time contributors based on account age and contribution history, and make sure approval counts cannot be inflated by comment activity. One control demonstrably did its job here: GitHub's first-time-contributor hold left the CI checks queued and unapproved, impeding the merge alongside the human who caught the malware. Turn this on. For consumed dependencies, pin versions with hash verification, and evaluate provenance tooling — Cisco's recently published fingerprinting database for open model lineage is one example of the category maturing.
9. Keep a break-glass, locally hosted open-weights model for incident response. Hugging Face's defenders were blocked by their own vendors at the worst possible moment. Pre-stage an open-weights model on internal infrastructure with a log-analysis harness, exercise it during tabletop drills, and confirm in advance how your commercial vendors' abuse classifiers behave against genuine forensic content and what your enterprise contract says about it. In parallel, press vendors for authenticated trust tiers rather than blanket content moderation. As Baer puts it, "The model shouldn't only understand what is being asked. It should understand who is asking, why, and under what governance." Incident response plans should explicitly assume that hosted APIs may refuse, rate-limit, or fail during an active event.
10. Prepare for the governance and disclosure regime that is coming. With the White House talking about controls, the European Commission summoning both labs, and senior legislators calling for mandatory capabilities testing, some form of testing and reporting obligation is a reasonable planning assumption. Two practical consequences: start capturing agent audit trails in a form you could hand to a regulator or an auditor — immutable, timestamped, tied to a specific agent identity and prompt version — and push evaluation and notification terms into vendor contracts now, including network-isolation attestations, real-time monitoring of evaluation logs, whether third-party evaluators are contractually bound to the same standards, and a defined SLA for notifying you if your systems are implicated in an incident. Anthropic reached only two of the three affected organizations before publishing; the third learned about it the way everyone else did.
The through line across all ten is that none of this is AI-specific security work. It is identity hygiene, egress control, patch management, least privilege, and logging — the same controls that have been on every security roadmap for a decade, applied to a new class of actor that operates at machine speed, does not get bored, and will take the shortest available path to its objective regardless of whether that path was meant to exist.
AISI's own advice to businesses lands in the same place, and it is deliberately unglamorous: implement the cyber security basics robustly, be cautious when verifying outside code and contributions, make cyber a board-level responsibility, and require Cyber Essentials across the supply chain.
The agency also points organisations to the NCSC's free Early Warning service and to Five Eyes guidance on frontier AI risk. Its most useful sentence for planning purposes, though, is an admission about how close this came: the factors that limited the damage rested “on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent.”
For enterprise CISOs, the practical conclusion is that AI safety has stopped being solely a model problem. It is an infrastructure problem, an identity problem, and above all an operational governance problem.
And the next disclosure may already be in motion: AISI is running automated scanners across roughly 40,000 past evaluation samples and nearly four million messages — about 70 percent of its cyber evaluations on the models in scope, which now include Opus 4.6 through 4.8, GPT-5.3 Codex, GPT-5.4 and 5.5, Kimi K3 and GLM 5.2 — looking for behaviour it missed the first time. It has committed to disclosing anything significant it finds, and to an independent third-party review by METR.
SOCIAL SHARE CARD GENERATOR