Which prompt-injection controls should sit outside the model rather than in the prompt?

## The sorting question For each control in the catalogue ask one thing: does it still hold if the model is fully persuaded by something it read? That single question sorts the taxonomy into two piles, and the sorting is the whole of the design judgment. **Probabilistic, model-dependent.** Instruction/data separation in the prompt. Spotlighting — delimiting, datamarking, encoding. Instructions to report embedded imperatives rather than act on them. Classifier passes that score input or output for injection attempts. All of these reduce the *rate*. None of them survive a persuaded model, and a classifier is itself a model with the same failure mode. **Deterministic, model-independent.** Human approval enforced at the side-effect boundary. The set of capabilities present in the loop at all. Isolation of untrusted prose from the privileged component. Policy checks on resolved arguments before execution. These run in code; they hold whether or not the model was fooled. The design rule follows directly: put on the deterministic side everything whose failure you could not accept, and use the probabilistic side to reduce how frequently the deterministic side is exercised. ## Why stacking prompt-level measures disappoints A reasonable-sounding argument says three mitigations at 90% each leave 0.1% through. That arithmetic assumes independence, and these failures are not independent. They share a mechanism — the model choosing to honour a convention described in the same context as the attacker's text — so a payload crafted against one frequently defeats the others in the same pass. Worse, an adversary iterates: a static defence facing repeated attempts loses most of its per-attempt margin. Layering is right; expecting the layers to multiply is not. Layers should be *diverse in mechanism*, and the diversity that matters is prompt-level versus code-level, not two more paragraphs of prompt. ## Making the decision concrete Start from the side effects, not the prompt. Enumerate what the agent can cause: what it can write, send, spend, delete, or transition. For each, ask what the worst plausible outcome is if it fires with attacker-chosen arguments, and whether it is reversible. That inventory drives everything. Then decide, per capability: - Should this exist in the loop at all? Removing a capability is the only control with no residual failure rate. Many agents hold tools present "for completeness" that no user journey needs. - If it exists, does it fire without a human? Irreversible and externally visible actions should not. - Does the component holding it need to read untrusted prose, or can a constrained record serve? If a schema suffices, the channel closes. - What does the harness verify about the arguments before executing, independent of the model's intent? Only after those four does prompt-level hardening enter, as hygiene applied uniformly to every untrusted span including tool results. ## Residual risk, stated honestly A principal-level answer says out loud that this is risk reduction, not elimination, and names what remains. Approval bounds side effects but not information flow. Isolation shrinks the channel to the size of the schema. Capability limits do not help against misuse of a capability the feature genuinely requires. Some feature requests — an autonomous agent reading arbitrary third-party content and taking irreversible external actions without review — do not have a safe configuration in the current state of the field, and the correct output of the design review is a narrower feature, not a longer prompt. ## Organisational shape Three things make the posture durable. First, make the classification of a tool as side-effecting a property declared in code and reviewed like a schema change, so it cannot drift. Second, log which mitigations were applied per request, so an incident review can distinguish "the layer failed" from "the layer was not there." Third, keep an inventory of untrusted-content entry points; the usual regression is a new tool that fetches external pages into a context that was previously fed only vetted material. As of mid-2026 the industry reference taxonomy for this class of risk in agent systems is the OWASP Top 10 for Agentic Applications, whose leading entry is goal hijack — useful shared vocabulary in a design review, and a reminder that the field treats these as architectural rather than prompt-quality concerns. ## Interview framing Give the sorting question first, name both piles, then state the assumption you design under: the prompt layer fails, so the question is what the model can do at that moment. Close with the honest limit — some capabilities should not be behind an agent at all — because a candidate who claims a complete defence is the one who has not run this in production.