Map the assistant’s data, authority and recipients

TL;DR: Follow a concrete request from its author to every reader and recipient. Mark where identity, permission or control changes. A staff member's right to read several customers' tickets does not give the assistant permission to disclose those tickets in a reply to one customer.

Where you are. Module one, lesson one. You will produce the boundary map and permission table used throughout this course.

The case: one support request, two audiences

Our fictional help desk serves two businesses, Alder and Birch. Mina and Noor are different Alder customers. Aria, an Alder support employee, may read both customers' tickets for assigned support work. A Birch customer has no access to Alder's records. These are exercise assumptions, not descriptions of a real company.

The assistant has a customer chat and a staff draft-reply button. It retrieves help articles and ticket history, sends selected text to a hosted model, and displays an answer. A later module adds order lookup and refund proposals. Initially, sending a message remains a separate staff action.

Mina asks about her order. Aria opens Mina's ticket and requests a draft. What may the assistant read, and what may the resulting message contain? Write separate answers. Aria can legitimately open Noor's ticket, but Mina is not an authorized recipient of Noor's private information. Reusing Aria's broad search context for Mina's draft crosses a disclosure boundary even if every database read was permitted.

The final course project is a release review for this feature. Save each lesson's output: a map, risk register, access matrix, output policy, tool contract and test report. You will use the evidence to approve a limited rollout or hold it.

Draw identities and destinations on the arrows

A diagram with boxes named browser, database and model cannot answer who gains access. Annotate each arrow with the acting identity, data class and destination. Include the context-building service, which selects data before the model sees it, and the delivery service, which decides where an answer goes.

The arrow from storage to context is a disclosure to the inference service. The arrow from a draft to Mina is a separate disclosure. A browser may also make network requests when it renders rich content. That creates a destination the backend's ordinary message-send logs may not capture.

For each arrow, ask two questions: who can change these bytes, and who may receive them? Authenticated authors can still supply untrusted instructions. An internal database can store text written by an outsider. Classifying the entire database as trusted loses that distinction.

A permission table you can test

This table is a case-specific policy. A different organization may assign narrower staff permissions or allow a formal cross-customer investigation. Record that policy explicitly. Do not silently turn a role named staff into access to every record.

The storage system may enforce row policies. A service may enforce object permissions. Search may apply mandatory filters. Several controls can participate; the map must show which component checks each request and whether any alternative route bypasses it. OWASP's authorization guidance calls for default denial and permission checks on every request.

Include copies and delayed work

A retrieved chunk can survive in a conversation history, response cache, trace, support export or queued draft. Put those stores on a second version of the map. For each copy, name its owner, permitted readers, retention rule and response to a permission change.

Suppose Aria loses access to Noor's account after generating an internal summary. A cache keyed by Aria's user ID still refers to the same person. The key alone cannot tell whether that summary remains permissible. Likewise, removing a document from the search index does not remove its text from an already assembled prompt. Later lessons turn these observations into revocation and containment tests.

The hosted model is another recipient. Record which data classes may leave for that processor, the selected processing arrangement and the person responsible for verifying it. A vendor name or encryption in transit does not answer retention, training-use or processing-location questions. If the relevant facts are unavailable, mark the decision unresolved and use synthetic data during design work.

Review the map with a counterexample

A useful map lets someone disprove your design. Ask a colleague to trace this benign exercise: a staff member reads an authorized internal note, then drafts an external reply. Where is the rule that prevents the note reaching an unauthorized customer? If the answer is only “the model knows this is internal,” the map has exposed a missing enforcement decision.

The OWASP threat-modeling method connects system modeling, threats, mitigations and validation. Here, the permission table is the bridge between a diagram and a testable claim.

Do this before moving on

Draw two paths for the fictional assistant: Mina's self-service answer and Aria's draft for Mina. Add the search index, model processor, response cache, audit store and message queue. For every hop, write author, acting identity, allowed data and recipient.

Then introduce one change: an internal summary is cached and reused by the draft feature. Mark the new authorization decision. Your output is ready when another reader can identify why Noor's ticket may be available to Aria but still excluded from Mina's draft. Use only a system you own or are authorized to assess if you substitute your own case.

Go deeper

• Threat modeling AI systems supplies the vocabulary for turning your diagram into explicit threats.
• Find the trust boundaries lets you compare a spoken explanation with the map you produced.
• Indirect prompt injection explains why stored customer text remains untrusted when staff retrieve it.
• Threat model an LLM chatbot changes the feature constraints and tests whether your method transfers.

Key takeaways

• Reading a record and disclosing it to a recipient require separate decisions.
• Record who controls each input even when the input lives in an internal store.
• Authorization may span storage and service gates; identify their coverage and bypasses.
• Copies, queues and external processors belong on the same security map.