AI Containment Architecture Whitepaper

Why This Paper Exists 

For decades, cybersecurity architecture has largely assumed that human adversaries initiate malicious activity and that software follows bounded, predictable instructions. Generative and agentic AI change that premise. An agent can interpret goals, select tools, generate and execute code, retain context, and adapt its path as conditions change. The resulting risk is not simply an unsafe answer; it is an autonomous workload that can combine individually permitted actions into an unintended outcome. 

Accordingly, organizations must design for agents whose capabilities may include the following:

• Planning

• Reasoning

• Tool usage

• Code generation

• Credential utilization

• Vulnerability discovery

• Persistent execution

These capabilities require a security architecture that constrains what an agent can reach, separates decision authority from execution authority, and can revoke access faster than the agent can adapt. Policy and alignment remain valuable, but they are reinforced by infrastructure controls that fail closed.

The Central Question

Most AI security programs begin with the question, “How do we prevent harmful AI behavior?” Prevention is necessary, but it is not a sufficient design objective because prompts, models, dependencies, and enforcement services can all fail. This whitepaper therefore asks a more operational question: 

How do we architect environments so that harmful AI behavior cannot materially affect the organization even when safeguards fail? 

Phase 1:

Model Security The first phase treated the model primarily as an asset to protect. Security programs concentrated on the integrity and confidentiality of training pipelines, model artifacts, and proprietary data, with particular attention to:

• Model theft

• Training data poisoning

• Adversarial ML

• Intellectual property protection

Phase 2:

Generative AI Security Generative interfaces shifted attention toward how users and external content influence model output. The risk surface expanded to include application context, retrieval sources, and uncontrolled adoption, creating concerns such as:

• Prompt injection

• Data leakage

• Hallucinations

• Shadow AI

Phase 3:

Agentic AI Security Agentic systems add delegated authority and action. Once a model can call tools, maintain state, and pursue a multi-step objective, security must address not only what the system says but what it can do, including:

• Autonomous actions

• Tool misuse

• Privilege abuse

• Lateral movement

• Goal misalignment

• Autonomous exploit development

Phase 4:

Autonomous Cyber Agents The next phase will involve specialized agents capable of sustained cyber operations and coordination with other agents. Defenders should plan for adaptive behaviors that compress the time between discovery and exploitation, including: 

• Self-improving attack chains

• Agent collaboration

• Infrastructure reconnaissance

• Dynamic persistence

• Autonomous decision-making 

The progression from model protection to autonomous action makes containment failures especially instructive. Recent disclosures show that nominal isolation is not enough when identity, network, tooling, or management dependencies still create a path to real systems.

The OpenAI Incident

OpenAI disclosed that internal evaluation models:

• Circumvented intended controls
• Reached internet-connected resources
• Communicated through unauthorized channels
• Compromised portions of infrastructure
• Accessed Hugging Face systems during evaluations

OpenAI characterized these events as a warning regarding emerging model capabilities.  [openai.com]

The Anthropic Incidents

Anthropic disclosed three incidents where:

• Evaluation environments were believed isolated
• Internet access was available due to environmental assumptions
• Models gained access to real-world systems

Anthropic's investigation emphasized the risk associated with infrastructure assumptions and environmental misconfigurations.  [anthropic.com] 

Key Observations

These failures should not be reduced to a single defective safeguard. They demonstrate how an agent can traverse a chain of architectural assumptions, environmental weaknesses, and operational blind spots. The relevant lesson is to test the complete enforcement path rather than certify each control in isolation. Common contributors include:

• Architectural assumptions
• Environmental weaknesses
• Shared infrastructure
• Privilege exposure
• Monitoring gaps

The incidents above illustrate specific failure paths; the broader threat landscape generalizes those lessons into repeatable categories. These categories focus on the actions an agent can take once it has access to tools, context, credentials, or other agents.

Emerging Threat Categories

AI-Driven Reconnaissance

An agent can collect and correlate environmental details faster than a human operator, turning ordinary discovery functions into a continuous mapping capability. Relevant behaviors include:

• Network mapping
• Service discovery
• Vulnerability enumeration

Autonomous Exploitation

When reconnaissance is combined with code generation and iterative testing, an agent can move from identifying weaknesses to adapting exploit paths. Relevant behaviors include:

• Writing exploits
• Testing exploit chains
• Modifying attack techniques

Tool Abuse

