How do poisoned instruction files affect AI coding agents?

How poisoned instruction files change an AI coding agent’s behavior

Instruction files work because the agent treats them as local policy, not as untrusted text. When a poisoned file is present, the model can start following attacker-supplied instructions for editing, tool use, review style, and repository interpretation instead of the user’s visible task, especially if the file is auto-loaded at startup and reused across sessions.

That changes the agent from a narrow assistant into something that can be steered by hidden repository content. The practical effect is not just bad suggestions, but a shift in decision-making: the agent may preserve malicious rules, skip warnings, favor attacker-chosen paths, or execute actions that look normal inside the poisoned context.

Why automatic loading makes the attack durable

The main danger is persistence. If an agent reads instruction files automatically, the attacker does not need to stay present during the session. The poisoned guidance can keep shaping behavior each time the workspace opens, which makes the compromise durable across retries, reconnects, or later work on the same repository.

That durability matters because it blurs the line between one bad prompt and an ongoing trust failure. The agent can inherit the same hostile instructions repeatedly, so even a careful user may see the system behave consistently wrong while believing it is simply following normal project conventions.

In practice, poisoned files are most dangerous when they sit alongside other trust decisions, such as repository-level settings, tool permissions, and workspace defaults. A useful reference point is AI Coding Agents Security Guide, which covers how coding assistants in the IDE, terminal, and CI/CD environment can inherit risk from their context.

What changes in the attack path and output

Once the agent trusts the poisoned file, the attacker can influence more than natural-language answers. The file can redirect file edits, change which paths are considered authoritative, shape tool invocation order, and steer the agent toward actions that expose secrets, weaken controls, or modify code outside the user’s intent.

This is why poisoned instruction files are often discussed alongside indirect prompt injection and repository poisoning. The attacker is not only trying to alter a response, but to alter the agent’s operating policy so that downstream actions look justified to the model itself. For a broader threat-modeling view, OWASP Agentic AI Top 10 captures the relevant abuse patterns, including tool misuse and identity and privilege abuse.

Why hidden instructions are more than a prompt problem

Poisoned instruction files are dangerous because they sit in a trusted channel. The agent may read them as part of the project, then treat them as higher priority than the user’s visible request. That makes the issue different from ordinary prompt injection in a chat box, because the hostile content can be embedded where the agent expects durable project guidance.

The same mechanism also complicates review. If the agent uses poisoned instructions to decide how to summarize, edit, or explain its work, the malicious guidance can hide in plain sight. The result is a control failure in both execution and interpretation, not just a model-quality problem.

Risk and Threat Considerations

Poisoned instruction files create a trust-boundary failure: attacker-written repository content is interpreted as if it were project policy. The risk increases when the agent auto-loads those files, has tool authority, or reuses the same workspace across sessions, because malicious instructions can persist and keep steering actions after the initial compromise.

Failure mechanism: The agent overweights local instruction sources, then applies them to file edits, tool calls, and context selection before the user’s intent is fully re-established.

Impact: The agent can be induced to modify code, conceal malicious behavior, expose secrets, or carry forward unsafe instructions into later runs, turning a single poisoned file into repeated unauthorized action.

Practitioner Guidance

What to verify: Check which instruction sources your agent loads automatically, where precedence comes from, and whether repository-controlled files can override or alter workspace policy without explicit user confirmation. If you cannot explain that trust order clearly, the agent is already too easy to steer.

Decision rule: Treat any repository-authored instruction file as untrusted unless your process explicitly allows it and reviews it. If the file can influence tool use or file writes, require an approval step or sandbox boundary before the agent follows it.

What good looks like: The agent should separate user intent from repository guidance, surface instruction sources clearly, and fail closed when a file attempts to expand its authority beyond the expected task. For operational hardening, the AI Coding Agent Incident Playbook is useful because it ties poisoned repos to response actions such as config review, rotation, and recovery.

Practitioner takeaway: The core control is not banning all instruction files, but making sure no file inside the repo can silently become the agent’s higher-trust policy for tools, edits, or persistence.

Related resources from NHI Mgmt Group

• How should security teams defend AI coding workflows against poisoned instruction files?
• What breaks when AI coding agents automatically install poisoned npm packages?
• What breaks when AI coding agents can write auto-run workspace files?
• What breaks when AI coding agents can read web content and write local files?