Indirect Prompt Injection in AI Coding Tools: The Attack Your IDE Can’t See

TL;DR

• Indirect prompt injection is an attack in which an AI coding tool follows instructions planted by an attacker in some content the tool loads automatically, such as a  README, rules file, pull request description, or Model Context Protocol (MCP) server responses. It works because these tools process ingested context without distinction between system-executable instructions, user instructions, or passive data.
• Coding tools sit at the center of agentic AI risk: of 53 agentic projects tracked in OWASP’s State of Agentic AI Security and Governance report (v2.01, June 2026), 28 are coding agents.
• An attacker requires zero access to the developer’s interface or session, relying entirely on the agent automatically loading malicious text from an external file or dependency.
• Modern payloads bypass traditional security reviews by exploiting excluded file types like images, application programming interface (API) responses carrying hidden pull request comments, dynamic runtime URLs, and fragmented MCP schemas.
• The integrated development environment (IDE) shows the developer none of this: instruction files are trusted by design, and MCP responses and API payloads never render in the interface.
• Natural language has no reliable boundary between commands and data, making surface governance and privilege boundaries far more effective than semantic text filtering.
• Securing developer agents requires reviewing instruction files like .cursorrules as code, scoping agent credentials independently, restricting outbound network egress, and requiring human approval for system actions.

What is Indirect Prompt Injection in AI Coding Tools?

Indirect prompt injection is an attack in which an AI coding tool follows instructions an attacker has planted in content the tool loads automatically, such as a README, rules file, pull request description, or Model Context Protocol (MCP) server response. Modern AI coding assistants operate on a structural trust assumption inside the developer environment. To generate completions and execute tasks, an assistant automatically retrieves context across every accessible workspace surface – ingesting README files, repository configuration rules (.cursorrules, AGENT.md), pull request text, dependency manifests, and connected Model Context Protocol (MCP) server inputs.

The fundamental gap is that the assistant treats all ingested context as part of its primary instruction set rather than as untrusted data.

This is not a traditional software bug that can be patched; it is an AI prompt security problem. Large language models (LLMs) process system instructions, developer prompts, and external data as a single stream of tokens: there is no reliable way to mark some tokens as commands and others as data. Because whatever the model reads can shape the code it writes, the same gap runs through AI code security as a whole.

The operational consequence is direct. Write access to any surface an agent reads (whether via a pull request, a dependency update, or an MCP response) creates an open channel into the developer’s assistant, while the session looks completely routine to the user.

This exposure sits at the center of modern AI adoption. According to OWASP’s State of Agentic AI Security and Governance report (v2.01, June 2026), coding tools represent the main epicenter of autonomous AI risk: of 53 agentic projects tracked by OWASP, 28 are coding agents, and prompt injection maps directly to six of the ten entries in the OWASP Top 10 for Agentic Applications. 

Direct vs. Indirect Prompt Injection: A Strict Boundary

The baseline framework for prompt-layer risk is defined by OWASP LLM01:2025 Prompt Injection. The standard distinguishes two entry points:

• Direct Prompt Injection: An instruction typed directly into the system’s interface by the user to manipulate the model’s behavior.
• Indirect Prompt Injection: An instruction the model consumes from an external data source, such as a website, document, or repository file, that alters model behavior when processed.

This distinction creates a single critical operational difference: in an indirect prompt injection attack, the adversary never touches the victim’s interface and requires zero access to their active session.

Where Can Prompt Injection Enter a Coding Tool?

Modern agentic coding tools operate by parsing vast amounts of workspace context into their reasoning loops. However, because large language models cannot structurally separate system instructions from arbitrary data, every external text surface an agent reads becomes a potential execution channel. Attackers exploit this design by embedding hidden commands inside ordinary repository assets, bypassing traditional security controls long before code ever reaches production.

Surface	Who can write to it	How it reaches the agent	Why review misses it
Context and Rules Files	Any contributor whose pull request is merged	Loaded automatically at initialization as behavioral configuration	Renders as ordinary prose; invisible Unicode hides the payload
MCP Servers and Tool Descriptions	Whoever controls a registered server	Read as tool names, schemas, and return payloads before each call	Sits outside the repository, so no diff and no scanner path
Review Surfaces: Pull Requests, Issues, and Binary Assets	Anyone who can open a pull request	Returned verbatim by the platform API the review agent queries	Hidden in the web view, or excluded from review by file type

Context and Rules Files

The transition from simple code autocompletion to agentic workflows introduced dedicated instruction files such as CLAUDE.md, AGENTS.md, and .cursorrules. Designed to establish project-wide architectural constraints and coding conventions, these files are loaded automatically by coding tools at initialization and treated as system-level guidance.

