Prompt Injection: What Product Teams Need to Know in 2026

By the UXreviewer.io team4 min read

Prompt injection is an attack in which text supplied to a language model, directly by a user or hidden in content the model reads, overrides the instructions the product intended. For chatbots it can cause embarrassing output; for agents with tools it can cause data leaks and unauthorised actions. As of late 2026 there is no complete technical fix, so the main defence is product design that limits what a successful injection can do.

That makes prompt injection a product decision as much as an engineering one. Which data sources may an agent read? Which actions need confirmation? Which features should not be built yet? This article gives product teams the mental model to answer those questions.

What is the difference between direct and indirect prompt injection?

Direct injection comes from the user typing instructions designed to make the model ignore its rules, reveal its system prompt or produce forbidden content. It matters most when the user is untrusted, for example in a public chatbot.

Indirect injection is more dangerous for agents. The attacker plants instructions in content the agent will process on behalf of a legitimate user: a web page, an email, a PDF, a calendar invite, a code comment or a product review. The user never sees the attack, and the agent may follow the hidden instruction with the user's permissions. Prompt injection is listed first in the widely used OWASP Top 10 for large language model applications, which reflects how central the risk has become.

Why does the risk grow when agents get tools?

Risk follows capability. A useful shorthand is to check whether an agent combines three things: access to private data, exposure to untrusted content, and an ability to communicate externally, for example by sending messages, calling URLs or rendering images from remote addresses. When all three meet, an injected instruction can make the agent read sensitive data and send it to an attacker.

Removing any one of the three greatly reduces the impact. That gives product teams concrete levers: limit data access, restrict which content the agent processes, or block outbound channels for sessions that touched untrusted input.

Multi-agent systems add another path. When one agent passes its output to another, an injection in the first agent's input can travel downstream and trigger actions in a system that never touched the original content. Treat messages between agents as untrusted by default, and give each agent its own narrow permissions.

Which design decisions limit the damage?

These are the same principles we recommend for guardrail design: capability limits first, model behaviour second.

• Least privilege: give each agent only the tools and data scopes its task needs, ideally read-only.
• Confirmation for consequential actions: sending, paying, deleting and sharing require explicit user approval with a clear preview of what will happen.
• Separation of trusted and untrusted content: mark retrieved content as data, and avoid letting it change the agent's goals or tool choices.
• Restricted outbound channels: allowlist domains, disable automatic loading of remote images or links in agent output, and limit recipients.
• Session hygiene: after processing untrusted content, reduce privileges for the rest of the session.
• Visible activity history: users can spot unexpected actions; see our guide to agent audit trails.

What questions should a product manager ask before shipping an agent feature?

If the honest answer to the second question is 'something severe' and there is no confirmation step, the feature needs redesign before launch.

1. Which untrusted sources can reach the model, including uploads, web pages, emails and third-party data?
2. What is the worst action the agent could take if it followed an attacker's instruction?
3. Which actions are irreversible, and do they all require user confirmation?
4. Can the agent send data anywhere outside our systems, directly or indirectly?
5. How would we detect an attack in logs, and how quickly could we disable the feature?
6. Have we tested with injected instructions in realistic content, not only with obvious jailbreak phrases?

How should prompt injection be tested?

Build a library of injected content relevant to your product: support tickets with hidden instructions, documents with white-on-white text, web pages with instructions in metadata, emails that ask the agent to forward data. Run the agent against these with realistic tasks, and check what it attempts, not only what it says.

Add these cases to your regression suite. Model updates, prompt changes and new tools can reopen attack paths that were closed. Coding agents deserve the same attention, because repositories, issues and dependencies are all untrusted content; our article on AI coding agent security covers that side.

What does prompt injection mean for compliance?

A successful injection that leaks personal data is a data breach under the GDPR, with notification duties and potential liability. The EU AI Act expects high-risk systems to be resilient against attempts to alter their use or output, and security questionnaires from enterprise customers increasingly ask about it.

Document your threat model, the controls you chose, test results and residual risks. Being honest that the risk cannot be eliminated, and showing how its impact is contained, is more credible than claiming a filter solves it.

Frequently asked questions