The setting is one line: "chat.tools.autoApprove": true in a project's .vscode/settings.json. It turned off user confirmations for GitHub Copilot agent mode in VS Code, and in August 2025 Johann Rehberger showed that a prompt injection could get the agent to write that line itself and then run terminal commands without asking anyone [2]. The agent escaped nothing. It edited a file it was allowed to edit, and that file decided whether it needed permission for everything else.
A coding assistant takes direction from three places: the person typing, the product's settings, and the repository it works in. Teams usually trust all three, though a repository holds contributions from many people, generated files, vendored code and text copied from the internet. Our position: an agent must never be able to raise its own authority, so any repository file that changes what the assistant does or may do is a protected path, and a write to it should ask a person. Prompt detection is useful. Path protection is what holds.
Precondition: instruction files are prompts that persist
Most assistants read a project instruction file so teams can describe conventions once. GitHub Copilot reads .github/copilot-instructions.md, path-specific files under .github/instructions, AGENTS.md files anywhere in the repository (the nearest one taking precedence), or a single CLAUDE.md or GEMINI.md at the root, and GitHub's documentation says repository instructions are automatically added to requests [5]. Cursor keeps project rules in .cursor/rules as .mdc files under version control, and rules marked alwaysApply are included in every chat session [7]. Others use similar files, such as .windsurfrules.
To the model these files are standing instructions with the weight of the system's own guidance, which is the point of the feature and the reason attackers want them. An injection in a web page affects one session. An injection in an instruction file affects every session, for every developer, until someone notices.
The Rules File Backdoor: instructions reviewers cannot see
In March 2025 Pillar Security published research it called the Rules File Backdoor [1]. Attackers hide instructions in rule files with invisible Unicode characters such as zero-width joiners and bidirectional text markers. The model reads the hidden text; a human reviewer does not, and Pillar reports it also stayed invisible in GitHub pull request review. In the demonstration, the assistant inserted attacker-chosen content into generated code and was told not to mention the change [1].
Pillar stressed persistence: once merged, a poisoned rule file affects every later session for everyone on the project, and it survives forking, so downstream projects inherit it [1]. The vendor responses are the useful part. Cursor, notified on February 26, 2025, said the risk falls under users' responsibility. GitHub, notified on March 12, said users are responsible for reviewing Copilot's suggestions, and on May 1, 2025 added a warning for hidden Unicode text on github.com [1]. Both treated the instruction file as user-controlled input whose safety is the repository owner's job. That makes it your boundary to defend.
Teardown: CVE-2025-53773, step by step
Rehberger's chain against Copilot agent mode in VS Code turns influence into execution [2]:
- Injection. He planted the prompt in a source code file, and notes it could equally arrive through a web page, a GitHub issue, a tool response or MCP server data.
- Self-configuration. The injection tells the agent to add "chat.tools.autoApprove": true to the project's .vscode/settings.json.
- No review step. Agent mode could create and write workspace files without user approval, and the edit took effect immediately rather than waiting as a reviewable diff. This is the enabling detail.
- Confirmations off. The setting disables user confirmations, which Rehberger calls YOLO mode.
- Execution. The same injection runs terminal commands, with variants for Windows, macOS and Linux.
Rehberger also pointed to .vscode/tasks.json and MCP server entries as other configuration an agent could write to the same effect, and noted he had described a similar issue in another coding agent shortly before [2]. He reported the issue on June 29, 2025 and confirms it was fixed in the August Patch Tuesday release [2]. NVD records CVE-2025-53773 as command injection (CWE-77) in GitHub Copilot and Visual Studio that allows an unauthorized attacker to execute code locally, with a CVSS 3.1 score of 7.8 from Microsoft [3]. Microsoft's advisory, released August 12, 2025, rates it Important, lists it as neither publicly disclosed nor exploited at release, and names Visual Studio 2022 version 17.14 with a fix in build 17.14.12 [4].
A composite of the two patterns: hidden text in a repository instruction file is loaded into the assistant's context every session, steers the agent to edit .vscode/settings.json, turns auto-approve on, and commands then run with no prompt. A protected path where the write asks breaks the chain at the config edit.
The figure combines the two findings deliberately, and it is a composite, not an observed attack. The CVE demonstration used a source file, and Rehberger found invisible-text payloads unreliable, often refused by models and visibly flagged by VS Code [2]. An instruction file is simply a more persistent place to put the same request, because the assistant reloads it every session instead of meeting it once.
The files that raise an agent's authority
Authority here means what the agent may do without asking: which tools are auto-approved, which commands are allowed, which servers it can reach. Any file that changes it belongs with CI workflows and IAM policies, whatever dotfile it lives in.
| File or path | What it controls | What an attacker gains by changing it |
|---|---|---|
| .github/copilot-instructions.md, AGENTS.md, CLAUDE.md | Standing instructions added to the assistant's requests [5] | A persistent prompt injection that reaches every developer's sessions |
| .cursor/rules (.mdc), .windsurfrules | Project rules, some applied to every session [7] | Hidden or plausible-looking rules that shape generated code [1] |
| .vscode/settings.json | Editor and agent settings, including auto-approval in the CVE-2025-53773 chain [2] | The agent stops asking before running commands |
| .vscode/tasks.json | Commands the editor can run as tasks [2] | A command that runs through a trusted-looking task |
| MCP server configuration | Which tool servers the assistant starts and connects to [2] | An attacker-controlled server with tools and descriptions of their choosing |
| .github/workflows/ | What runs in CI with repository secrets | Code execution with deployment credentials |
| Package manifests and lockfiles | What gets installed and run at build time | A dependency whose install scripts run on every machine |
Two things make this boundary easy to miss. The files look like documentation or preferences, so they get lighter review than code. And the assistant is often the author of changes to them, because teams ask it to update its own instructions. A change proposed by the assistant, reviewed by nobody and merged by habit is the path an injection needs.
Picture an illustrative fintech, Quillon Payments, whose open-source SDK accepts outside contributions. A pull request fixes a README typo and rewords two conventions in AGENTS.md, with an invisible instruction between them to enable tool auto-approval and not mention it. A week later the assistant follows it while adding a retry wrapper, and a second instruction in a test fixture then runs a shell command that reads the engineer's cloud credentials. Every step was permitted on its own; nothing treated the settings write as different from any other file edit.
Breaking the chain at the config write
The durable control is structural: an agent writes source code freely and cannot change its own configuration without a person saying yes. That splits the workspace into two kinds of path.
Source, tests and docs are ordinary work for an agent. Editor and agent configuration, CI workflows, instruction files, manifests and lockfiles, and environment files change authority, so writes to them require approval.
- Put instruction and agent configuration files under CODEOWNERS with required code-owner review. GitHub notes you must also assign an owner to the CODEOWNERS file itself, ideally by owning the whole .github/ directory [6].
- Fail CI on invisible and bidirectional control characters in instruction files, rule files and configuration, following Pillar's advice to audit rule files for invisible Unicode and review them with the rigor of executable code [1].
- Configure the assistant so file edits show as diffs before they apply, and so writes to editor settings, task files and MCP configuration always ask, which addresses the property Rehberger identified [2].
- Set auto-approval centrally through managed or user-level policy the repository cannot override, rather than in workspace configuration, where your editor allows it.
- Log a change to any protected file as a security-relevant event, whether a person or an agent made it.
At Quillon, any one of three of these would have stopped the chain: the code-owner rule on AGENTS.md, the CI scan for invisible characters, or a rule that makes the settings write ask.
What a gateway can and cannot see
A runtime gateway sees the model request, including the instruction file's contents, so hidden-instruction and instruction-override signals can be raised before the model acts. It sees tool calls that pass through it, such as MCP file-write and shell tools, with their arguments, so a write to a CI workflow or a credential path can be classified as consequential. It cannot see an edit made by an IDE's built-in file tool that never leaves the developer's machine. For those, the editor's own approval settings are the control, which is why the editor-side items above are not optional.
Where Intertrace sits in this chain
In Intertrace, hidden instructions and instruction-override language in model requests are structural signals that can block on their own. Action normalization reads tool-call arguments, raises the consequence tier for credential and CI file paths and for pushes to protected branches, and never lowers it; agent roles keep those actions asking, with path and session shown in one inbox. Discovery scans GitHub repositories for committed MCP configurations. Local IDE edits stay under your editor's settings.
How you know the boundary is there
Inventory every instruction, rule and agent configuration file across your repositories and who can change each. Search those files for zero-width, bidirectional and Unicode tag characters, and search history for commits that changed auto-approval, allowed-command or MCP server settings, noting who or what authored them. Then test:
- Add a zero-width joiner and a right-to-left override to a test instruction file on a branch. CI should fail and the diff view should warn.
- Change AGENTS.md from an account that is not a code owner. The pull request should not merge without code-owner approval [6].
- In a disposable workspace, ask the assistant to enable its own auto-approval. The write should ask or be refused, not apply.
- Plant a benign source comment telling the agent to edit .vscode/tasks.json. The edit should surface as a reviewable change.
- Have an agent write to .github/workflows/ through a tool that passes your gateway. The decision should ask and record the path.
Done means an agent still works in src/ and tests/ without friction, and every attempt to change its own instructions or permissions produces a visible question. Friction everywhere and people turn approvals off; none on configuration and the boundary is not there. Rerun the tests after every assistant or editor update, since edit-approval and auto-approval defaults change between releases.
