Prompt Injection Isn't a Jailbreak Problem Anymore. It's an Architecture Problem.

For two years, prompt injection got treated like a party trick. Someone tricks a chatbot into saying something embarrassing, a screenshot goes around, everyone moves on. That era is over. CrowdStrike's February 2026 Global Threat Report, built on frontline intelligence across more than 280 tracked adversaries, found threat actors injected malicious prompts into legitimate generative AI tools at over 90 organizations in 2025, stealing credentials and cryptocurrency in the process. The report's framing is blunt: prompts are the new malware.

That's not a hypothetical anymore. It's an incident category with a body count, and it maps directly onto the three patterns most production AI systems are actually built from: retrieval pipelines, model routers, and tool-calling agents. Each has a distinct injection vector. Each needs a distinct containment control. Generic advice like "sanitize your prompts" doesn't hold up against any of them. What follows is an architecture-by-architecture walkthrough of what's actually being exploited and what stops it.

RAG pipelines: the poisoning happens before the query

Most RAG security discussion focuses on accuracy: does the system retrieve the right chunk, does the model hallucinate on top of it. That's a real problem, but it's a different problem from the one attackers are now exploiting. The documented pattern is supply chain poisoning of the retrieval corpus itself. Attackers write documentation, blog posts, GitHub READMEs, or forum answers containing hidden instructions, then wait for an enterprise's ingestion pipeline to pull that content into its knowledge base. The payload sits dormant in a vector store until a user's query happens to retrieve it, at which point the model reads it as part of its context and follows the embedded instruction as if it came from the system prompt.

This is nasty for a specific reason: nothing about the ingestion process looks anomalous. The content passes whatever quality filters you have because it reads like normal technical writing. The attack doesn't fire until retrieval time, potentially weeks or months after ingestion, which makes root-causing an incident brutal. If your RAG pipeline pulls from public sources, package registries, GitHub, Stack Overflow clones, partner wikis, you have already ingested content you didn't write and don't fully control.

The mitigation isn't better retrieval ranking. It's treating every retrieved chunk as untrusted input, structurally, not just semantically. That means: strip or neutralize anything that looks like an instruction inside retrieved content before it reaches the context window, tag retrieved text distinctly from system and user turns so the model has a signal to weight it differently, and restrict what actions a RAG-backed agent can take as a direct consequence of what it reads. If a support bot's RAG source can cause it to draft an email, that's fine. If it can cause the bot to call a refund API or change account permissions, that's the actual attack surface, and it needs a gate independent of what the retrieved text says.

Model routers: attacking the choice, not the model

Multi-model stacks are now common enough that they've become their own attack surface. Enterprises route between models for cost, latency, or capability reasons, sending simple queries to a cheap model and complex or sensitive ones to a stronger, better-guarded one. Attackers have started crafting prompts specifically designed to manipulate that routing decision, phrasing a request so the router classifies it as low-complexity or low-risk and sends it to the weakest, least-guarded model in the stack, where the same request that a flagship model would refuse gets processed without friction.

This is a genuinely novel failure mode, and most teams running multi-model architectures haven't threat-modeled it at all. The mental model teams use for routers is almost always cost and performance, not adversarial input. But a router is a classifier making a security-relevant decision, and classifiers can be gamed.

The mitigation isn't a smarter router. It's refusing to let routing be a security boundary in the first place.

Concretely: don't let model choice be the only thing standing between a user and a dangerous capability. Apply the same permission and content-filtering layer downstream of every model in the router's pool, not just the strongest one. If your weakest model doesn't have the same guardrails as your primary model, an attacker who can influence routing has effectively picked the guardrails they want to face. Route on cost and latency all you want, but treat the security boundary as a separate, uniform layer that sits outside the routing decision entirely.

Tool-calling agents: this already happened, not hypothetical

It's tempting to treat all of this as speculative until you see a live case. Palo Alto's Unit 42 documented one: an attacker used indirect prompt injection to bypass an AI-based ad-review system, embedding instructions in content the reviewing model would process rather than attacking the model directly. Unit 42's note on the case is worth sitting with: the attacker used multiple indirect prompt injection methods, showing that actors are both adopting more sophisticated payloads and pursuing higher-severity intents than the low-severity behaviors observed previously.

That last clause matters. Early prompt injection incidents were mostly proof-of-concept: get the model to say something it shouldn't, embarrass a vendor, post a screenshot. What Unit 42 documented is different in kind, an attacker using injection to bypass a system that exists specifically to gate access or approve content, with real downstream consequences. That's the trajectory: injection techniques maturing from novelty to tooling used against systems that make real decisions with real permissions attached.

For agent architectures, the lesson isn't

For agent architectures, the lesson isn't about writing a better system prompt. It's that any agent with a tool that changes state, approves something, moves money, or grants access is a target regardless of how carefully its instructions are worded, because the attacker's payload doesn't have to convince the model of anything. It just has to be present in content the model processes as part of doing its job.

The shift: from prompt-level defenses to architecture-level containment

The practitioner consensus emerging from this wave of incidents is a real shift in how defense is framed. The old approach was prompt-level: tell the model what it should and shouldn't do, add refusal instructions, hope the system prompt holds under adversarial pressure. That approach is failing in the field because it treats the model's judgment as the security boundary, and judgment is exactly what injection attacks target.

The approach that's actually holding up is architectural, and it comes down to three moves:

• Limit what the model can do, not just what it should do. Permissions and scoped credentials, not instructions, are the enforceable boundary.
• Treat all external data as potentially hostile, including your own RAG sources. Ingestion doesn't confer trust.
• Require human approval for high-impact actions. If a tool call moves money, changes permissions, or is irreversible, put a person in the loop regardless of how confident the model is.

None of these are novel ideas in security generally. They're the same principle of least privilege and defense in depth that's existed for decades. What's new is applying them specifically to LLM-driven systems, where the natural instinct is to solve everything at the prompt layer because that's the layer you can iterate on fastest. Prompt-layer fixes feel productive because you can test them immediately and see the model behave better. But they don't hold under adversarial pressure the way a hard permission boundary does, because the attacker gets to choose the input and iterate against your defenses just as fast as you can write them.

What this means for how these systems get built

The practical takeaway isn't

The practical takeaway isn't to slow down AI adoption. It's to stop treating injection defense as a separate security review that happens after the architecture is set, and start treating it as a design constraint on the architecture itself. When you're deciding how a RAG pipeline ingests content, that's the moment to decide how retrieved text gets tagged and filtered, not after launch. When you're wiring up a model router for cost savings, that's the moment to decide whether every model in the pool gets the same downstream guardrails. When you're giving an agent a tool that can take a real-world action, that's the moment to decide whether it needs a human approval gate, not after an incident report.

The CrowdStrike numbers and the Unit 42 case study aren't warnings about some future risk. They're documentation of what happens when these decisions get deferred. The systems that get exploited aren't the ones with weak prompts. They're the ones where permissions, trust boundaries, and approval gates were treated as optional polish instead of load-bearing architecture from the start.