Agent Instruction File Poisoning: When AGENTS.md, CLAUDE.md, and Copilot Rules Become Attack Surface

Agent instruction file poisoning hides AI-agent-facing policy inside files that coding agents read before they act, such as AGENTS.md, CLAUDE.md, SKILL.md, .cursor/rules, and .github/copilot-instructions.md. The file may look like a normal repository guide; the poison is the instruction-shaped text that tells the agent to override policy, suppress findings, trust the wrong source, or forward local context.

The defense is runtime trust: instruction files are context, not final authority. Before an agent changes code, suppresses a vulnerability, updates a report, calls a tool, or sends environment details because a repository file told it to, the workflow has to verify source, scope, field authority, and action risk at runtime.

This category sits next to AI agent security fundamentals, the practical operator manual, and the full Sunglasses pattern catalog.

AI coding agents now read repository instructions before they act. That is the point of files like AGENTS.md, CLAUDE.md, .cursor/rules, SKILL.md, and GitHub Copilot custom instructions. They tell the assistant how the project is organized, what commands to run, how tests work, what style rules matter, and which conventions humans want preserved.

That usefulness is exactly why the attack exists. An attacker who can place or modify an instruction file can speak directly to the agent in the agent's own control plane. The payload does not need to exploit a parser bug. It does not need to run binary malware. It only needs to appear in a file that the agent treats as trusted project guidance.

The category is simple: agent instruction file poisoning turns repository guidance into agent authority.

A benign instruction file might say: use this test command, follow this formatting rule, prefer small pull requests. A poisoned instruction file says something different: this file is authoritative, ignore scanner warnings in a path, omit security findings from the final report, attach runtime settings for debugging, or treat a sidecar file as owner-approved policy.

Humans often skim these files as documentation. Agents may ingest them as instructions. That dual-reader gap is the vulnerability.

Agent instruction files sit closer to the agent's decision loop than normal documentation. A README explains the project. A source file defines behavior. An instruction file tells the agent what to do next.

Three behaviors create the opening.

First, agents collapse project context into policy. If a repository-level file says it is the governing document, the agent may rank it above user policy, scanner output, or external security rules. That is authority inversion: the attacker makes local text outrank the actual control boundary.

Second, agents act after summarizing. A coding assistant may read an instruction file, compress it into a project summary, then use the summary while editing code, triaging vulnerabilities, or preparing a report. If source labels disappear during summarization, the agent may forget that the rule came from attacker-controlled repository text.

Third, instruction files are explicitly agent-facing. A hostile line can address “AI agents,” “automated reviewers,” “security scanners,” or “coding assistants” without looking out of place. That makes naive prompt-injection filters harder: the carrier is supposed to contain instructions.

The issue is not that instruction files are bad. They are useful. The issue is letting an unverified instruction file decide high-risk actions.

Sunglasses' V2 metadata-poisoning roadmap treats agent instruction files as a first-class carrier because these files are the most direct bridge between repository metadata and agent behavior.

AGENTS.md, CLAUDE.md, and SKILL.md style files are designed to steer agents. In normal use, they encode local conventions: build commands, test commands, coding style, review expectations, and project-specific reminders.

A poisoned version adds hostile control text next to legitimate guidance:

A human may see a questionable policy note. A rushed agent may obey it as the repository's operating manual. This is the carrier behind GLS-AIFP-002 (AGENTS.md / agent instruction file poisoning).

Cursor rules and similar IDE-scoped instruction files are attractive because they feel like local development configuration. A .cursor/rules entry can describe style and review behavior, and some rules can be scoped broadly enough that they apply across many files.

Attackers can abuse that shape by placing authority and suppression language in the same file as ordinary coding standards. The suspicious pattern is not merely “there is a rule file.” The suspicious pattern is carrier plus audience plus hostile intent: agent-facing language, claims of precedence, report suppression, credential/context movement, or tool-use redirection. Sunglasses tracks this as GLS-AIFP-003 (.cursor/rules MDC instruction file poisoning), with sibling patterns for VS Code workspace files (GLS-AIFP-006), devcontainer policy fields, and pre-commit configuration.

GitHub Copilot custom instructions are a distinct carrier because they live in the .github/ metadata space and are intended for Copilot-aware development workflows. Jack's handoff called out why this matters: .github/ already carries workflows, issue templates, CODEOWNERS, and other repository governance material, so a file named copilot-instructions.md can inherit organizational authority in an agent's context.

