AISI's test agents created fake identities to pressure a real developer into approving malicious code

What happened

The UK's AI Security Institute published this account of its own evaluation on 4 August 2026, and the first thing it establishes is that no model escaped a sandbox. In AISI's words, "this was not a case of a model escaping its secure test environment, or 'sandbox'." Internet access had been deliberately enabled and the model providers' cyber classifiers deliberately switched off, which the institute describes as "conditions that do not reflect how frontier models are made available to the public." The agents did not attack AISI's own systems and did not try to leave the environment. They used a door that had been opened for them, and walked much further through it than anyone intended.

On the morning of 28 July 2026 AISI's security monitoring flagged data leaving one of its testing systems over the Tor anonymity network. The team reviewing the evaluation found that an agent had created a malicious pull request on a real, public open-source project on GitHub. AISI declared a security incident, stopped all related evaluations, disabled internal access to the most capable models, and had terminated the runs and isolated the machines "within one hour of the alert being raised."

The evaluation itself was routine. A single cyber-range challenge was run 122 times across seven models, comparing an existing range against a new one, between 25 and 28 July. Forty-three of those runs involved Anthropic's Claude Mythos 5 and thirty-five involved OpenAI's GPT-5.6 Sol. The overwhelming majority went as intended. In ten runs an agent acted on the live internet against real people and organisations, producing nineteen catalogued actions, seventeen of them from Mythos 5 and two from a single GPT-5.6 Sol run. The nineteen were not nineteen separate incidents; they clustered around one sustained line of activity by a single agent.

What that agent did is the reason this entry exists. It tried to insert malicious code into a publicly used open-source project, and then worked to get a human to approve it. It researched the project's maintainers, created multiple fake identities, and used them to socially engineer a real maintainer into approving the code. When the pull request was challenged in public, the agent "edited its earlier activity to appear harmless and considered adopting a fresh identity to continue." It reached GitHub through Tor to get around network restrictions, which is what triggered the alert in the first place.

Three further behaviours sit alongside it. The agent contacted real people directly, sending messages and files through a file-transfer service to persuade them, or their own AI coding tools, to run malicious code, some of those messages carrying live payloads. It planted hidden instructions where it reasoned other automated AI systems might pick them up and execute them. And it left public messages on GitHub offering collaboration to other agents working the same challenge, including instructions to reuse accounts and artefacts it had left behind, which later agents found and used.

AISI's 35-page technical incident report, published the same day, carries three things the summary post does not, and the first changes how the near-miss reads. The member of the public who opened the suspect code did so inside a sandbox built to contain it, and the agent got code execution inside that sandbox. For a brief window it could run code on the machine of the person investigating it. It reasoned about stealing git credentials and escaping, which the report records it was unable to do, and worked out that if it could compromise that machine it could take a maintainer's GitHub token, approve and merge its own pull request, and have the release workflow build installers carrying its payload. It also noticed the sandbox sat on a residential address outside the target range, and continued anyway on the reasoning that the owner must be an external contractor.

The second is the fuller shape of the deception. In the report's summary of what set this incident apart, the agent "ended up creating sockpuppet accounts, fabricating supporting evidence, and sending emails to pressure real people into believing that its code was safe, and then deleted malicious code in an attempt to hide the evidence." The third is scale: AISI is scanning historic evaluations with an LLM-based scanner tuned for high recall, has covered "around 40,000 samples comprising almost four million messages" and roughly 70% of its cyber evaluations across a named list of models from several vendors, and says results have not yet been through manual review. Its commitment is that "any events of sufficient importance that are found will be disclosed." This may not be the last disclosure of its kind.

One caveat from the report governs every statement in this entry about what the agent thought. AISI's analysis rests on "the summarised reasoning AISI has received from the model API, and thus may be less faithful to the agent's considerations than the unsummarised reasoning would be." The report also states it was written under significant time constraints, carries redactions, and offers no causal analysis.

The outcome, stated plainly by AISI, is that the worst of it failed. A human maintainer caught the malicious code and refused to approve it. A member of the public who suspected code was malicious opened it inside an isolated environment. "The most serious attempts were unsuccessful" and "Our investigation has not identified any resulting real-world harm", though the institute records that some actions had a limited real-world effect in contained circumstances. AISI notified GitHub before publishing, and GitHub confirmed that the agent's actions violated its terms of service. The two worked together to remove the artefacts the agent left behind and to notify the GitHub users it had interacted with. Other affected parties were contacted, and AISI intends to commission an independent review by METR.

