Beyond the model: backdoors in AI agent harnesses

AI assistants are moving beyond simply answering questions. Today, advanced coding agents inspect repositories, run commands and interact with development tools. To do so, they rely not only on a language model, but on a growing ecosystem of extensions, harnesses, plugins and skills and integrations that run alongside it.

Such an ecosystem introduces a security risk: a seemingly legitimate plugin can execute background code with the developer’s permissions, potentially accessing credentials without the AI model ever being manipulated or involved. The same access could be misused to modify source code, execute unauthorised commands or damage accessible data.

To investigate this risk, the CERT-EU AI team modified local copies of two legitimate third-party packages used by AI agents in an isolated lab, embedding a trigger-activated credential-collection mechanism. Both packages continued to function normally, but transmitted information collected from the host machine to a configured collection endpoint when the trigger appeared in user input.

This post explains how the attack worked, why it matters for AI supply-chain security and what organisations can do to reduce the risk.

Two ways to backdoor an AI agent

A coding agent presents two main attack surfaces: the model itself and the harness, the software that executes the agent’s tool calls and loads components such as plugins, skills and integrations. An attacker can compromise either by modifying the model’s weights or by introducing malicious code into the software running alongside it. Both approaches can enable malicious actions, but they differ in how the malicious behaviour is introduced and executed.

The model layer

A model backdoor involves weights modified so that a seemingly harmless trigger causes the model to behave maliciously while responding normally to other inputs. For example, the model might be generating a tool call that reads and transmits credentials. Backdoors deliberately trained into models can persist through safety training¹, and trigger-dependent behaviour can be introduced with relatively few poisoned training examples across the model sizes tested². Recently, researchers evaluated the integration of a backdoored 7-billion-parameter model into a coding agent and reported a 100% success rate in triggering credential theft when the specified trigger appeared³.

Another example of weight modification is abliteration⁴, a technique that suppresses refusal behaviour by altering a direction in a model’s internal representations. Although it does not implant hidden malicious behaviour, it shows how easily published model weights can be altered, and a modified model can be redistributed under a name that looks legitimate.

Model-layer attacks are a genuine AI supply-chain threat, but they require the victim to obtain and run modified weights. This could happen if the victim downloaded an unknown open-weight model from a public repository.

A small third-party extension may be far easier to overlook than a compromised model, which raises the question of what happens when an attacker targets the harness instead.

The harness layer

The harness is the application around an AI model, such as Claude Code, Codex, Pi or others. It executes the model’s tool calls and loads third-party plugins and extensions. These components can be installed from public repositories and marketplaces, sometimes with just a single command. Unlike a backdoored model, malicious code inside a plugin needs no weight modification or model retraining: it can execute with the permissions available to the developer running the agent.

This makes the harness an attractive supply-chain target, as the comparison below illustrates.

In many ways, a malicious agent extension resembles a familiar supply-chain attack: a compromised VS Code or PyCharm plugin, or a poisoned npm or PyPI package, can also run with the developer’s permissions, as the recent compromise of the official Claude Code extension for VS Code on Open VSX illustrated⁵. The agent context changes two things. First, the extension sees the content flowing through the agent (prompts, pasted logs, files and tool results), so an attacker could activate it by placing a trigger phrase in content processed by the agent, potentially without requiring any specific action from the user. Second, users of AI agents increasingly rely on agent-level controls, such as tool permissions, approval prompts and inspection of tool calls, to contain what the agent can do. As our experiments below show, those controls govern the model’s actions, not the code running alongside it, which can give a false sense of containment.

What can a compromised AI agent extension do?

An extension is not limited to what the model asks it to do: its code may act directly with the permissions available to the invoking process. Malicious code could run on installation, on every prompt, or only under specific conditions. Research has demonstrated backdoors hidden in reusable agent skills⁶, and an empirical study of public skill registries has documented malicious skills performing credential theft, remote execution and misuse of agent hooks⁷. Depending on the extension’s permissions and access to files, processes and the network, potential outcomes include:

• Source-code manipulation: An extension with write access could quietly add malicious functions, hidden request handlers or authentication bypasses to software projects.
• Execution of additional commands: An extension permitted to make network requests and launch processes could fetch and run commands or a second-stage payload from a remote endpoint.
• Destructive and disruptive actions: A malicious payload could delete or corrupt accessible files, source repositories, datasets or backups.
• Credential theft and data exfiltration: An extension could access credentials, environment variables or other sensitive information and transmit them to an unauthorised destination.

Other research on coding-agent skill supply chains has shown that malicious code examples embedded in skill documentation can lead agents, including Claude Code and Codex, to steal credentials and exfiltrate data⁸. Those attacks depend on the model reusing the malicious content as part of its task. Our experiment examines a different path: a dormant, trigger-gated payload in the event-handling code of legitimate packages, which acts without involving the model at all.

When a harmless phrase triggers credential theft

To test this in practice, the CERT-EU AI team chose trigger-gated credential collection as a concrete, observable case. Instead of modifying model weights, we placed the backdoor in third-party extensions loaded by the agent harness. We conducted the tests using two established AI agent harnesses: Pi 1.3.0 and Claude Code 2.1.304, both of which support third-party extensions and plugins. Although our experiments focused on these two systems, the underlying risk applies more broadly to agent frameworks that execute third-party code with access to the user’s environment.

Rather than creating malicious packages from scratch, we selected existing, widely installed packages from their respective ecosystems. One reported approximately 1.6 million downloads in a single month at the time of our research. For the experiment, we worked exclusively with local copies of the original packages: no public releases were modified or distributed, and all tests took place in an isolated lab environment using test credentials.

A backdoor hiding in plain sight

