TL;DR: Jailbreak usually refers to bypassing safety restrictions; prompt injection refers to attempted redirection through material with insufficient authority. The categories can overlap, so report the governing policy, source, observed outcome and control failure before assigning severity or remediation.
How to approach it
Clarify the terminology and the actual policy being tested. Ask who supplied the material, who saw the output and whether a tool or publication service acted. Separate attempted influence from confirmed violations. The rubric below is site-authored guidance for explaining that reasoning.
A strong answer
Suppose a fictional assistant has a declared rule against targeted abusive output and a separate grant system for publishing messages. A third-party document induces a prohibited draft. The publication service denies the requested public post, but a task reviewer has already seen the draft.
This can be an indirect prompt-injection finding and a safety-policy bypass at the same time. The publication denial is a successful enforcement result for the attempted public action. It does not erase the prohibited draft or its exposure to the reviewer. The seriousness of that exposure needs the actual audience, content and context.
Definitions differ. OWASP's 2025 entry, checked November 2026, includes jailbreaking within a broad prompt-injection category. Willison's March 2024 distinction separates model-safety attacks from application attacks. State your convention and preserve the operational facts so a different vocabulary does not hide the issue.
Third-party input
Attempts redirection
Prohibited draft
Observed safety failure
Reviewer exposure
Audience matters
Public post denied
Grant check held
Describe the observed policy breach
The fictional policy prohibits the generated draft. Record the source influence evidence and actual content.
| Observation | What to report | Responsible control |
|---|---|---|
| Third-party content attempts a task redirection | Source, route and evidence of influence | Input handling and instruction behavior |
| A prohibited draft is produced | Applicable policy and generated material | Model behavior and application content controls |
| A reviewer sees the draft | Actual audience and exposure | Product presentation and delivery policy |
| Public posting is denied | Current grant and tested denial | Publication service authorization |
A merely rude or unexpected answer is not automatically a jailbreak. Identify the restriction and whether an adversarial bypass occurred. An inaccurate answer can also result from ordinary retrieval or generation errors. Conversely, a plain answer can cause harm without any tool call, so “content only” is not a severity dismissal.
An injected request to send a file may look like ordinary business work, but a model with relevant context can still recognize an unauthorized disclosure. Do not claim safety training is categorically irrelevant. The reason to retain independent application checks is that a behavioral success or benchmark score does not enforce current task and recipient permissions.
Choose controls by mechanism. The provider or model operator may improve instruction priority and refusals. Product owners define the applicable content policy, moderation response and exposure rules. Resource services enforce object access; effect services enforce material terms, recipients, budgets and current grants. A team operating its own model may own several of these layers.
Evaluate them separately and together. For a safety case, state the prohibited category, expected response, adjudication and audience. For an injection case, state the source changes allowed, valid task, current authority and observed consequence. Both need legitimate-task checks to reveal false refusals. A combined test may show a model failure and a downstream control that held; report both instead of compressing them into one score.
Use only an explicitly authorized environment with synthetic records and harmless effect sinks. Preserve observation gaps, including accepted operations with no final result. Adaptive test success is not automatically a production incident probability. Rank findings by actual content or effect, affected audience, reach, repeatability and recovery evidence.
What interviewers probe next
- “Does a jailbreak benchmark establish that our agent is protected?” It supports claims about the evaluated policy and conditions. Test the application's resources, tools, output audiences and useful tasks separately.
- “Who owns a model-generated harmful answer?” Assign the relevant provider or model operator and product controls. Outsourcing inference does not remove responsibility for how the application exposes content.
- “Which label means higher severity?” Neither. Explain the demonstrated harm and additional plausible reach, including uncertainty; do not upgrade or dismiss a finding from terminology alone.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A fictional assistant produces a prohibited draft after processing a document. A publication service denies the post; a reviewer has already seen the draft.
Start here
A team calls the test a pass because nothing was published. What do you change?
Which policy and audience did each observation cover?
Record the denied publication as a control success and the prohibited generation and reviewer exposure separately. State what remains unknown rather than assigning one pass label to the complete interaction.
Carry it forwardCount distinct policy outcomes at their actual observation boundaries.
Weak answerLetting the final denial erase previous exposure.
Constraint changes
Another team calls every undesirable answer an injection. What evidence do you request?
Was there a source-driven attempt to change authority or instructions?
Ask for the source, applicable policy, intended task, model input and evidence linking the attempted redirection to the output. Investigate ordinary retrieval or generation errors as alternatives when that evidence is absent.
Carry it forwardA finding needs a mechanism and evidence, not only an unwanted symptom.
Weak answerTreating temporal proximity as proof of cause.
Constraint changes
The detector works well on disallowed-content requests. What should you test before using it here?
Does it see the task, source and authoritative permissions?
Evaluate the real document and action cases, allowed work and relevant audiences. Its existing benchmark may not cover these inputs or have the state needed to decide permission. Keep independently enforced task and delivery checks.
Carry it forwardMatch the detector to the claim you want to make.
Weak answerBuying one taxonomy label as evidence for all threats.
Now defend it
What belongs in the remediation plan?
Assign owners for instruction behavior, content exposure and any failed application policy. Keep controls that demonstrably held, investigate missing outcomes and retest both the forbidden case and valid work.
How it's scored
Weak: Treats the categories as mutually exclusive, equates unwanted tone with a jailbreak, or sends every safety issue to the provider without examining product exposure.
Hire: States a workable convention, identifies the policy and consequence, and separates model behavior from resource and effect authorization.
Strong Hire: Handles overlap, partial control success and earlier exposure; assigns owners by the failing component and designs meaningful safety, permission and utility checks.
Common mistakes
- Claiming an ordinary-looking request can never trigger a safety refusal.
- Treating a publication denial as proof that no one saw the draft.
- Using a strong provider score to remove task or audience checks.
- Inferring a source caused the failure solely because it was present in context.