Prompt Injection Defense: Block vs. Deceive

The standard playbook for prompt injection defense is input validation, output encoding, and model monitoring. One production ERP deployment using this approach claims a 90% reduction in successful injection attacks and a 40% decrease in response latency. The latency number is suspicious on its face, since defensive layers typically add overhead rather than remove it, and neither figure comes with methodology, baseline conditions, or independent verification. But even accepting the directional claim, 90% reduction means 10% of attacks still land. In a system with real tool access, that residual is not a rounding error. It is a breach surface.

The interesting question is not whether blocking defenses work. They work well enough in narrow contexts. The interesting question is what they structurally cannot do, and why the answer to that question is forcing a different architecture into existence.

Blocking Is a Losing Posture at Scale

Every Filter Creates a New Attack Surface

Input validation against prompt injection is pattern-matching against an open-ended generative space. Attackers iterate. Your filter rules do not iterate on their own. The asymmetry is fundamental: the defender must catch every malicious variant, the attacker only needs one that slips through. As injection techniques evolve from simple role-override strings toward multi-turn semantic manipulation and indirect injection through retrieved documents, the filter surface expands faster than any static ruleset can track.

The ERP context makes this concrete. A financial planning module that accepts natural language input is processing semantically rich text by design. Any filter aggressive enough to catch sophisticated injections will generate false positives on legitimate complex queries. That tradeoff gets worse as the application domain gets more specialized, because legitimate domain language increasingly overlaps with adversarial prompt structure. Legal and financial language, in particular, frequently contains conditional instructions, role definitions, and authority-granting statements that pattern-match against injection signatures.

Defenses Demand Constant Reinvestment, Not One Payment

The 20% development time overhead cited for implementing these defenses is a recurring cost, not a one-time investment. Every model update, every new input modality, every expansion of agent capabilities requires re-validating the defense layer. Teams underestimate this maintenance burden consistently.

Defenders Are Flying Partially Blind

The deeper problem with pure blocking is informational. A blocked request tells you that something was blocked. It tells you nothing about the attacker's technique, their persistence, their objectives, or whether the same attack is being tried at scale across your system from multiple vectors simultaneously. You accumulate a log of stopped events with no intelligence about the threat actor or the evolving attack surface.

This is tolerable when the adversary is a casual user testing boundaries. It becomes untenable when the adversary is systematic and adaptive, which is exactly what you should expect as AI agents gain more valuable capabilities. A financial planning agent with real transaction authority or a code execution agent with filesystem access is worth attacking carefully. The attacker who finds that value will iterate methodically. Your block log gives you nothing to work with.

Honeypot Architecture Changes the Information Game

The MIRAGE system takes the opposite posture. Rather than blocking high-risk prompts, it redirects them to a decoy persona that returns fabricated responses. The scoring layer, called Lobster Trap, evaluates messages for injection patterns, jailbreak attempts, role manipulation, and exfiltration signals before routing. Sessions are logged with full transcripts and tagged against MITRE ATLAS technique categories.

The intelligence gain here is real and structurally different from what blocking provides. A full session transcript with ATLAS technique tags tells you which injection category the attacker is using, how they adapt when initial attempts fail, and what they are ultimately trying to extract. That data is operationally useful in ways that a block event is not. It lets you update your scoring model with empirically observed attack patterns rather than theorized ones. It also means the attacker spends time and compute against a decoy instead of probing your real system boundary.

Blocking an attacker costs them nothing. Wasting their time against a convincing fake costs you almost nothing and costs them everything they were willing to spend.

ATLAS Mapping Turns Noise Into Actionable Intelligence

The MITRE ATLAS tagging is particularly worth noting for teams building serious security postures. ATLAS is the adversarial ML threat matrix, purpose-built for AI system attacks. Mapping observed injection attempts to ATLAS technique identifiers makes your threat intelligence portable, comparable across systems, and compatible with the emerging STIX/TAXII export that MIRAGE has on its roadmap. That is the foundation of a threat-sharing ecosystem, not just a local defense.

MIRAGE is described as alpha-stage open source, which means the core pipeline works but production hardening is on you. The attacker cost dashboards and STIX/TAXII IOC export are planned, not shipped. Apply appropriate expectations.

The Architectural Fork That Is Quietly Becoming Mandatory

Agent Capability Is the Forcing Function

Both of these systems are responding to the same pressure: agents are getting real capabilities. Tool access, persistent memory, multi-agent orchestration, and execution authority are moving from experimental to standard deployment configurations. That shift changes the threat model categorically, not incrementally.

When an LLM is a read-only question-answering layer, a successful injection is embarrassing. When that same LLM has write access to a database, can call external APIs, or can schedule actions that outlive the session, a successful injection is a security incident. The defenses appropriate for the first case are necessary but insufficient for the second.

Capabilities Outpace the Architecture Defending Them

This is the direction of travel that most teams are not yet pricing into their architecture decisions. The blocking-plus-monitoring stack from the ERP example is competent for today's deployment profile. It is not adequate for the agent profile that will be standard in eighteen months.

What a Mature Defense Stack Actually Looks Like

The emerging answer is not a choice between blocking and honeypotting. It is layered architecture where both operate in sequence:

The hard engineering problem in this stack is the scoring layer. A sidecar that adds meaningful latency to every request defeats the purpose. The Lobster Trap approach suggests this is solvable, but the alpha status means there is no production latency data to evaluate. Teams building this today will need to instrument carefully.

Convincing Decoys Demand Surprisingly Deep Character Work

The secondary hard problem is decoy persona quality. A decoy that does not convince the attacker to keep interacting provides no intelligence and no resource drain. Designing a persona that is plausible enough to sustain multi-turn adversarial sessions without either revealing real system information or breaking character is a non-trivial prompt engineering task that most teams have not done.

Where This Leaves You Today

The field is moving from "prevent injections" to "operate intelligently under the assumption that some injections will succeed." That is a different security philosophy and it requires different tooling, different logging infrastructure, and different threat modeling processes.

Teams still treating prompt injection as an input sanitization problem are one capability upgrade away from an inadequate posture. The agents you are deploying next quarter will have more tool access than the ones you shipped last quarter. Your threat model needs to be ahead of that curve, not catching up to it.

Sources: Dev.to: LLM tag (May 23, 2026), DEV.to (May 22, 2026)