TL;DR: Inventory private data, untrusted input and outbound routes. Trace whether they can combine to disclose data to an unauthorized recipient, then propose a restriction enforced outside the model. A two-minute triage produces a prioritized finding, not a complete security assessment.
How to approach it
Start with the legitimate task and the attacker's capability. Assume an outsider can send an email, while the assistant can read private files and propose replies. Ask who may receive those files and which service actually sends. Attribute the term to Simon Willison and use it to organize the review rather than predict an attack success rate.
A strong answer
Private data
Inbox, files, CRM, internal docs
- Read tools that return the user's data
Leg 1
Untrusted content
Content without authority to define the task
- Web pages, inbound email, tickets, shared docs
- Web fetch and inbox reading supply two legs
Leg 2
External communication
Any way out
- Send, post, fetch a URL, render an image link
Leg 3
Restrict the data path
Preserve the legitimate task
- Remove unnecessary egress or private-data access
- Check every route, including handoffs and rendering
A proposed control to verify
Use the time budget as a practice constraint:
- Inventory, 30 seconds. List mail, file search, web requests, sending and browser rendering, plus memory and agent handoffs.
- Classify, 45 seconds. Mail can be both private and attacker-written. Web requests can receive untrusted content and transmit data. Private documents may also contain instructions from people who cannot authorize this task.
- Trace, 15 seconds. Follow one path from the outsider's email to a proposed disclosure of a private file. Include the real recipient, browser or shared-storage reader.
- Choose a control, 30 seconds. If the task only needs a draft, remove sending and other outbound routes from that execution path. If delivery is necessary, enforce recipient and data policy, then bind approval to the exact body and attachments.
State the cost: draft-only mode needs a separate user action to send; a public-research worker without private access cannot combine public and private material automatically. An allowlisted domain or existing contact narrows destinations but does not authorize every disclosure.
The combination is a warning to investigate. A classifier's measured accuracy does not prove the route is closed. Separate agents can still relay content through tools and memory. Extend the review to destructive actions and budgets: those can cause harm without leaking private data.
What interviewers probe next
These are practice follow-ups, not reports of a particular employer's questions.
- "Confirmation adds friction. What would you simplify?" Remove unnecessary sends and review consequential actions with their actual parameters; do not assume familiar recipients are safe.
- "The browser blocks cross-origin reads. Is egress solved?" No. Requests may still transmit information; inspect the renderer and fetch policy.
- "Which test could disprove your design?" In an isolated fixture, try a second outbound route, a queued send or a changed recipient after approval.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
An executive assistant reads mail and private files, browses public pages and sends replies. You have two minutes for an initial review, followed by time to validate the design.
Start here
What if the team removes send-email but keeps web fetching?
Can an outgoing request carry information?
The fetch destination, path or query can disclose data, so that route remains. Inspect redirects, generated images and shared writes too. A removed tool name is not evidence that all outbound communication has been disabled.
Carry it forwardEnumerate actual data paths before declaring a capability absent.
Weak answerEquating no email tool with no outbound channel.
Constraint changes
What if sending is restricted to existing contacts?
Are all contacts authorized for all retrieved files?
No. A contact can be an outsider, compromised or simply the wrong person for the document. Enforce data-sharing policy and require review of the exact content and recipients. Familiarity with an address is not authorization to disclose a file.
Carry it forwardCheck the data and destination together.
Weak answerAutomatically approving replies because the recipient is known.
Constraint changes
What if a separate reader returns a summary or typed fields?
What influence survives the handoff?
Free text can preserve instructions, and a string inside JSON remains text. Validate allowed fields and values, retain source labels and keep action authorization independent of the reader output. Separate contexts help only when the interface constrains the data flow.
Carry it forwardStructure helps validation but does not establish trust.
Weak answerAssuming summarization removes an injection.
Now defend it
What would you require before signing off on the first release?
Verify task-scoped reads and a draft-only response path, with no alternate sends, arbitrary fetches or remote image loads. Test queued work and old credentials. Keep minimized action records and document remaining integrity and availability risks for the owner.
How it's scored
This is our learning rubric, not an employer's hiring scorecard.
Weak: Recites the three capabilities but overlooks requests, rendering or cross-agent handoffs.
Hire: Identifies a concrete disclosure path and places an effective restriction in the enforcing service.
Strong Hire: Explains the product cost, tests alternate routes and approval changes, and states which risks the initial triage leaves open.
Common mistakes
- Treating a read-only tool as unable to send data in its requests.
- Treating existing recipients as authorized for every retrieved file.
- Calling a summarized or JSON-formatted result trusted.
- Counting a detector result as proof of permission enforcement.
- Logging complete private messages when source references and protected evidence would suffice.