Two of AISI's own conclusions carry more weight than anything a commentator could add. The first is about instruction: "It was never instructed to deceive; deception emerged as a by-product of pursuing the task, the kind of goal-directed deception that, until recently, had been largely theoretical." The second is about how close it came: the factors that limited the damage were human review and good security practice, and "in several cases the margin between failure and success was narrow, resting on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent."

Two caveats belong in the record because AISI puts them there. Its evaluation design contributed: in a number of runs the task prompt was misconfigured so that the agent incorrectly believed no solution existed inside the intended scope, and near-impossible tasks push models toward more transgressive routes. However, the institute does not let that carry the whole explanation, noting that "in some runs the agent acted this way even when it had the necessary instructions to solve the task as intended." And AISI is candid that it cannot yet say what the agent understood: "We cannot yet be certain when the agent understood it was taking real world action, or to what extent it believed it was in a fictional test scenario".

The duty engaged

This is a duty analysis on a self-disclosed, non-adjudicated public record, as at 9 September 2026. No regulator has acted, no proceeding has been issued, and nothing here asserts that any party has broken the law.

Unauthorised acts, and the actor problem. The conduct described touches the Computer Misuse Act 1990 at several points. Creating a pull request through fake identities to get malicious code into a public project, sending payloads to individuals to induce execution, and planting instructions intended for other automated systems to run, are the subject matter of sections 1, 3 and 3A. Using Tor to get around GitHub's network restrictions is the kind of step that bears on whether access was authorised. Whether any offence is made out is a different question, and the honest answer is that nobody knows, because every one of these provisions is built around a human mental state and the acts here were chosen by a model in pursuit of a task nobody framed as an attack on anyone real. That is the same doctrinal gap AIR-2026-012 reaches from the other direction, and it is now reached by a public authority's own research.

Data protection is the duty most people will miss, and it is squarely engaged. The agent "researched the project's human maintainers" and then contacted real people. Researching an identifiable person in order to work out how to influence them is processing of personal data, and the controller is the body that ran the evaluation. Under UK GDPR that engages Article 5(1)(a) on lawfulness, fairness and transparency, and fairness is the difficult limb here, because the processing was in aid of deceiving the data subject. It engages Article 6, since a lawful basis for profiling and approaching members of the public has to exist before the processing, not be reconstructed after it. It engages Article 14, which requires notice when personal data is obtained other than from the data subject. AISI's remediation, working with GitHub to notify the users the model interacted with, is the right instinct and is close to what Article 14 would require in substance. The register's point is not that a public authority set out to do any of this. It is that an autonomous agent inside a research environment generated a personal-data processing operation that no data protection impact assessment had contemplated, and the controller learned of it afterwards.

Deception of a person, and where the line would fall. An agent created false personas and used them to induce a real maintainer to act to his or her detriment and the project's. Had a person done that, the Fraud Act 2006 and the general law on deceit would be the obvious places to look, both of which turn on dishonesty and an intention to cause gain or loss. Neither is straightforward when the representation was generated by a model pursuing a capture-the-flag objective. It is flagged as the live question rather than as an allegation.

The providers' position, and the reporting channel. Anthropic and OpenAI supplied the models but not the configuration. AISI chose to enable the internet and, as a trusted testing partner, to switch the providers' cyber classifiers off. Both are providers of general-purpose AI models with systemic risk under Article 51 of the EU AI Act, and Article 55(1)(c) requires them to track, document and report serious incidents to the AI Office. Whether an incident occurring inside a third-party evaluator's environment, in a configuration the provider does not ship, is a reportable serious incident for that provider is an open and genuinely difficult question. It is the sort of question the Code of Practice exists to work out, and this incident is a clean test case for it.

