On this page
The short answer
Test tenant isolation across the entire task path using paired synthetic tenants with deliberately similar records. Inspect retrieval, tools, memory, caches, queues, and permitted observability views. A final answer without another tenant’s name does not prove isolation if restricted context or actions crossed an earlier boundary.
What to take away
- Reuse similar names to expose missing tenant scope.
- Inspect intermediate data and committed operations.
- Exercise warmed caches and background workers.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Inventory every surface that carries tenant context
Cloudflare documents cache equivalence through default and custom key construction. Rubrex recommends treating cache scope as one part of a larger tenant-context inventory. Retrieval indexes, durable memory, tool adapters, queued jobs, and trace views also need explicit ownership.
Create synthetic tenants Amber and Birch, each with a project called Launch and a different harmless policy marker. Give them matching short record identifiers where the fixture supports it. The intended boundary is that each caller reads and changes only their own resources even when names and user questions are identical.
Evidence: Cloudflare AI Gateway: Caching [1]
Exercise warm paths and lost context
Warm a response cache with Amber’s request, then send Birch’s identical text. Repeat a document lookup, memory recall, and tool write under the second identity. A shared provider credential or identical prompt does not establish that two callers may share the same evidence or response.
Send a task through a mock background queue and inspect how tenant context reaches the worker. Remove the explicit tenant field in a controlled negative case. The worker should reject incomplete context rather than substitute a default tenant or infer ownership from a display name in the model’s arguments.
Review exposure and effects independently
Capture model context, tool requests, service decisions, and final records. Search for the other tenant’s marker in authorized test exports and artifacts. Also inspect whether an unauthorized write was attempted or committed even when no marker appeared in the final prose.
Run permitted same-tenant controls after each denied cross-tenant case. Report false denials, restricted-data exposure, unauthorized effects, and missing attribution separately. If observability access is included in the product, verify that a tenant-scoped viewer cannot inspect another tenant’s trace metadata merely because application output isolation is correct.
| Case | Evidence to retain | Acceptance condition |
|---|---|---|
| Identical cached query | Cache scope and returned marker | Correct tenant response |
| Queued task missing scope | Worker admission decision | No default-tenant action |
| Similar record IDs | Commit receipt and owner | Only caller-owned record changes |
Accept a bounded end-to-end isolation record
Release the Launch workflow when every tested surface preserves trusted tenant context and missing context fails in a controlled way. Bind service decisions to authenticated identity; do not let a generated tenant argument override it. Document any shared public corpus separately so legitimate shared content is not mislabeled as leakage.
Retain the tenant matrix, deployment mode, cache configuration, queue envelope, and evidence. Re-run when adding a shared store, exporter, or worker. A successful paired fixture is concrete evidence about these paths, not proof that all unknown cross-tenant interactions or infrastructure vulnerabilities have been excluded.
Limits of the evidence
The tenant matrix is proposed with invented records. No production isolation audit was performed. Cache documentation supports the equivalence concern, not a claim of a vulnerability in a named provider or a guarantee for the complete application.
Common questions
Is a tenant field in the prompt enough?
No. Use trusted identity and enforce scope at the services that access data or commit actions.
Can public documents be shared?
Yes, if their shared status is deliberate and separate from tenant-private evidence.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- Cloudflare AI Gateway: Caching Cloudflare · Living reference · Maintained documentationReviewed: documented default cache-key inputs and response sharing through custom cache keys; no vulnerability claim. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.