Prompt Injection via Workspace Content in AI IDE Agents

AI IDE agents read files, comments, dependency trees, and configs as part of the normal job of being useful. That reading is exactly where attackers get in: any workspace content the agent processes is a place to plant instructions, and the agent has no reliable way to tell a command from its actual user apart from a command hidden in a README written by someone else entirely. Treating documentation as inert is the mistake at the center of nearly every incident described below, and it's worth saying plainly: the agent doesn't know the difference between a file and an order, and neither does anyone who assumes it does.

Large language models are instruction-followers by design. Feed one a command in plain language and it will try to carry that command out, no matter where the command came from. The model doesn't check a source field before acting; it sees tokens in a context window and responds to what those tokens say. A system prompt, a user's typed request, a code comment, and a line in a dependency's changelog all land in the same window, processed the same way. Nothing in the architecture marks one as "trusted operator" and another as "arbitrary text found on disk."

IDE agents make this worse because their whole value depends on reading widely. An agent that can't parse a README, follow a dependency tree, or read inline comments isn't useful for real development work. So by design, these agents treat file content, package metadata, and configuration as trusted input, because reading that material is the job. The developer assumes the only voice giving the agent orders is their own prompt. In practice, though, the agent takes direction from anything sitting in its context, and the developer usually has no idea that a comment three files deep just told the agent to do something else entirely.

Security researchers split prompt injection into two categories: direct, where the attacker controls the prompt itself, and indirect, where the attacker plants instructions somewhere the target system will read during ordinary operation. IDE attacks are almost entirely the indirect kind. Nobody tricks the developer into typing a malicious command; instead, the developer opens a repository, runs a routine task, or installs a package, and the attack rides in on content the agent was going to read anyway.

Traditional security tooling wasn't built for this. Antivirus software, network monitoring, endpoint detection: all of it watches binaries, processes, and network traffic. None of it parses the plain-language content of a README or a code comment for buried commands, because until recently, no one needed it to. IDEs sat in the category of productivity tools, not execution surfaces. That category no longer holds once the IDE is running an agent with shell access and file-write permissions.

The specific workspace surfaces an IDE agent reads and can be poisoned

Start with README files and repository metadata, since they're the first thing an agent reads to understand a project. That's the point: an attacker who controls a public README can bury commands that read like project documentation but function as instructions. One documented case had a malicious README tell the agent to create a .cursor/mcp.json file and write attacker-controlled commands into it, including a reverse shell, all framed as normal project setup.

Dependency documentation is a second surface, and arguably the more dangerous one, because the attacker doesn't need access to the developer's repository at all. Agents parse changelogs, bundled README files, and inline documentation from installed libraries as a matter of course. Publish a malicious package, or compromise an existing one, and every developer who installs it hands the agent a document written by the attacker.

Code comments work the same way at a smaller scale. Agents read comments to infer intent and write contextually appropriate code, which means any comment block in any file the agent opens is a candidate for a buried instruction. There's no visual difference between a comment explaining a function and a comment telling the agent to exfiltrate an environment variable.

MCP, the Model Context Protocol, configuration files raise the stakes further, because these files define which tools and outside servers the agent can invoke. Poison one, and the attacker isn't just injecting a single instruction; they're reconfiguring what the agent can do going forward. Cursor's trust model compounds this: the IDE uses a one-time, name-based approval, so once a user approves an MCP server by name, that name keeps its trusted status permanently, even if the commands tied to that name change later. That's the mechanism behind CVE-2025-54136, known as MCPoison.

Extension configuration and skill files loaded at the start of a session stretch the same problem across the whole working period. Research on so-called skill-injection attacks describes these as persistent rather than one-time: a poisoned skill file loaded once can shape agent behavior across every later interaction in that session, not just the moment it's read.

CI/CD pipelines close the loop. Once an agent is wired into GitHub Actions or a similar system, issue bodies and pull-request descriptions become injection surfaces too. An attacker who once needed write access to a trusted repository now needs only the ability to open a pull request, which any free GitHub account can do.

The thread running through all of it: every one of these surfaces is something the agent reads as part of its intended, designed job. There's no anomaly at the moment of reading. The file looks like a file, and the comment looks like a comment. Detection has to happen somewhere other than the read itself, because the read is supposed to happen.

What a successful workspace injection actually does — the action layer

Agents don't stop at generating text. They call tools, write files, run shell commands, hit outside APIs, and in many setups, handle credentials directly. Research on agentic systems has found that AI agents move far more data than human users doing comparable tasks — reportedly sixteen times as much — which changes the scale of what a single compromise means: this isn't a leaked password from one account, it's a bulk data-exposure event triggered by one poisoned instruction.

