[EAAPL-PLT007] Multi-Tenant AI Platform

Category: Platform Engineering Sub-category: Multi-Tenancy / SaaS Platform Version: 1.1 Maturity: Proven Tags: multi-tenancy, tenant-isolation, data-isolation, cost-isolation, chargeback, tenant-onboarding, vector-store-isolation, policy-enforcement Regulatory Relevance: APRA CPS 234, Privacy Act / GDPR (data separation), EU AI Act Article 9, ISO 27001 A.9

1. Executive Summary

When an AI platform serves multiple tenants—whether internal business units within an enterprise or external customers of an AI-powered SaaS product—tenant isolation becomes a foundational engineering and compliance requirement. The failure mode is severe: a cross-tenant data leak from the AI system exposes confidential information to a competitor, breaches privacy legislation, and destroys trust simultaneously.

The Multi-Tenant AI Platform pattern establishes a rigorous isolation architecture spanning compute, data (including vector stores for RAG), cost attribution, and policy enforcement. It defines three isolation tiers—shared pool, dedicated namespace, and dedicated compute—each with different isolation strength, cost profile, and operational complexity, so platform architects can select the right tier for each tenant category. The pattern also provides an automated tenant onboarding framework that provisions all isolation controls consistently without platform team manual intervention, removing the risk of human error in security configuration. For enterprises and SaaS providers operating AI at scale, this pattern is the foundation upon which regulatory compliance and commercial trust are built.

2. Problem Statement

Business Problem

Enterprise business units and external customers expect their AI interactions, documents, and derived insights to be completely isolated from other tenants. A financial services platform where Client A's AI-processed documents are accessible to Client B's queries is a regulatory breach and a liability event. An internal enterprise platform where one business unit's AI queries reveal another's strategic data is a governance failure.

Technical Problem