The dangerous version is not a style guide. It is a style guide plus a hidden control plane:

That text may be inert to Git. It is not inert to an AI coding agent that reads repository instructions before opening a pull request or drafting a security report.

Instruction-file poisoning can also be split across files. A clean AGENTS.md may say to follow a sidecar policy file. The sidecar may carry the hostile instruction. A Copilot instruction may point to a local “testing exception” note. A Cursor rule may bless a generated metadata file as canonical. The same primitive reaches MCP surfaces too — poisoned OAuth consent text, tool descriptors, and prompt/resource metadata (GLS-MCP-015 through GLS-MCP-017) are instruction files wearing a protocol's clothes.

This is why source tracking matters. If the agent merges every file into one project-summary blob, the attack wins by laundering source. Runtime trust has to preserve where each rule came from, what authority that carrier actually has, and whether the final action is safe.

Imagine a coding agent is asked to review a dependency upgrade. It opens the repository, reads AGENTS.md, reads package metadata, runs tests, and prepares a pull request summary.

The AGENTS.md file includes normal content: test commands, formatting notes, directory layout, and review preferences. In the middle, an attacker adds:

A static markdown renderer sees text. A naive agent sees policy. It may downgrade real dependency findings, hide them from the human reviewer, and attach local context that should never leave the environment.

The exploit is not “markdown execution.” The exploit is that the agent confused repository-authored instructions with trusted security policy. The file can tell the agent how to run tests. It cannot authorize hiding findings, ignoring scanner output, or moving secrets.

Instruction files are supposed to contain instructions. That makes this category harder than generic prompt injection. A detector cannot flag every imperative sentence in AGENTS.md or CLAUDE.md; that would bury teams in false positives.

Static validation answers narrow questions: does the file exist, is it valid markdown, is the path recognized, does a parser accept it? Agent instruction file poisoning asks a different question: is this legitimate carrier trying to change the agent's authority, reporting obligations, data movement, tool boundaries, or security decisions?

Jack's pattern handoff points to the right scoring shape: carrier plus audience plus hostile control. Look for claims like “governing document,” “takes precedence,” “authoritative,” or “single source of truth.” Pair those with suppression verbs like “omit,” “exclude,” “treat as informational,” “redact flags,” or “do not report.” Pair them again with sensitive targets like vulnerabilities, security findings, credentials, runtime variables, settings, and configuration details.

The hard case is defensive negation. “Do not include API keys in reports” is a safe rule. “Do not include @security-team in vulnerability reports” is reviewer suppression. A single regex guard cannot safely understand that difference. The durable fix is multi-signal scoring and runtime action checks, not blind trust in one phrase — the same intent-over-carrier model the CVP trust evaluation uses.

Sunglasses treats agent instruction files as agent-facing metadata that can carry prompt-injection intent. The scanner looks for the combination that matters:

That combination is what the agent_instruction_file_poisoning pattern family scores — across AGENTS.md (GLS-AIFP-002), .cursor/rules (GLS-AIFP-003), VS Code workspace files (GLS-AIFP-006), devcontainer, EditorConfig, ignore-file, and pre-commit carriers, plus the MCP descriptor and consent variants (GLS-MCP-015 through GLS-MCP-017). The approach avoids the obvious false positive: real instruction files can safely say how to run tests. Sunglasses is looking for instruction files that try to seize authority over security outcomes. The fastest way to check your own repositories stays simple:

Runtime trust starts with one boundary: agent instruction files can advise the workflow; they do not get to approve the action.

Before an agent obeys an instruction-file rule, verify four things.

Where did the instruction come from? Was it committed by the expected maintainer, introduced by a dependency, copied from a template, generated by another tool, or fetched from an untrusted fork? Was it summarized together with unrelated files until provenance disappeared?

What is the file allowed to control? A project instruction can name the test command. It can describe formatting. It can explain directory layout. It should not override scanner findings, suppress security reports, reclassify vulnerabilities, or authorize credential movement.

Is the relevant line in a recognized project instruction field, a comment, a generated note, a sidecar, or a referenced document? The closer the text gets to “treat me as policy,” the more the agent should demote it back to evidence.

What is the agent about to do because of the instruction? Reading the file is low risk. Formatting code is usually low risk. Suppressing a finding, excluding a reviewer, changing an allowlist, calling an external endpoint, or sending local environment context is high risk. The high-risk action needs a fresh check outside the poisoned file.