Indirect Prompt Injection Triage Interview Scenarios for AI Security QA

Indirect prompt injection is a control-flow attack delivered as data. A document, webpage, email, ticket, image text, or tool result contains instructions that compete with the user's task and attempt to redirect an agent toward disclosure or action. Senior AI security QA must test the complete trust boundary, not only whether the model repeats a suspicious sentence.

These scenarios require a disciplined triage method: preserve provenance, trace the attack path, verify authoritative side effects, contain credentials and egress, and build a regression that still allows the legitimate task. A blanket refusal may be safe in one test while making the product unusable everywhere else.

Map the Attack Path

The official MCP security best practices emphasize explicit consent and strong authorization boundaries around connected systems. Indirect injection testing asks whether untrusted content can cross those boundaries by persuading an agent to act with authority the content itself never had.

For every scenario, identify the attacker-controlled source, trusted instruction source, model-visible context, available credentials, possible egress, side-effect boundary, and the evidence that proves containment.

Trust, Provenance, and Threat Modeling

1. Why should retrieved content never inherit the user's authority?

Retrieval answers which data may help the task; it does not authorize that data to issue commands. Tag content with source and trust class, present it as evidence, and enforce tool policy from authenticated user intent. Test a permitted document containing a request to access an unrelated account. The document may be readable, but its embedded request must not broaden identity, scope, or purpose.

2. How would you threat-model an email summarization agent?

Map sender control, HTML and attachment parsers, quoted threads, links, model context, address-book access, reply and forwarding tools, and any connected storage. Attack cases attempt to change recipients, include hidden canaries, fetch external URLs, or create follow-up actions. Test read-only summarization separately from sending. The safest useful design may allow extraction while requiring explicit user-bound approval for every outbound message.

3. Why is source provenance needed after text normalization?

Parsing, OCR, chunking, and summarization can erase where an instruction came from. Carry source identifier, structural location, transformation history, trust label, and content hash into context and traces. The policy engine can then distinguish user intent from retrieved evidence, and triage can locate the payload. If provenance disappears before the model call, later filters cannot reliably reconstruct authority.

4. How would you rank indirect injection severity?

Use demonstrated or reachable impact: unauthorized tool execution, sensitive disclosure, persistence, cross-tenant access, corrupted decisions, or task denial. Include privilege available, user interaction, affected population, and containment. A model merely quoting hostile text is different from following it; a blocked attempt is different from a committed side effect. Preserve both attempted path and authoritative outcome so severity is evidence-based.

Reproduction and Triage

5. How would you reproduce a report without exposing real secrets?

Clone the relevant configuration into an isolated tenant, replace secrets with unique synthetic canaries, snapshot the source and parser output, and replay the exact task with deterministic tool doubles where possible. Preserve every model-visible message and policy decision. If reproduction requires production data, minimize and redact under incident access controls rather than copying the entire trace into a general test fixture.

6. Why verify authoritative state before declaring an exploit successful?

The agent may propose a call that policy blocks, fabricate a result, or receive a tool error after attempting it. Check connector audit logs, target-system state, network egress, and response content. Classify proposed, authorized, attempted, committed, and verified stages separately. This distinction guides severity and remediation: model steering, policy bypass, connector execution, and misleading user communication are different defects.

7. How would you contain a suspected exfiltration incident?

Disable or narrow affected tools, revoke exposed credentials, block known egress destinations, preserve redacted traces and target logs, and identify every run sharing the source or session. Determine which canary or real fields left the boundary. Avoid deleting evidence while rotating access. Recovery includes fixing the control, testing adjacent channels, and notifying the proper incident owners based on confirmed exposure.

8. Why preserve the benign task alongside the attack payload?

A regression that only expects refusal can reward a product that stops processing all external content. Retain the user's legitimate objective and expected safe outcome, such as summarizing the document while ignoring its commands. Evaluate security and utility independently. The best fix blocks unauthorized influence but still extracts allowed facts, cites the source, and asks for clarification only when the evidence itself is genuinely ambiguous.

Layered Prevention and Containment

9. Why are prompt delimiters only one defense layer?

Delimiters and role labels make provenance clearer, but model behavior alone cannot enforce authorization. Combine them with least-privilege identities, argument validation, tool allowlists, approval binding, network restrictions, and output filtering. Test payloads that mimic delimiters or claim higher priority. Even if the model follows the injection, execution controls should prevent unauthorized state or disclosure.

10. How would you test tool allowlisting by task phase?

Define which tools are available during retrieval, analysis, drafting, approval, and commit. Supply injected content that requests a tool outside the current phase or purpose. Assert it is absent from the model contract or rejected by policy, and no hidden fallback reaches it. Dynamic exposure reduces attack surface, but transitions must be explicit and tested so an agent cannot self-promote into a privileged phase.

