AID-H-032: Multi-Tenant Inference Isolation & Leakage Prevention

Version 1.20261015 · Family — navigation only

Reduce cross-tenant leakage risk in shared AI inference infrastructure and third-party AI SaaS by enforcing tenancy-aware isolation for compute, serving state, cache layers, telemetry, and tenant-verifiable provider isolation evidence. This family technique addresses the reality that shared LLM or model-serving environments can expose prompts, context, outputs, model internals, or request patterns through state reuse, side channels, insufficient cache isolation, profiling surfaces, or weak provider isolation evidence.

Why this exists: accelerator hygiene and confidential computing are necessary but not sufficient. Enterprises increasingly consume inference as a service; they therefore need controls that govern which workloads may run on shared serving pools, what tenancy guarantees the provider must prove, and how serving-state leakage is prevented at runtime.

Scope boundary

Owns confidentiality isolation for shared or external inference services across capacity, serving state, tenant placement, profiling and debug surfaces, and provider evidence. It addresses service-tenancy leakage rather than generic output policy or component integrity.

AID-H-009.004: AID-H-032 owns shared-serving and tenant-placement isolation; AID-H-009.004 owns accelerator residue clearing and low-level compute hygiene. Clean VRAM does not isolate queues or KV caches, and logical tenant isolation does not prove hardware residue removal.

AID-H-027: AID-H-032 governs the broader shared inference topology and tenant boundary; AID-H-027 governs authenticity, context binding, and safe reuse of individual cache objects. Serving isolation must consume correct cache decisions without collapsing into cache implementation.

Warning

Medium to High on Cost, Capacity Planning, and Provider Choice

Stronger isolation for high-sensitivity inference may require dedicated capacity, provider-specific features, or reduced observability. These controls can increase cost and limit scheduling flexibility.

Guidance: classify workloads by confidentiality and business impact. Use the strongest isolation only where shared inference creates unacceptable disclosure risk, rather than mandating dedicated capacity for every use case.

Sub-techniques

Threat mappings

MITRE ATLAS

AML.T0025 Exfiltration via Cyber Means

MAESTRO

Data Leakage through Observability (L5)
Data Leakage (Cross-Layer)

OWASP LLM Top 10 2026

LLM02:2026 Sensitive Information Disclosure

OWASP ML Top 10 2023

OWASP Top 10 for Agentic Applications 2026

ASI06:2026 Memory & Context Poisoning

NIST Adversarial Machine Learning 2025

NISTAML.036 Leaking information from user interactions

Cisco Integrated AI Security and Safety Framework

AITech-4.2 Context Boundary Attacks
AITech-7.4 Token Manipulation
AITech-8.2 Data Exfiltration / Exposure
AITech-8.3 Information Disclosure
AITech-8.4 Prompt/Meta Extraction
AITech-11.2 Model-Selective Evasion
AITech-14.1 Unauthorized Access
AITech-16.1 Eavesdropping
AISubtech-4.2.2 Session Boundary Violation
AISubtech-7.4.1 Token Theft
AISubtech-8.3.2 System Information Exposure
AISubtech-8.4.1 System LLM Prompt Leakage
AISubtech-11.2.1 Targeted Model Fingerprinting
AISubtech-14.1.2 Insufficient Access Controls
AISubtech-16.1.1 Logging Sensitive Conversations

Google Secure AI Framework 2.0 - Risks

SDD: Sensitive Data Disclosure

Databricks AI Security Framework 3.0

Model 7.2: Model assets leak
Model Serving - Inference requests 9.10: Accidental exposure of unauthorized data to models
Model Serving - Inference response 10.6: Sensitive data output from a model