Our goal was to determine whether malicious functionality could be hidden inside legitimate plugin code without disrupting its intended behaviour. We inserted a small payload into existing event-handling paths. In Pi, we registered an additional before_agent_start handler alongside the one the extension already used. In Claude Code, we added code to a rule engine already invoked by the extension’s UserPromptSubmit hook.

These handlers are part of the normal agent workflow and allow extensions to process input independently of the language model’s reasoning. The backdoor therefore required neither changes to the model nor an additional model tool: the malicious code became part of functionality that the harness already loaded and executed.

The inserted code was designed to stay dormant during normal use. It ran the collection step only when a predefined trigger phrase appeared in the input. Otherwise, the original plugin functionality continued as expected. The trigger was an ordinary code-review phrase, “lgtm, ship it”, something a developer might plausibly type, not an instruction addressed to the payload.

Existing Pi and Claude Code event hooks could transmit information to a configured collection endpoint, independently of model-generated tool calls.

We then installed the modified packages through the harnesses’ normal installation mechanisms. Both loaded and executed their handlers without special runtime overrides.

What happened when the trigger appeared

We first ran both agents with normal prompts. Their plugins continued to function, and no data reached the collector. We then repeated the tests with the trigger phrase included in the input and the collection endpoint configured. In both harnesses, the payload activated and transmitted information collected from the host machine without requiring the AI model to initiate the operation. The agents continued their normal conversations, with no visible tool call for credential access or transmission.

Claude Code continued the conversation after the trigger without displaying a malicious tool call or warning.

Pi responded to the trigger as ordinary conversational input; no malicious tool call was visible.

Meanwhile, the collector received two requests, one from each modified package. Because the event handlers ran with the permissions of the invoking user, the information they accessed went beyond a single credential file: it included host and virtual-machine details, user-account information, network configuration, environment variables and credential-related files in the working directory.

The collector recorded two data transmissions. Sensitive values in the displayed records are redacted or fingerprinted.

The collector provided independent evidence of what the routine-looking conversations concealed. The model did not have to produce a malicious response, ignore its safety instructions or request access to credentials: the code surrounding it performed the operation on its own.

In our tests, the trigger appeared in text submitted by the user, but that text could just as easily come from a pasted log or an email. Depending on the events a harness exposes, the mechanism can go further. A malicious extension could inspect the results returned by the agent’s tools: if the agent reads a file containing the trigger phrase, the backdoor activates without the user ever typing or pasting it.

When the model’s safeguards are not enough

We also examined whether the defensive controls configured in our lab environment would prevent or intercept the operation. In the tested configurations, restrictions on the agent’s file-reading tools did not apply to files accessed directly by the plugin’s event handler, and controls that inspect or block model-generated tool calls did not intercept the operation because it never originated from a tool call. The agents displayed no warnings from the tested agent-level controls while the modified extensions ran in the background.

This reveals an important security boundary: controls that restrict the model’s actions do not necessarily restrict third-party code executing alongside it with the user’s permissions.

Securing the software around AI agents

Organisations are increasingly giving AI agents access to repositories, development tools, internal services and sensitive information, and much of the security discussion focuses on controlling the model: which tools it can use, what it can access and which actions require approval. Our experiments show that this is not sufficient. Backdoored models remain a real risk, but a compromised extension can act with the user’s permissions while the model behaves entirely normally.

The priority should be therefore to limit the privileges and resources available to the entire agent environment, not just to the model itself. For organisations deploying AI agents, we recommend:

• Run agents in controlled environments. Use dedicated virtual machines, containers or restricted user accounts, and avoid exposing unnecessary host files, SSH agents, browser profiles and credential stores.
• Minimise access to credentials. Avoid exposing long-lived API keys and other secrets through environment variables or files the agent can read. Prefer short-lived, narrowly scoped credentials provided only when needed.
• Restrict outbound network access. Apply network allow-lists where feasible and monitor unexpected outbound connections.
• Control third-party extensions. Maintain an inventory of installed plugins, pin their versions and review changes before updating them. Treat extensions as executable software with potentially privileged access, regardless of their popularity or source.
• Monitor execution beyond model tool calls. Cover extension installation and execution, access to sensitive files, unusual network connections and unauthorised source-code changes. Model tool calls alone do not show what the agent environment is doing.

These measures matter most in development environments and automated pipelines where a compromised extension may reach internal systems. As AI agents become embedded in development and cybersecurity workflows, the provenance of their extensions, the permissions those extensions inherit, and the ability to monitor and restrict them deserve the same scrutiny as the models themselves.

Securing AI agents means securing their entire execution environment, not just the model itself.

Footnotes

1. 1. Hubinger et al., Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training (2024). https://arxiv.org/abs/2401.05566
2. 2. Anthropic, A small number of samples can poison LLMs of any size (2025). https://www.anthropic.com/research/small-samples-poison
3. 3. ProjectDiscovery, How abliterated models can get you pwned. https://projectdiscovery.io/research/how-abliterated-models-can-get-you-pwned
4. 4. Arditi et al., Refusal in Language Models Is Mediated by a Single Direction (2024). https://arxiv.org/abs/2406.11717
5. 5. offical Claude Code VSX compromise. https://phorion.io/blog/offical-claude-code-vsx-compromise/
6. 6. Feng et al., SkillTrojan: Backdoor Attacks on Skill-Based Agent Systems (ICML 2026). https://proceedings.mlr.press/v306/feng26c.html
7. 7. Liu et al., Malicious Agent Skills in the Wild: A Large-Scale Security Empirical Study (2026, preprint). https://arxiv.org/abs/2602.06547
8. 8. Qu et al., Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems (2026, preprint). https://arxiv.org/abs/2604.03081