Can I prevent prompt injection without an external proxy?

You can reduce the attack surface significantly with prompt construction discipline (Layer 1), retrieval-time content evaluation (Layer 2), and post-response output checks (Layer 4). The residual surface includes encoded payloads, multi-turn persuasion, authority impersonation, and long-context dilution. The audit record the EU AI Act Article 12 and DORA Article 19 reviewers expect is also missing because the application controls every write path. The request-boundary layer is the architectural piece that closes the residual surface and produces the audit record. The defense is materially weaker without it.

What policy primitives does the request-boundary layer enforce?

Pattern matchers for instruction-override phrases, role-reversal framing, and authority impersonation. Canonical-form decoders for base64, hex, and zero-width Unicode. Identity-bound rules that verify the prompt's identity claims match the authenticated user. Data classification rules that detect PII, PHI, or financial data and apply redact or block actions. Conversation-aware rules that maintain state across turns. Each primitive produces a deterministic decision and an audit record.

Does prompt injection prevention apply to internal-only AI deployments?

Yes. The Meta March 18 Sev-1, where an internal AI agent exposed sensitive data to authenticated employees who should not have seen it, illustrates the pattern. Internal users have application credentials and can issue prompts that violate the organization's policy. The prevention layers apply identically to internal deployments. The audit record matters more in internal deployments because the regulator and the customer auditor often arrive after an internal incident has expanded into a disclosure event.

What happens if the request-boundary layer fails?

The layer is deployed in a fail-closed posture by default. If the inspection layer cannot reach the policy decision point or cannot commit the audit record, the request is denied. The fail-closed default matches what the EU AI Act and HIPAA Security Rule reviewers expect from a control on a high-risk decision path. Production deployments measure the layer's availability at 99.99%+ and the latency at under 50 ms from internal DeepInspect testing. The reliability budget for the inspection layer is the same budget regulated organizations apply to other inline security controls.

How does the four-layer model map to OWASP LLM Top 10?

OWASP LLM01 (Prompt Injection) is addressed by all four layers, with the request-boundary layer carrying the deterministic enforcement and the audit record. LLM02 (Sensitive Information Disclosure) is addressed at Layer 3 (data classification on the input) and Layer 4 (output checks). LLM06 (Excessive Agency) is addressed at Layer 3 (per-decision authorization). LLM08 (Vector and Embedding Weaknesses) is addressed primarily at Layer 2 (retrieval-time evaluation). The four-layer model covers the LLM Top 10 categories that have a control point at the HTTP request path.

How to Prevent Prompt Injection: The Four Control Layers That Hold Up in Production

Prompt injection prevention in production AI deployments is not a single control. The class of attacks that OWASP catalogs under LLM01 spans direct prompts, indirect injection through retrieved content, tool-result injection in agent loops, multi-turn persuasion, and several encoded-payload variants. A single control layer cannot stop all of them. The pattern that holds up under EU AI Act Article 12 and OWASP LLM01 review is a four-layer architecture where each layer addresses a specific class of attack, and the inspection layer at the HTTP request boundary is the deterministic enforcement point that produces the audit record.

I want to walk through what each of the four layers can and cannot prevent, where most deployments stop, and the architectural pattern that closes the rest of the gap.

Why a single control layer cannot stop prompt injection

The model treats the application instructions and the user-supplied content as a single context window. The application has no architectural way to mark which spans of the prompt are instructions and which are user input. The model has no architectural way to authenticate a claim like "ignore previous instructions" against the application's actual policy. The attacks that exploit this absence of a labeled boundary cannot be stopped by either side alone.

I argued this position in the model guardrails analysis. Refusal behavior trained into the model is probabilistic and degrades under adversarial pressure. Application-side filters cannot evaluate what spans of the prompt the model will treat as instructions. The defense has to span multiple layers, each addressing what the others architecturally cannot.

Layer 1: prompt construction discipline

The first layer is the work the application does when it builds the prompt. Construction discipline covers the patterns that reduce the surface area: structured prompts that separate the application instructions from the user content using delimiters and roles, output schemas that constrain the model to a typed response, and prompt templates that limit the user-controlled span to a specific function.

