Prompt injection: direct and indirect

Prompt injection occurs when content supplied to a language-model application redirects behavior away from the application's intended instructions or task. Direct injection arrives through an input supplied to the application. Indirect injection arrives through material the application retrieves or reads, such as a document, website, or tool result.

OWASP's prompt-injection guidance distinguishes these entry points and describes mitigations. The problem starts when the application treats text it was meant to read as instructions it should follow.

Explore Dome: Dome Platform · Docs: Security tutorial.

A legitimate request can retrieve an injected instruction

Suppose a user asks an assistant to summarize a supplier's document. The document includes text telling the assistant to ignore its task and transmit internal notes to another destination.

The user's request is legitimate. The attacker controls the document, not necessarily the user or application. If the assistant follows the document's instruction, the untrusted source has redirected the workflow.

Treat the supplier document as content to summarize, not as permission to send internal notes. The same applies if that text arrives through an approved search tool or appears in a cited source.

Prompt injection can affect more than the wording of an answer. The damage depends on which tools the application can use, which data it can read, and where it can send it.

Explore Dome: Tool Gateway · Docs: Tools gateway.

Reduce the effect an injected instruction can have

Limit what injected text could cause at several points:

• In the application, label and isolate untrusted content, keep the task narrow, and leave unnecessary secrets out of context.
• At tool and data connections, restrict allowed operations and inspect relevant inputs and outputs.
• Before a sensitive action, require approval for that specific action when the workflow calls for it.

These controls can limit the damage even if the injected instruction goes undetected.

For the supplier-document example, ask whether the application can access internal notes at all, whether it can send them externally, and whether the receiving destination is restricted. Blocking that transmission can protect the notes even if the model tries to send them.

Dome's rules and guards apply configured controls to traffic routed through Dome. Pattern-based inspection checks for configured matches; it cannot reliably determine the intent of every instruction.

Explore Dome: Authorization · Docs: Guards.

Test whether injected text can cause an unwanted action

Create a controlled example using synthetic content and a harmless destination. Record the original user task, the untrusted instruction, the proposed action, the enforcement result, and any backend effect.

Then include a legitimate document containing similar language, such as a security training example. A detector that blocks every mention of an attack can make a useful document-analysis workflow unusable.

Record both what the model attempted and what actually ran. If it tried to transmit the notes but the connection blocked them, the control worked for that test. If it ignored the instruction, you still need to test whether an attempted transmission would be stopped.

See tool poisoning for attacks carried by tool definitions and changes, and least privilege for limiting the actions an injected instruction could cause.

Explore Dome: Tool Gateway · Docs: Security tutorial.