Definitions

Definitions

The boundaries

Results

1. Make the safe path the only path: scoped repositories, namespaces, tenant-keyed caches.
2. Never accept identity from the model; derive it from the authenticated session.
3. Isolation is also performance: quotas and fair scheduling.
4. You cannot delete what you did not register.

Design rules

• Authenticate first and build an immutable request context (tenant, user, roles) that the platform, not the model, passes to tools.
• Scope data access through one layer that injects the tenant; forbid unscoped queries; add row-level security as backup.
• Use namespaces or collections per tenant for vector stores and memory; test recall by tenant size.
• Key caches by tenant (and user for personalised content); no cross-tenant semantic cache.
• Fetch per-tenant credentials at call time from a secrets manager; avoid shared broad service accounts.
• Give each tenant quotas for tokens, concurrency and queue share; schedule fairly (module 2).
• Isolate execution: separate sandboxes, filesystems and network egress rules per tenant.
• Tag all logs and traces with the tenant, restrict viewer access, set retention.
• Keep an erasure registry of all stores; test offboarding end to end.
• Write cross-tenant tests: two tenants, attempt every read path, with injected instructions; run them in CI.
• Offer stronger isolation tiers for sensitive customers.

Interview questions, with the follow-ups

Common mistakes

• Tenant id as a tool or API argument from the model or client.
• Per-endpoint tenant filters instead of an enforced scoped layer.
• Post-filtering vector results, or a shared index with no tenant tests.
• Shared caches keyed only by prompt.
• One shared service account that can read every tenant.
• No quotas, so one tenant's loop or flood affects all.
• Traces readable by every engineer, with raw tenant data inside.
• Offboarding that misses caches, traces and backups.
• No cross-tenant tests, so isolation is untested folklore.

What the example does not do

• No real database, RLS, vector store, secrets manager or authentication.
• Assumed rates: forgetting probability, model obedience, tenant sizes, traffic and budgets.
• Toy retrieval: random vectors, one query distribution, top-5 only; real stores support pre-filtering and larger candidate pools, which change the numbers.
• Cache and quota models are simple (no TTLs, no real scheduling).
• Injection is a coin flip, not a real model being attacked (Level 10 modules 1 and 8 cover that).
• No per-tenant encryption keys, residency or regional deployment.
• Much of this is general engineering knowledge, not measured fact: the isolation rules (per-session actor, environment and state isolation, and the rest) are design guidance, and only the toy experiments here were run.
• Optional real experiment (I did not run this): create two tenants in a staging copy of your platform, seed distinct secrets, and run an automated suite that tries every read path, with injected instructions, to access tenant B from tenant A; record every success as a bug.

For the curious Filtering after the search loses results as well as leaking them

Filtering after a global top-5 search left a tenant with 3,901 documents only 1.03 of its own results in 5. A cache keyed by prompt alone served 2,675 of 4,000 answers to the wrong tenant; keying by (tenant, prompt) gave 0. When one tenant flooded a shared budget, another received 24 percent of its demand; a per-tenant quota gave it 100 percent. Toy in-memory models, assumed rates, random vectors.

What you must be able to say (one page)

• Multi-tenancy means many customers share one deployment; isolation means one tenant can never read, change, slow down or learn about another. For agents the risk is higher than in ordinary SaaS because a model decides which tool calls to make, retrieved text can carry injected instructions (Level 10 module 1), and many shared layers (cache, vector index, memory, traces) sit between the user and the data. The design question interviewers ask is "design a customer-support agent platform for many companies" (this level's interview prompt).
• Where tenant data can cross: the API and session, the database, the vector index and memory, caches, tool credentials, compute and quotas, and logs, traces and backups. Put a control at each place and assume one will have a bug (defence in depth).
• Identity comes from the session, never from the model. A tool that takes tenant_id as an argument trusts whatever the model passes; a prompt injection can make the model ask for another tenant. In my simulation of 1,000 injected attempts (the model obeys 30 percent of the time, assumed), the argument-scoped tool leaked 306 times; a tool that ignores the argument and uses the tenant from the authenticated session leaked 0, even at 100 percent obedience (tested). This is the confused-deputy problem; it extends Level 10 modules 1, 2 and 5.
• Enforce the tenant filter, do not rely on convention. With a convention ("every query must pass the tenant"), 5 teams of 20 endpoints at a 5 percent forgetting rate had 6 forgetful endpoints out of 100 and returned 60 other-tenant rows; a scoped repository that injects the tenant from the request context on every query and has no unscoped read path returned 0. Add database row-level security (a policy the database itself enforces) as a second layer.
• Retrieval: filter before search, or use per-tenant namespaces. Filtering after a global top-k throws away other tenants' hits and leaves little: in my toy index (20,000 documents across 100 tenants with Zipf-like sizes, top-5, random vectors) a tenant with 3,901 documents got 1.03 of its own results in 5, one with 163 documents 0.07, one with 27 documents 0.00, and the other tenants' documents were fetched into memory (4 to 5 of 5), which is also a leak risk if the filter is ever skipped. A namespace per tenant returned 5 of 5 every time. Real vector stores offer pre-filtering or over-fetching; the lesson is to test recall per tenant size.
• Cache keys must include the tenant (and the user if answers are personal). With 3 tenants asking common prompts, a cache keyed by prompt only served 2,675 of 4,000 answers to the wrong tenant; keyed by (tenant, prompt) 0. Never share semantic caches across tenants (module 5).
• Compute isolation (noisy neighbour): when tenant A floods a shared token budget, tenant B received 24 percent of its demand; a per-tenant quota (each tenant capped at half the budget) gave B 100 percent. Combine per-tenant quotas, concurrency limits, fair queue scheduling (module 2) and bulkheads (module 6).
• Credentials and tools: per-tenant secrets fetched at call time from the session's tenant, no shared service account with broad access, and per-tenant tool allow-lists (Level 10 module 2). Sandboxes for code execution must not share filesystems or networks across tenants (Level 10 module 3).
• Logs, traces and backups hold tenant data too: tag every span with the tenant, restrict who can view which traces, set retention, and keep a registry of every store so that offboarding and erasure requests reach all of them (Level 10 module 6). In my toy, a registry that knew 4 of 6 stores left data in object_files and backups.
• Isolation levels are a spectrum: shared everything with row-level scoping (cheapest, most reliance on code correctness), schema or namespace per tenant, database or deployment per tenant (strongest, most expensive). Offer stronger isolation for regulated customers; decide by data sensitivity, cost and operations.
• Honest limits: toy in-memory models, assumed obedience and forgetting rates, random vectors, no real database, index, auth or network.