Because they are intended to govern agent behavior by design, they are trusted implicitly by the tool and rarely scrutinized during code review. A pull request introducing a modified rules file arrives through normal contribution channels. Attackers can hide malicious directives within these files using zero-width joiners, bidirectional text control characters, or obscure Unicode strings, rendering the text invisible to human reviewers while remaining fully legible to the LLM. 

As detailed in the rules-file backdoor research, once a poisoned rules file is merged into a main branch, it persists across developer sessions and often survives into downstream forks.

MCP Servers and Tool Descriptions

A second-order injection surface exists within the Model Context Protocol (MCP) ecosystem. To determine which external functions to execute, an agent queries a connected MCP server for available tool names, parameter schemas, and dynamic descriptions. The agent parses these descriptions as context to guide its next reasoning step.

This attack surface must be distinguished from tool poisoning. While tool poisoning alters a tool’s underlying logic or source code, an MCP prompt injection uses the tool’s description or return payload as a delivery mechanism for raw text commands. Because an MCP server registered by a developer persists across multiple integrated development environment (IDE) sessions, a single malicious payload (or an instruction fragmented across several server responses) can silently alter model behavior without triggering traditional payload scanners.

For a foundational analysis of the protocol layer, see OX Security’s MCP security baseline.

Review Surfaces: Pull Requests, Issues, and Binary Assets

Indirect prompt injection can also bypass the pull request review process entirely by targeting surfaces that human reviewers skip.

For example, an attacker can embed instruction overrides inside HTML comments within a pull request description. Web interfaces render these comments as invisible whitespace, but the Git platform’s underlying API returns the raw markdown string verbatim when an automated review agent fetches pull request metadata. Similarly, review workflows frequently ignore image uploads or binary assets. 

As demonstrated by the Ghostcommit image-asset vector, an attacker can render prompt injection instructions inside a standard PNG file referenced by a documentation index. When an AI review agent processes the pull request, it parses the image, follows the embedded instructions, and executes actions using the reviewer’s elevated privileges.

Documentation and Dependency Metadata

The widest attack surface sits furthest from the primary repository. Modern agents frequently retrieve external documentation, fetch issue tracker descriptions, inspect open-source package manifests (such as PyPI or npm metadata), and parse remote setup instructions during routine development.

This introduces transitive and runtime injection risks:

• Transitive Injection: The malicious instruction does not reside in the primary codebase, but in an external dependency’s changelog, README, or registry metadata pulled dynamically by the agent.
• Runtime Resolution: The setup command or URL referenced in the repository appears entirely benign as written. The string resolves to its actual execution payload only when fetched dynamically at runtime, bypassing static analysis engines and manual code reviews.

As highlighted in Mozilla’s warning on indirect prompt injection, any instruction executed via these surfaces inherits the full ambient authority of the agent’s execution environment, including access to local configuration files, environment variables, API keys, and terminal execution privileges.

Real Incidents and Proofs of Concept

While theoretical models of prompt injection focus on conversational edge cases, real-world exploitation in developer tooling demonstrates a direct progression from context manipulation to full system compromise. The following cases illustrate the escalating operational reach of indirect prompt injection in coding environments.

In-the-Wild Context Hijacking

In April 2026, researcher Mayur Sewani documented ten indirect prompt injection payloads observed operating in the wild, establishing that the threat vector had transitioned from theoretical research to active exploitation. Embedded across public web assets and external documentation, the set targeted agents that browse, summarize, and index web content, with one payload aimed specifically at assistants embedded in IDEs, terminal environments, and DevOps pipelines, and others instructing an agent to hand over any API key it could reach.

System-Level Command Execution: CVE-2025-53773

In August 2025, CVE-2025-53773, rated 7.8 high on the Common Vulnerability Scoring System (CVSS), established that indirect prompt injection can escalate directly to remote code execution (RCE). The exploit manipulated GitHub Copilot and Visual Studio into modifying local configuration settings to disable user confirmation prompts, allowing the agent to execute arbitrary shell commands directly on the developer’s workstation. Microsoft confirmed the report and shipped the fix in its August 2025 Patch Tuesday release.

Reviewer Credential Inheritance in Azure DevOps

In July 2026, Manifold Security disclosed a zero-day flaw in Microsoft’s official Azure DevOps Model Context Protocol (MCP) server, establishing that pull request reviews can be weaponized against the reviewer. An attacker embedded instructions inside hidden HTML comments in a PR description, which passed directly through the un-spotlighted MCP tool into the reviewing agent. Operating with the reviewer’s elevated credentials, the agent triggered unauthorized pipelines and exfiltrated confidential wiki pages from projects the attacker could not access. The flaw carried no CVE and no fix had shipped at disclosure, and Microsoft advised organizations to review pull request content before asking an AI tool to act on it.

Evasion Techniques: Ghostcommit and GhostSplice

