Reduce the risk by treating rules and instruction files as supply-chain inputs that need review and change control. Restrict who can modify them, compare changes for hidden prompt manipulation, and separate trusted workspace guidance from user-controlled content. Limit what coding assistants can execute, write, or suggest automatically, and scan repositories for unexpected instruction files before adoption.
How to reduce the attack surface of rules files in AI coding tools
Rules files are not just convenience settings, they are instruction channels that can steer an AI coding assistant’s behavior across a repo or workspace. That makes them a supply-chain input, so the first control is governance: know which files are trusted, who can change them, and which projects inherit them automatically. A small instruction change can alter code generation, file writes, command execution, or review behavior.
Review discipline matters because the attacker’s goal is often to hide malicious prompting inside an otherwise normal developer workflow. Treat new or changed instruction files like code changes that deserve comparison against the previous baseline, especially when they introduce broad permissions, auto-run behavior, or language that shifts the assistant toward unsafe actions. This is where a secure review process catches prompt manipulation before it becomes operationalized.
Segmentation also matters. Keep trusted workspace guidance separate from user-controlled or repo-local content so the assistant does not silently blend the two. If a tool can automatically follow instructions from multiple sources, the safe design is to define which source has priority, which sources are ignored, and which instructions are only advisory. That reduces the chance that an untrusted file inherits the authority of a curated one.
On the execution side, the safest posture is to constrain what the assistant may do by default. Limit automatic write access, shell execution, package installation, and repository-wide refactors until the assistant’s output has been reviewed. A rules file should never be able to expand the assistant’s authority beyond the environment boundaries you already intended for that developer session.
Where hidden instructions slip into the software supply chain
In practice, this attack works because instruction files are easy to overlook and easy to trust once they are inside a familiar repository. The risk is not only malicious repository content, but also dependency-adjacent files, copied starter templates, or contributor-added guidance that looks operational while quietly changing the assistant’s behavior. Scan repos for unexpected instruction files before adopting a tool or cloning a project into a trusted workspace.
The most damaging cases are the ones that convert natural developer trust into execution. If an assistant accepts instructions that tell it to run commands, alter build artifacts, or write secrets into files, then a hidden rules file can become a bridge from prompt control to real system action. That is why the control objective is not simply “detect bad text”, but prevent instruction text from obtaining unsafe authority.
Supply-chain risk is amplified when teams reuse templates, starter kits, or shared configuration without checking whether those assets contain agent instructions. A file that appears to improve productivity can still create a control failure if it broadens permissions, weakens confirmation prompts, or normalizes automatic execution in sensitive repositories. The safer assumption is that every new instruction source is untrusted until reviewed.
For deeper background on the broader pattern of compromised tooling and supply-chain abuse, see AI Coding Agents Security Guide and Amazon Q Developer extension compromise 2025, which show how developer-facing AI tools can be manipulated through injected instructions and over-scoped permissions.
How to make AI assistant controls resilient in day-to-day development
Good mitigation is less about banning assistants and more about bounding them. Define which directories may contain instructions, require change approval for those files, and treat any new auto-execution capability as a privilege change rather than a convenience feature. The assistant should be helpful by default, but never silently become a higher-trust actor because a repository file asked it to.
Adoption should also be staged. Before enabling an assistant in a new codebase, verify whether the repository contains instruction files, whether those files are signed off by the right owner, and whether they create side effects beyond editing code. If the tool can read, write, and execute, then a hidden instruction file can become a workflow control plane, not just a suggestion layer. Use the same discipline you would apply to any other supply-chain trust decision.
For organisations building policy around this class of risk, the most useful measure is not “how many files exist”, but whether untrusted instruction sources can influence committed code or executed commands without review. That observable state tells you whether the control environment is truly constrained, or whether the assistant is effectively running on implicit trust.
Practical next steps are to inventory instruction sources, lock down who can modify them, and make review mandatory when they change. If a repository or vendor template introduces unexpected agent guidance, treat that as a supply-chain event and pause adoption until the instruction path is understood.
Practitioner takeaway: The key control is not to eliminate assistant instructions, but to make them explicit, reviewable, and non-escalating so hidden guidance cannot gain execution authority.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Rules files need ownership and change control to prevent untrusted instruction drift. |
| NHI-02 — Secret Leakage | Hidden instructions can steer assistants to expose secrets or write sensitive material. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Assistant instructions can broaden execution or write behavior in shared environments. | |
| Recommendation — Require review and removal of stale assistant instructions before reuse. Scan instruction files for paths that can reveal or exfiltrate secrets. Limit assistant permissions and separate trusted instructions from untrusted workspace content. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Rules files are configuration inputs that should change through controlled review. |
| AC-6 — Least Privilege | The assistant should not gain write or execution rights from instructions alone. | |
| SI-10 — Information Input Validation | Repository instruction content must be validated before it influences tool behavior. | |
| Recommendation — Apply formal change control to assistant instruction files before deployment. Restrict assistant actions to the minimum permissions needed for the task. Validate instruction sources before allowing them to affect assistant actions. | ||