Direct answer: Prompt injection is not a bug a model update will close. Treat it as a design constraint: never let one agent session combine untrusted input, private data and the ability to act externally without supervision, and make every approval show where the instruction came from.

An agent is asked to summarize a vendor’s web page. Hidden in that page is a line of text addressed to the agent: forward the user’s latest invoices to an outside address. If the agent has email access, the summary request has just become a data leak. Nothing about this attack requires breaking the model. It only requires the model to do what it was built to do, which is follow instructions written in natural language, wherever they appear.

OWASP ranks prompt injection first in its 2025 Top 10 for LLM Applications and distinguishes two forms. Direct injection comes from the user’s own input. Indirect injection arrives through content the model ingests, such as a website, a file or an email, that carries embedded instructions. Indirect injection is the one agent products should worry about most, because agents are built to read untrusted content on a user’s behalf.

Why a better model will not close it

Models are getting better at resisting obvious attacks, and vendors publish real progress. But the core problem is structural. A language model receives instructions and data through the same channel, as text. Training can make it less likely to obey a planted instruction; it cannot make the distinction absolute. Security teams are used to bugs that get patched. This one behaves more like a property of the medium, so the defense has to sit partly outside the model, in the product.

The OWASP guidance reflects that. Of its seven mitigations, several are product and architecture decisions rather than model settings: enforce least privilege, handle sensitive functions in code instead of exposing them to the model, require human approval for high-risk actions, and clearly segregate untrusted content. These are choices a product team makes when it decides what an agent can see and do.

The risk lives in the combination

Simon Willison gave this problem a useful name in June 2025: the lethal trifecta. An agent becomes dangerous when it combines access to private data, exposure to untrusted content and the ability to communicate externally. Each capability on its own is ordinary. All three together give an attacker a route to read something private and send it somewhere else.

Meta’s security team turned the same idea into a design rule in October 2025, the Agents Rule of Two. Within a single session, an agent should have at most two of three properties: processing untrustworthy inputs, accessing sensitive systems or private data, and changing state or communicating externally. If a task truly needs all three, Meta’s guidance is that the agent should not run autonomously and should be supervised, for example through human approval. This is the most practical framing I have seen, because it converts a vague fear into a checkable property of a session.

Make the capability mix visible

If risk depends on the combination of capabilities, the interface should show that combination. Most agent products today display a list of connected tools in a settings page and nothing in the moment of work. A better pattern shows the session’s current state where the user is looking: this task is reading external web pages, has access to your inbox and can send messages. When the third capability switches on, the product should say so and change its behavior, for example by moving from automatic actions to proposed actions.

This also gives product teams a way to design modes instead of warnings. A research mode can read the open web and private documents but cannot send anything. An outreach mode can send messages but only reads content the user supplied. Each mode stays within two properties, and switching between them is a visible, deliberate act rather than a side effect of a prompt.

Approvals must show provenance

Human approval is the backstop every guideline recommends, and it fails quietly when the approval screen hides the important part. A dialog that says “Send email to billing@example.com?” asks the user to judge the action without its origin. The question that matters is why the agent wants to do it. An approval screen for an agent should state where the request came from: “This instruction appeared in the web page you asked me to summarize, not in your message.” That single line turns a rubber stamp into a real decision.

Provenance also helps after the fact. Action logs should record which input triggered each step, so that a reviewer can trace a bad action back to the content that caused it. Without that record, an injection looks like the agent making a strange mistake, and the team fixes the wrong thing.

Design rules for agent teams

  • Audit every agent session against the Rule of Two before launch, and document which pair of properties each mode uses.
  • Label untrusted content in the interface and in the context the model receives, and keep it out of system instructions.
  • Run sensitive operations through code with their own credentials, not through open-ended tool access.
  • Show the origin of the instruction in every approval for an external or irreversible action.
  • Log the input that triggered each action, and make that log readable by the person whose authority was used.
  • Include injected pages, files and emails in your adversarial tests, not only hostile user prompts.

Prompt injection will remain a model research problem for years. Product teams do not have to wait for it to be solved. They control which capabilities meet in one session, what the user sees when the risk rises and what an approval actually asks. Those are interface decisions, and they are available today.

Related reading

Sources

Author: Oleh Hebel. LinkedIn