Prompt injection is not a bug. It's the architecture.
Most LLM products treat prompt injection as a vulnerability to be patched. It isn't. It's the natural consequence of the architecture, and the only durable fix is to stop pretending instructions and data can share a context.
Every few weeks a new "prompt injection mitigation" lands on Hacker News. A clever system prompt, a regex on tool calls, a fine-tuned classifier that promises to detect malicious input. Each one buys a few weeks of safety until somebody finds the next bypass — and they always do.
Prompt injection is not a bug. It's the natural consequence of mixing instructions and untrusted data inside the same context window. You don't patch SQL injection by getting better at filtering apostrophes — you parameterize. You separate the channel that carries instructions from the channel that carries data, and you make it structurally impossible for one to be reinterpreted as the other. Until LLM products do the same thing, every prompt-injection "fix" is going to be wallpaper over a load-bearing wall.
What does the parameterized version of an LLM agent look like? It looks like a planner that generates a structured plan in a constrained, signed format, and an executor that runs that plan against tools without ever consulting the original prompt. The planner sees user input. The executor doesn't. The data the executor manipulates is never re-interpreted as a new instruction, because the executor isn't running a language model anymore — it's running a finite state machine over a typed plan.
This is harder to build than "add another guardrail." It's also the only design that survives contact with motivated adversaries. Every agent product I've reviewed in the last twelve months has the same shape — a single LLM brain that does both the thinking and the acting — and every single one has been trivially exploitable through a maliciously-crafted document, web page, or email that the agent is asked to process. The question isn't whether your agent can be prompt-injected. It's whether the blast radius matters.
If you're building an LLM product right now, the first question to answer is: what does my agent do that would actually matter if an attacker controlled it for thirty seconds? Read PII? Make a payment? Call an API on a customer's behalf? Now design backwards from there. The capability isolation you build at the architecture layer is the only thing standing between you and the next viral injection demo.