AID-H-032.001: Dedicated Capacity for High-Sensitivity Inference

Version 1.20261015 · Actionable sub-technique

Route high-sensitivity AI workloads to dedicated or reserved inference capacity instead of shared multi-tenant serving pools. This control is appropriate when prompts, retrieved data, outputs, or model IP would create unacceptable harm if leaked through co-tenant state reuse, side-channel observation, or provider telemetry. The design objective is not merely better performance; it is reduced blast radius and stronger confidentiality assumptions.

Pillars: infra, model, app

Lifecycle: scoping, operation, building

Scope boundary

Owns policy-based placement of high-sensitivity inference on dedicated or reserved capacity to remove unacceptable co-tenant confidentiality assumptions. It is a capacity-isolation decision, not a geographic routing or provider-evidence control.

AID-H-032.004: AID-H-032.001 selects dedicated capacity when shared tenancy is unacceptable; AID-H-032.004 verifies whether an external service's exact tier, runtime, region, and isolation evidence satisfy placement policy. A dedicated marketing label is insufficient without authenticated evidence where policy requires it.

AID-H-033.003: AID-H-032.001 decides shared versus dedicated tenancy; AID-H-033.003 decides eligible provider endpoints and regions from residency, retention, and training-use constraints. Capacity isolation and legal or geographic routing are separate dimensions.

Implementation guidance

AID-H-032.001-G001: Classify workloads and enforce a policy that forbids shared serving pools for high-sensitivity prompts, retrieved data, or proprietary models.

AID-H-032.001-G001

Classify workloads and enforce a policy that forbids shared serving pools for high-sensitivity prompts, retrieved data, or proprietary models.

Concept:

Do not treat dedicated capacity as a generic performance upgrade. Treat it as a security requirement for workloads whose confidentiality cannot tolerate co-tenant leakage risk.

Example: workload placement policy

# file: placement_policy.yaml
workload_classes:
  - name: public_chat
    sensitivity: low
    serving_tier: shared
  - name: internal_copilot
    sensitivity: medium
    serving_tier: shared_hardened
  - name: m_and_a_assistant
    sensitivity: critical
    serving_tier: dedicated
  - name: source_code_ip_model
    sensitivity: critical
    serving_tier: dedicated

Action: enforce the placement rule at deployment admission time. If a critical workload requests a shared serving tier, reject the deployment rather than silently accepting weaker isolation.

Keep the action safely bounded

Reconcile the complete population of every replica, endpoint, failover target, and traffic route serving the classified workload; reject expired, revoked, or stale policy and asset bindings under the policy-defined freshness window.

Reject shared or ambiguously shared placement, bind the workload to an approved dedicated pool and failure domain, prevent automatic spillover to shared capacity, and block traffic until the effective provider or scheduler placement is read back.

Verify safely

A separately credentialed verifier independently replays the classification-to-placement decision and effective scheduler or provider state, including shared-tier requests, autoscaling, failover, rescheduling, and provider-tier drift fixtures, reads back effective state from the enforcement system, exercises positive, negative, boundary, stale-evidence, and dependency-failure fixtures, and reconciles every eligible item.

Open-source tools

Kubernetes
KServe
vLLM
Open Policy Agent (OPA)

Commercial / hosted tools

Red Hat OpenShift AI
NVIDIA DGX Cloud Lepton Reservations (exclusive nodes; disable fallback to unreserved nodes)
Amazon Bedrock Provisioned Throughput for custom models (dedicated compute capacity; separate serving-state isolation evidence required)
Microsoft Foundry provisioned throughput (reserved throughput only; does not prove hardware isolation; disable spillover)
Vertex AI Provisioned Throughput (reserved throughput only; does not prove hardware isolation; reject pay-as-you-go overages)

Threat mappings

MITRE ATLAS

AML.T0025 Exfiltration via Cyber Means

MAESTRO

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

NIST Adversarial Machine Learning 2025

NISTAML.036 Leaking information from user interactions

Cisco Integrated AI Security and Safety Framework

AITech-8.2 Data Exfiltration / Exposure (requires dedicated serving placement without shared-pool spillover)
AITech-8.3 Information Disclosure (requires dedicated serving placement without shared-pool spillover)

Google Secure AI Framework 2.0 - Risks

SDD: Sensitive Data Disclosure

Databricks AI Security Framework 3.0

Model 7.2: Model assets leak