菜单
Review multi-tenant AI deployments for cross-tenant context leakage, LoRA adapter contamination, shared inference worker risks, system prompt bleed, and tenant isolation failures in model serving infrastructure.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Review agentic AI systems for long-term memory store poisoning, vector DB manipulation, cross-session instruction injection, and stale memory exploitation that persists attacker influence across agent sessions.
Review AI agent systems for agent impersonation, capability escalation, missing agent identity primitives, and authorization failures that allow agents to act beyond their granted permissions or impersonate other agents or human users.
Review organizational defenses against AI-assisted spearphishing, voice cloning, synthetic identity fraud, deepfake executive impersonation, and AI-accelerated reconnaissance that dramatically lowers the barrier to highly targeted social engineering attacks.
Review AI-generated content pipelines for deepfake detection gaps, provenance chain failures, C2PA implementation correctness, synthetic media attribution, and trust signal spoofing that undermines content authenticity verification.
Review AI browser agents for DOM injection attacks, credential harvesting via web automation, malicious web content that hijacks agent actions, session cookie theft, and phishing sites engineered to exploit browser-controlling AI agents.
Review upstream dataset integrity controls, HuggingFace repository risks, dataset versioning, dependency pinning, and third-party dataset provenance to prevent malicious data from entering training or RAG pipelines.
| name | multi-tenant-model-isolation |
| description | Review multi-tenant AI deployments for cross-tenant context leakage, LoRA adapter contamination, shared inference worker risks, system prompt bleed, and tenant isolation failures in model serving infrastructure. |
| last_reviewed | "2026-04-30T00:00:00.000Z" |
In a multi-tenant AI system, every shared resource is a potential cross-tenant channel. The question is not whether leakage is possible, but whether you have closed each channel.
Multi-tenant LLM deployments share compute, memory, and sometimes model weights across customers. This is economically necessary and technically achievable — but only when every isolation boundary is explicitly implemented and verified. The threat is not always an active attacker; it is often a configuration gap that allows one tenant's context to influence another tenant's session through shared inference state, caching, or adapter contamination.
| Principle | What It Means Here |
|---|---|
| Validate | Tenant identity is established from a cryptographically verified credential, not from user-supplied headers or request body fields. |
| Scope | All data access, cache lookups, RAG retrievals, and adapter loads are scoped by tenant ID as a mandatory, non-overridable parameter. |
| Isolate | KV cache, conversation context, system prompt, and adapter state are fully flushed between tenants on shared inference workers. Cross-tenant state persistence is architecturally prevented. |
| Enforce | Cross-tenant access attempts — detected through ID mismatches, failed scoping filters, or access pattern anomalies — trigger immediate alerts and session termination. |
The core vulnerability: Shared inference workers that process multiple tenants' requests must guarantee that no state from one tenant's session persists to influence another tenant's session. Improper KV cache management is the most common failure mode.
class TenantAwareInferenceWorker:
def __init__(self, model):
self.model = model
self.current_tenant_id: str | None = None
def handle_request(self, request: InferenceRequest) -> InferenceResponse:
if request.tenant_id != self.current_tenant_id:
self.flush_tenant_state()
self.current_tenant_id = request.tenant_id
self.load_tenant_config(request.tenant_id)
return self.model.generate(
system_prompt=self.tenant_config.system_prompt,
messages=request.messages,
)
def flush_tenant_state(self):
self.model.clear_kv_cache()
self.tenant_config = None
self.current_tenant_id = None
# Also clear any in-process conversation state
The core vulnerability: Shared data stores (vector databases, conversation history tables, configuration stores) used across tenants must enforce tenant scoping at the query level, not the application level. An application-level bug that omits a tenant filter exposes all tenant data to all other tenants.
# PostgreSQL row-level security for tenant isolation
# In migration:
# ALTER TABLE conversation_history ENABLE ROW LEVEL SECURITY;
# CREATE POLICY tenant_isolation ON conversation_history
# USING (tenant_id = current_setting('app.current_tenant_id')::uuid);
def get_db_connection(tenant_id: str) -> Connection:
conn = pool.acquire()
# Set tenant context for row-level security
conn.execute("SET app.current_tenant_id = %s", (str(tenant_id),))
return conn
tenant_id from the verified JWT or session token — never from a request body field, URL parameter, or header that the client controls.Add a cross-tenant isolation smoke test to your deployment pipeline. Inject a unique canary string in Tenant A's system prompt, then query Tenant B for it in the same environment. This single test catches the most common KV cache and context bleed failures before they reach production.