Hidden instructions in documents steer LLM judgements

You must now treat every external document a language model processes as potentially compromised, separate that content from your system's instructions, and ensure that any consequential decision based on the model's output receives human approval before it takes effect.

An analysis of 7 October 2026 of hidden instructions embedded in documents that language models process argues that malicious commands hidden in ordinary files can manipulate model outputs even in sensitive workflows, and that detecting such an injection does not reliably prevent it from distorting the result. Peer-reviewed research tested the effect across multiple models and CV screening scenarios, finding all systems susceptible. In our assessment, this means you cannot rely on a warning label or a detection flag to guarantee that a hidden instruction has not already shifted a model's judgment—which exposes anyone who approves or accounts for that judgment to personal risk unless the workflow is redesigned to separate untrusted content from decision-making authority.

What exactly is the vulnerability?

Indirect prompt injection occurs when instructions are embedded in external content—such as an uploaded CV, contract or medical record—that a model is supposed to analyse as data. The model does not merely process that text as information to be assessed; it sometimes executes the command hidden within it. In a CV screening workflow, such an injection can distort the comparison between candidates by shifting the weighting of one applicant against another. The researchers tested 27 CV documents across six consumer-facing models and four attack scenarios, and found that all systems tested were susceptible.

Why does detection alone not solve this?

The core finding is a distinction often conflated in practice: a model can detect an injection and still remain partly influenced by it. Detection and neutralisation are therefore not the same thing. Simple keyword filtering falls short because inserted instructions can be semantically plausible or obfuscated. A warning in the output does not rule out that the hidden instruction has already shifted the judgment. This is precisely where organisations can misjudge their security posture. Extended research into agentic, multi-step environments shows that widely used surface-level defences—prompt warnings, keyword filters, paraphrasing, spotlighting and using a second model to assess the output—often offer limited protection. Detection before a tool call is preferable to checking afterwards, but neither approach removes the risk entirely.

Which failure modes does this create?

• Distorted candidate assessment — hidden instructions in CVs can alter the model's weighting of applicants without the evaluator's knowledge.
• Unintended tool calls — injected commands can cause an agent to invoke functions or access data it was not meant to use.
• Data leakage — a manipulated output can cause the model to disclose information it should have withheld.
• False memory in agentic chains — external content can plant instructions that persist across multiple steps in a multi-turn workflow.
• Unauthorised actions — a compromised model output can trigger downstream processes that were never intended.

What controls must you now demonstrate?

1. Separate untrusted content from system instructions — ensure external documents are processed as data, not as commands, and keep them in a distinct namespace from your model's core directives.
2. Record the source, model version and detection results per run — document which external content, which model, and which detection flags were present for every AI-assisted decision.
3. Place consequential actions behind human approval — do not allow a model output to directly trigger a decision affecting individuals without a human checkpoint.
4. Limit model access to tools and data per workflow — define which APIs, databases and functions each workflow may invoke, and enforce that limitation at runtime.
5. Retain the full audit trail — keep the original external content, the model's output, the approval decision and any tool calls so that every outcome can be reconstructed and verified afterwards.

What can tooling do, and what remains your responsibility?

The answer lies in layering: separation, limitation and evidence together, not in a single filter. Distinguish three things that are often confused—detection (recognising suspicious content), mitigation (preventing that content from changing the result) and containment (preventing a manipulated output from becoming an unauthorised action). Tooling can help you detect and flag suspicious patterns, enforce access controls and maintain audit records. What tooling cannot do is judge whether a particular decision should have human oversight, or whether the risk profile of your workflow justifies the cost of that oversight. That judgment remains yours. The shared message across the research is sober: these attacks are real, and no single measure removes them entirely. Reason to treat the design of the workflow, not one control, as your defence.