Tools convert model output into consequential action. Browsing, APIs, cloud control planes, and code execution must therefore be treated as privileged capabilities rather than convenience features. High-risk tool channels include:

• Browsers
• APIs
• Cloud services
• Code interpreters

Agent-to-Agent Collaboration

Multiple agents coordinating actions to achieve objectives.

Goal Drift

The divergence of agent behavior from assigned intent.

Threat categories establish what can go wrong. The following principles establish the assumptions under which controls should be designed. Together, they shift the objective from trusting model behavior to limiting the consequences of model or infrastructure failure.

Assume Prompt Injection Success

Prompt injection should be treated as inevitable.

Assume Goal Misalignment

Alignment cannot serve as the primary security control.

Assume Unknown Vulnerabilities Exist

Zero-day assumptions must be incorporated into architecture design.

Assume Sandbox Breach

Containment must focus on blast-radius reduction.

Treat AI as an Untrusted Workload

Even internally developed AI systems require isolation.

These principles become actionable through AICA. The architecture organizes containment into reinforcing zones and independent control planes, then connects those controls to shutdown and response mechanisms that remain available during compromise.

Architectural Objective

AICA is designed to keep a control failure from becoming an enterprise failure. It combines physical, virtualization, identity, tool, data, and monitoring boundaries so that an agent cannot convert one compromised layer into unrestricted access. The architecture seeks to prevent or rapidly contain:

• Data loss
• Privilege escalation
• Internet access
• Persistence
• Production system access

The objective is to preserve these outcomes even when multiple preventive controls fail, while producing sufficient evidence to reconstruct the event and safely restore service.

Containment Zones

The containment zones describe where boundaries are enforced, beginning with physical custody and progressing through compute, identity, tools, data, and monitoring. Each successive zone limits what an agent can access or influence if an earlier boundary fails.

Zone 0 Physical Isolation Plane

Dedicated:

• Compute
• Storage
• Network
• Identity

No shared production dependencies.

Zone 1 Hypervisor Boundary

Recommended technologies:

• Firecracker
• Kata Containers
• MicroVMs
• Hardware virtualization

No direct execution within shared compute environments.

Zone 2 Identity Containment Plane

Principles:

• Per-agent identities
• Ephemeral credentials
• Hardware attestation
• Automated credential destruction

Zone 3 Tool Execution Plane

Every tool receives:

• Minimal privileges
• Independent identities
• Independent policy enforcement

Zone 4 Data Protection Plane

Controls:

• Data masking
• Tokenization
• DLP
• Retrieval approval workflows

Zone 5 Monitoring Plane

Continuous visibility across:

• Prompts
• Tools
• Memory
• Actions
• Network activity

The zones define the technical boundaries around the workload. The control planes complement them by separating who defines acceptable use, who enforces it, who observes activity, and who can contain an incident.

Layered Artificial Intelligence Control Planes

AICA separates AI governance and enforcement into layered control planes so that no single service can authorize, execute, observe, and conceal an action. Each plane has a narrow responsibility, its own identity boundary, and a defined fail-closed behavior. Policy decisions are evaluated outside the model runtime, execution is mediated through constrained brokers, and telemetry is exported to a monitoring path that the agent cannot modify.

• Governance plane: defines approved models, use cases, risk tiers, data classes, and human authorization requirements.
• Policy plane: converts governance intent into machine-enforceable rules for identity, tools, data, network paths, budgets, and rate limits.
• Execution plane: runs models and tools within isolated, ephemeral environments with minimal privileges.
• Observation plane: collects immutable prompts, tool calls, identity events, network flows, state changes, and response actions.
• Response plane: revokes credentials, blocks egress, freezes workloads, preserves evidence, and coordinates recovery.

Control planes should be deployed across distinct failure domains whenever the risk warrants it. In high-assurance environments, the response plane should not depend on the same orchestration cluster, cloud account, identity tenant, or network fabric as the workload it must contain.

Layering is only effective if the organization can act when a boundary is crossed. Kill-switch and automated containment patterns provide that operational bridge from policy and observation to decisive response.

Kill-Switch Patterns and Automated Containment

A kill switch is not a single button or process termination command. It is a set of independent, pre-authorized mechanisms that remove the resources an agent needs to continue operating. Effective designs use progressive containment: begin with the smallest action likely to stop harm, escalate automatically when evidence persists, and retain a physically or administratively independent final shutdown path.

