Prompt injection is an impact problem, not just an input problem

Many prompt-injection defenses ask one question: can we detect the malicious text? That is useful, but it is not the whole security problem.

The harder question is what happens when detection misses. If one persuasive instruction can turn a read task into an external send, a recommendation into a purchase, or a document summary into a credential-bearing tool call, the system has given untrusted content too much influence over consequential action.

Why filtering alone is a weak boundary

Prompt injection occurs when content processed by a model contains instructions that compete with the task the user or developer intended. The content can arrive directly from a user or indirectly through a webpage, email, document, tool result, or retrieved record.

In December 2025, the UK National Cyber Security Centre argued that current large language models do not enforce a robust security boundary between instructions and data inside a prompt. Its guidance treats prompt injection as a residual risk to be reduced and managed, not a vulnerability class with a known universal fix. It warns against products that claim they can simply stop it.

OpenAI reached a related conclusion from attacks against browsing agents. Its March 2026 analysis says mature prompt-injection attacks increasingly resemble social engineering. Classifying an input as malicious can become as difficult as detecting a lie without the missing context. OpenAI frames the dangerous combination as a source and a sink: an attacker can influence content, and the agent has a capability that becomes harmful in that context.

None of this makes detection pointless. Model training, classifiers, content separation, link checks, and red teaming can all reduce success rates. But a probabilistic detector should not be the authorization boundary for an irreversible action.

Start from the worst permitted outcome

The NCSC's practical recommendation is to emphasize deterministic safeguards that constrain the system's actions. OpenAI similarly recommends limiting access, requiring review before consequential actions, and giving agents specific tasks rather than broad latitude.

An architecture review can turn that guidance into a source-to-sink exercise:

1. Label trust at ingestion. Identify which content can be influenced by an external party. Email bodies, webpages, files, retrieved records, tool descriptions, and tool results are data, not authority.
2. Inventory dangerous sinks. List every path that can send data, spend money, modify state, reveal secrets, change permissions, publish content, or execute code.
3. Remove unnecessary combinations. A document summarizer usually does not need a send function. A mailbox reader usually does not need delete access. Separate read, draft, and commit capabilities instead of giving one tool a broad command surface.
4. Authorize outside the model. Validate the actor, resource, action, recipient, arguments, and policy in deterministic code or the downstream service. The model can propose an action; it should not decide whether its own proposal is allowed.
5. Make approval concrete. For high-impact actions, show the human the actual recipient, data, amount, permission, or diff. A generic “allow this agent” prompt is not meaningful review.
6. Constrain movement. Use destination allow-lists, scoped and short-lived credentials, sandboxes, rate limits, spend limits, and action budgets. A blocked destination should not be reachable through an overlooked proxy or secondary tool.
7. Record and test the chain. Log enough to connect the untrusted source, model decision, tool arguments, authorization result, and external effect. Test multi-step attacks that combine sources and sinks, not only strings containing familiar jailbreak phrases.

These controls do not eliminate prompt injection. They turn a successful injection from an open-ended compromise into a bounded failure the operator can detect, explain, and recover from.

The PrivacyFirst view

Prompt injection should be managed like social engineering inside a privileged workflow. We do not expect every manipulative message sent to an employee to be identified perfectly; we limit what one employee can approve, require additional review for exceptional actions, and monitor the systems they use.

Agentic systems deserve the same design discipline. The security claim should be about the maximum permitted impact and the evidence left behind—not a promise that the model will never be confused.