# Prompt Injection Attacks on AI Coding Agents > How untrusted text an AI coding agent reads can smuggle in commands, why filtering it out fails, and the containment strategy that actually reduces the risk. URL: https://www.matthewswong.com/en/blog/prompt-injection-ai-coding-agents/ - Author: Matthews Wong (https://www.matthewswong.com/en/about/) - Published: 2026-08-08 - Updated: 2026-08-08 - Category: Security > **Key takeaway:** Prompt injection is when untrusted text an AI coding agent reads, such as a code comment, issue, or web page, smuggles in instructions the agent then follows. Because agents cannot reliably tell data from commands, the practical defense is to limit what a compromised agent can reach and do, not to hope it detects the attack. An AI coding agent reads whatever you point it at: your files, a GitHub issue, a dependency's README, the page behind a URL. To the model, all of that text arrives in the same channel as your instructions, and it has no dependable way to know which words are trusted and which were planted by someone else. That is the opening for prompt injection, the defining security problem of agentic tools. This guide explains how the attack works, why filtering it out is a losing game, and the containment strategy that actually reduces the risk. ## How prompt injection works Prompt injection exploits a single fact: a language model concatenates trusted instructions and untrusted content into one stream of tokens and treats them alike. An attacker who controls any text the agent reads can phrase that text as a command, and the model may obey it as readily as it obeys you. For a coding agent, the untrusted surface is large and easy to overlook: - A comment or docstring in a dependency the agent reads while working. - The body of an issue or pull request the agent is asked to triage. - A web page or API response the agent fetches during a task. ## The lethal trifecta Security researcher Simon Willison names the dangerous combination the lethal trifecta: an agent that has access to private data, exposure to untrusted content, and a way to send data out. Any one alone is survivable; all three at once turns a planted instruction into stolen data. Picture the chain concretely: an agent reading a malicious code comment is told to collect environment variables and post them to a URL. Nothing is malformed; the agent is simply doing what the text asked. > Audit your agent for the trifecta before you audit its prompts. If you can break even one leg, private data, untrusted input, or an outbound channel, the same injection that would have leaked secrets becomes a harmless misfire instead of an incident. ## Why detection is not enough The tempting fix is to scan inputs for malicious instructions and strip them. It helps at the margin, but you cannot rely on it, for reasons that are structural rather than temporary: - There is no syntactic marker that separates an instruction from data; both are just natural language. - Attackers rephrase, encode, and hide payloads faster than any filter can enumerate them. - A filter strict enough to catch every attack would also block legitimate content, so it gets loosened until it leaks. - The OWASP GenAI project continues to rank prompt injection among the top LLM risks precisely because no clean detection exists. ## Contain the blast radius instead Since you cannot stop the agent from being fooled, design so that a fooled agent cannot do much harm. Scope its capabilities to the task and assume any input might be hostile. That means read-only tools by default, an allowlist for network access, and secrets kept out of reach of any session that touches untrusted content. Claude Code's security model reflects this: the agent defaults to read-only, asks before actions with side effects, and isolates web-fetched content so a page it reads cannot silently steer the session. The principle generalizes to any agent, treat capability, not detection, as the real control. > Skipping every permission prompt to move faster removes exactly the guardrail that contains an injection. On a session that reads only your own code the risk is low, but the moment that agent touches an issue, a URL, or a third-party dependency, unattended full autonomy is how a planted instruction reaches your shell. ## A practical checklist You will not eliminate prompt injection, so aim to make a successful one boring: - Break at least one leg of the trifecta on any agent that reads untrusted input. - Keep credentials and private data out of sessions that browse the web or triage external issues. - Require confirmation for irreversible or outbound actions, and keep an audit trail of what the agent did. Prompt injection is not a bug that gets patched; it is a property of how language models read. Stop trying to make the agent immune and make it contained instead: least privilege, no lethal trifecta, and a human in the loop for anything with side effects. A fooled agent that can only read is a footnote, not an incident. ## Sources & further reading - Simon Willison — The lethal trifecta for AI agents - OWASP GenAI — Exploit round-up report, Q1 2026 - Claude Code docs — Security ## Source links - https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ - https://genai.owasp.org/2026/04/14/owasp-genai-exploit-round-up-report-q1-2026/ - https://code.claude.com/docs/en/security ## FAQ ### What is prompt injection in AI coding agents? Prompt injection is when untrusted text an agent reads, such as a code comment, an issue body, or a fetched web page, contains instructions that the agent then follows as if they came from you. It works because a language model treats trusted instructions and untrusted content as one undifferentiated stream of tokens. ### What is the lethal trifecta? Coined by Simon Willison, the lethal trifecta is the dangerous combination of an agent having access to private data, exposure to untrusted content, and a way to send data out. Any one alone is manageable, but all three together let a planted instruction read secrets and exfiltrate them, turning a harmless input into a data breach. ### Why can't I just filter out malicious instructions? There is no syntactic marker separating an instruction from data, so filters rely on guessing intent from natural language. Attackers rephrase, encode, and hide payloads faster than any filter enumerates them, and a filter strict enough to catch everything also blocks legitimate content. Detection helps at the margin but cannot be relied on. ### How do I defend a coding agent against prompt injection? Contain the blast radius instead of trying to detect every attack. Break at least one leg of the lethal trifecta: default to read-only tools, keep secrets out of sessions that touch untrusted content, and use an allowlist for network access. Require confirmation for irreversible or outbound actions and keep an audit trail. ### Is it safe to skip permission prompts to work faster? Only on sessions that read your own trusted code. The moment an agent touches an external issue, a URL, or a third-party dependency, unattended full autonomy removes the guardrail that stops a planted instruction from reaching your shell. Skipping prompts on untrusted input is how a minor injection becomes a real incident. --- - HTML version: https://www.matthewswong.com/en/blog/prompt-injection-ai-coding-agents/ - Bahasa Indonesia: https://www.matthewswong.com/id/blog/prompt-injection-ai-coding-agents/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json