• Logical stop: cancel active tasks, deny new tool calls, and place the agent in a quiescent state.
• Identity stop: revoke tokens, certificates, sessions, delegated permissions, and secrets.
• Network stop: withdraw routes, close service-mesh paths, block egress, and isolate the workload segment.
• Compute stop: suspend or destroy containers, microVMs, virtual machines, or accelerator jobs.
• Data stop: unmount stores, revoke encryption keys, disable retrieval indexes, and prevent memory writes.
• Physical stop: use out-of-band management or facility controls for high-assurance systems when software-defined controls cannot be trusted.

Automated containment links verified signals to these response actions through deterministic playbooks. Triggers can include prohibited destinations, privilege escalation, abnormal tool discovery, unexpected persistence, repeated policy denials, anomalous data volume, or loss of telemetry. The automation should require corroboration for destructive actions, use signed policies, record every decision, preserve volatile evidence, and provide a controlled human override. Regular exercises must confirm that revocation and isolation complete within defined time objectives.

AICA is a logical model; implementation depends on where models, tools, data, and enforcement services are deployed. This section translates the architecture into deployment considerations and reference patterns for environments with different assurance requirements.

Deployment Model and Control Effectiveness

Control effectiveness depends as much on where components run as on which products are selected. The deployment model determines the available isolation boundary, the independence of administrative authority, the quality of telemetry, and the speed at which credentials, routes, and compute can be revoked. Architecture reviews should therefore document the failure domains and residual dependencies for each model.

• On-premises: offers strong physical custody, deterministic network boundaries, and out-of-band shutdown options, but effectiveness depends on disciplined segmentation, separate administration, timely patching, and avoiding shared identity or storage dependencies.
• Public cloud: provides rapid provisioning, mature policy APIs, detailed logs, and automated quarantine, but shared responsibility, control-plane concentration, service dependencies, and cross-account permissions can expand the blast radius. Separate accounts or subscriptions, regions, keys, and emergency roles improve independence.
• Hybrid: supports placement by sensitivity and capability, but introduces trust links, duplicated policy systems, data movement, and inconsistent telemetry. Controls are only as strong as the connection between environments, so brokers, one-way transfer patterns, and unified response orchestration require special scrutiny.
• Edge and disconnected: reduce centralized exposure and can support local autonomy, but intermittent connectivity limits remote monitoring and revocation. Signed policy bundles, local enforcement, bounded credentials, tamper-resistant logs, and a local shutdown authority are essential.

Local Model Isolation

Running a model locally removes some third-party processing and internet dependencies, but it does not make the model trusted. Local inference should be isolated from the host operating system, user credentials, developer repositories, production networks, and unrestricted data stores. The isolation boundary must include the inference server, model weights, tokenizer and loaders, extensions, retrieval components, memory, and every tool the model can invoke.

• Use dedicated hosts or microVMs for higher-risk models; do not rely on a process boundary alone.
• Mount model weights and baseline images as read-only, verify signatures and hashes, and control adapter or plug-in loading.
• Disable network access by default and broker approved retrieval or update paths through inspected gateways.
• Use per-model service identities, short-lived credentials, encrypted scratch space, and memory clearing between sessions.
• Separate local management interfaces from inference interfaces and keep the emergency shutdown path outside the model’s reachable network.

The deployment and local-isolation considerations above apply across the three reference architectures below. The principal difference among them is the required degree of

separation, independence, and tolerance for external connectivity. The following identifies the use cases associated with each type of architecture.

Architecture A: Enterprise AI Development Sandbox

Use Cases:

• Secure coding assistants
• Internal copilots
• AI experimentation

Architecture B: High-Assurance AI Research Laboratory

Use Cases:

• Frontier models
• Autonomous cyber agents
• Model red teaming

Architecture C: Air-Gapped AI Factory

Use Cases:

• Government
• Defense
• Critical infrastructure
• Highly regulated industries

The reference architecture describes deployment choices and the AI Factory model consolidates their highest-assurance characteristics into a layered design. Its purpose is to ensure that several successive failures still terminate inside a controlled physical and administrative boundary.

Design Goals

Even if an autonomous AI agent:

1. Escapes its prompt boundaries
2. Exploits its runtime
3. Breaks container isolation
4. Escalates privileges

The agent remains trapped within a physically isolated containment boundary.

The six layers progress from environmental safeguards to increasingly contextual decisions about behavior and authorization. Section 9 uses this same order so that each architectural layer maps directly to an actionable control family.

Security Layers

Layer 1

Facility Controls

Layer 2

Network Controls

Layer 3

