TL;DR: Place controls against specific prohibited reads, releases and effects, and state what each actually enforces. Deterministic implementation is useful only with correct policy inputs and complete coverage; learned defenses can reduce observed failures or block covered releases without establishing permission. Combine them around a supported workflow and test what happens when each layer fails.
How to approach it
Choose a concrete assistant, identify the source author and draw the actual data and action paths. List the audiences and operations the current grant permits. Place each control before the consequence it is meant to prevent, then name its assumptions and remaining gaps. Do not make the design a list of products or a universal ranking of controls.
A strong answer
A fictional account-support assistant reads selected customer messages and internal staff notes, then prepares a reply. The customer can edit message text but cannot read staff-only notes, add recipients or change the worker's account permissions. The worker may read both sources; that does not automatically authorize sending both sources back to the customer.
- 1
1 · Read the selected records
Current caller permissions
- A worker may read more than a customer may receive
Read authorization is one decision
- 2
2 · Process source material
Scoped contexts and measured defenses
- Preserve useful work and trace derived values
A clean score does not grant authority
- 3
3 · Admit the actual release
Content, audience and operation
- Enforce the current grant on every covered path
Check timing and fallback behavior
- 4
4 · Verify the result
Denied, delivered or unresolved
- Protect evidence and inspect missing outcomes
Keep language and effect failures distinct
Build the permission layer from trusted identity and current policy inputs. The retrieval service checks which records the worker may access. The reply service separately checks the actual audience and allowed content flow. Shared records can be legitimate reads; "only the user's own data" is too narrow to describe every valid access model.
A narrow tool can reduce the operation space. For example, a reply function can resolve a selected thread in service code rather than accept arbitrary recipient text. Yet existing thread participants are not automatically entitled to every staff note or attachment. Check recipient membership, actual audience, content restrictions and the current task grant together. A narrow function signature alone does not prove the right policy.
Review the layers with their precise claims:
| Layer | Property it can support | Assumption or gap to inspect |
|---|---|---|
| Resource authorization | Reject reads outside the current caller grant | Trusted identity, policy freshness and every read path |
| Restricted effect interface | Admit only allowed operations and parameters | The allowed set must match the task, including cumulative limits |
| Data-flow and audience policy | Prevent a covered release to a forbidden audience | Correct labels, derivations and complete release mediation |
| Rendering restrictions | Prevent specified client fetches or active content | Preview, export and other rendering paths need their own coverage |
| Source cues and trained priority | Improve measured handling of conflicting source instructions | Actual model, representation, cases and useful-work results |
| Classifier-based gate | Block covered inputs or releases at its operating point | Misses, false blocks, verdict timing and fallback behavior |
A domain allowlist can enforce membership in a destination set. That set may include a shared host with unauthorized accounts, so it does not establish audience permission by itself. Likewise, disabling remote images on one view addresses that fetch path; it does not close every disclosure through text, exports, links or other clients.
The design can separate planning from source reading where the task permits. A committed workflow and a quarantined reader reduce certain ways source prose reaches a planner. They still pass values to later steps, and a fixed program can contain data-dependent branches. Inspect the argument and release policies as described in the architecture lesson.
Use source marking, hierarchy-aware behavior and classifiers where evaluation supports their benefit. A classifier can be preventive when its verdict gates the relevant release. Its empirical coverage is a different assurance claim from a service refusing a recipient outside a trusted grant. Calling one component probabilistic does not make its observed prevention unreal; calling another deterministic does not make its policy correct.
If human approval is required, bind it to the actual immutable operation and show the relevant audience, content and effect. A current bounded standing grant can legitimately permit automation. The choice should follow the task and release requirements, with meaningful review capacity measured, rather than requiring a click for every action or accepting every click as informed authorization.
Failure handling belongs in the layer design. A required check that times out must use its specified hold or restricted fallback. A denied operation must not be silently retried through another tool. A missing effect receipt must not become an automatic success label or a reason to repeat an uncertain action.
For evidence, record minimized source references, policy and component versions, decisions and actual release outcomes with suitable access and retention. Unexpected actions are investigation signals, not automatic proof of injection. A later turn may still depend on an earlier source through memory or a summary even after raw text leaves context; inspect those dependencies instead of assuming a context reset erased them.
Test the system only in owned or explicitly authorized isolated environments with synthetic records and controlled effects after real checks. Include wrong recipients, forbidden content flows, guard timeouts, alternate paths and valid replies. Measure source-following errors, denied proposals, confirmed exposure, unknown outcomes and lost useful work separately. Each requirement needs evidence; one aggregate success rate cannot certify the whole design.
What interviewers probe next
- "Which layer would you build first?" Address a concrete unmet requirement with the highest relevant consequence; for this case, separate staff-note readership from the customer reply grant.
- "The sender is limited to thread participants. Is exfiltration solved?" No; verify that each participant may receive the specific content and that other release paths are covered.
- "Can the classifier run after streaming starts?" Only if the relevant protected release remains safely held or constrained; a late verdict cannot retract delivered text.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A fictional account-support assistant reads customer messages and staff-only notes to prepare replies. Customers control message text, while service code owns the worker's read permissions and the customer reply grant.
Start here
The worker may read a staff note. Can the assistant include it in a customer reply?
Are read and disclosure permissions identical?
Not automatically. The customer audience may lack permission for the staff note even though the worker may access it. Check the actual content flow and recipient grant at release, including derived summaries and attachments. A successful retrieval check does not grant a new audience access.
Carry it forwardRead permission does not imply unrestricted redistribution.
Weak answerReusing the caller's read grant as permission for every recipient.
Constraint changes
The system sends only to participants already on the thread. Which question remains?
What content is each participant entitled to receive?
Verify that the current grant covers those recipients and the specific content. An existing participant may be the customer who must not receive staff-only notes. Thread membership narrows possible destinations but does not establish every disclosure permission or cover other release paths.
Carry it forwardA bounded destination set still needs correct content permissions.
Weak answerCalling existing-thread recipients automatically safe.
Constraint changes
The output classifier blocks a covered disclosure before any text is released. Is that prevention?
Which observed consequence did the gate stop?
Yes, for that covered release under the observed conditions. Report the prevention while retaining empirical coverage, false-positive and timing limits. It remains distinct from a rule that denies a forbidden audience on every mediated path using trusted permissions.
Carry it forwardCredit a working gate without overstating its coverage.
Weak answerSaying a probabilistic classifier can never prevent anything.
Now defend it
How would you present the design for approval?
For each prohibited consequence, identify the enforcement point, trusted inputs, coverage and observed evidence. Include allowed replies, classifier operating costs, timeout and alternate-path behavior, derived state and unresolved effects. State the supported release scope and the remaining conditions.
How it's scored
The design should connect every asserted property to its implementation and its evidence.
Weak: Lists guardrails, treats deterministic code as automatically correct, or assumes a known hostname or thread member is always authorized.
Hire: Places resource, action and release checks along the actual workflow and explains the coverage limits of learned defenses.
Strong Hire: Tests trusted policy inputs, alternate paths, failure timing and derived state while preserving allowed replies and meaningful evidence.
Common mistakes
- Using a successful read check as permission to send the same content elsewhere.
- Equating a narrow tool name with a correct audience policy.
- Logging full sensitive context for every event without a justified evidence plan.
- Treating a blocked operation as proof that no misleading or confidential text reached a reader.