C5 for Multi-Tenant GenAI SaaS

Multi-tenant GenAI SaaS has a simple failure mode: one tenant's data appears in another tenant's prompt, retrieval result, trace, or generated answer. C5-oriented controls should make that failure hard to create and easy to detect.

Isolation Layers

• Identity isolation: tenant-bound users, administrators, sessions, and tokens
• Data isolation: tenant-aware source stores, indexes, embeddings, caches, and logs
• Runtime isolation: separated queues, workers, namespaces, or accounts based on risk
• Key isolation: tenant-specific keys where contractual or risk requirements demand it
• Observability isolation: support and engineering teams cannot casually inspect tenant payloads

RAG-Specific Risks

Vector stores need strong tenant filtering and authorization checks after candidate retrieval. Metadata filters alone are not enough if ingestion, indexing, or query code can drop tenant context.

Testing Evidence

• Cross-tenant retrieval tests
• Authorization bypass tests
• Admin access review results
• Tenant deletion and export test records
• Incident drills for cross-tenant leakage

Bottom Line

For multi-tenant GenAI SaaS, C5 readiness depends on demonstrable tenant boundaries across identity, data, runtime, logs, and support operations. Tenant ID in a prompt is not isolation.