Prompt Injection Defense Patterns for LLM Powered Applications

Quick answer: there is no complete fix for prompt injection, so design for containment. Treat all external text as untrusted data, give the model only the permissions its task needs, require confirmation for actions with side effects, validate model output before using it, and never place secrets in prompts. Assume some attacks will succeed and limit the damage.

Why Is Prompt Injection Hard to Eliminate?

A language model receives instructions and data as one stream of text. It has no reliable way to tell your system prompt apart from a sentence inside a document, an email, or a web page that happens to look like an instruction. Anyone who can place text in front of the model can try to steer it, which is why this problem differs from classic injection bugs that parameterized queries solve.

There are two forms. In direct injection, a user types instructions meant to override your rules. In indirect injection, the malicious text arrives through content your application retrieves or processes, such as a web page, a support ticket, a PDF, or a tool result. Indirect cases are more dangerous, because the user may be innocent and the application acts on text no one reviewed.

Because models follow instructions probabilistically, filters and clever prompts reduce risk but do not remove it. Treat phrases like ignore previous instructions as one signal among many, not as a complete blocklist. Attackers rephrase, translate, and encode their text, so pattern matching alone will not hold.

Which Patterns Reduce the Impact?

Focus on limiting what a hijacked model can do. These measures work together and are more reliable than trying to detect every attack:

• Separate trusted instructions from untrusted content, label the untrusted parts clearly, and tell the model to treat them as data.
• Apply least privilege to tools: read-only access by default, narrow scopes, and no broad credentials.
• Require explicit user confirmation for actions that send messages, change data, spend money, or touch other systems.
• Do not put secrets, API keys, or private data in the prompt, since the model may repeat them.
• Restrict where model output can go, and avoid rendering it as executable content or unescaped markup.

Isolation matters when an application mixes sources. If one model call reads untrusted web content and another has access to private data and tools, keep them separated so injected text cannot cross from the first to the second. A common design uses a low-privilege step that summarizes untrusted input into a constrained, validated format before a higher-privilege step sees it.

How Do You Validate Output and Monitor?

Treat model output as untrusted input to the rest of your system. If the model returns a tool call, validate the tool name against an allowlist and check every argument against a schema and business rules, just as you would for user input. Reject anything outside expected values, and do not let the model construct raw database queries, shell commands, or URLs that you execute without checks.

Watch for outbound channels. A common exfiltration route is rendering a model-generated link or image whose address contains private data, which sends it to an attacker when the page loads. Restrict allowed domains for links and images, and strip or review URLs in generated content.

Log prompts, retrieved content, tool calls, and decisions, with appropriate privacy controls, so suspicious behavior can be investigated. Test your application with adversarial inputs as part of regular evaluation, and update tests as new patterns appear. Security guidance in this area changes quickly, so consult current industry and provider documentation.

Frequently Asked Questions

Can a strong system prompt prevent prompt injection?

It helps but cannot guarantee safety. Models can still be persuaded to ignore instructions, so rely on permissions, validation, and confirmation steps.

What is indirect prompt injection?

It is when malicious instructions arrive inside content the model processes, such as a web page or document, instead of the user's own message.

Should I filter user input for known attack phrases?

Filtering can catch simple cases, but it is easy to bypass. Use it as one layer, not as your main defense.

Is human confirmation really necessary?

For consequential actions, yes. A confirmation step stops an injected instruction from causing irreversible harm without anyone noticing.

Summary

Design as if injection will sometimes work: separate trusted and untrusted text, minimize permissions, validate every output and tool call, and require confirmation for risky actions. Monitor, test adversarially, and keep secrets out of prompts. Follow current provider and security guidance.