All pages
Guides
How do I tell if a coding agent was prompt-injected?
Where injected instructions reach a coding agent, what gives one away, what detection can and cannot do, and why tightening a session after it reads untrusted text works better.
A prompt injection is text the agent reads as data that it then follows as instructions. A coding agent reads a lot of text written by strangers, so the question is less "will it happen" than "would you notice, and how much could it do".
Where it comes in#
- Pull requests and issues: descriptions, review comments, and the text of an issue the agent was asked to fix.
- The repository itself: a README, code comments, test fixtures, and the agent's own instruction files (
CLAUDE.md,AGENTS.md, Cursor rules) in a repository someone else wrote. - Dependencies: documentation and source of a package the agent reads while debugging.
- The web: pages and search results the agent fetches.
- MCP tool results: a ticket, a document, a chat message or a database row returned by a server, and the tool descriptions the server publishes.
- Other agents: messages and files one agent leaves for another.
What gives one away#
Injected instructions rarely announce themselves. What shows is the gap between what the person asked for and what the agent then did:
- reading credentials,
.envfiles or SSH keys the task did not need; - fetching a URL nobody mentioned, or sending data to one;
- editing CI configuration, shell profiles, git hooks or the agent's own settings;
- a sudden change of direction right after it read an issue, a page or a tool result;
- hiding text: hidden Unicode characters in an instruction file, or instructions not to tell the user something.
You can look for these by reading transcripts, by hand or with a model. Detection by a model catches some and misses some; so does a person reading quickly.
Why tightening beats spotting#
No detector catches every injection, and new phrasings appear constantly. What works regardless is limiting what a session can do once it has read something untrusted. With what the agents already give you:
- keep permission prompts on, and add
askrules for tools that reach the network or push code; - use Claude Code's sandbox for Bash, which limits the hosts and files a command can reach;
- do the reading in a separate, read-only session, and the editing in another;
- give risky work its own container or VM without your credentials. See How do I let an agent work on a repository I don't trust?
Where Golem fits#
Golem works on both halves: a signal that a session read something hostile, and controls that tighten the session when it does.
- The prompt-injection check scores what an agent reads (web pages, search results, MCP results, messages from other agents) and signs the verdict into the session. The text itself is not stored with it. It is off until you turn it on, and it scores the first 32 KB of each result.
- Rules act on the score.
entry.result_injection_scoreandentry.session_max_injection_scoreare fields a rule can read. The built-in rule withholds a result scored at 0.98 or above before the agent reads it, in Claude Code and on Golem's MCP path. It ships in shadow, so it records what it would have done until you enforce it. - Lockdown. A rule can lock the session down after a likely injection, a web fetch or a jail refusal: on a Mac, every later shell command in that session runs with no network, no credentials and writes only inside the repository. The three starter rules ship off. See Lockdown.
/safely. Typed by the person before a risky read, it restricts the session to read-only tools. It is decided from what the person typed, so nothing the agent reads can turn it off. See Safely.- Config scan. Every 30 minutes the Golem agent reads agents' instruction files and MCP and hook settings, and alerts on hidden Unicode characters, instructions to hide something from you, and servers or hooks that pipe a download into a shell.
- A changed tool description.
entry.tool_description_changedis true when an MCP tool's description changed since Golem last saw it. - Reading for the gap. Golem's investigator reads finished conversations for the difference between what was asked and what was done, and raises a flag for a person. It is off by default, runs on a model you choose, and never blocks anything. See Session review.
What Golem does not do#
- The injection check is a detector, and like any detector it misses some. It is a signal for rules, not a guarantee.
- Isolation does not detect an injection. The sandbox and the jail limit what one can reach.
- A result can be withheld only where it passes through Golem: Claude Code's hooks and Golem's MCP gateway. In other agents a rule on a result cannot hold it back.
- The shell jail and lockdown are macOS and Claude Code only.