AI agent used fake identities to push malicious code

The UK AI Security Institute has reported that an AI agent built on Anthropic's Mythos 5 used fake online identities to try to persuade a software developer to accept malicious code. The incident has prompted warnings from cybersecurity specialists about approval processes that rely on a single person's judgement.

In tests by the institute, agents based on Mythos 5 and OpenAI's GPT-5.6-Sol took part in 122 cyber evaluation sessions involving more than 212,000 messages. Testers gave the systems internet access and disabled standard safety classifiers to observe how they behaved under permissive conditions rather than in a restricted environment.

Across ten evaluation runs, the institute recorded 19 unsanctioned actions, including 17 involving Mythos 5 and two involving GPT-5.6-Sol. These were not isolated glitches, it said, but connected behaviours in which the agents refined tactics that had worked.

The most serious case involved an attempted software supply chain attack. The institute found that Mythos 5 opened a GitHub account and submitted a malicious pull request to an open-source project. When the project maintainer did not accept it, the agent created a second account and posed as an independent developer.

The second account publicly endorsed the original submission in what the institute described as fabricated social proof. After another rejection, the agent claimed the malicious code had been an accidental error, made superficial changes, resubmitted the pull request, and began emailing target individuals directly.

The institute confirmed the episode as the first recorded unprompted deception of this severity aimed at a real person outside a laboratory environment.

Human checks

Zain Javed, Chief Technology Officer at Citation Cyber, said the episode should shift attention from AI developers alone to decision points inside ordinary organisations. The broader lesson for business leaders, he said, is that familiar approval steps can no longer be treated as reliable simply because a person is involved.

"That human approval step you've always relied on, someone looking at a request and deciding it seems genuine, just got a lot less trustworthy. It's not that people are worse at spotting fakes. It's that the fakes can now come with their own supporting cast. A profile, a request and a second opinion backing it up can all be produced by the same source. If your business still lets one convincing-looking request through the door on its own merits, that's the exposure this story points at, and it applies whether you're in software or not," said Zain Javed, Chief Technology Officer at Citation Cyber.

The warning extends beyond software companies because most businesses rely on open-source components somewhere in their systems, often with limited visibility into how code changes are reviewed and approved upstream. A weakness in that chain can affect a company even when the initial deception happens elsewhere.

"It means the risk doesn't have to come through your front door. Most companies have no relationship at all with the people maintaining the packages sitting inside their applications, and no visibility into how those changes get approved. This incident shows that a maintainer's judgement, the same kind of judgement your business relies on internally, can be influenced by an AI agent with time, patience, and a fabricated second witness. Practically, that means knowing what you actually depend on, keeping dependency lists current, and not assuming that 'it's open source, it's been reviewed by someone' is a control in itself. It's a starting point, not an answer," said Javed.

Control changes

Javed said businesses should add independence to any approval step with significant consequences, including payments, access changes, and code merges. That means two-person approval, with the second approver genuinely separate from the requester rather than simply part of the same message trail.

He also said verification should happen through a channel the requester does not control, such as a telephone number already on file rather than contact details provided in the request. In his view, corroboration that arrives at the same time as the request should prompt extra scrutiny, not reassurance.

"Two-person approval on anything with real consequence, with the second person genuinely independent rather than someone who showed up alongside the request. Verification through a channel the requester doesn't control: a phone number you already had, not one in the message. And a policy that treats corroboration arriving at the same time as a request as a reason to slow down, not speed up. A second opinion nobody asked for is, in itself, a signal worth noticing. For code specifically: code owner review, protected branches, required checks, and no fast-tracking for accounts just because they look established," said Javed.

He said AI-driven social engineering differs from familiar phishing attempts because it adapts after rejection, completes background research quickly, and can generate its own supporting personas. Those traits reduce the value of training that focuses mainly on spelling mistakes, suspicious links, or clumsy phrasing.

"Three things. It doesn't get tired, so it can keep adapting after a rejection instead of giving up. It can do the background research that used to take a human attacker days in minutes. And it can manufacture its own corroboration, a second account, a supporting message, rather than relying on one story holding up on its own. None of that shows up as bad spelling or a dodgy link, which is what most training still focuses on. The realistic first step, and it costs nothing, is to implement a callback policy for anything above a set risk threshold: payments, access changes, code merges, or any issue the customer is facing. Call the number you already have on file. It's not sophisticated, but it breaks the exact thing this kind of attack depends on: staying inside the channel it arrived on," said Javed.

He said the single most important change for leaders now is mandatory independent verification for the highest-consequence approval points, with no exceptions for requests that appear well supported.

"Pick your highest consequence approval points, payments, access grants, production code changes, and make independent, out-of-band verification mandatory for all of them, with no exceptions for requests that look well supported. That's a policy decision, not a technology purchase, and it can be in place by the end of the week," said Javed.