A 15-minute tenant-isolation exercise

Your result in 15 minutes

Create a small boundary diagram and three test cases for a knowledge assistant used by two separate tenants. You need a browser and somewhere to take notes. No model, GPU, account or installation is required.

This is a design exercise. Record expected behavior here; only a later test against a running system can establish observed behavior.

If you arrived from Your AI runs locally. Is every tenant's data isolated?, use this exercise to turn the article's questions into a concrete review.

1. Define two synthetic tenants — 3 minutes

Use these invented records. Do not use customer data or credentials.

| Identity | Verified membership | Document | Synthetic content | | --- | --- | --- | --- | | Alice | Tenant A | A-PLAN | Tenant A's project code is BLUE-ORCHID. | | Bob | Tenant B | B-PLAN | Tenant B's project code is AMBER-KITE. |

For this exercise, each user may read only their tenant's document. Neither user has an administrator role.

Write the rule: A request may retrieve a document only when the authenticated user's verified tenant membership permits it. A tenant name supplied in a prompt or request body is not proof of membership.

2. Draw the request and its boundaries — 4 minutes

Copy this flow into your notes, then draw a separate boundary around each tenant's data:

Alice / Tenant A                    Bob / Tenant B
       |                                  |
       +----> Authentication and policy <-+
                        |
              Verified tenant context
                        |
              Authorized retrieval
                /               \
       A documents/index    B documents/index
                \               /
              Permitted context only
                        |
                  Model endpoint
                        |
             Answer + scoped citations
                        |
               Protected evidence

Label any shared components: gateway, retrieval service, model runtime, caches, queues, logs and administrators. Separate document stores do not by themselves establish separation in every shared service.

For each shared component, name its control owner and how tenant context is checked. If you do not know how a shared inference runtime isolates request state, mark that as an unresolved requirement. Consider separate serving instances where your isolation requirement calls for them.

The architecture gallery includes a tenant-isolated RAG design and a comparison of API and self-hosted deployment boundaries.

3. Write allowed and denied tests — 5 minutes

| Test | Request | Expected behavior | Evidence to inspect | | --- | --- | --- | --- | | Allowed | Alice asks for the project code in A-PLAN. | Authorized context includes A-PLAN, and the answer can cite it. | Verified tenant A, retrieved document IDs, citation ID and policy decision. | | Denied | Alice asks explicitly for B-PLAN, including its document ID. | Authorization denies access or retrieval produces no authorized result. B-PLAN text never reaches the model. | Denial decision and retrieved-context inspection showing no tenant B content. A harmless-looking answer alone is insufficient. | | Spoofed tenant | Alice sends a request with tenant_id=B. | The server rejects the mismatch or uses Alice's verified membership. The body cannot grant tenant B access. | Effective tenant context and policy decision at the retrieval boundary. |

Keep evidence synthetic and minimal. Prefer document IDs and decisions; inspect actual context only in this controlled exercise. A denial event must not copy the denied document's contents into broadly accessible logs.

Stretch test: repeat the allowed A and B requests concurrently, then alternate them through cache hits, errors and retries. Check for mixed citations, responses or evidence. Passing one serial request does not establish isolation under load or recovery.

4. Review your output — 3 minutes

Your notes should answer all five questions:

1. Which identity establishes the effective tenant, and where is it verified?
2. Where is unauthorized data blocked before entering model context?
3. Which caches, queues, runtimes and logs are shared?
4. What evidence distinguishes an enforced denial from a model that simply did not reveal the data this time?
5. Which requirement remains untested, and who owns the next test?

Use this compact record for each case:

Case: allowed / denied / spoofed tenant
Actor and verified tenant:
Target document:
Enforcement point and owner:
Expected decision and permitted context:
Observed result: not run (design exercise)
Evidence to collect:
Unresolved gap and next action:

Continue from the exercise

• Read Trust boundaries and data flows for the fuller mapping method.
• Explore the public Introduction to private RAG before choosing an executable workshop.
• Choose a learning path to connect this exercise to your role.
• Create a free account to save your progress. Email confirmation also unlocks the advanced SAI-230 onward lessons; this exercise remains public.