Abstract
An AI coding agent is the highest-privilege agent most engineers run, and the least contained. It sits inside the developer trust boundary — the machine with the source, the cloud credentials, the SSH keys — and it can write files, edit configuration, and execute shell commands. It also, by design, reads content that attackers can influence: repository files, issues, pull-request comments, dependency code.
When those two facts meet, prompt injection stops being about leaked text and becomes remote code execution. We analyze three real 2025 disclosures, quantify the blast radius, and locate where the approval boundary must sit to survive an agent that moves faster than a human can supervise.
01A shell inside the trust boundary
Give a model a shell and untrusted input in the same session, and you have built a remote code execution primitive that the attacker triggers by writing a comment.
Traditional developer tooling is trusted because it does what the developer tells it. A coding agent breaks that assumption: it does what the current contexttells it, and the context includes files and comments authored by whoever contributed to the repository. The developer’s implicit trust in their own tools is silently extended to every author of every artifact the agent reads.
02Anatomy of a coding agent
A modern coding agent typically has four capability classes, each a distinct risk:
- File write — including the ability to modify its own configuration and the project’s tool settings.
- Command execution — a shell, often to run tests, builds, and package managers.
- Network / web — fetching docs, packages, or browsing, which doubles as an exfiltration channel.
- Tool/MCP integration — external servers that add capabilities and read paths.
The compounding risk is self-configuration. If an agent can write files, and its own approval behavior is governed by a file, then an injection that writes that file can disable the very control meant to stop it. This is the mechanism behind the most serious coding-agent disclosures — the agent is talked into escalating its own privileges.
03From injection to remote code execution
The path is short. (1) The agent ingests attacker-influenced content — a PR description, an issue, a code comment, a README, or the output of a tool. (2) That content carries an instruction. (3) The agent, unable to distinguish instruction from data, acts. (4) Because the agent holds file-write and shell privileges, the action is code execution. The attacker never needed credentials; they needed the victim to point an over-privileged agent at their content.
04Three real disclosures
A prompt hidden in repository content (e.g. a PR or comment) could induce the assistant to modify the workspace settings file to enable automatic tool approval — turning off the human confirmation step — after which it could run shell commands and act without oversight. The vendor shipped a fix in its August 2025 update cycle [1]. Boundary that failed: the agent could write the file that governed its own approval behavior.
CurXecute:content returned from an external MCP source could instruct the agent to rewrite the project’s MCP configuration; with auto-run enabled, injected commands executed immediately — demonstrated end-to-end from a crafted message flowing through an integration [2].
MCPoison: a trust-on-first-use flaw — the editor validated an MCP config on first approval, then trusted later edits without re-validation. An attacker approves a benign config, then silently swaps in a malicious one that runs without re-prompting [2]. Boundary that failed: time-of-check to time-of-use gap in the approval model.
Covered in depth under prompt injection: invisible markdown in a PR drove a coding assistant to exfiltrate private source and secrets via a trusted image proxy [3]. Included here because it targets the coding-agent surface specifically — the injected content arrives through normal developer workflow.
05The real blast radius
The blast radius of a compromised coding agent is not the repository — it is the developer’s entire authenticated environment. On a typical engineering laptop that includes cloud credentials in environment variables and config files, SSH and signing keys, session tokens for internal tools, and package-publishing rights. An agent with a shell inherits all of it.
06Where the approval boundary belongs
The recurring root cause across these disclosures is a mis-placed approval boundary. Two anti-patterns dominate: approval that the agent can disable by writing a file, and approval that is validated once then trusted forever. The corrective principles:
- Out-of-band. The approval mechanism must live where the agent cannot write it — not in a workspace file the agent can edit.
- Re-validated on change. Configuration for tools/MCP must be re-approved whenever it changes, closing the TOCTOU gap.
- Effect-scoped, not step-scoped. Gate on high-impact effects (shell execution, credential access, new egress destination), not on every token, so the gate survives machine pacing.
- Confined by default. Run the agent with least privilege and no ambient credentials, so a bypassed approval still meets a bounded environment [4].
07Production failure modes
The agent can modify the control that governs it
Mechanism
Approval/auto-run state is stored in a project or workspace file. An injected instruction directs the agent to edit that file and enable unattended execution.
Why the existing control failed
The security control shared a writable surface with the thing it was controlling; there was no privilege separation between “do work” and “change how work is authorized.”
Signals to monitor
- Agent edits to settings / mcp config / .vscode files
- Auto-approve or auto-run toggled during a session
- Shell invocation immediately after reading external content
- Config file changes not authored by the developer
Controls
- Store approval state outside agent-writable paths
- Re-validate tool/MCP config on every change (no TOFU)
- Deny agent write access to its own config by policy [4]
- Run in a least-privilege sandbox without ambient creds
08Auto-approve: never, sometimes, or gated?
| Mode | Developer speed | Risk when agent reads untrusted content | Where it fits |
|---|---|---|---|
| Approve every action | Slow | Low (human sees each command) | Any repo with external contributors |
| Auto-approve everything | Fast | Critical — injection = RCE | Never on a machine with real credentials |
| Gated auto-approve (allowlist of safe actions, sandbox) | Fast | Bounded to sandbox + allowlist | Most day-to-day coding, in a contained workspace |
Never enable blanket auto-approve on a host that holds real credentials. Run coding agents in a contained workspace (ephemeral container or dev VM) with no ambient cloud/SSH secrets, and reserve auto-execution for an allowlist of side-effect-free actions. This preserves the speed that makes the agent worth using while ensuring that a successful injection lands in a bounded blast radius — the same containment logic developed in containment architecture.
09Limitations
- All three cases were responsibly disclosed and patched; they demonstrate feasibility, not measured in-the-wild prevalence.
- Product internals evolve quickly; specific settings names and defaults cited here may change after patching, though the class of flaw persists.
- The blast-radius argument assumes a typical developer environment with ambient credentials; well-isolated setups reduce it substantially — which is the point.
- Deterministic privilege control [4] helps but depends on correctly scoped policies and does not address flaws in the approval mechanism itself.
10Where this leads
Coding agents pull in capability through external tools, which raises the question of who wrote those tools — the subject of MCP server security. The containment that bounds a compromised coding agent is developed in containment architecture and sandbox escape, and the credential exposure it implies is the focus of identity and access control.
—References
- J. Rehberger (Embrace The Red); Microsoft. GitHub Copilot / VS Code remote code execution via prompt injection & auto-approve (CVE-2025-53773). Security disclosure (CVE-2025-53773), 2025. https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/
- Aim Security (CurXecute); Check Point Research (MCPoison). Cursor IDE agent vulnerabilities: CurXecute (CVE-2025-54135) and MCPoison (CVE-2025-54136). Security disclosure (CVE-2025-54135 / CVE-2025-54136), 2025. https://research.checkpoint.com/2025/cursor-vulnerability-mcpoison/
- Legit Security; GitHub. CamoLeak — GitHub Copilot Chat private source-code exfiltration (CVE-2025-59145). Security disclosure (CVE-2025-59145), 2025. https://www.legitsecurity.com/blog/camoleak-critical-github-copilot-vulnerability-leaks-private-source-code
- T. Shi, J. He, Z. Wang, H. Li, L. Wu, W. Guo, D. Song. Progent: Securing AI Agents with Privilege Control. arXiv:2504.11703 [cs.CR], 2025. https://arxiv.org/abs/2504.11703
- E. Debenedetti, J. Zhang, M. Balunović, L. Beurer-Kellner, M. Fischer, F. Tramèr. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. arXiv:2406.13352 [cs.CR], 2024. https://arxiv.org/abs/2406.13352
Engineering assistance
ProxyTech works with engineers and teams building production AI, cloud, security, data and distributed systems. If this analysis maps to a system you are designing or operating, we provide hands-on support and interview preparation for these domains.