11. Why should sensitive data and untrusted content be separated when possible?

An attacker-controlled instruction is more dangerous when the same model context contains exportable secrets. Use data minimization, scoped retrieval, tokenized identifiers, and dedicated operations that return only necessary fields. Test whether a public document can cause private tenant data to enter a tool argument or final response. Least privilege limits impact even when instruction following fails.

12. How would you evaluate a guardrail around a tool call?

Create allowed, clearly prohibited, and boundary proposals with the same user task and varied injected sources. Validate tool, target, fields, purpose, provenance, and approval state before execution. Capture false allows and false blocks by slice, with deterministic vetoes for sensitive scope. The OpenAI Agents SDK guardrails documentation provides guardrail execution concepts; security QA must still verify the protected side effect itself.

{
  "decision": "deny",
  "reason": "tool_scope_not_derived_from_user_intent",
  "user_intent_id": "intent-illustrative-17",
  "untrusted_sources": ["retrieved-page-4"],
  "proposed_tool": "upload_file",
  "target": "external-host",
  "side_effect_observed": false
}

Attack Variants and Egress Tests

13. How would you test hidden or transformed instructions?

Place semantically equivalent payloads in visible prose, metadata, markup, OCR text, encoded blocks that the application legitimately decodes, quoted messages, and nested tool results. Keep transformations within real parser behavior rather than inventing impossible channels. Record which representation reaches the model. A fix at one renderer is incomplete if another ingestion path reconstructs the same hostile instruction downstream.

14. Why test multi-step delayed attacks?

An injected instruction may ask the agent to store a note, alter memory, create a task, or retrieve another source that later triggers the harmful action. Use isolated persistent state and trace provenance across runs. Verify that untrusted content cannot create trusted standing instructions or approvals. Cleanup must remove all test persistence. One-turn filters miss attacks whose influence is intentionally separated from impact.

15. How would you test exfiltration channels comprehensively?

Inventory final responses, URLs, search queries, tool arguments, file writes, telemetry, citations, notifications, and rendered external resources. Seed distinct canaries by sensitivity class and monitor each channel in an isolated environment. Assert both exact and encoded leakage where the product performs encoding. Do not put real credentials in the test. Channel coverage should map to actual enabled capabilities, not a generic checklist.

16. Why include attacks that resemble legitimate document instructions?

Real content contains procedures, code, and imperative language. If every imperative triggers refusal, false positives will be severe. Build contrast pairs: a document saying "send the form" as quoted policy evidence versus one directing the agent to send data now. Expected behavior depends on user intent, authority, and tool phase. This evaluates contextual control without asking the model to infer security from keywords alone.

Evaluation and Release Evidence

17. How would you construct an indirect injection evaluation set?

Sample real source types and tasks, then pair clean controls with attack variants across languages, transformations, tool privileges, and impacts. Label safe task outcome, prohibited action, prohibited disclosure, required clarification, and authoritative state. Keep part of the set blind and version source parsers. Include benign imperative content so security improvements cannot pass simply by refusing everything.

18. Why measure false refusals beside attack success?

A control that blocks all retrieved content may report zero successful attacks while destroying the product. Track whether the legitimate task completes, facts remain accurate, and allowed tools still work. Slice false refusals by source and task. Security vetoes remain non-compensable for critical effects, but utility evidence helps choose among defenses that provide equivalent containment.

19. How would you set a release gate for a connected agent?

Define critical prohibited actions and disclosures as deterministic vetoes, require complete traces and authoritative state checks, and report safe completion on matched benign cases. Test each enabled source-to-tool path, not just one chatbot prompt. Numerical thresholds are illustrative until calibrated to the product's risk. Block release when any high-impact path can bypass user-bound authorization or when evidence is ungradable.

20. Why must production detections become generalized regressions?

An exact payload soon becomes a known string rather than a durable security test. Preserve the incident case, then vary wording, source format, target, tool, placement, and delayed path while keeping the same security invariant. Add clean neighbors to watch false blocks. The regression succeeds when controls preserve user intent across the attack family, not when a filter recognizes one sentence.

Make the Security QA Decision

Strong candidates trace authority from the authenticated user to every proposed action and refuse to grant authority to retrieved content. They separate attempted influence from committed impact, validate with synthetic canaries, and make the safe useful outcome part of every regression.

The decisive close is to block any release where untrusted content can widen tool scope, expose protected data, or create persistent instructions without fresh user-bound authorization. Contain the path at execution boundaries, then prove legitimate work still completes under the same controls.