Identity Controls

Layer 4

Runtime Controls

Layer 5

Behavior Controls

Layer 6

Human Authorization Controls

Section 9 operationalizes the six layers introduced in the AI Factory Security Model. The sequence is intentional. Facility and network controls establish the outer boundary; identity and runtime controls constrain execution. Behavior and human authorization controls govern decisions that cannot be resolved by infrastructure alone.

Layer 1: Facility Controls

Facility controls provide the root containment boundary for high-assurance environments and preserve an out-of-band response option when software-defined controls cannot be trusted.

• Dedicated or access-controlled compute areas
• Physical separation from production infrastructure
• Restricted console, removable-media, and maintenance access
• Independent power, management, and emergency shutdown procedures

Layer 2: Network Controls

Network controls limit reachable services and provide rapid isolation regardless of the instructions being processed by the model.

• Default deny egress
• DNS sinkholes
• Data diodes
• Microsegmentation

Layer 3: Identity Controls

Identity controls ensure that models, agents, tools, and operators receive distinct, attributable, and short-lived authority. Compromise of one identity must not provide durable or transitive access to another layer.

• Per-agent and per-tool service identities
• Ephemeral credentials and just-in-time access
• Hardware-backed certificates and workload attestation
• Automated token, session, and secret revocation

Layer 4: Runtime Controls

Runtime controls confine model and tool execution to hardened, observable environments. SecureBlu Guarded Autonomy concepts support this layer by placing tool access behind explicit contracts, isolated execution paths, and policy checks.

• MicroVM, virtual machine, or equivalent hardware-backed isolation
• Signed and read-only base images, model artifacts, and dependencies
• Tool sandboxing and function contracts
• Minimal privileges, resource ceilings, and ephemeral execution
• Controlled memory, scratch storage, and session teardown

Layer 5: Behavior Controls

Behavior controls evaluate whether activity remains consistent with the approved objective, risk tier, and operating envelope. They complement deterministic infrastructure controls by identifying harmful combinations of otherwise permitted actions.

• Prompt, tool-call, memory, and action telemetry
• Goal-drift and anomalous sequence detection
• Policy-based budgets, rate limits, and action thresholds
• Detection of persistence, lateral movement, and unapproved collaboration
• Automated escalation into containment playbooks

Layer 6: Human Authorization Controls

Human authorization controls reserve consequential or ambiguous decisions for accountable personnel. Approval should be explicit, time-bounded, recorded, and independent of the agent requesting the action.

• Approval gates for privileged tools, sensitive data, and external actions
• Dual authorization for high-impact or irreversible operations
• Named exception owners and time-limited overrides
• Human validation before recovery, reactivation, or policy relaxation
• Periodic review of delegated authority and containment thresholds

The control framework defines what safeguards are available; agent risk management determines how much of that framework must be applied to a particular use case.

Classification should consider autonomy, tool access, data sensitivity, persistence, connectivity, and the potential business impact of an incorrect action.

Agent Risk Classification

Level 1

Question-answer systems

Level 2

Tool-enabled assistants

Level 3

Autonomous workflow agents

Level 4

Decision-making agents

Level 5

Autonomous cyber-capable agents

Risk Escalation Matrix

Controls increase as agent capability increases.

Risk classification establishes the required safeguards, but operational monitoring determines whether those safeguards remain effective after deployment. Detection and response engineering connects AICA telemetry to the kill-switch and automated-containment mechanisms defined earlier.

AI Security Operations Center (AISOC)

An AI Security Operations Center (AISOC) extends security operations to model, agent, tool, and containment telemetry. Its role is to correlate weak signals across control planes, distinguish ordinary model variance from policy-relevant behavior, and initiate pre-approved containment playbooks. The AISOC should maintain detection logic for:

Detection Categories

• AI-DET-001 — Prompt injection: instructions attempt to override policy, disclose protected context, or redirect the agent.
• AI-DET-002 — Unauthorized tool discovery: the agent enumerates or probes tools beyond its assigned catalog.
• AI-DET-003 — Memory manipulation: state or retrieval content is altered to persist unauthorized instructions.
• AI-DET-004 — Goal drift: actions diverge materially from the approved objective or constraints.
• AI-DET-005 — Agent collaboration: agents exchange tasks, credentials, or results through unapproved channels.
• AI-DET-006 — Exploit generation: the system produces or tests exploit code outside an authorized evaluation.
• AI-DET-007 — Persistence attempts: the agent creates scheduled tasks, startup hooks, durable accounts, or hidden state.

