TL;DR: Direct injection enters through a request channel; indirect injection is carried in material the application processes. Compare the actual source access, task authority, reachable data, audience and effects: neither route is automatically more severe.
How to approach it
State the route convention you are using, then ask who authored the material and what the application can do with it. Separate the person submitting a request from the service identity executing it. Use a concrete comparison and name the missing evidence that would change your ranking. The scoring below is an original practice rubric.
A strong answer
In a direct case, an adversary uses the assistant's request interface to attempt a change outside governing instructions or permissions. That interface may be public or authenticated. Its backend may hold capabilities broader than the caller should exercise, so the attack's reach is not automatically confined to the caller's personal records.
In an indirect case, attempted redirection arrives through task material: a document, message, retrieved chunk, attachment, tool result or saved memory. Its author might not interact with the assistant directly. Their ability to edit the source can still require credentials on another service. A legitimate user can carry that source in a paste or upload; record authorship and intended role rather than trusting the API message label alone. Greshake and colleagues (2023) studied this external-data route into LLM applications.
Compare these fictional configurations:
| Configuration | Entry and authority | Demonstrated or potential consequence |
|---|---|---|
| Public support request, backend-wide record reader, no effective object check | Direct request reaches a broadly privileged service | A controlled test confirms cross-customer disclosure |
| Supplier page read by a restricted drafting assistant | Indirect source reaches a task with no delivery grant | The test changes a draft's ordering; private access and external effects remain denied |
Prioritize the confirmed disclosure in the first configuration. The second still needs an integrity review and a check of its actual audience. If its draft decides procurement outcomes or reaches a shared publication path, that changes its impact. Do not assume that absence of an email tool means every output is private or low consequence.
Input route
Request or task material
Acting identities
User, task and service
Reachable resources
Check object permissions
Effect and audience
Observe the actual result
Record route and author
A request may carry a third-party passage. Capture both entry channel and authorship.
Inventory all writers and transformations. An authenticated internal search service may return fields originally supplied by external customers. A source label can help preserve that distinction, but enforcement must use trusted policy inputs. A tool response's transport identity does not authorize every instruction embedded in its content.
At the resource service, derive the actor and delegated task from trusted session or workload context, then check the requested object. A model may name an object ID as a selector; the mistake is accepting that selection without authorization, not allowing selection itself. Legitimate shared calendars and delegated documents need policy checks rather than a universal “own records only” rule.
At an output or effect boundary, check the permitted material, recipient, current grant and relevant limits. Remove capabilities the task does not require. If automatic work is permitted by an existing bounded grant, an unrelated source cannot expand it. New authority should come through the designated approval or task-control path.
For evidence, distinguish source reach, model influence, service admission and effect. A retrieved document that produced no observed deviation under one query is a limited result. One poisoned source does not affect every reader automatically. Conversely, deleting the source does not clear derived summaries, indexes, caches or queued work. Test those paths explicitly in an authorized isolated environment.
What interviewers probe next
- “The attacker has no account on our assistant. Are we safe?” Check whether they can influence a source the assistant processes, and whether a public direct request channel also exists.
- “A calendar appears only in the user's reply. Is that exfiltration?” Determine who actually sees the reply and whether its rendering, logging or sharing triggers another recipient. A private display alone does not prove attacker receipt.
- “Which variant scales further?” Identify reuse, caching, indexing and the affected permission scopes. Shared indirect material can spread across tasks; direct automation can also reach many requests or broadly privileged backends.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
Compare a public support interface with a supplier-document drafting assistant. All tests use fictional records in an authorized isolated environment.
Start here
The support caller supplies a different customer ID. Must the application forbid IDs in requests?
What decides which selected objects are permitted?
No. IDs can select legitimate resources. Resolve the authenticated or public actor and current task, then authorize the selected object at the resource boundary. The model's chosen ID is not a grant.
Carry it forwardAuthorize selections rather than mistaking identifiers for credentials.
Weak answerBanning selectors while leaving backend permissions unchecked.
Constraint changes
A colleague pastes a supplier page into the chat. Does that make the supplier's instructions trusted?
Who authored each part of the message?
No. The colleague carries the page as task material. Preserve its source role and distinguish it from the colleague's actual authorized instruction. Document how the evaluation labels that entry route.
Carry it forwardAPI role and content authorship are different dimensions.
Weak answerTrusting all pasted material as the user's instruction.
Constraint changes
The drafting assistant adds an automatic link preview. What changes?
Which component fetches or shares the generated URL?
Inspect the preview service, request destination and data carried by the URL. The assistant may gain an external disclosure path despite having no explicit outbound tool. Apply destination and material policy to that actual path.
Carry it forwardRendering and auxiliary services belong in the capability map.
Weak answerEquating a missing email tool with no outbound path.
Now defend it
What evidence would reverse the initial ranking?
A verified high-impact audience or effect in the indirect path, or evidence narrowing the direct disclosure claim. Reassess using actual material and permissions, not a preferred taxonomy.
How it's scored
Weak: Assigns severity from the route, assumes every direct caller is authenticated, or equates every indirect source read with compromise.
Hire: Defines both routes, names the source capability and execution identity, and compares observed consequences under the actual grants.
Strong Hire: Handles pasted third-party material, shared access, alternate output paths and derivative state; separates demonstrated reach from hypotheses and preserves useful authorized work.
Common mistakes
- Treating the victim's personal identity as the only authority an agent can exercise.
- Assuming internal sources contain only privileged instructions.
- Relying on a domain allowlist without checking allowed proxies and data audiences.
- Describing all unexpected intermediate actions as unauthorized without reading the task grant.