Can structural design patterns block prompt injection attacks?

The paper argues that general-purpose LLM agents — ones meant to automate "a wide range of workflows" and given access to powerful tools such as code execution — cannot be given "meaningful and reliable safety guarantees" against prompt injection as long as both the agent and its defenses rely on the current class of language models. Its alternative is a set of design patterns for "application-specific agents" that trade some generality for "provable resistance" to prompt injection. The paper's own framing of the goal: "once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions."

The excerpt describes the first two of six patterns. In the Action-Selector pattern, the agent works like an LLM-modulated "switch" statement: it maps a natural-language request onto one of a small, predefined (optionally templated) set of actions, and — critically — no output from those actions ever feeds back into the agent, so injected content in a tool result has nothing to act on. In the Plan-Then-Execute pattern, feedback from tool outputs is allowed back to the agent, but the sequence of actions is fixed as a plan before execution begins, so tool outputs can influence what the agent later says but not which actions get taken. The paper sorts existing defenses into LLM-level (prompt engineering, adversarial training), user-level (human confirmation before sensitive actions), and system-level (external verification and control), and places its own patterns in the system-level category, arguing it is "one of the most promising paths toward robust safety guarantees" precisely because LLM- and user-level defenses "do not provide guarantees" or "pose a safety risk themselves with tired or overloaded human verifiers."

This sits against Do internal agent hops in pipelines need security monitoring?, which found that input-boundary filters see only the user's prompt and miss every inter-agent hop; this paper's patterns are aimed at exactly that gap, constraining the agent's control flow architecture-wide rather than filtering at a single entry point. It also bears on Can prompts alone reshape multi-agent workflows without system access?: the Plan-Then-Execute pattern is offered as a structural answer to that kind of planning-time reshaping, since the plan is fixed before tool outputs can touch it — though this excerpt does not test the pattern against that specific attack. And it contrasts with Why does prompt hardening work for single agents but not multi-agent systems?, an LLM-level, prompt-engineering defense of the kind this paper argues cannot "provide guarantees" regardless of how much it reduces exposure in practice.

The excerpt does not include the paper's empirical results: it mentions "ten case studies" and a claim of "provable" resistance, but the body given here stops at the taxonomy and the first two patterns, with no benchmark numbers, attack success rates, or utility-cost measurements attached to either pattern. The claim to take from this excerpt is therefore architectural rather than measured: these are constraints an agent's designer chooses at build time — which actions exist, whether tool output can reach the agent, whether the plan is fixed before execution — not a filter or detector that can be added on top of an already general-purpose agent after the fact.