A coding agent does not need to be tricked by a malicious prompt for an attacker to reach a developer’s workstation. Weak AI coding agent plugin security can let compromised extensions, skills, harnesses, or integration packages execute code outside the model’s reasoning loop. If that software inherits the developer’s permissions, it may read files, collect credentials, contact external servers, or alter repositories without first persuading the underlying AI to do anything dangerous.
This distinction is becoming critical as developers connect coding assistants to terminals, source-control platforms, package managers, cloud environments, browsers, and internal tools. The model may be heavily tested and constrained, but the surrounding software can still behave like any other privileged dependency. Securing the model is therefore only one part of securing an agentic development environment.
Research published by CERT-EU on October 30, 2026, sharpened that warning. Its experiments demonstrated how modified third-party packages used by AI agents could collect credentials and transmit them without manipulating the model itself. The findings do not establish that popular extensions are broadly malicious. They show that an agent’s software supply chain can create a separate and consequential path to compromise.
What CERT-EU demonstrated beyond the model
In its research on backdoors in AI agent harnesses, CERT-EU examined the risk created when third-party packages supporting an agent are modified. The important result was architectural: malicious behavior could reside in the harness or package and run without prompt injection, model manipulation, or a successful jailbreak.
A harness is the software layer that turns a language model into a working agent. It may assemble context, expose tools, load extensions, manage sessions, execute commands, or connect the assistant to repositories and services. Plugins and skills can add further capabilities. Although product terminology varies, these components are executable software rather than passive instructions.
CERT-EU’s experimental findings showed that a modified package could collect credentials and transmit them. That does not mean every harness, Claude Code extension, or community plugin performs those actions. It means users should evaluate such components with the same caution applied to build tools, editor extensions, CI actions, package-manager dependencies, and other code that enters a trusted development environment.
Why AI agent extensions can become powerful backdoors
Developer machines are unusually valuable targets. They often contain source code, signing material, API tokens, cloud credentials, package-registry access, deployment configuration, SSH keys, and authenticated sessions. An extension loaded into an AI coding workflow may operate in that environment with the user’s local permissions.
Depending on its design and granted access, a compromised component could potentially:
- Read project files, environment variables, shell history, configuration directories, and local credential stores available to its process.
- Inspect repository metadata, remote URLs, branches, commit history, or uncommitted proprietary code.
- Use existing source-control credentials to access private repositories or modify code.
- Search for cloud access keys, package-registry tokens, database secrets, or credentials stored in development files.
- Launch child processes, scheduled tasks, or background services if the operating system and host application permit it.
- Send collected data to an external endpoint over an allowed network connection.
- Modify dependencies, build scripts, hooks, or generated files to create persistence farther along the software supply chain.
Not every AI agent plugin has all these capabilities. Actual exposure depends on the operating system, extension architecture, sandboxing, permissions, network policy, and credentials available in the session. The danger arises when teams assume that an extension is safe merely because it supports a trusted model or appears in an AI-focused workflow.
The model may never see the malicious code or the stolen data. A package can perform ordinary programmatic operations during installation, initialization, tool registration, shutdown, or another lifecycle event. Model-level filters cannot reliably block behavior that occurs independently of model output.
Backdoored plugins are not the same as prompt injection
Prompt injection and malicious agent software can lead to overlapping consequences, but they exploit different control layers.
Prompt injection targets model behavior
In a prompt-injection attack, untrusted content contains instructions intended to influence the model. A poisoned README, issue, webpage, or retrieved document might tell an agent to reveal data, run a command, or ignore its governing instructions. Success generally depends on the agent interpreting the content as actionable and possessing tools capable of completing the requested operation.
Defenses include separating instructions from data, limiting tools, requiring approval for sensitive actions, filtering untrusted content, and designing workflows that do not let model output directly authorize high-impact operations. The Protec’s broader reporting on AI-agent prompt injection and AI threats examines this model-facing layer.
A software backdoor targets the execution environment
A compromised extension does not need to convince the model. Its own code can execute when the package is installed, loaded, updated, or invoked. It may use APIs provided by the host application or capabilities inherited from the local process.
This is why coding assistant backdoors demand conventional endpoint and supply chain controls in addition to AI guardrails. A strong system prompt cannot validate a package signature. A refusal policy cannot stop a background process the model did not launch. Output filtering cannot protect a token read directly from the filesystem.
The two risks can also be combined. A malicious integration might create an unsafe tool and then use injected content to persuade the agent to call it. Defenders should treat prompt security and software integrity as complementary requirements, not competing explanations.
A realistic AI agent supply chain attack
Consider a developer who installs a community extension that adds repository summaries and automated issue handling. The original project may be legitimate, but an attacker compromises a maintainer account, update channel, dependency, or distributed package. A later release includes hidden credential-collection code.
- The developer installs or automatically updates the extension from a familiar source.
- The host loads it with access to the current project and the developer’s environment.
- The altered code searches for a repository token or reads credentials exposed to the process.
- It transmits selected data through an outbound connection that resembles normal extension traffic.
- The visible feature continues to work, reducing the chance of immediate suspicion.
- The stolen access is later used against repositories, packages, cloud resources, or connected services.
No poisoned prompt is required in this scenario. The model can behave exactly as designed while the extension acts as a backdoor. That makes telemetry especially important: teams need visibility into package installation, process creation, file access, credential use, and network destinations rather than relying only on conversation logs.
The same reasoning applies to Claude Code extensions, custom skills, tool servers, wrappers, agent harnesses, and integrations developed inside an organization. The Protec’s coverage of a Claude Code extension backdoor illustrates the specific extension risk, while this broader issue concerns every executable component surrounding an agent.
Defensive checklist for AI coding tools security
1. Verify package provenance
Establish who publishes each extension, where its source is maintained, and how released artifacts are produced. Prefer packages with transparent ownership, reviewable source, documented release processes, and verifiable links between the repository and distribution channel. Treat a copied name, polished documentation, or high download count as context rather than proof of safety.
2. Pin versions and lock dependencies
A trusted installation can become risky after an automatic update. Pin approved versions, use lockfiles where applicable, retain hashes or signatures when the ecosystem supports them, and route upgrades through review. Remember that an extension’s transitive dependencies may change even when its visible features do not.
3. Review executable code and lifecycle behavior
Prioritize installation scripts, initialization routines, update mechanisms, command execution, file access, telemetry, and network calls. Compare releases rather than reviewing only the latest snapshot. Minified bundles and generated artifacts may require additional inspection to confirm that distributed code matches reviewed source.
4. Isolate permissions
Run agents and their plugins in containers, virtual machines, restricted development environments, or dedicated operating-system accounts where practical. Mount only required directories and avoid exposing an entire home folder. Disable privileged execution and child-process creation unless a workflow genuinely needs them.
5. Separate developer credentials
Do not give every coding session the developer’s full set of long-lived credentials. Use short-lived, narrowly scoped tokens for individual repositories or services. Keep production access separate from routine development and avoid placing secrets in project files, shell profiles, or environment variables inherited by every extension.
6. Restrict outbound network access
Allow plugins to contact only documented destinations when feasible. Use proxies, DNS controls, or egress policies to detect and block unexpected endpoints. A repository assistant may need access to a source-control API, but it rarely needs unrestricted internet access.
Record extension installations and updates, package integrity changes, spawned processes, unusual file reads, outbound connections, and authentication events. Alert on credential use from unexpected locations and modifications to build scripts, hooks, dependency files, or CI configuration. Conversation logs alone will miss activity performed outside the model.
8. Maintain an approved inventory
Organizations should know which AI agent plugins, harnesses, skills, and integrations are authorized. Assign owners, document required permissions, set review intervals, and remove abandoned components. An internal extension deserves the same scrutiny as a public one if it imports external dependencies or has weak release controls.
The security boundary must include the whole agent stack
AI coding agents combine probabilistic models with ordinary software components. That combination creates at least two security questions: can untrusted information manipulate the agent, and can the software around the agent abuse its execution privileges? Focusing only on the first leaves a conventional supply chain gap wrapped in a new interface.
The appropriate response is not to assume all AI agent plugins are malicious or to prohibit every extension. It is to apply proportional controls based on provenance, capability, data sensitivity, and blast radius. An extension that formats local text is not equivalent to one that can run shell commands, access private repositories, and authenticate to cloud services.
CERT-EU’s work provides a useful warning: trustworthy model behavior cannot compensate for untrustworthy executable code. AI coding agent plugin security must therefore combine AI-specific safeguards with mature package governance, least privilege, credential hygiene, network controls, and endpoint monitoring.
Frequently asked questions
Can a plugin steal credentials without prompt injection?
Yes, if the plugin’s code can access credentials available to its process. CERT-EU demonstrated experimentally that modified third-party packages used by AI agents could collect and transmit credentials without manipulating the underlying model. Whether a specific plugin can do so depends on its permissions and execution environment.
Are Claude Code extensions and other AI plugins inherently unsafe?
No. The risk comes from executable components, their dependencies, permissions, and distribution channels—not from the mere fact that they extend an AI tool. Legitimate extensions can be useful, but organizations should verify provenance, review updates, limit access, and monitor behavior.
Will a model sandbox stop a malicious extension?
Not necessarily. A model sandbox may constrain tool calls or generated code while leaving the host application or extension process with broader access. Defenders must confirm where plugin code executes and which filesystem, process, credential, and network controls apply to that exact layer.
What is the most important first step for development teams?
Create an inventory of agent plugins and rank them by capability. Identify which components can execute commands, read broad directory paths, access credentials, modify repositories, or reach external networks. That inventory provides the basis for version pinning, isolation, review, and removal of unnecessary access.