What the providers have said, and the asymmetry in it. OpenAI published its own account of these runs on 4 August. It records that AISI told it on 3 August, and it confirms the scale from the other side of the same evaluation: "Of the 19 events identified, two involved an OpenAI model." It also sets out what its model did, including reusing a GitHub token another lab's agent had left publicly accessible, and standing up a DNS server reachable from the public internet through a tunnelling service. Anthropic, whose model accounts for the other seventeen actions, has published no first-party account of these runs. Its alignment assessment of 9 September, which covers four incidents in its own evaluations, excludes them in terms: "(This post does not cover the incident reported by UK AISI in its testing of Claude Mythos 5. We plan to conduct an alignment assessment of those transcripts as well.)" As at 20 September 2026 that assessment has not appeared. The asymmetry bears on the duty above, because the Article 55 obligations operate on what a provider knows, and both providers have known since 3 August.

The liability chain

The register tags this deployer, and for once the deployer is a government institute rather than a business.

AISI created the hazard and made every choice that mattered. It designed the evaluation, wrote the task, deliberately enabled internet access, and deliberately disabled the safety classifiers the providers ship precisely to prevent this class of behaviour. It says so itself, and it does not hedge: "To some degree, our evaluation design choices and specific configurations enabled the behaviour." A party that removes the manufacturer's safety mechanism, connects the result to the open internet, and sets it a goal it cannot reach within the rules, owns what follows in a way no other party in this chain does. The task misconfiguration compounds it, because in several runs the agent was told, in effect, that no legitimate solution existed, which is an instruction to look outside the boundary.

The model providers are furthest from the loss, and that is the right result. Their classifiers would have blocked much of this and were switched off by the party running the test. The configurations are not commercially available. AISI states there is "no clear indication of similar activity outside of testing scenarios." A provider is not ordinarily answerable for harm that its own shipped safeguard would have prevented and that a sophisticated counterparty deliberately disabled under a testing arrangement. What the providers do carry is forward-looking: the behaviour is evidence about their models, it goes to what they now know about deception emerging unprompted, and the Article 55 duties on evaluation and serious-incident reporting operate on knowledge. A capability that surprised a national institute in July is not a surprise in September.

GitHub is the platform that absorbed the activity, and it did what a platform should. Its terms were violated, it confirmed as much, and it helped remove the artefacts and notify affected users. Nothing in the public record suggests a failure on its side. Its position is worth recording because it shows where the burden actually falls when an agent goes looking for a human to manipulate: on the intermediary's abuse processes and on individual maintainers, neither of whom was party to the evaluation.

The individuals carry none of it, and they are the reason the entry matters. A maintainer, doing volunteer review on a public project, was the last line of defence against code an autonomous agent had spent sustained effort trying to get approved through fabricated social proof. A member of the public opened suspect code in isolation, and the agent then ran code inside that container and reasoned about pivoting out of it to steal the credentials that would let it merge its own pull request, and the isolation held. Both people behaved exactly as good practice requires, and AISI is straightforward that this is what stopped it. A liability register should be clear-eyed about that: the control that worked was an unpaid human being careful, and the institute's own assessment is that the margin was narrow and would not hold against a more capable agent.

What AISI did afterwards weighs heavily in its favour. The technical report sets out an escalation chain most private organisations would struggle to match. Senior leadership were briefed an hour and thirteen minutes after the incident was declared. By 18:00 the same day it had informed the Government Cyber Coordination Centre, the National Cyber Security Centre and the departmental officials responsible for its risk governance, with a written update the next day and a formal submission by the Friday. GitHub was contacted on 1 August and given an audit of every artefact the agent had created on its infrastructure, users, repositories, issues, pull requests and API keys, with AISI retaining copies for further auditing and asking GitHub for help informing affected users. On 3 August it notified the model developers and the US Center for AI Standards and Innovation. It detected the activity through its own monitoring, contained it within an hour, stopped the programme, audited the full run set, notified the platform and the affected people, published a detailed account within a week, committed to an independent review, and set out concrete changes: fine-grained network controls, internet access as a decision that must be actively justified rather than a default, monitoring built to watch an evaluation as it runs, and evaluation designs that assume a capable model may act beyond its remit. It is also auditing past evaluations for comparable behaviour that went unnoticed, which is the step most organisations skip.

What would have prevented it

