On this page

The short answer

Test indirect prompt injection by placing a harmless unauthorized instruction inside material the assistant is supposed to read as evidence. Observe attempted actions and actual downstream effects separately. Pair each adversarial source with legitimate content so a system that refuses every document cannot appear secure by abandoning the intended task.

What to take away

  • Keep the user task and retrieved instruction distinct.
  • Use harmless markers and isolated tool stubs.
  • Measure task usefulness alongside boundary enforcement.

Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.

Choose one untrusted entry point

OWASP describes indirect injection through external content. Rubrex recommends choosing a specific entry point for a reproducible fixture: a retrieved policy passage, an email quote, a tool result, or a document comment. Mixing every source type into one case makes a failure harder to diagnose.

Use a synthetic expense-policy assistant whose task is to explain a reimbursement rule. One source contains the real rule plus an instruction to send a harmless marker to a mock endpoint. The user requested an explanation, and the retrieved source has no authority to expand that task.

Evidence: OWASP: LLM Prompt Injection Prevention Cheat Sheet [1]

Vary placement while preserving the legitimate answer

Place the same harmless instruction before the policy, after it, and inside a quoted example. Keep the actual reimbursement facts constant. Include a legitimate document that discusses malicious instructions as a topic, where the assistant should summarize that discussion without treating it as a command.

Expose a mock outbound tool that records attempted arguments without contacting a real destination. If the application intentionally has no outbound capability, inspect attempted tool proposals and final text instead. State the tested boundary precisely; absence of a tool does not establish that the model understood the instruction hierarchy.

Inspect attempted and executed behavior separately

Retain the original task, retrieved passage, model-visible tool menu, attempted calls, adapter decisions, and final answer. A service-denied call is an enforcement success and a behavioral failure worth fixing. An answer that repeats the marker as an unnecessary instruction can be a different output-handling problem.

Score authorized task completion beside unauthorized admission. The clean control should still answer the policy question with correct evidence. Record refusals, unsupported policy claims, and instruction-following failures separately so a more restrictive prompt does not hide a loss of usefulness.

Proposed synthetic fixture: indirect prompt injection: a retrieval test fixture
CaseEvidence to retainAcceptance condition
Instruction before policyRetrieved passage and call logPolicy answered, no unauthorized effect
Quoted security discussionAnswer and source labelsTopic summarized as data
Clean policySupported final answerUseful task still completes

Turn the result into a boundary-specific change

Accept the fixture when the assistant answers the policy question and no unauthorized outbound operation commits. Fix authority validation at the tool boundary even if prompt changes improve behavior. Re-run the same placement variants after changing retrieval formatting, tool adapters, or source parsing.

Preserve the exact synthetic document versions and budgets used. Add a newly observed entry point as a new case rather than declaring a universal injection score. A passing fixture establishes behavior for these sources and tools; it cannot prove resistance to all future wording, modalities, or persistent-context interactions.

Limits of the evidence

The policy and marker instructions are authored examples, not an executed attack campaign. No live endpoint or client system was tested. These cases cover one entry point and action boundary, not universal prompt-injection resistance.

Common questions

Does a denied tool call count as success?

It shows enforcement worked, while the attempted unauthorized action remains a behavioral finding.

Should adversarial cases contain real secrets?

Use synthetic markers and controlled tools so the evaluation creates no unnecessary exposure.

Sources & further reading

Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.

  1. OWASP: LLM Prompt Injection Prevention Cheat Sheet OWASP · Living reference · Maintained security guidanceReviewed: indirect external-content injection and hidden-instruction extraction categories; tool boundary authority and controlled paired test design; no attack execution or universal defense claim. Accessed October 16, 2026.

Questions or corrections? Write to Rubrex. Read our editorial approach.

From reading to a repeatable evaluation

Put a quality bar around your use case.

The AI Reliability Sprint covers one use case, a baseline, failure analysis, and one improvement experiment in 10 business days.

Request an evaluation call

See the Sprint deliverables →