The file's text, extracted by GovTribe without its formatting.
Appendix A — Compliance and Isolation Requirements Empire AI RFP: Secure HPC Enclave for Regulated Research Data · Issued: 09/10/2026 This appendix forms part of the above RFP and is incorporated into it by reference. The requirements stated here are binding on any resulting award. CR-2 is pass/fail: a proposal that cannot satisfy every mandatory isolation requirement will not be evaluated further. Bidders must address each requirement in the compliance matrix required under Proposal contents in the main RFP, and must cite requirement identifiers (CR-1, CR-2, CR-3) in their response.
CR-1 Compliance framework The enclave must establish a defensible baseline against NIST 800-234 and satisfy the HIPAA Security and Privacy Rules. Bidders must map the proposal to the administrative, physical, and technical safeguards. Addressable specifications that the bidder proposes not to implement must be identified with the reasoning and the compensating control.
CR-2 Mandatory isolation requirements These are pass/fail and apply regardless of which options are recommended under the design assessments in the main RFP. Bidders must state, for each, the specific technical mechanism that enforces it.
| Requirement |
| What must be demonstrated |
| Layered tenant isolation |
| One tenant’s regulated data must be unreachable by any other tenant even if a single enforcement layer is misconfigured or compromised. The proposal must describe a minimum of four independent enforcement layers spanning scheduling, workload namespace, network, storage, and GPU allocation. |
| Per-tenant key separation |
| Each tenant’s data at rest must be encrypted under a distinct key held in external key management. Compromise of one tenant’s key must have no effect on any other tenant. |
| Default-deny east-west |
| Cross-tenant communication must be blocked by a default-deny policy applied at the platform or fabric level, not by per-workload opt-in rules. |
| Independent control plane |
| The enclave management plane, cluster manager, and administrative access path must be independent of the existing shared management domain and existing jump hosts. |
| No inherited adjacency |
| The enclave must have no routed adjacency to existing production clusters. The recommended option under Assessment B must satisfy this. |
| Validated enforcement |
| Perimeter enforcement must be validated by test at acceptance — a deny-by-default posture with an enumerated allow-list, demonstrated rather than asserted. |
| Mediated ingestion |
| Data movement from existing storage platforms into the enclave must traverse a filtered, one-directional path. Live network adjacency between storage systems is not acceptable. |
| End-to-end audit |
| Every regulated-data access path — platform API, storage, gateway, and privileged administrative session — must produce tamper-evident, continuous logs sufficient to answer "who accessed what, and when" for any dataset at any time. |
CR-3 Performance requirements: controls must minimize HPC performance degradation Empire AI expects bidders to flag, rather than silently accept, any control that would meaningfully degrade HPC performance, and to propose a compensating control instead. The following are explicit constraints.
| Data-plane inspection |
| GPU-to-GPU collective traffic and RDMA data movement must not traverse any inspection, proxying, or brokering point. Security controls apply at the boundary and the control plane, not in the job data path. |
| Host firewall on fabric |
| Host-based firewalling should not be applied to RDMA data-plane interfaces, where it adds overhead on traffic the kernel does not inspect or creates false assurance. State the compensating control — fabric-level partitioning, subnet isolation, or equivalent. |
| Encryption overhead |
| State the measured throughput and latency impact of encryption at rest, and of any in-transit encryption on the storage path, at sustained maximum load. |
| Audit and telemetry overhead |
| State the measured impact of audit logging and monitoring agents on high-IOPS storage access and on metadata operation rates. Kernel audit subsystems and per-syscall logging on compute nodes must be scoped, not applied wholesale. |
| Kernel hardening |
| Identify any hardening measure that conflicts with GPU driver, RDMA, or MPI operation, and propose a scoped alternative rather than an exception granted after deployment. |
| Session brokering |
| Any privileged-access or session-recording layer must sit on the interactive access path only. It must not mediate job launch, scheduler communication, or data movement. |
| Scheduler containment |
| Interactive sessions on compute nodes must be bound to an active job allocation and terminated on job completion, without imposing a fail-open condition or blocking legitimate access when the containment mechanism is unavailable. |
| Acceptance benchmarking |
| Performance must be measured on the delivered system both before and after security controls are applied. Bidders must propose the benchmark suite and acceptance thresholds. |