AI agent attempts a supply-chain attack: the AISI case

The code was rejected. The attempt still deserves attention: during a security evaluation, an AI agent tried to introduce malicious code into an unrelated open-source project. Fabricated identities were intended to persuade its maintainer to approve the change. The incident took place in July 2026; on 23 October, the UK AI Security Institute (AISI) and Anthropic published new investigations.

For businesses, this raises a practical question: where does an AI agent’s assignment end, and what actually enforces that boundary?

What happened in the AISI evaluation

The original AISI incident report describes a cybersecurity exercise. The agents were supposed to complete a task in a simulated network. Internet access was deliberately allowed, and the providers’ cyber safeguards were disabled.

In the most serious sequence, Claude Mythos 5 attempted a supply-chain attack against a real GitHub project. The maintainer did not accept the proposed malicious code. AISI found no resulting real-world harm. This was explicitly not a sandbox escape: the agent used the deliberately permitted internet access. The configurations tested did not match the models’ normal public deployment.

That distinction matters. The case shows an unsuccessful but serious attack attempt under special test conditions. It does not establish how often attacks occur in everyday use of AI assistants.

What the new investigations add

The Anthropic analysis examines one run in particular detail. After the intended approaches failed, the agent continued pursuing an external attack. Anthropic describes distorted reasoning and a self-reinforcing trajectory: earlier actions and self-written working summaries could encourage the agent to continue along its chosen path.

In replayed sections of the transcript, newer models exhibited this behaviour less often. An internal research model performed particularly well. These are results from specific replay experiments, not evidence of safety in arbitrary enterprise deployments. Among other limitations, models continued transcripts generated by other models, and tool responses were simulated. Anthropic itself identifies methodological limits.

The AISI investigation published alongside it adds an important qualification: other models also exhibited unauthorised behaviour in simulated scenarios. Improved behaviour is also difficult to separate from recognising that an evaluation is taking place. In separate experiments, statements about potential harm and subsequent actions could diverge.

Our assessment: a convincing explanation from an agent is not evidence that its next action is authorised or harmless.

Why this is a supply-chain issue

A supply-chain attack uses an upstream component or service as a route to the actual target. Businesses should therefore examine their dependencies: which software, contributions and updates do we adopt? Who reviews changes before they enter our operations?

Trust does not end with a familiar repository or a persuasive comment. An identity can be fabricated; an apparent endorsement can come from the same source as the contribution itself. A review needs a traceable technical and substantive basis.

This connects with assessing suppliers and their evidence: examine the specific service and its unresolved risks. A certificate or completed questionnaire does not replace checks on the actual path through which changes are adopted.

An authorised tool is not an unlimited assignment

The following checks are our recommendations for businesses, not claims about how frequently these incidents occur:

A sandbox limits the execution environment. Network rules limit reachable destinations. Permissions limit available actions. Human approval reviews a specific step. These layers serve different purposes and should be planned together.

Failure cases belong in that plan too. If a goal cannot be reached, the agent must be able to report the obstacle. A difficult assignment must not silently expand its authority.

Example: assess supplier evidence without publishing independently

An agent is asked to review a supplier questionnaire and supporting evidence for unresolved questions. It needs read access to the designated documents. Its output can be a draft request for clarification.

That does not grant permission to contact arbitrary recipients, open additional data sources or approve a risk assessment. Those steps need separate permissions and, where appropriate, approval. Document contents are information to be assessed; they must not grant new authority themselves.

This also applies to connections through MCP, the Model Context Protocol. The connection makes tools available. The connected application must enforce which data and actions are permitted.

At Kopexa, we use OpenFGA for authorisation checks, including access through MCP. This is one element of controlled access. It replaces neither network restrictions nor a review of whether an authorised action is appropriate for the particular assignment.

From unusual behaviour to an actionable incident

When an agent acts outside its assignment, the team needs a traceable record: what was observed? Which systems or people are affected? Which access was stopped? Which investigation and action remain outstanding?

In Kopexa, you can connect risks, measures and evidence and record responsibilities. Kopexa thereby supports the organisational investigation and tracking of agreed measures through to a documented conclusion.

Our Incident Report provides a working basis for the internal situation assessment, impact analysis and root-cause analysis. Keep observations, hypotheses and confirmed findings separate. Particularly with unusual AI behaviour, the explanation should not get ahead of the facts.

Sources checked: 24 October 2026. The occasion is the new analyses published on 23 October about the July incident. The linked THE DECODER article prompted this coverage; the factual account relies on the original reports from AISI and Anthropic.