AID-H-032.002: Cross-Tenant Serving-State Isolation

Version 1.20261015 · Actionable sub-technique

Prevent one tenant's requests from influencing or exposing another tenant's inference state by isolating request queues, prefix caches, KV caches, batching groups, session state, warm-worker state, failover state, memory pools, shared-memory regions, and IPC handles. Require a server-authoritative registry and lifecycle authorization for every shared-memory or IPC create, map, attach, read, write, unmap, destroy, restart, failover, and ownership-handoff operation.

This control should explicitly govern prompt-prefix reuse, request coalescing, warm caches, worker reuse, region generation and revocation, restart/failover behavior, and serving-placement decisions, because these performance features are common leakage and cross-tenant contamination paths in shared inference systems.

Pillars: infra, model, app

Lifecycle: building, operation

Scope boundary

Owns cross-tenant isolation of request queues, batching groups, prefix and KV state, sessions, warm workers, memory pools, shared-memory regions and IPC handles, failover state, serving pools, and placement remediation. It governs registry-authorized serving-state lifecycle and logical serving topology rather than general application-resource authorization, cache-object integrity, or hardware residue clearing.

AID-H-027: AID-H-032.002 enforces tenant-isolated placement and serving-state topology; AID-H-027 verifies cache keys, envelopes, authorization context, invalidation, and safe object reuse. Where both touch caches, this control consumes cache evidence and disables sharing or remediates placement.

AID-H-009.004: AID-H-032.002 isolates logical serving state above the hardware layer; AID-H-009.004 clears GPU or accelerator residue and verifies low-level compute hygiene. Worker and queue isolation do not prove VRAM sanitization.

AID-H-018.002: AID-H-032.002 owns tenant-isolated inference serving state, including shared-memory and IPC region lifecycles; AID-H-018.002 authorizes application and service resource handles at the final action adapter. An authorized business resource does not authorize inference-memory attachment, and an isolated inference region does not authorize the later business action.

Implementation guidance

AID-H-032.002-G001

Partition serving state by tenant; authorize every shared-memory and IPC lifecycle transition through an authoritative generation-bound registry; and disable cross-tenant prefix, queue, batch, warm-state, or failover reuse unless the serving platform can prove tenant-safe isolation and pass cache-timing evidence gates.
Concept:

Shared-state optimizations are attractive because they reduce latency and cost, but they can also create covert channels. The isolation design should start from a simple rule: queues, batching groups, worker state, failover state, and serving pools are tenant-scoped unless there is explicit evidence that stronger sharing is safe. Cache-object key correctness and cache-timing probes are produced by AID-H-027; this sub-technique consumes those findings and changes the serving topology or placement.

Example: tenant-scoped serving boundaries
# File: serving/tenant_state_policy.yaml
cache:
  key_template: "{tenant_id}:{model_id}:{prompt_prefix_hash}"
  prefix_or_kv_cache_shared_across_tenants: false
  cache_timing_evidence_source: "AID-H-027"
  on_cache_timing_failure: "dedicated_pool_or_disable_prefix_reuse"
batching:
  group_template: "{tenant_id}:{model_id}"
queue:
  partition_template: "{tenant_id}:{model_id}"
sessions:
  namespace_template: "{tenant_id}:{session_id}"
workers:
  warm_pool_template: "{tenant_id}:{model_family}"
failover:
  require_fresh_tenant_rebind: true
Authoritative shared-memory and IPC registry

Never expose a runtime-owned shared-memory name, file descriptor, region key, or IPC object directly as a caller-chosen identifier. Keep caller and internal namespaces disjoint. A serving-control-plane registry must create collision-safe opaque region IDs and bind each one to the authenticated owner workload, tenant, object type, byte size, access mode, generation, job or model, creation and expiry times, and current lifecycle state.

shared_memory_ipc:
  caller_namespace_template: "tenant/{tenant_id}/request/{request_id}"
  internal_namespace_template: "runtime/{workload_id}/region/{region_id}"
  accept_caller_supplied_internal_names: false
  registry:
    authority: "serving-control-plane"
    required_binding_fields:
      - owner_workload_id
      - tenant_id
      - object_type
      - size_bytes
      - access_mode
      - generation
      - job_or_model_id
      - created_at
      - expires_at
      - lifecycle_state
    authorized_operations:
      - create
      - map
      - attach
      - read
      - write
      - unmap
      - destroy
      - restart_rebind
      - failover_rebind
      - ownership_handoff
    require_atomic_generation_lease: true
    require_current_lease_at_use: true
    tombstone_destroyed_generations: true
    require_fresh_rebind_after_restart_or_handoff: true
  fail_closed_dependencies:
    - authenticated_identity
    - tenant_policy
    - region_registry
    - scheduler
    - lifecycle_readback

For every lifecycle operation, the broker derives workload and tenant identity from the authenticated channel, resolves the opaque region ID in the authoritative registry, verifies type, size, mode, job or model, generation, expiry, revocation and destroy state, and acquires an atomic generation lease before returning a descriptor or performing the operation. The final runtime must consume that exact lease and generation, then independently read back the transition. A lookup followed by an unbound map is a TOCTOU bypass. Restart, failover, worker replacement, or ownership handoff invalidates the old lease and requires a fresh authorized binding; a stale generation or destroyed tombstone never reactivates.

Shared-memory and IPC negative verification

Reconcile the complete region population and every lifecycle operation with queue, batch, warm-worker, memory-pool, scheduler, restart, failover, and handoff evidence. Test guessed and copied handles, caller-selected internal names, namespace collisions, cross-tenant attach, read-to-write escalation, wrong type or oversize mapping, stale generations, use after revoke or destroy, worker restart, failover, ownership transfer, direct runtime-API bypass, and identity, policy, scheduler, registry, or readback outages. Every mismatch or unavailable required authority fails closed; an absent shared-memory or IPC architecture is NOT_APPLICABLE for this method rather than PASS.

Additional serving-state checklist

Action: require the serving platform to document how cache keys, batching groups, queue partitions, warm-worker pools, failover state boundaries, and placement tiers are derived. If tenant identity is not part of those boundaries, or if AID-H-027 evidence shows cross-tenant prefix-cache observability, treat the platform as shared-without-proof and keep sensitive workloads off it until this sub-technique enforces a tenant-isolated or dedicated serving topology.

Keep the action safely bounded

Reconcile the complete population of every eligible request plus every serving-state lookup, batch membership, worker assignment, restart, and failover transition; reject expired, revoked, or stale policy and asset bindings under the policy-defined freshness window.

Derive all partitions from authenticated server-side identity, prohibit mixed-tenant batching and state reuse unless the exact mechanism has independently verified isolation, consume H-027 cache findings, and move affected traffic to isolated placement or disable reuse on any mismatch.

Open-source tools

Commercial / hosted tools

Threat mappings

MITRE ATLAS

MAESTRO

OWASP LLM Top 10 2026

OWASP ML Top 10 2023

OWASP Top 10 for Agentic Applications 2026

NIST Adversarial Machine Learning 2025

Cisco Integrated AI Security and Safety Framework

Google Secure AI Framework 2.0 - Risks

Databricks AI Security Framework 3.0

AID-H-032.002: Cross-Tenant Serving-State Isolation | AIDEFEND

Loading interactive view…

AIDEFEND™

A Practical Knowledge Base for AI Security Defenses

Version

GitHub MCP Service