Security Architecture Overview

This section provides a conceptual overview of the SL5 security architecture organized across five security streams: network, physical, machine, personnel, and supply chain.

Network Security

The SL5 Network is air-gapped from external networks and supports model development, training, and internal deployment operations. The SL5 Network may span multiple geographically distributed facilities, including remote office locations (such as in San Francisco) and other datacenters connected via encrypted inter-facility links. All facilities must comply with all SL5 requirements including applicable ICD 705 guidance for physical security [6], [7], [22], [23].

Fig. 1. SL5 Network Architecture showing the relationship between Weight Enclaves, the broader SL5 Network, and inter-facility connections.

Weight Enclaves provide additional isolation within the SL5 Network for systems with direct access to covered models. This separation enables stricter controls on the most sensitive assets—covered model weights—while supporting R&D operations and remote work locations in the broader SL5 Network. Systems requiring direct weight access (training, inference, fine-tuning, mechanistic interpretability) operate within Weight Enclaves under strict allow-by-exception code execution; all code must complete testing and signing before deployment. Research experiments conducted by AI models are executed in confined environments in the broader SL5 Network (see Figure 1), outside the Weight Enclaves. Each Weight Enclave resides in a single physical facility. Transfers exceeding the Weight Enclave outbound bandwidth limit must occur via encrypted physical media. This has significant implications for geographically distributed training: such training may prove infeasible under this constraint, or may require substantially different approaches than current practice. One speculative example is distributed RL training with daily gradient synchronization via physical media transfer. Section 1.3 highlights this as a key open question.

Key interventions:

• Air-gapped SL5 Network with no external network connections
• Weight Enclaves isolated within SL5 Network, containing only minimal necessary software with strict allow-by-exception code execution
• Single-facility restriction for Weight Enclaves; inter-enclave transfers exceeding bandwidth limits require encrypted physical media
• Dual inline network encryptors from different suppliers (per NSA “Rule of Two”) for inter-facility SL5 Network connections [14]
• FIPS 140-3 Level 3 minimum validation for network encryptors [11]
• Physical bandwidth limitation on Weight Enclave boundaries preventing weight exfiltration even if other security measures fail

Physical Security

SL5 facilities are constructed to an applicable subset of ICD 705 directive providing physical access control, emanations protection, and transmission security [6], [7], [22], [23]. The particular subset is determined by whether the threat model being prioritised is theft of model weights & cryptographic keys vs. also sabotage, autonomy threats and algorithmic IP theft. SL5-level security may generally warrant an updated version of ICD 705 plus potential additional AI-datacenter and AI-SCIF specific overlays. Following SCIF terminology, Red Zones are areas where SL5-protected information may be processed or stored; Black Zones are areas with no network path to SL5-protected information. All SL5 Network hardware and access locations reside within Red Zones.

Key interventions:

• ICD 705 facility construction with applicable TEMPEST countermeasures (RF shielding, power conditioning) [6], [7], [9], [23]
• Access control vestibules (mantraps) at all entry points to prevent tailgating
• Protected Distribution Systems (PDS) per CNSSI 7003 for nearby connections [8]
• Shielded rack enclosures meeting NSA 94-106 specifications for Weight Enclave systems processing covered models [10]

Machine Security

AI accelerators require hardware security features that enable protection of covered models even when the host system is compromised, when data traversing physical interconnects is intercepted, or when the hardware itself is physically attacked. These capabilities enable end-to-end encrypted data paths where data arrives encrypted from origin, is decrypted only within the accelerator, and is re-encrypted before any host-accessible export.

Fig. 2. AI Accelerator Security Architecture showing the accelerator as an independent security domain with device-controlled memory isolation and end-to-end encrypted data paths.

Key interventions:

• Integrated root-of-trust with hardware-provisioned identity, secure key storage, and attestation capability
• Device-controlled memory isolation allowing accelerators to deny host access independent of host software
• Interconnect encryption protecting data transmitted between accelerators during distributed operation
• Tamper protection for compute cores and accelerator memory where data exists unencrypted during computation
• Execution integrity verification ensuring only authorized code executes on accelerators

Current commercial AI accelerators vary in confidential computing capabilities, and gaps remain relative to SL5 requirements. For example, NVIDIA Blackwell's memory isolation and code verification depend on a CPU TEE rather than being accelerator-controlled, and commercial threat models exclude physical attacks [16], [24].

Current implementations also lack mechanisms preventing composition attacks, where individually-authorized operations are combined to exfiltrate data. Two approaches show promise. The Ascend-CC research architecture (2024) demonstrates confidential computing that excludes the CPU from the trusted computing base, using device-controlled memory isolation and firmware-level task sequence attestation [17]. Alternatively, restricting workloads to fused kernels verified to not exfiltrate data individually or through composition avoids the need for vendor engagement but may increase implementation complexity for organizations.

Organizations must engage accelerator vendors during architecture phases—hardware security features require years to develop, and influence over roadmaps cannot be gained retroactively.

Personnel Security

A five-tier sensitivity level framework (SenL-1 through SenL-5) addresses insider threat through graduated vetting, monitoring, and access controls. This represents the strongest feasible private-sector approximation of government clearance programs. Detailed tier definitions, vetting procedures, and operational safeguards are specified in a separate SenL Framework Document [26].

Key interventions:

• Five sensitivity levels based on access to covered models and critical infrastructure [26]
• Vetting depth scales from baseline checks (SenL-1) through verified subject and reference interviews (SenL-4/5) [26]
• Monitoring intensity scales from periodic checks to intensive monitoring of compartmented system interactions [26]
• Access obligations scale from standard NDA to custodian-specific protocols and post-employment restrictions [26]
• Dual authorization for critical operations involving covered models [26]
• SenL-5 clearance required for unescorted Red Zone access, with two-person integrity [26]

Organizations may need to pursue government involvement (through classified contract pathways, information sharing arrangements, or new statutory authority) to achieve personnel security sufficient for the stated threat model. Section 1.3 highlights this as a key open question.

Fig. 3. Personnel Security Program showing the organizational investment required for SenL-5 capability: vetting pipeline, continuous operations, legal navigation, ICD 705 facilities, and potential government pathways [26].

Supply Chain Security

Hardware supply chain integrity requirements address risks from compromised components. Hardware supply chain requirements follow NIST SP 800-161 Rev 1 guidance directly [3].

Data entering the SL5 environment from external sources must be screened for adversarial content—poisoning attacks, jailbreak attempts, and adversarial examples that could compromise AI systems or sabotage research. External data is a critical input to AI system development, analogous to hardware components; both can carry embedded attacks from upstream sources, and correlated attacks targeting both software and training data could amplify impact.

Robust adversarial content detection remains an open research problem; best-available defensive measures are insufficient against sophisticated adversaries [18], [19]. This standard mandates staging isolation and investment in detection research, understanding that breakthroughs in adversarial robustness are necessary to fully address this threat. Section 1.3 highlights this as a key open question.

Key areas:

• Adversarial content screening for all external data, with staging isolation until data completes automated detection and human review
• Supplier governance: criticality-based inventory, continuous assessment against security baseline, qualified bidders/manufacturers lists, supply base diversity where feasible, requirements flow-down to sub-tier contractors
• Component integrity assurance: comprehensive testing including counterfeit detection, physical inspection, tamper detection, developer screening

Fig. 4. Adversarial Robustness threat model showing how external data can carry attacks that activate at training time or test time, the mitigations required (staging isolation, automated detection, human review), and the consequence if defenses fail.