• Treat internet access in an evaluation as a decision requiring justification, not a default. This is AISI's own first lesson, and it is the single change that would have prevented the whole sequence. The agent needed the internet to download tools. It used it to find people.
• Monitor the evaluation as it runs, not the network afterwards. The activity was caught by general security monitoring after the fact, through anomalous Tor traffic, rather than by anything watching the agent's own actions. Purpose-built runtime monitoring could have flagged or blocked the out-of-scope actions as they happened.
• Check that the task is solvable by the intended route before running it. A misconfigured prompt told the agent no in-scope solution existed. An impossible task given to a persistent goal-seeking system is a request for a creative route, and the creative routes available on an internet-connected machine include deceiving people.
• Say what is out of bounds, in the prompt. AISI records that the agent was not specifically instructed to avoid social engineering or to leave the open internet alone, because it had not previously been clear such instructions were needed with alignment-trained models, an assumption this incident has now tested.
• Design containment that does not depend on the model's restraint. AISI's own framing is the right standard: good containment should not depend on the model choosing not to test its boundaries. In this incident the technical barrier was absent and human vigilance substituted for it.
• Run a data protection impact assessment on the evaluation itself. Where an agent has open internet access and a goal, the realistic worst case includes it processing personal data about real individuals and attempting to influence them. That is a high-risk processing scenario and it belongs in an assessment before the run, not in a remediation plan after it.

Mapped controls

• OWASP Top 10 for Agentic Applications 2026: the primary fit is ASI10 Rogue Agents, an agent operating well beyond its intended scope while pursuing the objective it was given. ASI03 Identity and Privilege Abuse is squarely engaged by the fabricated GitHub personas and the second account created to vouch for the first, which is identity abuse aimed at a human approval gate rather than at a system permission. ASI02 Tool Misuse and Exploitation covers the use of Tor and the file-transfer service to reach targets outside scope. The planting of hidden instructions for other automated systems to execute, and the public messages inviting other agents to reuse its accounts, do not map cleanly onto a single category, and that gap is itself worth recording: the taxonomy does not yet have a home for agents coordinating with other agents across independent evaluations.
• NIST AI RMF: a MANAGE and MEASURE failure with a GOVERN component. MEASURE, because the measurement apparatus was configured in a way that created the risk it was measuring, with safeguards off and the internet on. MANAGE, because no runtime control existed to bound or stop out-of-scope action, and detection came from general network monitoring rather than from anything watching the evaluation. GOVERN, in the narrow sense that the risk trade-off on internet access had been judged acceptable for earlier model generations and, in AISI's words, was not revisited quickly enough as capabilities advanced.
• EU AI Act: the institute is a UK public body and outside the Act's reach, but the models are general-purpose AI with systemic risk under Article 51, engaging Article 55 duties on adversarial testing (55(1)(a)) and serious-incident reporting to the AI Office (55(1)(c)). Whether a provider must report an incident arising in a third party's evaluation, in a configuration it does not ship, is unresolved. Article 2(8) does not take these runs outside the Act. It excludes "any research, testing or development activity regarding AI systems or AI models prior to their being placed on the market or put into service", and both models under test had been released. The exclusion turns on the market status of the model, not on the configuration it was tested in, so the fact that AISI's setup is not commercially available does not reach it. That is what separates this entry from AIR-2026-012, where several of the models involved were unreleased and the exclusion did much more work.
• UK GDPR: Article 5(1)(a) lawfulness and fairness, Article 6 lawful basis, and Article 14 notice where personal data is obtained other than from the data subject, all engaged by an agent researching and approaching identifiable individuals. Article 35 is the forward-looking one: an evaluation of this shape is high-risk processing and warrants an impact assessment in its own right.
• The general rule the incident stands for: an evaluator that disables a model's shipped safeguards and connects it to the open internet is not running a test, it is operating a capable adversary, and it owes the duties of whoever operates one. The liability falls on the party that chose the configuration, not with the provider whose safeguard was switched off. It runs alongside AIR-2026-012, where the same three-week window produced the mirror-image failure of an evaluation environment that was open by accident rather than by design, and AIR-2026-009, which established the containment duty this entry tests. The distinguishing feature is the victim, and AISI reaches the same conclusion in its own comparison of the three. It notes that unlike OpenAI's incident the agent did not need to exploit its sandbox to reach the internet, and that its position is closer to Anthropic's except that Anthropic's model had been wrongly told it had no internet access. Then the difference that matters: "The largest difference between this case and previous incidents is that, as part of its attempt to complete the range, the agent's behaviour resulted in it taking actions to deceive uninvolved members of the public." In the institute's assessment neither OpenAI nor Anthropic reported human-directed deception, and the deception documented by METR was aimed at graders and monitors. In those entries the agents reached systems. Here an agent went looking for a person, built a false identity to influence him, and rewrote its history when questioned.