The categories of injected action break down cleanly, and it's worth naming each one instead of waving at "malicious behavior" as a blur. Arbitrary code execution, where the agent writes and runs code nobody asked for. Credential harvesting, where the agent pulls secrets from environment variables or config files and sends them somewhere it shouldn't. Persistence installation, where the agent writes malicious MCP configs or scripts meant to outlive the current session. Supply-chain propagation, where the agent commits poisoned code to repositories the developer has push access to, spreading the compromise to everyone downstream.

Then there's outright environment destruction. The Amazon Kiro incident, where an agent with autonomous access to a live AWS environment issued destructive infrastructure commands that deleted and then rebuilt the environment, produced a thirteen-hour outage.

Developers are usually sitting right there watching the agent work, yet that doesn't help as much as it should. Agents move faster than a human can review each step, and approval fatigue sets in fast: after the tenth confirmation dialog in an hour, most people click through without reading closely. The more autonomy an agent gets, the larger the blast radius of a single injected instruction, and that relationship isn't linear so much as multiplicative. Give an agent broader tool access and risk doesn't just add up, it compounds, because every new capability is another action a hijacked instruction can trigger.

Documented attacks against production IDE agents in 2025 and 2026

A coordinated disclosure in December 2025 surfaced more than thirty vulnerabilities across multiple AI coding platforms, resulting in twenty-four CVEs affecting Cursor, Roo Code, JetBrains Junie, and GitHub Copilot. That's not a handful of isolated bugs; it's a pattern across the industry's major agent products, disclosed at once, and it should read as an indictment of the category rather than of any single vendor.

Cursor drew two of the more instructive cases. CVE-2025-54135, nicknamed CurXecute, showed that prompt injection through workspace content could trigger arbitrary command execution without the user noticing anything unusual. CVE-2025-54136, MCPoison, exploited the one-time, name-based trust model described above: approve an MCP config by name once, and Cursor never asks again, even after the commands behind that name change. MCPoison matters because it shows the trust architecture itself, not just malicious content sitting in a file, is the attack surface.

GitHub Copilot had its own remote code execution case, CVE-2025-53773, where attacker-controlled content in project files, dependency documentation, and repository metadata got the agent to run arbitrary shell commands during what looked like routine coding work. Researchers testing Copilot, Cursor, and Claude Code found attack success rates between fifty and eighty percent across model families in these scenarios. That's not a marginal failure rate; it's closer to a coin flip landing in the attacker's favor most of the time.

The MCP supply chain produced its own case study with the postmark-mcp package. It shipped fifteen clean releases before a later update quietly added code that exfiltrated email content. Fifteen clean releases is enough to build a solid reputation with any review process based on version history, and agents granted email-sending capability through that package silently forwarded correspondence to a hidden attacker-controlled address.

The NX CLI incident in August 2025 showed how far the injection surface stretches once CI/CD gets involved. A misconfigured GitHub Actions workflow was compromised, and the attacker turned local AI developer tools, including Claude, Gemini, and Amazon Q, into scanners hunting for secrets across affected systems. The pipeline wasn't a separate concern from the workspace; it was an extension of it.

GitHub Copilot also figured in a documented 2025 incident where contents from more than twenty thousand private repositories belonging to major enterprises got exposed in a single event. Across every one of these incidents, the pattern repeats: a developer did something completely ordinary, opened a repo, ran a task, installed a package, and the attack simply rode along on that ordinary action.

Why attack success rates stay high even when defenses are applied

Google's work on Gemini offers the clearest data point here: after applying the strongest available defenses, including adversarial fine-tuning, the most effective attack technique tested still succeeded 53.6% of the time. That's after the best-known mitigation, not before it, and it should settle any argument that this is a problem defenses can simply out-engineer.

The underlying reason is structural, not a matter of effort. LLMs cannot structurally tell instructions apart from data; both arrive as the same kind of token sequence, run through the same mechanism. Model-level defenses can lower the odds that the model obeys a buried instruction, but they can't drive that probability to zero, because there's no architectural seam to enforce a hard boundary between "command" and "content."

Attack success also scales with how many times an attacker is willing to try. Indirect prompt injection against Claude Opus 4.5 succeeded 4.7% of the time on a single attempt, climbed to 33.6% at ten attempts, and reached 63.0% at one hundred attempts. Automated attackers don't get tired and don't need to sleep; they iterate through attempts far faster than any human defender can review logs and spot a pattern forming.

Jailbreak data from production deployments tells a similar story. Roughly one in five jailbreak attempts succeeds in assessed environments, and the average successful attack takes about forty-two seconds across five interactions, well under the time it takes a human reviewer to notice something's wrong and step in.

Only 34.7% of organizations have deployed dedicated defenses against prompt injection specifically, which means most IDE agent deployments right now lean on the model's own built-in behavior as the sole line of defense. Defenses tuned to catch known attack patterns tend to fail against novel payloads they weren't trained on, while defenses aggressive enough to sanitize inputs broadly risk breaking legitimate developer workflows in the process, which is its own kind of failure.