AI platform components are inherently multi-tenant targets: vector stores index content from multiple tenants; caches may serve responses across tenant boundaries; model endpoints are shared compute. Without explicit isolation controls at each layer, cross-tenant data leakage is possible through RAG retrieval (returning documents from the wrong tenant), cache poisoning (serving a cached response from one tenant to another), or cost attribution errors (one tenant's usage charged to another).

Symptoms

• Vector store queries returning documents without tenant scoping (all-tenant search)
• No per-tenant rate limits or cost attribution; tenants experience noisy neighbour effects
• Tenant onboarding is a manual process requiring platform team involvement; inconsistent security configuration
• No per-tenant policy enforcement; one data classification policy applied globally
• Cost management treats all tenants as a single entity; chargeback impossible

Cost of Inaction

• Cross-tenant data leakage incident triggering regulatory investigation, breach notification, and reputational damage
• Noisy neighbour compute contention causing SLA breach for premium tenants
• Inability to operate AI as a SaaS product without demonstrable tenant isolation
• Manual onboarding taking 2–4 weeks per tenant, limiting growth velocity

3. Context

When to Apply

• Platform serves ≥2 tenants with confidentiality requirements between them
• External-facing SaaS product built on AI capabilities with customer data isolation requirements
• Internal enterprise platform with compliance obligation to separate BU data (e.g., different regulatory jurisdictions)
• Chargeback or billing by tenant is required
• Tenants have different policy requirements (e.g., some tenants have more restrictive data classification rules)

When NOT to Apply

• Single tenant with no isolation requirement: overhead not warranted
• Fully federated model where each tenant operates their own platform instance: tenant isolation is achieved at infrastructure level, not within a shared platform
• Proof-of-concept: implement single-tenant first; multi-tenancy retrofit is always harder than building it in

Prerequisites

• Identity provider with tenant-scoped claims in JWTs (tenant ID in token)
• AI API Gateway (PLT002) as enforcement point for tenant context
• Vector store that supports namespace or metadata filtering (required for RAG isolation)
• Cost management service capable of per-tenant attribution
• Infrastructure-as-code for automated tenant provisioning

Industry Applicability

4. Architecture Overview

The Multi-Tenant AI Platform addresses isolation across five dimensions: identity, compute, data, cost, and policy. Each dimension has multiple isolation tier options, and the appropriate combination of tiers per tenant type drives the overall architecture.

Tenant Identity and Context Propagation establishes the tenant as a first-class citizen in all platform components. Every authenticated request carries a tenant ID claim in its JWT (or API key metadata). This tenant ID is extracted by the AI API Gateway at authentication time and propagated as a context header (X-Tenant-ID) to all downstream platform services. No downstream service makes a data access decision without this tenant context; it is the universal key for isolation enforcement. The tenant registry (a simple lookup table mapping tenant IDs to isolation tier, policy profile, and resource configuration) is consulted by the gateway on every request.

Compute Isolation Tiers define the strength of isolation at the inference layer. The Shared Pool tier routes all tenants to the same model endpoint pool; isolation is enforced through request-level context and response handling only. This is appropriate for internal business units with a trust relationship. The Dedicated Namespace tier gives each tenant a logically separate API endpoint with dedicated rate limits and circuit breakers, but sharing underlying model compute. This is appropriate for external customers with contractual SLA requirements. The Dedicated Compute tier provisions separate model serving infrastructure per tenant; this is the strongest isolation, appropriate for high-value customers or regulatory requirements (e.g., financial data processing where the model server must be in the customer's own environment).

Data Isolation — Vector Store is the most technically complex isolation requirement. When tenants use RAG (retrieval-augmented generation), documents from different tenants must never appear in each other's retrieval results. This is achieved through namespace isolation (each tenant has a dedicated namespace or collection in the vector store; queries are scoped to the tenant's namespace by the platform, not by the application code) or metadata filtering (all documents are stored in a shared collection with a tenant_id metadata field; every query includes a mandatory filter on this field that the platform injects and that cannot be removed by the application). The namespace approach is stronger (physical isolation; no risk of filter bypass); metadata filtering is simpler but requires the filter injection to be implemented correctly and consistently at every query site.

Cost Isolation and Chargeback provides financial accountability. The cost management service (PLT004) maintains per-tenant token consumption counters. Each tenant has a configured budget with independent warning and blocking thresholds. Billing for external SaaS tenants is generated from the cost event stream, filtered by tenant ID, and integrated with the billing system (Stripe, Zuora) via a reconciliation job. Internal chargeback reports aggregate monthly spend by tenant/BU for finance system integration.

Per-Tenant Policy Enforcement allows tenants to have different data classification rules, model access policies, and output filtering requirements. The policy engine (OPA) evaluates policies against a composite context including both the platform's global policies and the tenant's specific overrides. This means a tenant operating in the EU can have stricter data residency rules than a tenant in another jurisdiction, without requiring separate platform infrastructure.

Tenant Onboarding Automation is the operational mechanism that makes multi-tenancy scalable. A tenant onboarding workflow (implemented as an Infrastructure as Code template or an internal workflow service) provisions all isolation resources consistently in a single automated run: creates the tenant namespace in the vector store, creates the rate limit quota in Redis, creates the tenant record in the tenant registry, creates the API key in the secrets manager, creates the policy profile in OPA, creates the cost budget in the cost management service, and sends the onboarding confirmation to the tenant. This process must be idempotent (safe to re-run) and audited (every provisioning action logged).

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow — Tenant-Scoped RAG Request

Error Flow

8. Security Considerations

Tenant Isolation Enforcement

• Tenant ID in JWT must be a non-forgeable claim signed by the trusted IdP; tenant ID must never be accepted from request body or URL parameters
• Namespace injection into vector store queries must occur at the platform layer, not application layer; applications must not be trusted to correctly scope their own queries
• Zero-trust principle: every request is re-evaluated for tenant context regardless of previous requests in the same session

Data Separation

• Vector store namespaces use hard partitioning (separate collections in Qdrant, separate schemas in pgvector with RLS) rather than soft filtering where possible
• Cache entries are always prefixed with tenant namespace ({tenant_id}:{cache_key}); Redis ACLs enforce per-namespace access
• Audit logs include tenant ID on every record; security monitoring tracks cross-tenant anomalies

OWASP LLM Top 10

9. Governance Considerations

Tenant Data Governance

• Each tenant's data in the vector store is subject to the tenant's own data governance policies; the platform provides isolation infrastructure but does not govern tenant data content
• Platform retains logs of all access to tenant namespaces; these logs are available to tenants as part of their audit rights

Onboarding Governance

• All tenant onboarding must be performed via the automated workflow; manual provisioning is prohibited as it bypasses audit and consistency controls
• Tenant offboarding (data deletion) must be automated and audited; all tenant namespaces and cost records purged within the agreed retention period

Governance Artefacts

10. Operational Considerations

Monitoring

SLOs

Disaster Recovery

11. Cost Considerations

Cost Drivers

Indicative Cost Range

12. Trade-Off Analysis

Isolation Tier Selection

Vector Store Isolation Options

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

Privacy Act / GDPR

• Tenant namespaces in vector stores constitute separate data processing environments; the platform operator acts as a data processor and must ensure isolation of controllers' data
• Tenant offboarding must include complete data deletion from all namespaces; automated deletion with audit log satisfies data erasure obligations

APRA CPS 234

• Multi-tenant isolation controls are information security capabilities that must be maintained per CPS 234 paragraph 36
• Quarterly cross-tenant penetration tests are required to verify isolation controls as CPS 234 operational resilience evidence

EU AI Act Article 9

• Per-tenant risk management configurations allow different risk profiles per customer, satisfying Article 9's requirement for context-specific risk management systems

15. Reference Implementations

AWS

Azure

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven Multi-tenant AI platforms are in production at SaaS companies and enterprises. Qdrant native multi-tenancy, pgvector RLS, and Redis namespace isolation are all production-ready. Automated onboarding is the variable factor.

Scoring Matrix

18. Revision History