Prompt Injection Defenses

The core principle: never make the model the security boundary

Prompt injection defenses work best when the model is treated as an unreliable interpreter of untrusted text, not as the component that enforces authority. A model can help classify, summarize, draft, and plan. It should not be the only thing deciding whether a user may see a record, whether an email should be sent, whether code should execute, or whether a transaction should proceed.

OWASP's LLM01 guidance is careful on this point: there may not be foolproof prevention. That is not a reason to give up. It is a reason to layer controls so one model failure does not become a full application compromise.

Controls that matter more than clever prompting

The strongest controls are boring software security controls adapted to LLM workflows. Use per-user authorization before retrieval. Give tools narrow scopes. Use read-only credentials where possible. Apply deterministic validation to every tool call. Avoid free-form code execution. Keep sensitive data out of prompts unless it is truly needed. Make the model ask for human approval before actions with financial, legal, security, or privacy consequences.

Output handling deserves the same attention as input handling. If the model returns HTML, Markdown, SQL, code, JSON, links, file paths, or tool parameters, validate those outputs in normal software. Parse structured output with a schema. Reject unknown fields. Validate destinations. Refuse actions that do not match the user's original intent and permissions.

Useful architecture patterns

The dual-LLM pattern separates privileged planning from untrusted-content processing. A privileged model receives trusted user intent and may call tools. A quarantined model reads untrusted text without tool access and returns bounded summaries or extracted fields. The privileged side can refer to those results, but untrusted text does not get direct access to tools.

Action-selector designs go further: the model does not invent arbitrary tool calls. It chooses from a constrained set of actions, and ordinary code decides whether the action is allowed. Plan-then-execute designs separate a proposed plan from execution, giving the application and user a chance to review before anything irreversible happens. Context minimization reduces the amount of untrusted and sensitive material present in any one model call.

Why input filtering alone fails

Filters are useful as one signal. They are not a complete defense. Natural language is flexible, and malicious instructions can be paraphrased, encoded, split across documents, hidden in markup, embedded in images, or disguised as data. A model-based detector can catch known patterns, but it can also miss adaptive attacks or block legitimate content.

Use filters to reduce noise and catch obvious cases. Then assume some hostile content will pass through. The hard controls are downstream: privileges, validation, confirmations, sandboxing, monitoring, and rollback.

Defensive checklist

• Map inputs. Identify every place untrusted text can enter model context.
• Map authority. List every tool, credential, dataset, and user-facing output the model can influence.
• Apply least privilege. Scope retrieval and tool access to the current user and task.
• Validate tool calls. Enforce policy outside the model before execution.
• Use allow-lists. Prefer known actions, domains, recipients, and parameters over open-ended generation.
• Add human review. Require confirmation for destructive, external, financial, legal, privacy, or security-impacting actions.
• Instrument everything. Log retrieved sources, prompts, outputs, tool calls, denials, and user confirmations.
• Red-team continuously. Re-run tests as models, tools, prompts, retrieval, and product flows change.