Blocking prompt injection hidden in LLM web search results

How indirect prompt injection arrives through search results

Indirect prompt injection occurs when an LLM accepts input from external sources such as websites or files. The injected text does not need to be visible or readable to a person. It only needs to be parsed by the model. Hidden instructions, invisible Unicode characters and zero-width spaces are all documented concealment methods in ingested content.

When an agent browses the web, reads files and calls external APIs, every external data source becomes a potential attack vector. A search snippet or a fetched page enters the context window alongside the system prompt and the user request. The model has no built-in boundary between instructions and data, so text on a page can be interpreted as a command.

The consequences map to three outcomes. The model can be redirected, so that it leaks its system prompt or emits exfiltration markup. Data in context can be sent to an attacker-controlled server, as in the GrafanaGhost case, where an indirect injection path in an observability platform's AI features could push sensitive data out through external rendering flows. And an agent with broad access can be pushed into a confused-deputy action it would not otherwise take. GrafanaGhost is not a web search case, but it shows the same path from untrusted content to data egress.

Why no single control fully stops it

OWASP states that no mitigation eliminates prompt injection entirely. It also states that RAG and fine-tuning do not fully mitigate it, and that system prompt safeguards alone are not sufficient. Prompt wording, labels such as "the following is untrusted data" and deny lists raise the cost of an attack, but they are not an enforcement boundary. Deny lists miss rephrased instructions.

Screening retrieved content has limits too. Pattern-based filters do not reliably catch indirect injection. A trained classifier catches cases that regex misses, but screening cannot stop an injection it fails to detect, and it does not cover content that arrives through other channels. Output inspection is detective: it runs after the model has already interpreted the injection.

NIST makes the same point for agent systems. Multiple design tenets may be needed to mitigate a specific attack, and deterministic decisioning outside the reasoning engine can limit the impact of injection. The practical conclusion is to assume some injected content will reach the model, and to design the layers after retrieval so that a successful injection cannot do much.

Evidence to retain for each interaction and tool call

Controls matter to an auditor only if you can show they operated. For each search-augmented interaction, retain a decision record that answers four questions: what was retrieved, what policy applied, what decision was made, and what happened next.

A practical record includes a timestamp and the identity of the user or agent; the policy version evaluated; a reference to the retrieved content, such as source identifier, chunk count and size; the result of any screening; the tool call requested and its parameters; the decision (allow, redact, block, rate limit or escalate); the approver and outcome where a human was involved; and the resulting action.

Two cautions apply. First, record what the check proves and no more. A matching content digest shows consistency with an approved baseline, not that the content is safe or free of injection. Second, log security-relevant metadata and decisions, but exclude credentials, secrets and unnecessary sensitive prompt or response content, so the evidence store does not become a new exposure. Redact parameters before they are written.

NIST AI RMF notes that human intervention may be needed where an AI system cannot detect or correct errors. Records of escalations and approvals show that this intervention happened. Documenting the controls as layered, rather than as one filter, is also more accurate to how they work.

Where runtime policy enforcement fits

The tool-call and egress layers are where a decision has to be made outside the model and produce a record. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit or escalate for human approval to individual interactions and tool calls. Enforcement happens at runtime, not after the fact, and it generates audit-ready evidence as a by-product of each decision. It can be self-managed in the customer cloud, with configurable retention and data residency.

That is one layer of the design described above. It does not replace content screening or prompt structure, and it does not make detection perfect. It limits what a successful injection can reach and gives a regulated enterprise a record of what its AI was allowed to do and what it did.