A colleague proposes letting Claude Code run unattended over a queue of scraped web pages, arguing that the approval system makes prompt injection a solved problem. How should you assess that?

The principle — a control that reduces risk is not a control that removes it, and an unattended design has to be judged on what remains.

Why the key is correct — Anthropic states the limit of its own defences without hedging: while these protections significantly reduce risk, no system is completely immune to all attacks. That sentence is what settles the question. The defences named around it are real and worth having — commands that fetch content from the web such as curl and wget are not auto-approved by default, web fetch uses a separate context window to avoid injecting potentially malicious prompts, suspicious bash commands require manual approval even if previously allowlisted, and unmatched commands default to requiring manual approval. Every one of those is a reduction. None is a proof. A queue of scraped pages is a stream of untrusted content by construction, which is the input class the whole risk is defined around, so the residual is exactly where the proposal concentrates its volume.

Why the others are wrong — the fail-closed default for unmatched commands is genuine, and treating it as sufficient is the specific error the documentation forecloses. Leaning on human judgement at the prompt is self-defeating in an unattended design, because the human is the part being removed. And the fourth answer reaches the right verdict through a false premise: fetched content is handled with more caution than local content, not the same, and someone who believes otherwise will misjudge the next design too.

Remember this — read what a vendor says about the limits of its own protections; Anthropic states them plainly, and that sentence is the one to quote back.

Sources — Anthropic's Claude Code security page.