AI Coding Agent Security: How Prompt Injection Leads to Credential Theft (and How to Stop It)

What is prompt injection against a coding agent?

Traditional security models keep instructions and data strictly separate. LLM-based agents don't: a systematization-of-knowledge paper analyzing 78 studies on the topic notes that models process both through the same channel, so content an agent merely reads — a PR title, an issue body, an MCP tool's response, a fetched web page, an error trace — can carry instructions the agent treats as authoritative. The same paper catalogs 42 distinct attack techniques and found attack success rates against published defenses exceed 85% once an attacker adapts. The OWASP Secure Coding with AI Cheat Sheet independently lists the same surface: issue bodies, PR comments, README files, dependency changelogs, and fetched pages all become instruction sources once an agent reads them.

This matters more for coding agents than chatbots because coding agents are wired to tools — shell execution, package installs, git push — and typically run with the developer's own credentials. A successful injection isn't a bad chat response; it's an action taken with your permissions.

Has this actually happened, or is it theoretical?

It's been demonstrated against production tools, cross-vendor. Security researcher Aonan Guan, working with Johns Hopkins researchers, showed that Anthropic's Claude Code Security Review, Google's Gemini CLI Action, and GitHub Copilot Agent could each be hijacked via GitHub PR titles, issue bodies, and comments — turning the host repository's own GitHub Actions secrets (API keys, tokens) into stolen data, exfiltrated back through GitHub itself with no external infrastructure. The Copilot variant bypassed three dedicated runtime defenses GitHub had added specifically to prevent this: environment filtering, secret scanning, and a network firewall.

Separately, the Cloud Security Alliance documented "agentjacking": attackers inject malicious instructions into Sentry error events using only a public, write-only DSN credential. When a developer asks their agent to investigate open errors, the agent retrieves the poisoned event through Sentry's MCP server and executes the embedded instructions with the developer's own privileges — recovering AWS credentials, GitHub/GitLab tokens, npm tokens, and CI/CD secrets in the proof-of-concept, with zero policy violated and zero anomaly threshold crossed.

What CVEs exist for this specifically?

The SoK paper above catalogs over 30 CVEs tied to agentic coding assistants; five representative ones:

Microsoft's research team went further, disclosing two CVEs in Microsoft Semantic Kernel (CVE-2026-25592, CVE-2026-26030) that chained prompt injection into full host-level remote code execution — one through an unsanitized parameter in a search plugin reaching Python's eval(), the other through an unvalidated file path letting an injected instruction write a malicious script straight to the host's Windows Startup folder from inside what was supposed to be an isolated sandbox.

Why is this hard to fix with blocklists?

Because the agent's job legitimately requires reading untrusted content. Blocking specific commands doesn't close the hole — the OWASP cheat sheet notes Anthropic blocked the ps command as a mitigation, and attackers simply moved to cat /proc/*/environ to read the same environment variables a different way. The SoK paper's review of 18 published defense mechanisms found most achieve less than 50% mitigation against adaptive attackers. The architectural fix isn't a smarter filter; it's removing the agent's ability to reach sensitive capabilities at all unless explicitly scoped.

How do I actually defend my agent setup?

Both the SoK paper and OWASP converge on the same shape of answer: least privilege, not detection. Meta's security team frames it as the "Rule of Two" — an agent should satisfy no more than two of: (A) processing untrusted input, (B) accessing sensitive data, (C) changing state or communicating externally. Every incident above is an agent doing all three at once. A practical tiered approval model, adapted from the SoK paper's proposal:

Concretely: use an explicit tool allowlist (e.g. Claude Code's --allowed-tools) rather than trying to blocklist dangerous ones; run agents with ephemeral, scoped credentials instead of long-lived developer tokens in environment variables; exclude .env, *.pem, and SSH keys from the agent's visible context; and require human approval before shell execution, network egress, or any credential-adjacent action — particularly for MCP servers and CI agents that process content from outside contributors.

Frequently asked questions

References

• Prompt Injection Attacks on Agentic Coding Assistants (SoK, arXiv 2601.17548)
• OWASP — Secure Coding with AI Cheat Sheet
• Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot
• Cloud Security Alliance — Agentjacking: MCP Injection Hijacks AI Coding Agents
• Microsoft Security — When Prompts Become Shells: RCE Vulnerabilities in AI Agent Frameworks