Across two disclosures in 2026, the University of Missouri-Kansas City’s ASSET Research Group published Ghostcommit and, in August, GhostSplice, establishing that instruction payloads can pass static inspection tools and model-side filters intact. Ghostcommit embedded commands inside image assets to exfiltrate .env secrets as integer constants that bypassed secret scanners, while GhostSplice fragmented an instruction across multiple MCP tool exchanges so no single fragment triggered security rules. While Claude Code refused the Ghostcommit instruction where other models complied, the researchers proved that model-level refusal is inconsistent and cannot substitute for structural data isolation.

From Context Injection to Transport-Layer Takeover

Indirect prompt injection can also be the way into a deeper, transport-layer flaw. Separate research by OX Security into the STDIO communication layer of the Model Context Protocol revealed unauthenticated command injection and server takeover flaws across major frameworks – including FastMCP, Agno, Letta, LangFlow, Flowise, and Windsurf. Disclosed through coordinated reporting, maintainers characterized the underlying behavior as by-design due to the protocol’s reliance on unvalidated local process boundaries. 

The flaw sits in the transport layer, but OX’s research found that indirect prompt injection is how an attacker reaches it from inside an IDE. In Windsurf (CVE-2026-30615), attacker-controlled HTML led the tool to rewrite its local MCP configuration and register a malicious STDIO server, executing commands with no further user interaction. OX’s disclosure lists Cursor, VS Code, Claude Code, and Gemini-CLI as vulnerable too, with Windsurf the only zero-click case.

Can Indirect Prompt Injection Be Detected?

Evaluating detection capabilities requires a clear-eyed accounting of what modern security tooling can observe versus where its visibility breaks down.

Current AppSec and developer-environment tooling can effectively monitor physical surfaces and operational boundaries:

• Instruction File Diffing: Treating configuration files (.cursorrules, AGENT.md, CLAUDE.md) as code with strict linting rules and version-control tracking.
• Obfuscation Detection: Flagging invisible zero-width spaces, homoglyphs, and bidirectional Unicode control characters embedded within repository text.
• API Representation Aligning: Parsing and rendering the raw markdown returned by platform APIs (e.g. GitHub or Azure DevOps PR descriptions) so security tools inspect the exact token stream an agent ingests, rather than relying on sanitized web views.
• Expanding Asset Coverage: Bringing images and non-text binary files into automated review pipelines to detect embedded text payloads.
• MCP Inventorying: Discovering active local MCP servers, extracting their registered tool definitions, and logging schema changes across sessions.
• Runtime Behavior Logging: Recording agent tool invocations, shell command executions, and outbound network traffic originating from developer workstations.

The Four Core Blind Spots

Research in 2026 established four distinct evasion mechanisms, each specifically designed to bypass traditional detection controls:

1. Review Exclusion by File Type: Security pipelines commonly skip binary, media, or non-code assets (e.g. PNGs or SVGs), allowing embedded instructions to enter the agent’s context uninspected.
2. Interface Disconnect: Hidden comments or structural metadata remain unrendered in human web interfaces while passing directly into the agent’s context window via API responses.
3. Runtime Resolution: Setup instructions, script references, or URLs appear completely benign during static code analysis, resolving to malicious payloads only when executed dynamically at runtime.
4. Context Fragmentation: Attackers split an instruction across multiple MCP tool schemas, file fragments, or conversation turns, ensuring no single piece triggers a detection signature.

Underlying these blind spots is an unsolved computer science challenge: there is no general algorithmic solution for reliably separating command instructions from raw data in unstructured natural language.

Because an LLM evaluates incoming context semantically rather than syntactically, detection tooling cannot reliably infer whether a block of English text will be interpreted by the model as passive data or an imperative command. As a result, modern detection functions at the surface and infrastructure boundaries (monitoring file modifications, tool registrations, and execution events) rather than attempting to parse semantic intent.

How Can Engineering Teams Defend Against Prompt Injection?

Because semantic detection remains imperfect, engineering organizations must deploy a layered defense strategy. These controls prioritize operational boundaries to contain the impact of an injected instruction, even when the injection itself goes undetected.