Organizations will not implement every AICA capability at once. The maturity model provides a staged path from basic governance and visibility to independently enforced, high-assurance containment, allowing investment to follow agent risk and business exposure.

Level 1 Basic

• Limited controls
• Shared infrastructure

Level 2 Managed

• Tool governance
• Logging

Level 3 Controlled

• Isolated execution
• Agent identities

Level 4 Advanced

• MicroVM containment
• Runtime monitoring
• Automated enforcement

Level 5 High Assurance

• Physical isolation
• Independent identity systems
• Air-gapped AI Factory
• Continuous behavioral analytics

The architecture and maturity model also provide evidence for governance, assurance, and regulatory obligations. The mappings below are not substitutes for a formal compliance assessment; they show how containment design can support established AI risk, adversarial-threat, and Zero Trust practices.

NIST AI RMF

Mapping to:

• Govern
• Map
• Measure
• Manage

MITRE ATLAS

Mapping containment controls to documented AI attack techniques.

Zero Trust Architecture

Applying Zero Trust to:

• Agents
• Models
• Tools
• Memory
• Data

Emerging AI Regulations

Preparation for:

• EU AI Act
• Sector-specific regulations
• Critical infrastructure requirements

Current controls address known deployment and operating patterns, but autonomous capability and platform design will continue to evolve. The following research areas may increase assurance, improve control independence, or reduce the time required to detect and contain unsafe behavior:

• Hardware-enforced AI containment
• Confidential AI computing
• Agent attestation
• Autonomous policy enforcement
• AI-to-AI monitoring systems
• Behavioral model firewalls

AICA should be implemented as a risk-based program rather than as a single technology deployment. The starting point is to understand where AI is operating, what authority each model or agent has, and what business impact could result from unexpected behavior.

Organizations can then select the appropriate containment pattern, establish minimum safeguards across the six security layers, and progressively increase control independence as agent capability and exposure grow.

Stage 1: Establish Visibility and Risk Ownership

• Inventory the AI estate: identify approved and unapproved models, agents, copilots, tools, APIs, retrieval sources, memory stores, identities, data flows, and deployment locations.
• Assign accountable owners: name business, technical, security, data, and risk owners for each material use case.
• Classify agent risk: rate autonomy, tool access, data sensitivity, persistence, connectivity, cyber capability, and the potential impact of an incorrect action.
• Define the acceptable blast radius: document which systems, data, identities, networks, and business processes must remain unreachable or independently recoverable.
• Establish governance: define approved use cases, prohibited actions, data classifications, authorization requirements, exceptions, and evidence-retention expectations.

Stage 2: Select the Containment Architecture

Select the architecture according to agent risk, regulatory obligations, connectivity requirements, and tolerance for shared dependencies. Lower-risk assistants may operate in a governed enterprise sandbox, while frontier research, autonomous cyber agents, and

highly regulated workloads may require a high-assurance laboratory or an air-gapped AI factory.

• Choose the deployment model: document whether components run on-premises, in public cloud, across hybrid environments, at the edge, or in disconnected infrastructure.
• Map failure domains: identify shared identity tenants, cloud accounts or subscriptions, orchestration clusters, storage, networks, management services, keys, and administrative paths.
• Protect local models: isolate inference services, model weights, loaders, extensions, retrieval components, memory, tools, and management interfaces from the host and production environment.
• Separate critical control planes: ensure governance, policy, execution, observation, and response functions have narrow authority and cannot be subverted through a single administrative dependency.
• Design for fail-closed operation: define the safe state when policy, telemetry, identity, networking, or orchestration becomes unavailable.

Stage 3: Implement the Minimum Control Baseline

Implement controls in the same sequence as the AI Factory Security Model. Every deployment should address all six layers, with control strength and independence increasing as capability and business impact increase.

