[EAAPL-SEC003] Model Isolation

Category: Security / Compute Isolation Sub-category: Blast Radius Limitation Version: 1.2 Maturity: Proven Tags: isolation sandboxing network-segmentation process-isolation resource-quotas egress-control zero-trust Regulatory Relevance: APRA CPS234 §21, EU AI Act Art. 9, ISO 27001 A.13.1, NIST AI RMF MANAGE 2.2

1. Executive Summary

Model Isolation defines the architectural pattern for constraining the execution environment of AI models — whether hosted internally or accessed via API — to limit the blast radius of a model compromise, data exfiltration attempt, or misconfigured model workload. It treats every model execution environment as a potential attack surface and applies defence-in-depth isolation controls at the network, process, storage, and identity layers.

For executives, the business case is straightforward: AI models represent a new class of compute workload with unique risk characteristics. Unlike a web server that executes deterministic code, an LLM or ML model can be manipulated by adversarial inputs to produce unexpected outputs, access data it should not access, or generate outputs that cause downstream harm. If a model execution environment is not properly isolated, a compromised model can become a pivot point for lateral movement across the enterprise network, access secrets or databases it should never reach, or exfiltrate data through its outputs.

This pattern is especially critical for organisations running on-premises model inference, fine-tuning workloads, or AI agents with tool access. It is equally relevant as a design requirement when evaluating model hosting vendors: the vendor's isolation architecture should be reviewed against this pattern before procurement decisions.

2. Problem Statement

Business Problem

Enterprises running AI model workloads face a novel risk: a model serving network requests is a stateful, long-running process that processes inputs from potentially adversarial sources. Unlike a stateless API endpoint, a model's behaviour can be influenced by its inputs in complex ways. If the model process runs with broad network access, file system access, or cloud IAM permissions, a successful adversarial input or model misconfiguration can lead to data exfiltration, lateral movement, or privilege escalation.

Technical Problem

AI model serving processes — whether Python (PyTorch, Transformers, vLLM), Go-based inference servers, or containerised model endpoints — typically run with more permissions than required:

