TL;DR: A model may follow instructions found inside lower-trust task material even when message roles are correctly represented. Preserve source and role structure, then enforce data access and consequential operations independently of the model’s interpretation. Identify the actual effect before claiming a boundary failure or successful prevention.
How to approach it
Name an input author, a legitimate task and a protected resource. Distinguish a structural role-assignment bug from semantic influence within a correctly formatted message. Then trace the generated output to the service or reader that can experience the consequence.
A strong answer
In an original fictional makerspace, a member asks about their own booking. The assistant reads public manuals and member-authored comments. Staff maintenance notes are outside the member’s allowed data. A comment can try to redirect the task without gaining authority to grant that access.
A causal chat model processes a formatted representation of messages. The chat-template documentation from Hugging Face, checked November 2026, explains that formats and control tokens differ between models. That does not imply every role marker is ordinary text or that the API has no enforceable structural rules. Trusted code can control who may submit a privileged message while the model still misinterprets a direction inside a lower-trust source.
- 1
1 · Source attribution
A member wrote the booking comment
- Trusted code keeps the comment in its real message role.
- The author cannot declare a staff role by writing a claim.
- 2
2 · Model interpretation
The comment influences a proposal
- The model may follow a direction found inside task material.
- No structural role change is required for this behavior.
- 3
3 · Resource enforcement
The booking service evaluates the actual request
- Trusted identity and task scope determine permitted access.
- A proposed staff-only read is denied independently of the model.
Ask which boundary actually failed
A message-role assignment defect and semantic instruction following are different failures. Inspect both rather than treating every influenced proposal as a forged system message.
The architectural consequence is specific: do not use the model’s interpretation as the sole authority for a required permission. Resolve the authenticated member and current task outside generated arguments. Filter source eligibility before adding records to context, check object access at resource services, and enforce the permitted recipient and operation before committing an effect. A final refusal cannot undo a private record already exposed through a readable draft.
Treat generated output according to its consumer. A renderer, database query, scheduling handler and subsequent model each impose different requirements. Parameterized database operations separate values from query syntax; that is a useful enforced boundary at that sink. It does not, by analogy alone, supply a universal natural-language instruction/data separator for the whole application.
Reduce unnecessary authority and raw input exposure. A planner may operate on a narrow task representation, with another component handling untrusted documents under restricted capabilities. Examine what can cross that interface: a concise summary may still contain an instruction or select an unauthorized but syntactically valid value. The design needs explicit data and capability rules, not merely two differently named models.
Keep well-formed messages, task guidance and behavior evaluations. They can improve useful work and reduce undesirable proposals. State what each measured result establishes for its configuration. A proposed private read that was denied differs from an actual unauthorized read, and both differ from release to a member. The application map supplies those observation points.
For a defensible test, use authorized synthetic records. Submit permitted and disallowed proposals directly to the relevant application boundary as well as testing complete model-driven runs. This exposes missing permission checks without requiring a working injection payload. Check valid tasks too, so disabling all useful behavior does not masquerade as a successful design.
What interviewers probe next
- “The API refuses caller-supplied system roles. Is injection solved?” That protects a structural boundary; lower-trust content can still influence the model’s interpretation, so verify independent effect controls.
- “The tool request was denied. Is there a finding?” Record the denied proposal and inspect the requirement: an earlier read, saved artifact or other effect may independently violate it.
- “Can we put a second model in front?” Specify what it is allowed to output and what the next component may do; evaluate both useful work and residual influence.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A fictional makerspace assistant answers members using public manuals and their own bookings. Member-authored comments may influence the answer, but staff maintenance notes must remain inaccessible. The API preserves the comment’s original role.
Start here
What if the model treats a member comment as a new instruction without any role field changing?
Separate the serialized message from the model’s interpretation.
Treat this as semantic influence inside the allowed structure. Preserve source attribution, inspect the generated proposal and verify what the application actually executed or exposed. Do not claim that the member became a real system-message author.
Carry it forwardCorrect structure and correct interpretation require different evidence.
Weak answerCalling every prompt-injection result a parser escape.
Constraint changes
What if the proposed staff-note read is rejected, but a previously saved answer already contains that note?
Follow the data that bypasses the proposed read.
The denied call protects that operation, but the saved answer is another disclosure path. Check its origin, current reader policy and eligibility for reuse. Remove unauthorized context from this task and verify saved responses, previews and history as applicable.
Carry it forwardA downstream denial does not erase an earlier disclosure path.
Weak answerScoring the entire workflow safe from one denied tool request.
Constraint changes
What if a separate model turns each manual into a short structured summary before the planner reads it?
Ask what information and influence survive the transformation.
The separation can reduce raw exposure, but the summary can retain directions or produce a harmful allowed value. Specify the summarizer’s output contract, preserve provenance, constrain the planner’s capabilities and test actual downstream decisions. Isolation is a mechanism to evaluate, not a guarantee conferred by adding a model.
Carry it forwardTransforming content does not automatically change its authority.
Weak answerTreating a second model as a complete trust filter.
Constraint changes
What if the product removes scheduling tools but still renders links from the generated answer?
Identify the remaining reader and renderer capabilities.
Remove scheduling from the threat map, then review the response’s contents, destinations, remote resource loading and saved audience. A read-only assistant can still disclose material or expose a renderer to unsafe input. Keep controls specific to the paths that remain.
Carry it forwardCapability removal narrows risk without proving every other boundary.
Weak answerEquating no write tools with no consequential outputs.
Now defend it
What evidence would support the claim that the member cannot obtain staff-only material?
Authorized fixtures must exercise source eligibility, saved-state reuse and actual response or artifact readership. Show that the relevant services deny unauthorized reads and disclosures under the stated configuration, including independently supplied invalid proposals. Retain observation gaps and do not infer universal immunity from a finite test set.
How it's scored
Weak: Treats every model mistake as a forged role, or relies on stronger wording alone.
Hire: Preserves input provenance, separates semantic influence from structural defects and places access checks at real resources.
Strong Hire: Traces saved-state and recipient paths, limits authority across component boundaries and proposes tests that distinguish rejected proposals from observed effects.
Common mistakes
- Claiming that correct role serialization proves semantic obedience.
- Claiming that a shared representation makes structural checks useless.
- Treating a summary or second model as automatic authorization.
- Reporting a safe final answer while ignoring readable artifacts or earlier effects.