• Govern Instruction Files as Code: Mandate strict code-review workflows and codeowner approvals for any modifications to .cursorrules, CLAUDE.md, AGENTS.md, or repository-level Copilot guidelines.
• Apply Explicit Structural Delimiters: Wrap untrusted external inputs (file contents, PR descriptions, web responses) inside explicit XML tags or Markdown delimiters before submitting them to the model, verifying that every integration tool path enforces this boundary consistently.
• Inventory and Gate MCP Server Additions: Establish an authorized registry of permitted MCP servers and tool configurations, requiring explicit security approval before developers can register new protocol endpoints.
• Treat External Setup Instructions as Untrusted Code: Enforce a policy that setup commands, script execution directives, or dependency additions found in repository documentation must be treated as unverified third-party binaries, regardless of whether an AI assistant recommends them.
• Scope Agent Credentials Independently: Decouple agent identities from individual developer accounts. Assign assistants scoped, task-specific credentials with minimal read/write access to internal services, repository APIs, and cloud resources.
• Enforce Human-in-the-Loop Confirmation: Mandate interactive human confirmation for high-impact agent tool calls; specifically, operations that write to disk, modify local configuration, execute shell commands, or initiate external network requests.
• Constrain Development Environment Egress: Restrict outbound network access from developer workstations and build environments, ensuring that unauthorized data exfiltration attempts fail at the network boundary even if an agent complies with an injected payload.

These controls hold firm even when an injected instruction successfully circumvents model-level safety filters, providing structural resilience against context-level attacks.

This threat vector maps directly to ASI06: Memory and Context Poisoning in the OWASP Top 10 for Agentic Applications. ASI06 formalizes the risk of adversaries manipulating an agent’s persistent memory, RAG pipelines, or retrieved workspace context to alter its autonomous execution paths.

Mapping engineering controls against the ASI06 baseline provides security teams with a validated benchmark for securing agentic workflows, context retrieval pipelines, and developer environments against memory and context corruption.

Common Mistakes and Limitations

Organizations attempting to secure AI-assisted developer workflows routinely fall into six operational traps:

1. Treating Rules Files as Configuration: Viewing .cursorrules, CLAUDE.md, or AGENTS.md as static configuration settings ignores their actual role. In an agentic tool, these files are part of the model’s executable prompt stream.
2. Assuming Diff Reviews Catch Injected Content: Standard peer reviews focus on code logic diffs. They routinely miss instruction files that render as benign prose, ignore HTML comments unrendered in web interfaces, and skip non-code binary assets entirely.
3. Unmonitored MCP Server Sprawl: Permitting developers to connect local MCP servers on an ad-hoc basis creates an uninventoried attack surface. Without continuous schema tracking, security teams cannot verify what tools an agent can access or what data an external server returns.
4. Over-Privileging Agent Credentials: Running agents under a developer’s full identity and access management (IAM) and system permissions to minimize setup friction grants the assistant excessive access. An injected prompt immediately inherits the developer’s complete read, write, and network privileges.
5. Mistaking Model Refusal for Comprehensive Coverage: Assuming that a model’s safety filters provide complete protection is a dangerous posture. Compliance varies significantly across different LLM architectures, prompt structures, and context lengths.
6. Over-Relying on Model-Side Guardrails: Deploying prompt-filtering guardrails reduces the statistical frequency of successful injections, but it does not close the underlying vulnerability class. So long as the model evaluates untrusted data and system instructions within the same token stream, the attack vector remains open.

The OX Security Angle: Governing the Connected AI Stack

As developer environments transition from manual code composition to agentic synthesis, security posture depends entirely on governing the AI stack that developers assemble. Tools, MCP servers, local skills, third-party packages, and underlying models form an interconnected execution graph. Because an indirect prompt injection attack executes through whichever surface has been connected to the agent’s context, security teams must maintain real-time visibility and control across the entire developer ecosystem.

OX VibeSec addresses this exposure by extending governance directly to the prompt boundary and agent environment. Rather than relying solely on post-commit pipeline scans, it identifies and controls every component of that stack (MCP servers, external SaaS, models, and AI users) and applies user-based permissions to the coding tools and agents a developer can reach. By maintaining continuous, granular visibility into agent activity and its impacts, OX keeps every connected tool and agent action accounted for, so an injected instruction has less to reach and less authority when it arrives. At runtime, VibeSec security hooks analyze changes to sensitive files in real time. They block edits matching a dangerous MCP execution pattern before they reach disk, preventing the same technique used in the CVE-2026-30615 exploit.

Securing the Execution Boundary

Indirect prompt injection in AI coding tools works because large language models cannot structurally distinguish imperative instructions from passive data. When an assistant automatically ingests repository context (whether from README files, pull request metadata, dependency manifests, or MCP server responses), every untrusted text surface becomes an execution vector into the developer’s environment.

Because natural language offers no universal mechanism for filtering intent, attempting to solve this problem by inspecting semantics alone is a failing strategy. The true defensible boundary is not what the text says, but what the agent is allowed to load and allowed to do. Securing agentic workflows requires governing the connected AI stack: inventorying instruction files and MCP tools, enforcing strict structural delimiters, stripping excessive credentials, and requiring explicit human gating for high-impact actions.

To learn how your organization can govern agentic permissions, defend developer workstations, and secure AI-driven pipelines against prompt-layer exploitation, schedule a demo with an OX Security expert.