Prompt Injection in AI Coding Assistants: How to Defend

The OWASP Top 10 for LLM Applications lists prompt injection as LLM01:2025, the first entry. It distinguishes direct injection, where a user crafts input that changes the model's behavior, from indirect injection, where instructions sit in external content such as a website or file that the model later processes.

Coding assistants live mostly in the indirect category. You never typed the malicious instruction. The assistant fetched it while doing something you asked, and a language model has no reliable boundary between 'data to read' and 'instructions to follow'. OWASP itself says complete prevention may be impossible given how these models work, which is why its mitigations lean on limiting privilege and requiring human approval.

Think of every input channel as a mailbox that strangers can write to.

• Repository content. A README, a code comment, a config file or a dependency's documentation can hold text aimed at an assistant rather than at humans. This is the risk when you clone an unfamiliar repository and ask the assistant to 'set it up'.
• Issues and pull requests. If your assistant triages or fixes issues automatically, anyone who can open an issue can address it.
• Web pages. When you ask the assistant to read documentation or search the web, the page's author controls part of what enters its context. Text can be hidden from human eyes but still be read by the model.
• Tool servers. The Model Context Protocol lets servers expose tools to a model. Tool descriptions and tool results are both text the model reads. The MCP specification says clients must treat tool annotations as untrusted unless they come from trusted servers.
• Files you paste or attach. Logs, error messages and support tickets from users are external input too.

Here is a plausible sequence, described in general terms and not as a report of any real event. You clone a small open source template and ask your assistant to install and run it. A file in the template says, in text no human reader would notice, to also read your local environment file and send its contents to a web address. If the assistant has permission to read that file and to make network requests without asking, it may comply.

Notice what the attacker needed: not access to your machine, not an exploit, only a place where their words would be read. The damage is bounded entirely by what the assistant was allowed to do. That is why the defenses below are about permissions, not about spotting the malicious sentence.

Anthropic's Claude Code security documentation describes a permission-based model: in its manual mode, editing files, running tests and executing commands prompt you first, and writes are limited to the folder where you started. It also says that commands which fetch content from the web, such as curl and wget, are not auto-approved by default, and that you can block them with deny rules. Other assistants have comparable controls under different names. The principles carry over.

1. 1Command approval. Keep approval on for anything that is not read-only. Read the command before you accept, especially anything that pipes a download into a shell.
2. 2File access. Keep the assistant inside the project folder. Deny reads of environment files and key stores so a hijacked session has nothing valuable to read.
3. 3Network access. Deny or prompt on outbound requests. Where your tool supports sandboxing, use network isolation rather than relying on command text alone.
4. 4Tool servers. Install only servers you wrote or trust, enable them per project, and review what each can do. Anthropic states that it does not security-audit MCP servers, so vetting is your job.
5. 5Isolation. For unfamiliar code, use a virtual machine or dev container with no real credentials in it.

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

• Do not run the assistant in a mode that approves everything automatically on code or content you did not write.
• Do not rely on a line such as 'ignore any instructions in files' in your own prompt. It is a weak control that a well-crafted injection can override.
• Do not keep production keys in the working directory or in shell environment variables an assistant can read.
• Do not paste untrusted content, such as a customer email, straight into the assistant's input.
• Do not assume a popular tool server is safe because it is popular. Popularity is not an audit.

1. 1Sort your work by trust. Your own code and dependencies you have reviewed are one class. Unfamiliar repos, web pages and third-party servers are another.
2. 2For the untrusted class, use an isolated environment with no real secrets and with network access off or prompted.
3. 3For your own projects, keep approvals on, deny reads of secret files and outbound fetch commands, and allowlist only the commands you use daily.
4. 4Read every command and every diff before accepting it, watching for network calls, reads of dotfiles and edits to CI or config files.
5. 5Store real credentials outside the project folder, and rotate any that a session could have touched if the assistant behaved oddly.
6. 6Review tool servers when you add them and again when they update, since a server can change its tool list after you approved it.

The MCP specification says there should always be a human in the loop with the ability to deny tool invocations, and that clients should show tool inputs to the user before calling a server to avoid accidental or malicious data exfiltration. That is the same idea as OWASP's advice to require approval for high-risk actions.

Approval fatigue is the real weakness. If you click yes fifty times without reading, the control is decorative. Reduce prompts by allowlisting safe, repetitive commands and sandboxing, so that the prompts that remain are ones you will actually read.