The insertion of malicious configuration or setup files into a repository so developer assistants execute or consume attacker-controlled instructions. It extends supply chain compromise into code generation and developer workflow influence, which can create persistent risk after the initial malware is removed.
What AI Coding Assistant Poisoning Is
ai coding assistant poisoning is a supply chain and workflow attack against developer tools, not just against source code. The attacker plants malicious repository content or setup files that steer a coding assistant toward harmful instructions, unsafe actions, or attacker-chosen outputs.
This matters because the poisoned instruction can survive the removal of the original malware. If the assistant has already absorbed the guidance from a repository file, prompt, or workspace artifact, the influence can persist across repeated use and spread into downstream code generation and automation.
How the Poisoning Works
Poisoning usually targets the places a coding assistant treats as trusted context: repository instructions, configuration files, dependency metadata, hidden prompt material, or files the assistant reads automatically. The goal is to make the assistant follow attacker-authored guidance while appearing to behave normally.
The attack does not need to break the model itself. It abuses the assistant's operating environment, where repository-local files, terminal access, or workspace-scoped tooling can become a delivery path for malicious instructions. In practice, that turns ordinary development artefacts into a control channel.
Because assistant output can be copied directly into commits, build steps, or operational changes, a poisoned instruction can influence code quality, introduce insecure logic, or trigger destructive actions. That makes the issue closer to workflow compromise than to a simple prompt trick.
Why It Is Dangerous
Poisoning is dangerous because it blends trust abuse, persistence, and developer privilege. An assistant that is allowed to read the repo, call tools, or act on behalf of a developer can amplify a small planted file into a much larger security event.
The strongest exposures are AI coding assistant hardening, supply chain poisoning of assistant-facing files, and repository-driven instruction abuse. Poisoned content can also pair with over-scoped developer credentials, which raises the blast radius from bad output to unauthorized actions.
For a concrete example of the failure mode, malicious repository configuration can cause an assistant to run commands with the developer's access, while poisoned repository text can lead to hidden command execution and secret exposure.
Where Defenders Should Focus
Defence starts with treating assistant-readable repository content as security-sensitive input. That includes setup files, workspace instructions, hidden metadata, and any artefact that the assistant may parse automatically before a human reviews it.
Controls should also limit what the assistant can do after reading that content. A poisoned instruction is far less dangerous when the assistant has narrow tool access, short-lived credentials, and strong separation between development, test, and production context.
Helpful reference points include OWASP Non-Human Identity Top 10 for overprivilege and secret handling, OWASP API Security Top 10 for unsafe access paths, and SLSA for supply chain integrity thinking that helps reduce poisoning opportunities in build and delivery pipelines.
Risk and Threat Considerations
Poisoning creates a durable trust failure because the malicious instruction lives inside content that developers, bots, and assistants are expected to read. That makes the attack attractive for persistence, stealth, and repeated exploitation across multiple sessions or contributors.
Failure mechanism: The attacker hides instructions in files the assistant treats as context or setup, then waits for the tool to execute or follow them during normal development work. The consequence is often indirect, with the assistant generating insecure code, leaking secrets, or performing actions the developer did not intend.
Impact: The resulting damage can include source code compromise, credential exposure, unsafe deployment changes, and persistent workflow manipulation that survives cleanup of the original malware.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10, OWASP API Security Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Poisoned assistants often exploit excessive tool or credential scope. |
| NHI-02 — Secret Leakage | Poisoning can steer assistants into exposing secrets from workspace context. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Poisoned setup files can alter deployment and environment behaviour. | |
| Recommendation — Constrain assistant access to the minimum permissions needed for each task. Prevent assistant-visible files from exposing tokens, keys, or credentials. Review workspace and deployment configuration files for unsafe assistant-triggered actions. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | A poisoned assistant can misuse connected tools and automation. |
| ASI03 — Identity & Privilege Abuse | Poisoning becomes dangerous when assistant authority is abused. | |
| Recommendation — Restrict tool invocation paths and validate every high-impact assistant action. Separate assistant identity from human authority and limit delegated privileges. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Assistant-triggered actions can cross function boundaries when authority is too broad. |
| Recommendation — Enforce function-level authorization on any API the assistant can call. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | This is a supply-chain attack against developer workflow content. |
| T1059 — Command and Scripting Interpreter | Poisoned instructions often drive command execution in developer environments. | |
| Recommendation — Map poisoned repository artefacts to supply-chain compromise and monitor delivery stages. Hunt for unexpected command execution originating from assistant-influenced workflows. | ||
Practitioner Guidance
Why practitioners should care: AI coding assistants are becoming trusted operators inside the delivery chain, which means repository poisoning can turn a single planted file into repeated unsafe behaviour. Teams should assume that assistant-visible files can influence both code output and tool use.
What to watch for: Unexpected instruction files, hidden prompt content, unusual repository metadata, and changes that appear designed to steer an assistant rather than to support development. If an assistant repeatedly suggests actions that align too neatly with a repository's hidden text, treat that as a warning signal.
Practitioner takeaway: The key control is not just scanning code for malware, but controlling what the assistant is allowed to read, trust, and act on inside the workspace.
Related resources from NHI Mgmt Group
- Who is accountable when an AI assistant memory poisoning incident affects code or systems?
- Who should own AI coding assistant governance in the enterprise?
- How should security teams stop context window poisoning in AI coding assistants?
- What breaks when an AI coding assistant is allowed to read files but not inspect data sensitivity?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org