A filter is not a boundary
Prompt-Injection Defenses for Tool-Using Agents: Isolation, Allowlists, and Output Filters
A chat model that only talks can be embarrassing. A tool-using agent that talks and acts can move money, change infrastructure, or send mail. Prompt injection is usually filed under Security. The harm that matters for this paper is NIST Safe: life, health, property, and environment.
This essay is a tour of a comparison paper. Three common defenses — isolation, allowlists, and output filters — sit in different places in the agent loop. They fail in different ways. None of them is a Safety program by itself.
Four claims
The model is not the perimeter. Once untrusted text is in the same context as instructions, the model may treat that text as a request. A Safety control that depends on the model ignoring that request is a hope, not a gate.
Isolation bounds blast radius. Separate untrusted content, and run tools in a privilege-separated environment, so a confused model cannot reach every credential and every side effect. Isolation does not decide whether an action is worth taking.
Allowlists fail closed on capability, not on meaning. A tool that is not mounted cannot fire. A destination that is not listed cannot be called. A schema-valid request to a mounted write tool can still harm property.
Filters inspect text. They can catch known instruction-like patterns before a tool runs. They do not revoke tools, and they do not survive a determined paraphrase.
Where each control sits
| Defense | Sits at | Holds if the model is fully steered | Typical Safety miss |
|---|---|---|---|
| Isolation | Context channels and tool runtime | Partially — effects stay inside a box | The box still includes a write that damages property |
| Allowlists | Tool mount and argument gate | Yes, for anything not listed | Listed tools with broad meaning |
| Output filters | Text just before a tool or a user | No | Novel wording; another model in the filter path |
A worked minute
A workspace mounts mail, a browser, and a repo. A retrieved page contains instruction-like text. Isolation keeps that page out of the system-prompt channel and runs the browser in a locked-down session. The allowlist refuses a shell that was never mounted. An output filter asks a reviewer before a send. The remaining question is whether send should have been mounted at all.
That last sentence is the Safety question. The first three are how you keep a confused model from answering it alone.
Failure modes to refuse
- Filter-only “Safety” with a full tool belt still mounted
- Isolation that shares production credentials with the boxed runner
- An allowlist that contains every tool the product ships
- Treating jailbreak refusal rates as a measure of Safe
Why compare, not crown
Isolation, allowlists, and filters compose. The load-bearing order is: shrink what can run, shrink where it can run, then inspect what is about to run. A filter in front of an unbounded agent is a warning label on an open door.
For the full comparison, defense variants, worked cases, and a Measure that counts actions rather than refused sentences, read the paper.
Citation
@online{violet2026injectiondefenses,
author = {Haigh, John},
title = {Prompt-Injection Defenses for Tool-Using Agents: Isolation, Allowlists, and Output Filters},
date = {2026-09-14},
year = {2026},
url = {https://www.violetai.ca/en/research/prompt-injection-defenses/paper},
}