• Network access to all subnets (allowing lateral movement if compromised).
• File system access to model weights, configuration, and sometimes application data.
• Cloud IAM roles with broad permissions (inherited from the host's instance profile).
• Outbound internet access (a model can exfiltrate data through HTTP calls in a tool-enabled agentic context).
• No resource quotas (a single runaway inference job can starve other workloads).

Symptoms

• Model serving processes running as root or with excessive IAM permissions.
• No network segmentation between model servers and sensitive data stores.
• Model weights stored on writable file systems (enabling weight poisoning).
• No egress controls on model serving infrastructure.
• Unrestricted resource usage by individual inference jobs.

Cost of Inaction

3. Context

When to Apply

• Any on-premises or cloud-hosted AI model inference workload.
• AI agents with tool access (the consequences of a compromised agent are significantly higher than a passive model).
• Fine-tuning workloads that process proprietary or sensitive training data.
• Multi-tenant AI platforms where multiple teams or customers share model infrastructure.
• RAG systems where the model has access to a document retrieval layer.

When NOT to Apply

• External API-only model usage (Azure OpenAI, Anthropic Claude via API) — isolation is the provider's responsibility; however, this pattern informs the contractual and audit questions to ask the provider.
• Single-developer local experimentation environments.

Prerequisites

Industry Applicability

4. Architecture Overview

Model isolation is implemented as a set of concentric isolation boundaries — each layer reduces the blast radius of a compromise at the layer above. The architecture philosophy is: assume the model is compromised; design the environment so that a compromised model cannot reach anything of value.

Network Isolation

Model serving workloads are deployed in a dedicated, isolated network segment (VPC subnet, Kubernetes namespace with NetworkPolicy, or dedicated VLAN). This segment has no direct connectivity to:

• Core databases (customer data, financial records).
• Secrets stores (vault, secrets manager).
• Internal corporate networks.
• Internet (unless explicitly permitted by egress policy).

Inbound traffic reaches the model only from the AI Gateway (EAAPL-SEC001) via a specific port. All other inbound traffic is denied. Outbound traffic is restricted to: the model registry (to fetch weights), the telemetry endpoint (to ship metrics/logs), and explicitly allowlisted tool endpoints (for agentic use cases). A DNS sinhole or DNS firewall prevents the model from resolving arbitrary internet hostnames.

Process Isolation

Model serving processes run with the minimum operating system permissions required:

• Non-root user (UID 1000+).
• Read-only root filesystem (model weights and configuration are mounted read-only).
• No CAP_SYS_ADMIN or other privileged Linux capabilities.
• Seccomp profile restricting available system calls to those required for inference.
• AppArmor or SELinux policy enforcing the process's access to file system paths.
• No access to the host network namespace (container network only).

In Kubernetes, this is implemented via a PodSecurityPolicy (or Pod Security Admission in modern Kubernetes) with runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, and a custom seccomp profile.

Resource Quotas

Runaway inference jobs cause denial of service. Resource quotas are enforced at:

• Container level: CPU requests/limits, memory requests/limits, GPU memory limits.
• Kubernetes namespace level: ResourceQuota objects limiting total CPU, memory, and GPU across all pods.
• Per-request level: token limits enforced by the serving layer (vLLM max_tokens, TGI max_new_tokens).

Resource quotas protect not only the model infrastructure but also adjacent workloads sharing the cluster.

Secret Access Minimisation

The model serving process requires no secrets beyond what is needed to authenticate to the model registry and emit telemetry. It does not hold database credentials, user API keys, or service-to-service tokens. Any secrets required are:

• Injected at startup via a sidecar (Vault Agent, AWS Secrets Manager CSI driver) and expire after use.
• Never stored in environment variables (accessible to any process in the container).
• Never stored in the model's context window.

Read-Only Model Weights

Model weight files are mounted read-only. This prevents weight poisoning attacks (where an attacker with write access to the model's file system can modify weights to alter model behaviour). Weights are loaded from a signed, immutable artefact store (container registry with image signing, S3 with Object Lock) and verified at startup using a cryptographic hash.

Egress Controls for Agentic Systems

For AI agents with tool access, egress is the highest-risk attack surface. A compromised agent can use legitimate tool calls to exfiltrate data. Egress controls implement:

• An explicit tool endpoint allowlist enforced at the network layer (not just application layer).
• Rate limits on tool call frequency to limit exfiltration bandwidth.
• Deep packet inspection on HTTP tool calls (payload inspection for data exfiltration patterns).
• Tool call audit logging to detect anomalous patterns.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow

Error Flow

8. Security Considerations

Authentication & Authorisation

• Model serving process has no inbound authentication to manage (auth handled by AI Gateway before request reaches model).
• Outbound authentication for tool calls uses short-lived tokens injected by the secret sidecar — never long-lived credentials embedded in configuration.
• Kubernetes Service Account tokens used for Vault authentication are bound to the specific pod's namespace and expire within 1 hour.

Secrets Management

• No secrets in environment variables (visible in container inspect, logs, crash dumps).
• No secrets in model weights or configuration files.
• Secret sidecar injects credentials into in-memory tmpfs only.
• All credential access logged by Vault for audit.

Data Classification

• Model execution environment is classified at the sensitivity level of the highest-classification data it will process. A model serving requests containing CONFIDENTIAL data must be isolated in a CONFIDENTIAL-tier network segment.
• Cross-classification boundary serving is prohibited — a model serving CONFIDENTIAL requests must not also serve PUBLIC requests (context window contamination risk).

Encryption

• Model weights encrypted at rest in registry (AES-256, provider-managed key) and in transit (TLS 1.3 from registry to pod).
• Network traffic within the pod is encrypted using Kubernetes pod-to-pod mTLS (Istio/Linkerd) or WireGuard (Cilium).
• Scratch space (for intermediate computation) uses encrypted ephemeral volumes.

Auditability

• All egress connection attempts (successful and blocked) logged with source pod, destination IP/hostname, and timestamp.
• All secret access events logged by Vault.
• All resource quota violations logged for security review (may indicate attempted resource exhaustion attack).

OWASP LLM Top 10 Coverage

9. Governance Considerations

Responsible AI

• Model isolation ensures that AI model behaviour is bounded — a model cannot access data beyond its authorised scope, which is a prerequisite for responsible deployment.
• Isolation boundaries must be documented in the AI system's risk register and reviewed as part of the AI impact assessment process.

Model Risk Management

• Isolation controls form a critical part of the model risk management framework: they limit the operational risk from a model behaving unexpectedly.
• Weight integrity verification is a model risk control — it ensures the deployed model is the validated, approved model.

Human Approval

• Changes to network policy (e.g., adding a new egress allowlist entry) require approval from Security Architecture and are subject to change management.
• Changes to seccomp profiles or AppArmor policies require security team review.

Governance Artefacts

10. Operational Considerations

Monitoring

• Process-level: CPU, memory, GPU utilisation per inference process; seccomp violation events.
• Network-level: egress connection attempts (blocked and permitted); inbound connection sources.
• Storage-level: write attempts to read-only filesystem (apparmor/seccomp violation).
• Resource-level: quota utilisation trends; OOMKill events.

SLOs

Logging

• Structured JSON from all sidecars. Mandatory: pod_name, namespace, event_type (egress_attempt, seccomp_violation, oomkill, weight_integrity_check), outcome (allowed/blocked/failed), timestamp_utc.
• Network connection logs include src_pod, dst_ip, dst_hostname, dst_port, protocol, bytes_transferred, outcome.

Incident Management

• Egress connection attempt to non-allowlisted destination → P1 security incident; immediate pod isolation; security operations investigation.
• Seccomp violation → P2; pod quarantined; security review of syscall.
• Weight integrity failure → P1; pod does not start; MLOps escalation; artefact store integrity investigation.

DR

11. Cost Considerations

Cost Drivers

Optimisations

• Use node affinity and taints to co-locate multiple isolated model workloads on the same GPU node while maintaining pod-level isolation — share the node's GPU, not the network or filesystem.
• Implement GPU time-slicing (MIG on NVIDIA A100) to allow multiple isolated pods to share a single GPU without memory isolation risk.

Indicative Cost Range

12. Trade-Off Analysis

Option Comparison

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

15. Reference Implementations

AWS

Azure

GCP

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven

18. Revision History