Construction discipline reduces compliance with the simpler payloads. It does not stop indirect injection through retrieved content, tool-result injection in agent loops, multi-turn persuasion, or encoded payloads. Stanford Trustworthy AI and the AIUC-1 Consortium briefing summarized by Help Net Security found that prompt construction alone leaves a material residual attack surface.

Layer 2: retrieval-time content evaluation

The second layer addresses indirect injection. When the application retrieves a document, a web page, or a tool result into the prompt, the retrieved content carries a different trust level than the user input. Retrieval-time evaluation applies a separate policy to the retrieved content: classify the source, detect instruction-like spans, strip or quarantine high-risk content before it enters the model context.

The layer prevents most of the indirect prompt injection attacks I have seen in production RAG and agentic browser deployments. The limitation is that the application has to actually run the evaluation. Many deployments skip the step because the engineering cost is real and the security benefit is not visible until the first incident.

Layer 3: request-boundary policy enforcement

The third layer is the inspection point at the HTTP path between the application and the model. The layer evaluates every request against per-route, per-role, per-classification policies. The evaluation is deterministic. The decision (permit, redact, block) is committed before the request reaches the model.

The layer addresses the attack classes that the first two cannot:

Multi-turn persuasion, by maintaining conversation state across turns
Encoded payloads, by canonicalizing the prompt before policy evaluation
Authority impersonation, by verifying that identity claims match the authenticated identity
Long-context dilution, by scanning the full input rather than a head sample

The layer also produces the audit record. Every decision generates a per-decision record containing identity, role, policy version, data classification, and outcome. The record is signed and committed before the response returns to the application. I walked through the architecture in the inline enforcement piece.

Layer 4: post-response output checks

The fourth layer evaluates the model output before the application acts on it. The output check catches payloads where the model has been induced to produce content the application would not have approved if asked: leaked system prompts, prohibited data classes in the response body, or tool calls that exceed the user's authorization.

The layer prevents output-formatting hijack and several agent-loop attacks where the immediate next action is the harmful step. The limitation is that the output check fires after the model has done its work, which means latency cost and a window where the application may have already started downstream effects. The check is necessary but is not sufficient on its own.

Why most deployments stop after Layer 1

Layer 1 is application code. Engineering teams implement it as part of normal feature work. Layer 4 is also application code and is often added after the first incident. Layer 2 requires a separate retrieval pipeline component. Layer 3 requires an inspection point in the network path between the application and the model.

The third layer is the one most deployments skip. The engineering cost is higher than Layer 1, the security benefit is not visible until an incident or an audit, and the architectural pattern (an external proxy in the AI request path) is unfamiliar to teams that have not run an enforcement layer before. The result is that most production deployments have construction discipline, partial retrieval evaluation, and post-response checks, with no request-boundary policy. The audit record is missing. The deterministic block decision is missing. The forensic chain stops at the application boundary.

What surviving a regulatory review requires

EU AI Act Article 12 requires automatic recording of events over the lifetime of the system. The records must be detailed enough to reconstruct what happened, who initiated it, and what data was involved. Layers 1, 2, and 4 do not produce records the regulator will accept because the application controls the write path. The application can wipe, suppress, or fail to commit the record. A record the application controls is self-attestation.

The third layer is the only one that produces an audit record outside the application's custody. I covered the architectural reasoning in the EU AI Act Article 12 walkthrough. The pattern emerges from the regulation, not from product marketing.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits inline at the HTTP path between the application and any LLM. The layer evaluates per-route, per-role policies against the user-supplied prompt content, the retrieved-document content, and the agent-loop tool results. The decision is deterministic. The record is signed and committed before the model receives the request.

The DeepInspect mechanism does not replace Layers 1, 2, or 4. The four layers form defense in depth. The third layer is the one that produces the audit record, fails closed under load, and stops the attack classes the application cannot address alone.

If your AI deployment is running on Layer 1 alone, the residual prompt injection surface is broad. Run the free AI Readiness Check to see where the gaps sit in your stack.