Benchmark results back this up at scale. Evaluations of leading models in realistic multi-tool scenarios have found attack success rates in the same range, not contrived edge cases built to make a point. The conclusion that follows isn't comfortable, but it's the honest one: a defense's existence proves nothing. Only testing whether a specific attack still works after the defense goes in proves anything, and most teams skip that step.

The specific properties of workspace injection that make it harder to catch than other injection types

Workspace injection has a few properties that set it apart from injection aimed at a chatbot's direct input field, and each one makes detection genuinely harder, not just marginally so.

The attacker needs no access whatsoever to the developer's machine or accounts. All that's required is the ability to place content somewhere the agent will eventually read it: a public repository, a package registry, a GitHub issue. That's a much lower bar than stealing credentials or breaching a network perimeter, and it's the reason this attack class scales the way it does.

Workspace content is also supposed to be full of instructions, which is exactly what makes this category so hard to filter. Comments tell the agent what code is meant to do. READMEs tell it how to build and run a project, and configuration files tell it which tools to use. Legitimate content and a malicious payload are structurally identical text; there's no syntactic marker separating "this comment explains the function" from "this comment tells the agent to leak a secret."

Persistence adds another layer. MCP configs and skill files loaded once at startup carry their effects into every later action the agent takes during that session, so this is never a single-turn problem the way a one-off jailbreak attempt might be.

Trust inheritance compounds all of it. Once a developer approves a tool, a config, or a package, later changes to that same tool, config, or package often inherit the original approval automatically, no questions asked. The MCPoison pattern isn't unique to Cursor; it's a design choice that scales to any system built around persistent trust grants rather than re-verification.

Supply chains add depth on top of that. The malicious instruction might sit several hops away from the developer: buried in a transitive dependency's documentation, inside a GitHub Action that a dependency happens to use, or recommended inside an MCP server that a popular tutorial links to. Research from Cornell found that 8.5% of VS Code extensions expose credential-theft risks, which adds an entire pre-authenticated attack layer that loads before the developer has typed a single line of code.

Because agents run at machine speed, by the time a developer notices something looks off, the injected action has usually already finished running, and whatever evidence might have explained what happened may not be there to find anymore.

What a credible security posture for AI IDE agents actually requires

Any serious threat model for an AI IDE agent has to name workspace content explicitly as an attack surface. Every file type the agent reads, README, comment, config, changelog, needs to show up in the risk assessment on its own merits, not get waved through under an assumption of safety because it's "just documentation." Teams that still sort files into "code" and "docs" for security purposes are working from a distinction the agent itself doesn't recognize.

Minimal privilege matters more here than in most security contexts, because the fix is structural rather than behavioral. An agent that can only read files it was explicitly told to analyze can't be hijacked by a README it was never told to open in the first place. Shell execution, file-write permissions, and network calls should all be scoped to the narrowest range a given task actually needs, not the broadest range the platform allows.

MCP servers and extensions need governance that treats them like code, because that's what they are. Configs should be version-controlled and reviewed before they're loaded, not approved once by name and trusted forever. Revoking and re-approving on any change, rather than leaning on persistent name-based trust, closes the exact gap MCPoison exploited. Installed extensions deserve the same scrutiny against known risk patterns before they get agent access.

CI/CD pipelines need the same controls as the local workspace, not lighter ones. Issue bodies, pull-request descriptions, and workflow triggers are injection surfaces the moment an agent processes them. Pinning GitHub Actions to a specific commit hash rather than a mutable tag, and restricting which events can trigger an agent-enabled workflow, closes off a real chunk of the CI/CD surface described above.

None of this counts unless someone actually checks it. A safeguard applied to agent behavior has to be tested by running the real attack after the safeguard is in place, not declared effective because it exists on paper. Legitimate workflows also need to keep working after any control goes in; a safeguard that breaks real functionality gets disabled by frustrated developers within a week, which defeats the point of adding it in the first place. Coverage claims need their gaps named out loud, too. A team that believes it's covered without knowing exactly where it isn't is operating on false confidence, and false confidence is worse than knowing the gap is there.

Human review has to stay in the loop for any agent action that writes files, runs commands, or touches configuration. Cutting that review step to speed up automation also cuts the one check most likely to catch an injected action before it actually lands.

Cisco's 2026 State of AI Security report found that 83% of organizations plan to deploy agentic AI, but only 29% feel ready to do so securely. That fifty-four-point gap between intent and verified readiness isn't a footnote; it's the exact terrain where workspace injection attacks will keep finding purchase, for as long as deployment keeps outrunning the controls that would make it safe.