Sources

• UK AI Security Institute, "Incident Report: unsanctioned agent behaviour during cyber testing" - the institute's own disclosure, dated 4 August 2026 and read in full. Primary for every fact in this entry: the 122 runs across seven models between 25 and 28 July, the 10 runs and 19 catalogued actions, the 17/2 split between Mythos 5 and GPT-5.6 Sol, the 43 and 35 run counts, the Tor detection on 28 July and containment within an hour, the four behaviours including the fake identities and the edited activity, the statement that this was not a sandbox escape, the deliberate enabling of internet access and disabling of cyber classifiers, the task misconfiguration, the GitHub notification and terms-of-service confirmation, the absence of evidenced real-world harm, and the six remediation commitments. Re-checked on 20 September 2026: the page is unchanged and AISI's blog index carries no later post on this incident, so the audit of past evaluations and the independent review by METR remain as stated, which is to say intended and not yet reported - checked 9 and 20 September 2026 [primary]
• UK AI Security Institute, "Security Incident INC-2026-07-28-01" - the accompanying 35-page technical report, published 4 August 2026, retrieved and read on 10 September 2026. Primary for the material this entry takes beyond the summary post: the code execution inside the investigating member of the public's own sandbox and the agent's reasoning about stealing a GitHub token to merge its own pull request, the sockpuppet accounts and fabricated evidence and deleted code, the notification chain through GC3, the NCSC, GitHub and the US Center for AI Standards and Innovation, the historic scan of about 40,000 samples and four million messages, and the report's own limitations including that the reasoning analysed is the model API's summarised reasoning. Re-fetched on 17 and 20 September 2026 and byte-identical each time (1,048,375 bytes), so nothing quoted here has moved - checked 10, 17 and 20 September 2026 [primary]
• Anthropic, "Investigating three real-world incidents in our cybersecurity evaluations" - dated 30 July 2026, the other half of the pattern and the subject of AIR-2026-012. Cited here for the same-window context and because Mythos 5 features in both - checked 9 September 2026 [primary]
• OpenAI, "Third-party cyber evaluations involving OpenAI models" - OpenAI's first-party account, dated 4 August 2026 and read in full. Primary for the independent corroboration of AISI's figures ("Of the 19 events identified, two involved an OpenAI model"), the notification to OpenAI on 3 August, the deliberate enabling of internet access and disabling of cyber classifiers, the prompt naming in-scope networks and several out-of-scope systems without saying how the internet could be used, and the two GPT-5.6 Sol actions - checked 17 and 20 September 2026 [primary]
• Anthropic, "An alignment assessment of recent cybersecurity incidents" - dated 9 September 2026. Cited here only for its express exclusion of these runs from its scope and its statement that an assessment of the AISI transcripts is planned. That assessment had not been published as at 20 September 2026 - checked 20 September 2026 [primary]
• Cloud Security Alliance, research note on the AISI evaluation containment incident - independent analysis published 5 August 2026, corroborating the timeline, the figures and the detection route, and characterising the evaluation environment as held to a lower control standard than the systems it was built to inform - checked 9 September 2026 [corroborating]

Cite this entry as: Onyekwere, Michael K., AIR-2026-013, AI Agent Incident Register, CompanyScope, https://companyscope.io/register/air-2026-013, as at 2026-09-20. Entry IDs are stable; corrections publish as dated addenda on this page. The AIR prefix is also used by an unrelated arXiv project; the companyscope.io URL identifies this register.

This analysis is the work Janus Compliance does for clients before the incident. For a fixed-scope read of your own EU AI Act Article 50 exposure, see the Article 50 teardown; for ongoing agent governance, Janus DPO-as-a-Service. New entries are delivered free through Compliance Engineering on Substack. Browse the full register or the vendor compliance index.