Why Indirect Prompt Injection Is a Trust Boundary Problem, Not an Alignment Problem

When tool-augmented LLM agents started executing real-world tasks at scale, the security community inherited a problem it had not fully reckoned with. An agent that can browse the web, read local files, call third-party services, and load community-authored skills is an agent that consumes attacker-controllable text and then acts on it. The dominant response has been to train models to resist malicious instructions embedded in that text. A recent paper, ClawGuard: A Runtime Security Framework for Tool-Augmented LLM Agents Against Indirect Prompt Injection by Wei Zhao, Zhe Li, Peixin Zhang, and Jun Sun at Singapore Management University, argues that this framing misdiagnoses the problem. I think they are correct, and the consequences are worth working through carefully.

The Mechanics of the Vulnerability

The core issue is structural. In a typical agentic loop, a user instruction is processed by the model, which reasons, selects a tool, invokes it, and then appends the tool output directly to the conversation history as a trusted observation. The agent reasons over that accumulated context to decide its next action. There is no distinction in the context window between what the user said and what a web page said. Instructions and data share the same channel.

That single design choice is the vulnerability. Anyone who can influence a tool output gains a direct line into the agent's reasoning. The paper organizes these influence points into three injection channels:

• Web and local content injection, where adversarial instructions sit inside web pages, documents, or search results that the agent retrieves. The bar for an attacker is low: compromise any resource the agent is likely to fetch.
• MCP server injection, which exploits the open third-party Model Context Protocol ecosystem. A malicious server can embed instructions in returned content or, more insidiously, poison tool description metadata before any tool is even invoked, steering tool selection itself.
• Skill file injection, where adversarial instructions are semantically blended into legitimate behavioral guidance in public skill repositories, making them hard to detect without knowing the agent's intended task.

The metadata-poisoning variant deserves emphasis. It attacks the planning stage rather than the observation stage, which means defenses that only sanitize tool outputs miss it entirely. This is why a piecemeal approach struggles.

Why the Existing Defense Categories Fall Short

The paper sorts prior defenses into three buckets and identifies a specific failure mode for each.

Model-level defenses include RLHF safety alignment and instruction hierarchy training. These require fine-tuning, which immediately rules them out for the large fraction of deployments that consume models through closed-source APIs. Worse, even well-aligned commercial models still fail against context-dependent injections in agentic pipelines. This is the crux of the argument: you are asking a probabilistic system to reliably hold a security boundary, and reliability is exactly what probabilistic systems do not guarantee. Every new alignment effort invites a new bypass.

Protocol-level defenses such as StruQ physically separate instructions from data. This is the right intuition at the wrong layer. It demands coordinated changes across both model providers and tool providers, which is incompatible with the heterogeneous reality of current agentic frameworks.

Architecture-level defenses offer the strongest guarantees but at a deployment cost. CaMeL does not fit open-ended agents whose tool calls are decided at runtime. AgentSpec requires domain experts to hand-author rules for each deployment context, which does not scale.

The gap the authors identify is a defense that is model-agnostic, protocol-agnostic, automatic, and deterministic. That is the niche ClawGuard targets.

What ClawGuard Actually Does

The framework rests on a deceptively simple idea: enforce a user-confirmed rule set at every tool-call boundary. It has two phases.

First, a one-time pre-session rule induction step. Before any external tool is invoked, the system derives task-specific access constraints from the user's stated objective and confirms them with the user. The critical property here is that this rule set, called R_task, is produced before any adversarial content can enter the context. It is uncontaminated by definition, because it is computed from the user instruction alone. This sidesteps the chicken-and-egg trap of trying to filter injected instructions after they have already mixed into the trusted context.

Second, per-tool-call enforcement, which applies four components at each boundary:

• A Content Sanitizer that redacts sensitive data spans both from outgoing tool-call arguments and from incoming tool-returned content before it is appended to history.
• A Rule Evaluator that checks each proposed tool call against the active rule set R = R_base ∪ R_task, covering tool invocations, local file paths, and outbound network destinations.
• A Skill Inspector that performs automated risk assessment plus mandatory user confirmation before a skill executes for the first time.
• An Approval Mechanism that routes ambiguous verdicts to the user for explicit authorization, with everything logged in an Audit Log.

The effect is that an injected instruction can corrupt the agent's reasoning all it wants, but the resulting tool call still has to pass a gate that was defined independently of that corruption. If the user asked to summarize a document and the injected text convinces the agent to exfiltrate credentials to an external host, the outbound destination is not in R_task, and the call is blocked before any real-world effect occurs.

The authors evaluate across AgentDojo, SkillInject, and MCPSafeBench on five state-of-the-art language models, reporting substantial and consistent reductions in attack success relative to unprotected baselines, without compromising agent utility. The choice to cover all three benchmarks matters, because each maps to one of the three injection channels, demonstrating that a single enforcement mechanism closes all of them.

My Take

The conceptual contribution here is sharper than the engineering. Reframing indirect prompt injection as a trust boundary violation rather than an alignment failure is the kind of move that reorganizes how you think about an entire problem space. In conventional security, we do not ask a process to politely decline privilege escalation; we deny it the capability. ClawGuard ports that intuition into the agentic setting by ensuring the policy is fixed before the untrusted data arrives.

What I find most durable is the temporal ordering argument. The reason post-hoc filtering of tool outputs is doomed is that the filter operates on already-contaminated context. By computing constraints from the user objective first, ClawGuard establishes a reference point that the attacker provably cannot influence. This is a stronger property than detection accuracy; it is an information-flow guarantee.

That said, I would not overstate the determinism. The rule induction step itself uses an LLM to translate a natural-language objective into access constraints. If that translation is too permissive, the gate has holes; if too restrictive, utility suffers and users get prompt-fatigued into rubber-stamping approvals. The paper's claim of preserved utility hinges on this inducer being well-calibrated, and calibration across diverse tasks is exactly where I would press hardest. There is also a usability question: mandatory confirmation for first skill execution and ambiguous calls shifts security burden onto users, and users are reliably the weakest link. An attacker may simply craft tool calls that fall inside an over-broad R_task rather than trying to break out of it.

The MCP metadata poisoning case is interesting because rule induction happens before tool descriptions are even read, which should neutralize the steering attack. But if R_base permits a tool category broadly, a poisoned description within that category could still misdirect behavior in ways the rule set does not catch.

Closing Thoughts

ClawGuard makes a clean argument that the right defense layer for indirect prompt injection is the tool-call boundary, enforced deterministically and induced automatically. It avoids the fine-tuning trap, the cross-provider coordination trap, and the expert-rule-authoring trap simultaneously, which is a meaningful coverage win. The open questions I would want answered next are the fidelity of automatic rule induction under adversarial objective phrasing, the human factors of the approval mechanism at scale, and whether the same boundary discipline extends to multi-agent systems where one agent's output becomes another's untrusted input. The general lesson, though, is one the security field already knew: when you need a hard guarantee, build a gate, not a better-behaved guesser.