The best fixes for AI 'prompt injection' attacks don't teach the AI to resist tricks — they just cut off its ability to act on them.

This looks at why the strongest defenses against prompt injection don't try to make the model spot malicious text. Instead they track where untrusted content travels inside an agent and decide what that content is allowed to reach. Seen that way, an injected instruction is only dangerous if it can get from a webpage, email or tool output to an action that has real effects, like sending money, deleting files or emailing someone. The corpus shows that cutting that path is far more reliable than teaching the model to resist persuasion. Six architectural patterns, including Plan-Then-Execute and Action-Selector, block injection by making sure untrusted input can never shape which action gets taken. Because they constrain the system itself, they give guarantees rather than lower odds of failure Can structural design patterns block prompt injection attacks?.

The less obvious lesson is that 'flow' has two separate channels, and protecting one doesn't protect the other. Willison's Dual LLM pattern keeps a privileged planner away from untrusted data, so an attacker can't rewrite the plan. But the plan still runs on values pulled from untrusted sources. Suppose the plan says 'email the report to the address in this document.' An attacker who controls that document controls where the email goes, without touching the plan Does isolating planning from untrusted data actually stop prompt injection?. That gap is why CaMeL attaches metadata to every value recording where it came from and what it may be used for, then refuses to let tainted values reach sensitive tool arguments. It costs some usefulness (77% of tasks solved, 7 points below an undefended agent), but policy compliance is guaranteed Can capability tracking stop prompt injection attacks?. This is the same thinking as taint tracking in traditional software security, applied to language models.

The flow view also explains why defenses built on instructions fall apart in multi-agent systems. Telling a single agent to be careful cut exposure to malicious payloads by 40–75%, but the same instructions did nothing once work was split across several agents. The agent doing the risky action wasn't the one holding the security context Why does prompt hardening work for single agents but not multi-agent systems?. Attacks can also enter earlier than defenders expect. FLOWSTEER shows that a crafted prompt can bias how a planner sets up a workflow before any inspection runs, raising malicious success by up to 55% Can prompts alone reshape multi-agent workflows without system access?. Sanitizers placed at specific checkpoints carry hidden assumptions about where attacks show up. One compression filter blocked 100% of leaks between agents but failed 23.4% of the time at the user-prompt boundary, because it assumed payloads get appended when users actually put them first Why does compression defense fail at the user prompt boundary?. Each channel needs its own threat model.

Compare this with the content-based approach. OpenAI's Model Spec ranks instructions by authority (root, system, developer, user), and the model is supposed to ignore lower-ranked instructions that conflict with higher ones Can a fixed instruction hierarchy actually prevent prompt injection attacks?. That is a flow rule of a kind, but the model enforces it through its own judgment, so it fails whenever the model misjudges a message's role. The useful takeaway is that prompt injection may never be fully solved inside the model. The most robust answers treat the LLM as an untrusted component and put the guarantees in the system around it. That makes prompt injection look less like an AI alignment problem and more like a classic software security problem.