Full Report
Learn security best practices to deploy generative AI models as part of your multi-tenant cloud applications and avoid putting your customers’ data at risk.
Analysis Summary
# Best Practices: Securing Multi-Tenant Generative AI Cloud Applications (Tenant Isolation)
## Overview
These practices focus on applying the **PEACH tenant isolation framework** principles to secure multi-tenant cloud applications that leverage Generative AI (GenAI) solutions, specifically Large Language Models (LLMs). The primary goal is to prevent cross-tenant data exposure, which is a high risk due to the nature of GenAI models being potentially enriched by or containing data sourced from multiple end users.
## Key Recommendations
### Immediate Actions (Quick Wins)
1. **Restrict Index Data Sources:** Immediately limit data referenced during inference (in Indexes) to only trusted internal organizational data. Avoid relying on unvetted Internet lookups unless explicitly necessary and risk-assessed.
2. **Data Segregation Review:** Perform a rapid audit to ensure that existing data segregation mechanisms (for storage, access control, and database queries) are correctly applied to all data streams interacting with the GenAI components (models, indexes, RAG systems).
3. **Review LLM Provider Usage Policy:** Verify that your organization's use of foundation models (e.g., via Azure, GCP, AWS APIs) complies with the provider's terms regarding data processing and retention, especially concerning sensitive tenant data.
### Short-term Improvements (1-3 months)
1. **Implement Input/Output Sanitization:** Deploy robust filters and guardrails immediately upstream and downstream of the LLM call to scrub potentially sensitive tenant identifiers or extracted private information from prompts and responses.
2. **Apply PEACH Principles to Architecture:** Formally map the GenAI service architecture against the PEACH tenant isolation framework, identifying and documenting all areas where isolation boundaries might be weak (e.g., shared model instances, shared index lookups).
3. **Isolate Training/Finetuning Data:** Establish strict, tenant-separated environments for any model finetuning activities. Ensure that proprietary secrets or sensitive tenant data are **never** exposed to the model during training or finetuning cycles, regardless of subsequent runtime filters.
### Long-term Strategy (3+ months)
1. **Develop Tenant-Aware Access Control for Indexes:** Implement granular, context-aware authorization checks that verify the requesting tenant's permissions *before* allowing the underlying index retrieval system (e.g., Azure Cognitive Search) to access data during RAG/inference steps.
2. **Tenant Partition Isolation for LLM Components:** Where feasible and financially viable, migrate high-risk or highly sensitive multi-tenant workloads to employ fully partitioned LLM resources (e.g., dedicated finetuned model instances or dedicated inferencing environments per high-value tenant group) to enforce isolation at the execution layer.
3. **Establish Comprehensive Threat Modeling:** Integrate GenAI-specific attack vectors (like prompt injection or data poisoning) into the standard application threat modeling lifecycle, focusing specifically on isolation escape scenarios derived from model interaction.
## Implementation Guidance
### For Small Organizations
- **Leverage Managed Services Isolation:** Rely heavily on the isolation capabilities provided inherently by cloud service providers for their GenAI/ML services (e.g., using dedicated deployment slots or specific VNet configurations if available) to minimize custom isolation implementation overhead.
- **Stick to Off-the-Shelf Models:** Minimize finetuning initially. Use commercially available foundation models via basic API calls and focus security efforts primarily on validating user input and sanitizing LLM output.
### For Medium Organizations
- **Formalize Isolation Documentation:** Document the intended isolation mechanisms and establish ownership for each layer identified in the PEACH framework analysis related to the GenAI pipeline.
- **Implement Canary Testing for RAG Changes:** Before exposing new data sources or index configurations to the general tenant base, roll them out to a small subset to test for accidental data leakage or query scope creep.
### For Large Enterprises
- **Develop Centralized Guardrail Service:** Implement an internal security layer or service mesh component responsible for universally enforcing input prompting rules, output moderation, and tenant context injection across all consuming applications.
- **Mandate Security Gates in CI/CD:** Enforce automated checks within the DevOps pipeline that verify the data lineage for any model being finetuned to ensure no unauthorized sensitive data sources are included in the training/finetuning datasets.
## Configuration Examples
*(Specific, executable configuration snippets were not detailed in the provided text, but general best practice configurations are implied:)*
1. **Index Access Control (Conceptual):** When querying a search index, ensure the query structure explicitly includes a tenant ID filter derived from the authenticated user context:
json
{
"query": "...",
"searchFields": ["content"],
"filters": "tenant_id eq 'USER_TENANT_ID_HERE'"
}
2. **Prompt Construction Template (Conceptual):** Embed tenant context securely at ingress:
System Prompt: "You are operating on behalf of Tenant X. Do not reveal Tenant Y's data."
User Prompt: "[User Input]"
## Compliance Alignment
The focus on robust data segregation and protection aligns with established security frameworks:
* **NIST Cybersecurity Framework (CSF):** Primarily aligns with the **Protect** (PR.DS - Data Security) and **Detect** (DE.CM - Continuous Monitoring) functions regarding sensitive data boundaries.
* **ISO/IEC 27001/27002:** Aligns with controls related to access control (A.9) and data segregation in shared environments (A.14/A.18 depending on implementation details).
* **OWASP Top 10 for LLM Applications:** These practices directly address broader risks like Insecure Output Handling (LLM03) and Insecure Plugin Design (LLM05) through strict isolation and data scoping.
## Common Pitfalls to Avoid
1. **Trusting Runtime Filters Alone:** Do not assume that filters placed solely on the LLM output will prevent a successful cross-tenant data leak if the underlying data retrieval mechanism (e.g., the index lookup) has already been compromised or misconfigured to fetch shared data.
2. **Ignoring Training/Finetuning Pollution:** Neglecting the security hygiene of the training dataset. Secrets leaked during finetuning are extremely difficult to patch via runtime guardrails.
3. **Oversimplifying 'Index' Boundaries:** Assuming that because an index service is used, tenant isolation is automatically handled by that service. Tenant isolation must be explicitly enforced across the retrieval, context stitching, and presentation layers in your application logic.
## Resources
- **PEACH Framework Documentation:** Principles for Tenant Isolation in Cloud Applications (Search for the Wiz PEACH framework).
- **Microsoft Azure Documentation:** Architectural approaches for AI and ML in multi-tenant solutions.
- **OWASP:** OWASP Top 10 for Large Language Model Applications.
- **OpenAI/CSP Safety Guides:** Official safety best practices provided by foundation model producers (e.g., OpenAI safety best practices).