TL;DR: Start with the chatbot's legitimate work, protected data, readers and available actions. Obtain explicit test authority, select consequential failure objectives and prepare isolated accounts, synthetic records and controlled effects. Explore candidate failures, verify what actually happened, and measure selected outcomes under a declared protocol. Deliver findings, useful-work results, uncertainty and retest criteria.
How to approach it
Make the chatbot concrete before choosing tests. A public FAQ bot, an account assistant and a clinical information tool have different requirements. State one workflow, the actors who can influence its inputs and the recipient boundary the assessment must examine.
A strong answer
Consider a fictional support assistant that reads order records and customer attachments, explains delivery status and drafts replies for staff. Customers may receive their own order facts. Internal support notes belong to staff. The product should answer an ordinary delivery question accurately without requiring an unnecessary escalation.
First obtain an approved scope: environment, accounts, interfaces, permitted methods, data handling, attempt limits, contacts and stop conditions. An integration being reachable does not authorize its assessment. Use synthetic orders and separate customer fixtures. Preserve the application checks under review while routing admitted external effects to controlled receivers.
Test source
Customer attachment and order
Actual context
Identity and retrieved fields
Reply decision
Send denied or admitted
Other readers
Draft and transcript access
Confirm exposure
Record which source content actually reached the model under the test identity.
Map the actual workflow. Trace identity into retrieval, source content into model context, output into customer and staff surfaces, and tool proposals into authorization and effects. Include draft storage, attachment extraction and retained conversation state if the feature uses them. A document uploaded but never parsed is different from a document actually shown to the model.
Select objectives from those paths. Can one customer receive another customer's record? Can customer-supplied text change a recipient or an operation outside the current grant? Can a draft expose an internal note even when the send operation is blocked? Does the bot make an unsupported consequential claim that violates the product's requirements? Text-only output can matter even without a tool call.
Create cases that separate the causes. Use allowed order questions, denied cross-account requests, ordinary quoted instructions in attachments and controlled source content that challenges a specific boundary. This site describes such cases by their security objective rather than publishing working injection strings. Record the source position and the user's legitimate request so reviewers can distinguish malicious influence from an authorized task.
Explore with people, scripts or model-assisted search as the scope permits. Keep attempts bounded and reset state deliberately. A search that learns from earlier feedback is useful for finding defects; its selected results are not automatically a population failure rate. Freeze a separate protocol when measurement is the objective.
Verify the result at the right location. In an original synthetic trace, the model proposes an internal note for a customer reply, the send check denies it, and draft storage accepts it. The next question is who can read the draft. If only authorized staff can read it and that use is permitted, do not call it customer disclosure. If a customer fixture receives the protected note through the draft path, report the evidenced release. A missing reader trace remains an uncertainty.
Report findings that can be fixed. Include the violated requirement, actor control, affected configuration, restricted evidence references, observed consequence, reproduction conditions and any limits on replay. Separate confirmed causes from hypotheses. Assign an owner and a retest criterion that covers the failed path. One confirmed violation can be actionable even if repetition is unsafe or unreliable.
Keep ordinary support cases in the retest. A temporary refusal of all replies may contain a problem, but it does not demonstrate that the feature now completes its intended work. Record temporary restrictions and the evidence required to restore them.
What interviewers probe next
Write a small test card for the draft path: permitted reader, protected field, actor-controlled input, expected decision, evidence location and cleanup owner. Add an allowed draft case and an unknown-result state. The card should let another authorized reviewer tell the difference between a failed check, a safe denial and missing instrumentation.
For a provider-level concern, preserve the evidence and use the engagement's approved disclosure process. The assessment lead should coordinate any external report and immediate application containment. Do not independently publish sensitive traces or assume switching a provider removes the application defect.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
An authorized support-bot exercise uses synthetic customer orders. A proposed reply contains a staff note, the send is denied, and the draft is stored for later review.
Start here
What if only staff can read the stored draft?
Is that audience permitted to receive the note?
Check the product rule and actual readership. If authorized staff may use the note in that draft, this observation is not a customer disclosure. Retain the denied-send evidence and assess any separate requirement on the generated draft without inventing an external effect.
Carry it forwardThe recipient and requirement determine the violation.
Weak answerCalling every internal-note appearance an external leak.
Constraint changes
What if the customer can read the draft before staff review?
Where did the release occur?
The draft path may already release the protected content. Correlate write and reader evidence, then report that boundary rather than crediting the send denial as complete prevention. The corrective owner must address draft readers as well as the sending path.
Carry it forwardStored artifacts can be release surfaces.
Weak answerAssuming only a send button can disclose information.
Constraint changes
What if the safe receiver cannot show whether a write occurred?
What does silence establish?
Mark the effect unresolved and repair the instrumentation before claiming a denial. Preserve the proposal and any decision records. Do not replay against real customers to compensate for a missing test signal.
Carry it forwardMissing evidence is not a negative result.
Weak answerTreating absent receiver logs as proof that no effect occurred.
Now defend it
Which retest supports restoration of the draft feature?
Exercise the actual permission path with forbidden staff-note releases, permitted staff drafts and ordinary customer replies. Verify stored readers and admitted effects, document unresolved cases and restore only the scope supported by the results.
How it's scored
- Weak: Starts with a prompt list, ignores identity and readers, and reports unusual text as proof of compromise.
- Hire: Defines authorized scope and meaningful objectives, uses safe fixtures and verifies outcomes beyond generated text.
- Strong Hire: Separates discovery, measurement and unresolved effects; identifies a draft disclosure missed by send-only tests; preserves useful-work and recovery evidence.
Common mistakes
Treating a refusal as proof that every path is safe. Skipping the real authorization check in the test harness. Calling a synthetic marker a real customer leak. Requiring repeated harm before reporting a confirmed event. Sharing a provider issue outside the agreed disclosure authority.