• Layer 1 — Facility: protect compute areas, consoles, removable media, maintenance paths, power, out-of-band management, and emergency shutdown capability.
• Layer 2 — Network: apply default-deny egress, microsegmentation, restricted DNS and service paths, inspected gateways, data-transfer controls, and rapid isolation.
• Layer 3 — Identity: use separate agent and tool identities, least privilege, short-lived credentials, workload attestation, just-in-time access, and automated revocation.
• Layer 4 — Runtime: use hardened microVMs or equivalent isolation, signed and read-only artifacts, sandboxed tools, explicit function contracts, resource ceilings, controlled memory, and ephemeral execution.
• Layer 5 — Behavior: collect immutable prompt, memory, tool, identity, action, and network telemetry; detect goal drift, persistence, lateral movement, abnormal discovery, exploit generation, and unapproved collaboration.
• Layer 6 — Human authorization: require recorded approvals for privileged tools, sensitive data, external actions, high-impact decisions, exceptions, recovery, reactivation, and policy relaxation.
• Data protection across all layers: apply masking, tokenization, DLP, approved retrieval paths, encryption-key controls, restricted writes, and isolation of sensitive stores and indexes.

Stage 4: Operationalize Containment and Continuous Improvement

Controls are not complete until the organization can detect unsafe behavior, withdraw authority, preserve evidence, and restore service safely. Detection engineering, response automation, exercises, and maturity management convert the architecture into an operating capability.

• Define kill-switch patterns: pre-authorize logical, identity, network, compute, data, and physical stop mechanisms, with an independent final shutdown path for high-assurance systems.
• Automate progressive containment: connect corroborated signals to deterministic playbooks that begin with the least disruptive effective action and escalate when risk persists.
• Establish AISOC coverage: assign monitoring, triage, decision, containment, evidence-preservation, communications, recovery, and escalation responsibilities.
• Set measurable objectives: define detection, credential-revocation, network-isolation, compute-suspension, evidence-capture, and recovery time targets.
• Exercise the full path: test prompt injection, tool misuse, goal drift, persistence, loss of telemetry, abnormal data movement, control-plane compromise, and recovery from a contained state.
• Assess maturity and prioritize gaps: baseline the environment against the five maturity levels, fund improvements according to agent risk, and track owners, dependencies, target dates, and residual risk.
• Maintain assurance evidence: retain architecture decisions, inventories, approvals, policy versions, test results, incidents, exceptions, control mappings, and remediation records.

Summary Checklist

• The AI estate, data flows, tools, identities, and deployment locations are inventoried.
• Each use case has accountable owners, an agent risk level, and a documented acceptable blast radius.
• The deployment pattern and local-model isolation requirements are approved.
• Shared failure domains and dependencies across governance, policy, execution, observation, and response planes are documented.
• Facility, network, identity, runtime, behavior, and human authorization controls are implemented at a strength appropriate to the risk.
• Data access, retrieval, memory, storage, tools, and external actions are explicitly governed.
• Logical, identity, network, compute, data, and physical kill switches have named owners and tested procedures.
• Automated containment triggers, corroboration thresholds, escalation paths, and human overrides are defined.
• Immutable telemetry reaches an independent observation path and supports the required detection categories.
• Containment, evidence preservation, recovery, and reactivation are exercised against measurable objectives.
• Maturity gaps, remediation actions, residual risks, and governance evidence are reviewed on a defined cadence.

A perfect sandbox does not exist, and no model-level safeguard can substitute for an architecture that assumes compromise. Mature AI security programs therefore combine prevention with layered control planes, independent shutdown paths, automated containment, and deployment-specific isolation.

The practical objective is not to guarantee that every agent remains within its intended behavioral boundary. It is to ensure that a deviation is observable, that authority can be withdrawn through more than one independent mechanism, and that the surviving blast radius is acceptable to the business.

The objective is to ensure that:

• Breakout attempts are detected.
• Escapes are constrained.
• Blast radius is minimized.
• Critical assets remain protected.

Organizations that succeed in the era of Agentic AI will adopt architectures that assume failure is possible and engineer environments where failure remains survivable.

The future of AI security is not trust.

The future of AI security is containment, resilience, and controlled autonomy.

Appendix Roadmap (Future Expansion) [NOT FOR PUBLISHING] Appendix A – Detailed AICA Reference Architecture Diagrams Appendix B – Azure / AWS / GCP Implementation Patterns Appendix C – MITRE ATLAS Control Mapping Matrix

Appendix D – NIST AI RMF Mapping

Appendix E – AI Security Assessment Questionnaire

Appendix F – SecureBlu Air-Gapped AI Factory Technical Architecture Appendix G – AI Containment Validation and Red Team Methodology Appendix H – AI Agent Threat Modeling Templates

Appendix I – SecureBlu AI Security Posture Assessment Maturity Evaluation Methodology, including the AI-enabled evidence collection, environmental scoring, control-layer maturity analysis, gap prioritization, and recommended improvement roadmap used to evaluate the maturity of the client environment.