Prompt injection, explained for people who have to sign off on it

Prompt injection is usually introduced with a demonstration of someone talking a chatbot into saying something it should not. That framing makes it look like a content moderation problem, which is why it gets deprioritized.

The security problem is a different shape.

The two forms, and only one of them matters much

Direct prompt injection is a user typing something to make the model ignore its instructions. The affected party is the user themselves. It is a product quality issue and occasionally a brand issue.

Indirect prompt injection is instructions arriving inside content the model reads: a document, a web page, an email, a code comment, the response from an API the agent called. The user did not write it and may never see it. This is the security problem, because the attacker is not the person at the keyboard.

Where it becomes a vulnerability

Three conditions together.

1. The model reads content the attacker can influence
2. The model can take actions: call tools, read data, write somewhere, send something
3. Those actions run with authority the attacker does not otherwise have

A model that only produces text for one user to read has a limited blast radius. A model that can query a database, call an internal API or send an email has the blast radius of whatever that tool can reach.

Note that this is not a novel class of problem. It is a trust boundary violation, with a new and unusually permeable boundary. The mitigations look familiar because they are: validate input, constrain what downstream components accept, scope credentials, require authorization for consequential actions.

What the published research shows

This is not hypothetical, and the useful sources are the vendors' own evaluations rather than commentary.

OpenAI's Operator system card documents red teaming of its browser-using agent against adversarial instructions placed in test websites, emails and databases, and reports measurable susceptibility across its evaluated scenarios along with the performance of a monitor built to detect attempts. OpenAI states that known cases were mitigated and that prompt injection remains an ongoing concern.

Anthropic's agentic misalignment work is a different exercise: fictional corporate simulations testing what tool-using models do when given sensitive context, autonomous action, and a constructed goal conflict. The researchers are explicit that the people and organizations were fictional and that this is early-warning evaluation rather than observed behaviour in deployed systems. What it isolates is the capability combination: broad data access plus tool authority plus unreviewed external actions.

Both are controlled evaluations. Neither is a report of an agent independently attacking a customer. Read that way, they are more useful than the headlines, because they describe the conditions under which the risk appears.

What to actually test

Seed injections in every content path. Not just the chat box. Documents the product ingests, web pages it fetches, email it processes, the responses from third party APIs, filenames, code comments, database fields written by other users. Anywhere untrusted text reaches the model's context.

Enumerate tools and the identity each runs as. This is where the severe findings are. An agent calling a backend with a service credential rather than the caller's permissions can reach data the user could not, which turns a content-level attack into a privilege escalation. Ask for the list, ask what identity each tool uses, and test the gap.

Test tenant boundaries in retrieval. Shared embeddings, shared caches and shared vector stores are how one customer's content shows up in another customer's session. This is an ordinary multi-tenancy bug with an unusual storage layer.

Treat model output as untrusted input downstream. Generated text inserted into a page, a SQL query, a shell command or another system's API is where prompt injection becomes code execution. The model is not the vulnerability here; the thing that trusted its output is.

Exercise the approval gates. If a consequential action requires human confirmation, test whether it can be reached without one: through a different entry point, through a chained tool call, through a batched operation.

What not to rely on

Instructing the model not to follow injected instructions. It reduces the rate. It does not close the path. Published evaluations show mitigated susceptibility, not eliminated susceptibility, and a control that works most of the time is not a boundary.

Input filtering for injection patterns. Same argument, and the search space is natural language.

The durable controls are architectural: least privilege on every tool, schema-constrained data passing between components, human approval for irreversible actions, and treating model output as untrusted wherever it lands.

For the questionnaire

Enterprise security questionnaires have moved faster than the compliance frameworks here. Neither SOC 2 nor ISO 27001 names AI specifically, but if an AI feature is part of the system in scope then it is part of what has to be tested, and the questions buyers are asking now are about model access, data use, tenant isolation and what the model is allowed to do without a person in the loop.

Having tested that surface is a better answer than a policy about it.