Summary
- A prompt injection technique targeting AI coding assistants has been observed in the wild, exploiting how these agents read and act on local instruction files.
- The attack blurs the boundary between passive text documents and executable actions, allowing malicious content to redirect agent behaviour.
- Coding assistants that automatically consume files such as project-level instruction or configuration documents are particularly exposed.
- The technique requires no special privileges — an attacker needs only to place or influence a file the AI agent will read.
- Security teams should treat AI agent instruction files as a trust boundary and apply appropriate controls.
What is happening
A prompt injection technique targeting AI coding assistants has been confirmed active in the wild. The attack works by embedding malicious instructions inside local files — including markdown documents — that AI agents are configured to read as part of their normal operation. When the agent consumes the file, it treats the injected content as legitimate instruction and acts accordingly, without any indication to the developer that something has gone wrong.
Why coding assistants are the target
Modern AI coding assistants are designed to be context-aware. They read project files, pick up on repository-level instructions, and act on guidance found in configuration or documentation files to tailor their responses. This design choice — useful in legitimate workflows — becomes a liability when an attacker can influence what those files contain. The agent has no reliable way to distinguish between instructions placed there by a trusted developer and instructions planted by an adversary.
The trust problem at the centre of this attack
The core issue is that AI agents extend an implicit level of trust to the local file system. A markdown file, which most users and tools treat as inert text, is interpreted by these agents as something closer to a directive. That gap between human expectation and agent behaviour is exactly what this technique exploits. The attack does not require the agent to be misconfigured in any obvious sense — it is working as designed, which makes the problem structurally difficult to resolve through simple patching.
How exposure arises in practice
The attack surface is broader than it might initially appear. Any environment where developers use AI coding assistants against codebases that include externally sourced files, open-source dependencies, cloned repositories, or shared project workspaces is potentially exposed. An attacker who can introduce a file into that environment — through a pull request, a dependency, a shared template, or social engineering — has a plausible path to influencing agent behaviour. The attack does not require the developer to open or read the malicious file themselves; the agent does that work on their behalf.
What the sources do and do not tell us
The reporting from Dark Reading confirms this technique has been observed in active use, not merely as a theoretical proof of concept. However, the sources do not detail the specific AI coding assistant products confirmed to be affected, the full range of actions an injected instruction can cause an agent to take, or whether any vendor patches are currently available. Those gaps are worth noting when assessing your own exposure and in conversations with AI tooling vendors.
Why it matters
AI coding assistants are now embedded in developer workflows across the majority of software teams, including those building or maintaining security-critical systems. If an adversary can redirect agent behaviour through a planted file, the consequences could include exfiltration of code or credentials, introduction of malicious code into a build pipeline, or manipulation of developer output in ways that are difficult to detect after the fact. This is not a hypothetical extension of prompt injection theory — it has been seen in the wild. CISOs should be asking their engineering and platform teams which AI coding tools are in use, what files those tools are permitted to read, and what controls exist over the content of those files. The attack requires no elevated access and leaves no obvious footprint for the developer, which makes it particularly relevant from a detection and insider-threat-analogue perspective.
What to do now
- Inventory which AI coding assistants are in use across your development teams and understand which local and project-level files each tool is configured to read automatically.
- Treat AI agent instruction files — including markdown configuration and project-level prompt files — as a trust boundary, and apply the same scrutiny to their contents as you would to executable code.
- Review controls over who can introduce files into codebases and shared repositories that developer AI tools will consume, including via pull requests and third-party dependencies.
- Raise the issue with your AI tooling vendors to understand their current mitigations, roadmap for addressing instruction-file trust, and whether affected versions have been identified.
- Brief development leads and security champions on the technique so they can identify anomalous agent behaviour and understand the risk of working with externally sourced repositories while AI coding assistants are active.
