A Prompt-Injection Defense Playbook for AI Apps in 2026

An AI application may read text that contains instructions written by an attacker. A strong system prompt does not make untrusted content safe, especially when the model can call tools or expose private context.

This guide is designed for developers, security reviewers and agent builders. It turns the topic into a reviewable sequence rather than asking readers to trust a provider label, a detector score or a fluent model answer.

Before you start

Write down the exact task, accountable owner, approved data, affected people and the result that would be unacceptable. Use safe representative examples during the first pass. Where health, legal, employment, financial, safety or regulatory obligations may apply, involve a qualified professional and follow the rules that govern your organization.

1. Label every trust boundary

Separate developer instructions, user requests, retrieved content and tool output in the application architecture. Never merge third-party text into a privileged instruction channel.

Document the decision made during “Label every trust boundary”, the evidence consulted and the person responsible for the next action. That short record helps developers, security reviewers and agent builders distinguish a repeatable control from an informal habit.

2. Limit tools and credentials

Give the model only the actions needed for the current task. Use scoped tokens, narrow parameters and short-lived authorization rather than a broad account credential.

Test “Limit tools and credentials” with a normal case and a deliberately difficult case. Record what passed, what required correction and which condition should trigger a human review for developers, security reviewers and agent builders.

3. Validate before side effects

Check destinations, record identifiers, amounts, file paths and permissions in deterministic code. A model's fluent explanation is not authorization.

Assign an owner and completion criterion for “Validate before side effects”. If the evidence is missing or contradictory, pause the workflow instead of allowing speed or model confidence to become the approval rule.

4. Require approval for consequential actions

Show the proposed action and essential evidence to a person before sending, deleting, publishing, purchasing or changing access.

Keep the input, output version and reviewer note associated with “Require approval for consequential actions” where policy permits. This makes later corrections traceable without retaining unnecessary sensitive data.

5. Test indirect attacks

Seed evaluation documents, emails and pages with conflicting instructions. Confirm that the system ignores them, contains the impact and records the attempt.

Review this step after material changes to the model, provider, prompt, data source or connected system. A control that worked in one configuration should not be assumed to cover the next one.

Common failure modes and controls

The following table is a pre-launch challenge list. Teams should adapt it to the systems, people and permissions in their real deployment.

What to measure

Do not optimize a single headline number. Measure useful outcomes together with correction effort, critical failures and the human work needed to make the result acceptable.

• attack success rate in the red-team setDefine the numerator, denominator, owner and review period for attack success rate in the red-team set; compare like-for-like workflow versions.
• unauthorized tool calls blockedTrack unauthorized tool calls blocked beside correction effort and serious exceptions so a faster result does not hide weaker quality.
• sensitive-data disclosure rateSample sensitive-data disclosure rate by risk level and user group; investigate material changes instead of relying on one aggregate percentage.
• human approval bypass rateSet a baseline for human approval bypass rate, record the intervention and review whether the change remained useful after human verification.

Final review checklist

• Trust boundaries are documented
• Tools use least privilege
• Arguments are validated
• High-impact actions need approval
• Adversarial tests run in CI
• Security events are retained safely