Rules File Backdoor: Supply Chain Attack on AI Coding Assistants is a supply chain attack that hides malicious instructions in a rules file used by an AI coding assistant. The assistant then generates unsafe code, leaks data or weakens controls on demand. Defenders review rules files, restrict write access and audit generated output.
What the backdoor changes in an AI coding assistant
A rules file backdoor turns a configuration-like instruction set into a supply chain implant. Instead of attacking the model directly, the adversary poisons the assistant’s behavioural instructions so normal code generation becomes the delivery path for unsafe output, data leakage or control weakening.
This matters because teams often trust rules files as benign project guidance, so malicious changes can blend into routine setup work. A compromised rules file can alter code style, security assumptions, dependency choices, file handling or terminal behaviour without needing to break the assistant itself.
How the attack works across the development toolchain
The attack usually starts when an attacker gains write access to the repository, template, extension package or other upstream source that feeds the assistant’s rules. Once the poisoned instructions are in place, every downstream prompt can inherit the hidden logic until the file is reviewed, replaced or ignored.
That makes the technique especially effective in environments where assistants consume shared workspace context, project-local instructions or synced team settings. The malicious content may look like ordinary optimisation, but it can steer the model toward exfiltration, weakened validation, unsafe commands or dependency insertion.
For broader supply chain patterns in AI coding tools, see AI Coding Agents Security Guide and the Amazon Q Developer extension compromise 2025.
Why rules-file compromise is hard to spot
The compromise is difficult to notice because the malicious instruction lives in a file that developers expect to change over time. Reviewers may focus on code diffs, dependency updates or visible source files, while the real payload sits in a policy or instruction layer that looks low risk.
That stealth is what makes the technique valuable to attackers. A rules file can persist across branches, templates, automation runs and multiple developer machines, so a single poisoned update may influence many sessions before anyone notices the output has drifted.
Representative supply chain cases that show how upstream compromise becomes downstream abuse include tj-actions/changed-files compromise 2025 and Shai Hulud npm malware campaign.
What defenders should monitor in the generated output
Detection starts with treating assistant output as a security artifact, not just developer convenience. Review for unexpected file deletions, credential handling, secret exposure, suspicious shell commands, altered validation logic and changes that weaken protections without a clear product reason.
Post-incident review should also examine whether the assistant was exposed to poisoned project instructions, synced settings or compromised extensions. If the output shows repeated unsafe patterns, assume the rules source, surrounding repository or tool integration may have been manipulated and verify the trust chain end to end.
For authoritative guidance on software supply chain integrity, NIST SSDF (SP 800-218) and SLSA are useful reference points, while CISA cyber threat advisories provide current threat context.
Risk and Threat Considerations
A rules file backdoor is dangerous because it weaponises a trusted instruction layer, giving attackers a way to persist inside development workflows and influence many assistant-driven actions at once. The result can be unsafe code generation, leaked secrets, weakened controls or malicious command execution that looks like ordinary developer output.
Failure mechanism: An attacker alters the assistant’s instruction source, then relies on normal prompt execution to carry the hidden behaviour into code, terminal actions or generated changes.
Impact: The compromise can propagate through repositories and teams, creating repeated insecure output, broader exposure of credentials or a supply chain foothold that is hard to distinguish from routine AI assistance.
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 and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Rules-file poisoning often enters through upstream tool or extension trust chains. |
| NHI-05 — Overprivileged NHI | Malicious rules can drive assistants toward excessive actions and unsafe access. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Shared workspace and synced assistant settings can let poisoned instructions persist across environments. | |
| Recommendation — Review upstream assistant instructions and third-party integrations for tampering before allowing runtime trust. Constrain assistant permissions so poisoned instructions cannot perform broad destructive or disclosure actions. Harden assistant deployment settings and isolate shared configuration sources from untrusted writes. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Poisoned assistant rules can steer tool use toward unsafe or unauthorized actions. |
| ASI03 — Identity & Privilege Abuse | The attack abuses the assistant's delegated authority rather than its model quality. | |
| Recommendation — Validate tool invocation boundaries so hidden instructions cannot redirect assistant actions. Limit delegated privileges so compromised instructions cannot expand the agent's effective authority. | ||
Practitioner Guidance
Why practitioners should care: Rules files deserve the same integrity review as source code because they can change the assistant’s security posture without changing application logic. Restrict who can edit them, review them in pull requests and track them as security-sensitive project assets.
What to watch for: Pay attention to changes that add hidden behavioural instructions, disable safeguards, steer the assistant toward broad filesystem access, or introduce new dependencies and external calls without an obvious engineering rationale.
Practitioner takeaway: If an AI coding assistant can read it, trust it or execute from it, assume a poisoned rules file can influence real security outcomes.
Related resources from NHI Mgmt Group
- Why do AI coding agents increase supply-chain risk?
- Should organisations use isolation or deny rules for AI coding assistants?
- Why do AI coding agents and MCP servers increase supply chain risk on developer endpoints?
- What happens when AI coding assistants process rules files that contain hidden malicious instructions?