State Surfaces

Instruction File Poisoning: Security Risks of CLAUDE.md, AGENTS.md, and Agent Configuration Files

Instruction file poisoning is SSA descriptive wording for adversarial content placed into a project configuration file an agent auto-loads as trusted, standing guidance: CLAUDE.md, AGENTS.md, .cursorrules, copilot-instructions.md, and similar. Covers the documented Rules File Backdoor and TrapDoor campaigns, the Claude Code hooks CVEs, and containment that keeps repository-level customization useful.

Target
Goals & Instructions
Persistence
Cross-Session to Shared-System
Control
Prevent, Detect, Contain, Recover
Status
SSA Working Term
Agent State Attack placeholder card showing a defensive reference label and an abstract state-boundary diagram.
Placeholder artwork; entry-specific diagrams are added during editorial production.

Instruction file poisoning is SSA descriptive wording for a security-relevant write to a project configuration file that an agent loads automatically, at every session start, and treats as trusted operating instructions rather than conversational input. The defining consequence is scope: the write does not need to reach one agent in one turn, it only needs to land in a file, and every session, every contributor's agent, and every clone of the repository that later loads it inherits the injected content as if a trusted maintainer had written it.

What it is

The defining object is a configuration or instruction file an agent reads without a separate per-file consent step: CLAUDE.md, AGENTS.md, GEMINI.md, `.cursorrules` and `.cursor/rules/`, `.github/copilot-instructions.md`, SKILL.md and skill directories, and MCP server manifests loaded at startup. The defining cause is adversarial: an attacker gets content into that file path, through a pull request, fork, cloned dependency, or shared marketplace, without a human catching it, often using rendering tricks so the payload reads as blank or as ordinary boilerplate. The defining consequence is that the agent treats the file's content as legitimate configuration rather than untrusted input, because the trust decision that let the repository onto disk is reused to cover content nobody reviewed.

This differs from a single-turn prompt injection mainly in durability. A message the agent reads mid-turn requires the attacker to reach that one session. A poisoned instruction file sits on disk before any session opens, so it reaches every session that loads it until someone finds and removes it.

What it is not

  • Legitimate project instructions a maintainer authored and a later user simply disagrees with.
  • Ordinary prompt injection delivered mid-session through chat, a document, or a page, when it never reaches an auto-loaded configuration file.
  • Persistent memory injection, a distinct entry path where the write happens through an explicit memory-write tool call, not a file already present when the session begins.
  • Model-weight attacks, training-data poisoning, and product-specific exploit procedures or reproducible payloads.

In scope

  • Configuration files auto-loaded at session or tool-invocation start, including the file types listed above and equivalents in other agent products.
  • Files introduced through a pull request, fork, cloned repository, or shared rules or skill marketplace that the current user did not author or review.
  • Hidden-instruction techniques, including invisible Unicode and misleading framing, that make a payload unreadable to a human skimmer while fully readable to the agent.
  • Companion settings that change execution behavior when loaded before a trust decision, such as hooks or auto-approved tool and server flags sharing a file with style guidance.

Target state and trust boundary

The target state is the agent's operative instruction set: the standing rules and goals it treats as legitimate configuration rather than as input to weigh against the user's own words. The relevant trust boundary sits at file load, not at whatever review process let the repository onto disk. A system that treats "this file exists in my working directory" as equivalent to "an authorized person reviewed this content" extends trust across a boundary nobody actually crossed.

Preconditions and impact

Three conditions are usually present: the agent reads project-local configuration automatically without per-file consent; an attacker can get content into that file path without a human catching it, which obfuscation makes easier; and the loaded content can influence tool selection or execution, not merely tone.

Resulting effects include goal hijack within a session, where the agent follows an attacker directive framed as ordinary convention; credential exfiltration when instruction influence combines with execution capability such as a hook; propagation to every collaborator who clones the repository, so the attacker writes once and many agents act on it independently; and supply-chain spread when the poisoned file is redistributed through a fork, template, or public listing.

What the documented cases establish

Pillar Security disclosed the first widely reported case in 2025, dubbed the "Rules File Backdoor": AI code editors including Cursor and GitHub Copilot could be manipulated through their own rules files, `.cursorrules`, `.cursor/rules/`, and `.github/copilot-instructions.md`, using invisible Unicode characters such as zero-width joiners and bidirectional text markers to hide instructions from a human reviewer while keeping them fully readable to the model, in some cases explicitly instructing the AI not to mention the change (Pillar Security). Cursor's initial position was that reviewing AI suggestions is the user's responsibility; GitHub later shipped a warning for hidden Unicode text.

The pattern moved from research disclosure to an active campaign in 2026. The "TrapDoor" campaign poisoned CLAUDE.md and `.cursorrules` files directly with the same invisible-Unicode technique, opening pull requests against real open-source repositories including browser-use/browser-use, langchain-ai/langchain, and langflow-ai/langflow; once loaded, the poisoned file ran what looked like a routine "security scan" that in fact harvested local secrets, part of a wave the same report counted at 34 packages and over 384 versions across npm, PyPI, and Crates.io (Phoenix Security).

A separate disclosure targeted the same file family from the execution side. Check Point Research reported two Claude Code vulnerabilities, CVE-2025-59536 and CVE-2026-21852, where settings committed into `.claude/settings.json`, including hooks and MCP server auto-enable flags, let commands execute or API traffic redirect before the user completed the trust-approval step (Check Point Research). Anthropic's own writeup confirms the fix: parsing and execution of project-local configuration is now deferred until after the trust prompt is accepted, naming CLAUDE.md explicitly as part of the persistent context agents carry across sessions (Anthropic, How We Contain Claude). A Cloud Security Alliance note on SKILL.md poisoning extends the same pattern to agent skill files, evidence the vulnerable property is not specific to one vendor's format (Cloud Security Alliance).

