When an LLM application reads user or external content, that content can influence its next decision. Prompt injection becomes a security issue when the influenced model can reach private data, invoke tools, change state, or communicate externally.

This page is a practical starting point. For the full threat model, provenance-aware data flow, bound approvals, sandboxing, and incident response, use the complete prompt injection defense guide.

1. Define the Boundary You Need to Protect

Do not begin with a list of suspicious phrases. First document:

  • the authenticated user, tenant, and resources available to the workflow;
  • untrusted sources, including documents, web pages, tool output, OCR, and memory;
  • available reads, writes, purchases, sends, and network destinations;
  • invariants that must hold even if hostile content changes model behavior.

Example: content in a support ticket can affect a draft reply, but it must not select a recipient, access another tenant's order, or approve a refund. These are application policies, not promises that a prompt can enforce.

2. Recognize the Relevant Attack Surfaces

Injection can be direct user text or indirect content retrieved from a page, email, repository, RAG chunk, image, or tool result. It can also persist through generated summaries, configuration, or memory. Treat every external source as data rather than as authorized policy.

Keyword patterns, encoding normalization, and safety classifiers are useful for telemetry, triage, and reducing known abuse. They cannot reliably infer intent across languages and contexts, and a “safe” classifier result must never grant permission.

3. Build the Firewall Around Effects

Keep Instructions and Data Distinct

Use provider-supported roles and clear data delimiters so the model can reason more reliably. Do not concatenate secrets into prompts. This reduces confusion but is not access control: handwritten XML or JSON boundaries do not make untrusted text safe.

Apply Least Privilege and Deterministic Authorization

Give the model only task-scoped capabilities. Before a tool executes, application code should check the real user and tenant, object ownership, action and argument schema, destination, data labels, rate limits, and whether a precise user confirmation is needed. The model proposes; trusted code decides.

Control Context, Output, and Egress

  • preserve source and trust metadata through retrieval, OCR, extraction, and summaries;
  • enforce document ACLs before RAG ranking and separately authorize persistent-memory writes;
  • validate generated structured output before it becomes a tool argument;
  • sandbox generated code and restrict network destinations, redirects, logs, URLs, and rendered content;
  • bind human approval to the exact final recipient, resource, data fields, amount, and irreversible effect.

4. Test Complete Attack Chains

Use isolated AI red-team testing to exercise direct and indirect sources, tool-argument manipulation, RAG and memory poisoning, multilingual or multimodal variants, and repeated attempts. Measure unauthorized actions, data egress, and changes to durable state alongside legitimate-task accuracy, false refusals, latency, and cost. A model refusal is not a success if an external action already occurred.

Conclusion

An LLM firewall is not a single classifier or prompt template. It is a set of controls that prevents untrusted language from gaining authority: limited capabilities, deterministic authorization, source-aware data flow, constrained egress, exact approval, and continuous evaluation.