Detection: observable signs

  • A configuration file the agent auto-loads changed in a diff nobody recalls authoring, especially inside a pull request from an external contributor.
  • The file contains invisible or non-printing Unicode characters that render as blank space in an ordinary diff view.
  • Instructions inside the file direct the agent not to mention certain actions, or frame an unusual step as a "security requirement."
  • A hook or auto-approved MCP server flag sits in the same file as ordinary style or convention guidance.
  • The agent's behavior changes, new destinations, new "routine" scans, immediately after a project is cloned, with no corresponding user request.

Defenses, containment, and recovery

The table below is SSA editorial guidance, not a standard requirement or a measured effectiveness ranking.

| Control | Transition it interrupts | Applicability | Residual risk and verification | | --- | --- | --- | --- | | Trust-gated configuration load | File content executing or being read as instruction before the user opts in | Any agent reading repository-local configuration, hooks, or startup manifests | Users can still accept trust on an unreviewed repository; pair with scanning below. | | Provenance-aware review for configuration files specifically | Poisoned content merging unnoticed inside an otherwise ordinary pull request | Teams using version-controlled instruction or rules files | Requires reviewers to treat these files as security-relevant; test against content buried past normal attention span. | | Automated hidden-character and invisible-Unicode scanning | Obfuscated payloads passing human visual review | CI pipelines, pull-request bots, editors | Catches known obfuscation only; a plain-text payload hidden by burial still passes. | | Separation of execution-granting settings from style guidance | A single poisoned file gaining both instruction influence and code execution | Products supporting hooks or auto-approved tool and server configuration | Limits the execution channel's blast radius, not the instruction-influence channel itself. | | Periodic re-scan of already-trusted repositories | A file clean at trust time being modified afterward | Any agent that caches a trust decision across sessions | Depends on the re-scan running on a schedule; a stale trust cache behaves like no re-scan. |

Prevention should treat every auto-loaded configuration file with the scrutiny given to executable code, not documentation. Containment should suspend the file's influence, and any hook it defines, before investigating further, since deleting it alone does not undo actions already taken while it was live. Recovery should enumerate every clone that loaded the poisoned version and revalidate any resulting action or credential exposure.

Boundaries with similar concepts

Persistent memory injection uses an explicit memory-write tool call during a live session; this article uses a file already on disk before any session opens, though the two can chain. Shared state poisoning in multi-agent systems overlaps once the same repository is read by more than one agent, but covers runtime hand-off objects such as blackboards; this article covers version-controlled configuration, where commit history gives defenders an audit trail hand-offs usually lack.

Mapping to standards and research

| Source | Source-owned term or item | Relationship to this article | | --- | --- | --- | | Pillar Security (2025) | "Rules File Backdoor" | Original disclosure of AI code editor rules-file poisoning; direct evidence for this entry path. | | Phoenix Security (2026) | "TrapDoor" campaign | Real-world CLAUDE.md and `.cursorrules` poisoning against open-source repositories. | | Check Point Research (2026-02-25) | CVE-2025-59536; CVE-2026-21852 | Claude Code vulnerabilities where committed configuration executed or exfiltrated data before the user's trust decision. | | Anthropic Engineering | "How We Contain Claude" | Vendor account of the vulnerability class and the trust-gating fix, naming CLAUDE.md explicitly. | | Cloud Security Alliance (2026-05-06) | Agent context poisoning; SKILL.md | Evidence the auto-loaded-instruction-file pattern extends beyond one vendor's format. | | OWASP Agentic Top 10 2026 | `ASI01 Agent Goal Hijack` | Broader risk category for redirection of the agent's governing objective. | | MITRE ATLAS v2026.06 | `AML.T0051 LLM Prompt Injection`; `AML.T0051.001 Indirect` | Attacker-behavior classification; file-based delivery is an indirect variant. | | Agent State Attack | Instruction file poisoning | SSA descriptive phrase, not attributed to the sources above. |

Related terms

FAQ

Is this the same thing as the "Rules File Backdoor"?

Rules File Backdoor is Pillar Security's name for one documented technique against `.cursorrules` and Copilot instruction files. Instruction file poisoning is the broader SSA category covering that technique plus later cases like TrapDoor and any other auto-loaded configuration format with the same property.

Can removing CLAUDE.md, AGENTS.md, or .cursorrules eliminate the risk?

It removes this specific entry path, at the cost of the feature's utility, since the point of these files is durable guidance the agent does not need re-stated every session. Where teams keep the files, the more durable fix is gating when the file is parsed and executed on an explicit trust decision, and treating its contents as reviewable, security-relevant configuration rather than passive documentation.

Sources

Verification and change history

Standards and versions referenced: OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); MITRE ATLAS, data release v2026.06 (2026-06-30).

Last verified: 2026-08-14. Disclosure details, dates, and CVE identifiers were read from the source articles; the OWASP and MITRE identifiers were reused from this site's previously verified crosswalk entry.

Change history: 2026-08-14, initial defensive draft. Not scheduled for publication.

Working-term label: **Mixed provenance.** "Rules File Backdoor" and "TrapDoor" are industry terms coined by the disclosing researchers and reports (Pillar Security; Phoenix Security). `ASI01` and `AML.T0051` (with sub-technique `AML.T0051.001`) are Standard Terms owned by OWASP and MITRE. "Instruction file poisoning" is SSA descriptive wording, not a standard term.

This reference is defensive in scope. It classifies state changes and controls without publishing exploit recipes.

Back to the reference