RFP Secure HPC Enclave MAIN.docx

Empire AI RFP: Secure HPC Enclave for Regulated Research Data Issued: 09/10/2026 · Questions due: 09/18/2026 · Responses due: 09/28/2026 · Contacts: Abadali Sheikh (asheikh@empireai.edu), Cesar Arias (carias@empireai.edu), Kiran Keshav (kkeshav@empireai.edu), Loreley Giraudon (lgiraudon@empireai.edu ) Overview Empire AI invites proposals for the design, supply, installation, and integration of an isolated high-performance computing enclave for regulated and sensitive research data, including protected health information (PHI) subject to HIPAA Compliance. The enclave will host multiple member institutions as independent tenants on shared physical infrastructure.

Several architectural decisions, notably storage sourcing and the network perimeter, are deliberately left open, and bidders are expected to assess the options described in this document and recommend an approach.

Two objectives govern the design and carry equal weight. First, the enclave must satisfy the HIPAA Security and Privacy Rules and establish a defensible NIST 800-234 baseline, with isolation enforced by technical controls rather than by solely administrative policy. Second, it must remain a high-performance computing environment: security controls that materially degrade tightly coupled GPU training, RDMA data movement, or high-IOPS storage access are not acceptable, and bidders are expected to say so where a conventional control would do that.

Target readiness for first regulated workload is [January 4, 2027].

Structure of this RFP The requirements against which proposals will be evaluated are set out in two appendices issued alongside this document. Both are incorporated into this RFP by reference and are binding on any resulting award. Bidders must read all three documents together.

Requirements are cited throughout this document by their identifier — for example CR-2 or TR-3. Where the documents conflict, the mandatory isolation requirements in Appendix A (CR-2) prevail, followed by this document, followed by Appendix B.

Bidders must submit a completed compliance matrix covering every requirement in Appendix A and Appendix B, as set out under Proposal contents below.

Existing environment: context for design assessment The following summarizes the current environment only to the extent bidders need it to assess the open design questions. Detailed topology, addressing, and configuration can be released under NDA to shortlisted bidders.

Scope Requirement identifiers in parentheses indicate where the governing requirement is stated.

1. Design assessments and recommendation on the open questions in this document.

1. Power Requirement: final design must adhere to ~100kW max power. (TR-6)

1. GPU backend interconnect, frontend & storage Ethernet, and OOB management network. (TR-1)

1. Multi-tenant storage platform, per the option recommended under Design Assessment A. (TR-3)

1. Network perimeter and security boundary, per Design Assessment B. (TR-2)

1. Workload orchestration, scheduling, and GPU allocation, per Design Assessment C & D. (TR-4)

1. IAM: Identity federation, tenant onboarding automation, and the audit logging pipeline. (TR-5)

1. Key and secrets management supporting per-tenant key separation. (TR-2, CR-2)

1. Racks, PDUs, cabling, professional services, acceptance and performance testing, documentation, and training. (TR-6, CR-3)

1. Preferably Infrastructure-as-code baseline and delivery pipeline covering the full enclave. (TR-7) Design assessments requested These are the open questions. Each response must contain a reasoned recommendation, the alternatives considered, and the compliance and performance consequences of each. Every recommendation must be assessed against the requirements in Appendix A and Appendix B, and any recommendation that cannot satisfy a mandatory isolation requirement (CR-2) must be identified as such.

Assessment A: Storage sourcing - reuse or procure VAST has confirmed that controller and capacity nodes can be pulled from the existing production deployment and reallocated to the enclave. Bidders must assess whether the enclave storage platform should be built from reallocated hardware or newly procured hardware and must price each option they consider viable and in line with the security and compliance requirements in Appendix A and the storage requirements in Appendix B (TR-3).

Assessment B: Network perimeter: new appliances, existing pair, or hybrid Empire AI has not determined whether the enclave requires a dedicated firewall pair. Bidders must assess the options below against the isolation and audit requirements in Appendix A (CR-2) and the perimeter requirements in Appendix B (TR-2), and recommend one. Whichever option is recommended, the proposal must state how firewall enforcement will be validated by test at acceptance.

Assessment C: Workload orchestration model Empire AI currently utilizes SLURM as the workload manager. A container platform, such as Run:ai, offers stronger namespace, RBAC, and network-policy isolation primitives, but adds a layer between tightly coupled MPI and RDMA workloads and the hardware. Bidders must assess whether the enclave should be orchestrated by a container platform or an HPC scheduler with equivalent isolation controls and must address:

1. Measured performance impact on tightly coupled multi-node GPU training and on collective communication, relative to bare-metal scheduling. Performance constraints and acceptance thresholds are stated in Appendix A (CR-3).

1. How tenant isolation, per-tenant audit logging, and default-deny east-west enforcement are achieved under the recommended model, consistent with Appendix A (CR-2) and Appendix B (TR-4, TR-5).

Assessment D: GPU isolation The enclave will host multiple institutions on across ≥8 HGX nodes. Bidders must recommend a default GPU allocation model for regulated workloads (i.e. dedicated node, dedicated GPUs within a shared node, or hardware partitioning) and must quantify the consequences rather than assert the outcome. A model that guarantees isolation by stranding capacity must be identified as such. The recommendation must satisfy the layered isolation requirement in Appendix A (CR-2) and the GPU allocation requirement in Appendix B (TR-4). The response must identify the specific mechanism that closes each of the following, and how it is validated by test:

1. Residual data in GPU memory between allocations — whether memory is scrubbed, by what mechanism (driver behavior, platform policy, or operator action), and whether that mechanism is enabled by default or must be configured.

1. Peer access across the intra-node GPU interconnect where two tenants share a host — whether interconnect partitioning is configured and enforced, or whether "dedicated GPUs" relies on scheduler assignment alone.

1. Telemetry and performance-counter visibility — whether one tenant can observe another’s utilization pattern through GPU monitoring interfaces exposed on a shared host.

1. The shared host attack surface under any model that co-locates tenants on one node: kernel, GPU driver instance, host memory bandwidth, PCIe topology, and BMC.

Relationship to Assessment C. GPU allocation is enforced differently under a container platform than under an HPC scheduler, and hardware partitioning support differs materially between them. The recommendation here must be consistent with the orchestration model recommended under Assessment C, and the bidder must state how the two fit together.

Implementation and support The selected vendor will be expected to:

1. Deliver the design assessments as a documented decision record before hardware is ordered.

1. Author and test the infrastructure-as-code baseline. (TR-7)

1. Deliver, rack, cable, and configure all proposed hardware, including any reallocated assets. (TR-1, TR-6)

1. Configure the fabrics, perimeter policy, and out-of-band management plane, and validate enforcement by test. (TR-1, TR-2, CR-2)

1. Deploy the storage platform with per-tenant namespaces and key separation, and — where reallocation is involved — execute the removal from production with a defined outage window and rollback plan. (TR-3)

1. Deploy the orchestration platform, GPU management, and tenant scheduling. (TR-4)

1. Build identity federation, automated tenant onboarding, and integrate at least one tenant institution for reference. (TR-5)

1. Stand up the audit pipeline and demonstrate end-to-end coverage of every regulated-data access path. (TR-5, CR-2)

1. Conduct isolation validation testing, including deliberate attempts to cross tenant boundaries at each enforcement layer. (CR-2)

1. Conduct performance benchmarking before and after security controls, against the thresholds in Appendix A (CR-3).

1. Deliver the NIST 800-234 and HIPAA control mapping as an as-built artifact, updated to reflect what was deployed. (CR-1)

1. Provide as-built documentation, runbooks, and operational training for Empire AI staff.

1. Supply continuous go-live support for 1 year after handover and a technical support option for 3 years and identify any warranty or on-site support not included in the base proposal. To be priced separately.

Optional items — price separately These must be priced as discrete line items and must not be bundled into the base proposal. Empire AI may award any, all, or none.

Proposal contents - Responses should include:

1. Reasoned recommendations for Design Assessments A through D, with alternatives considered and the compliance and performance consequences of each.

1. A technical description and architecture diagram of the recommended design.

1. A completed compliance matrix covering every requirement in Appendix A and Appendix B, stating for each requirement whether the proposal complies, complies with exception, or does not comply, with a cross-reference to the section of the response that addresses it. Any exception must state the reason and the compensating control.

1. A point-by-point response to each mandatory isolation requirement in Appendix A (CR-2), naming the enforcing mechanism.

1. A point-by-point response to each performance constraint in Appendix A (CR-3), with measured or referenced figures rather than assurances.

1. A control mapping to NIST 800-234 and to the HIPAA Security Rule safeguards, identifying any addressable specification not implemented and its compensating control. (CR-1)

1. A description of how the design supports Privacy Rule obligations, including minimum necessary, accounting of disclosures, and egress control. (CR-1)

1. Storage capacity and performance figures at each priced tier, measured with encryption and isolation enabled. (TR-3)

1. Rack elevation, power, cooling, floor loading, and network requirements for the complete build. (TR-6)

1. Failure-domain analysis identifying single points of failure and their mitigation.

1. The infrastructure-as-code toolchain, repository structure, and handover model. (TR-7)

1. The tenant onboarding workflow end to end, from institution agreement to first researcher job submission. (TR-5)

1. An acceptance test plan covering isolation validation, enforcement validation, and performance benchmarking. (CR-2, CR-3)

1. An implementation plan and schedule against the readiness target, with critical path, lead times, and schedule risks identified.

1. A complete itemized price covering hardware, software, licensing, installation, professional services, support, and recurring costs, with each design-assessment option priced separately.

1. A statement of whether the bidder will execute a Business Associate Agreement (BAA), and for which components and personnel, together with the bidder’s subcontractor flow-down approach: any subcontractor that will create, receive, maintain, or transmit ePHI on the bidder’s behalf must be identified, with confirmation that the bidder will obtain a business associate agreement from that subcontractor meeting the same requirements.

1. 1, 3, & 5-year support terms with response and resolution targets.

Evaluation criteria - Proposals will be evaluated on:

1. Quality of reasoning in the design assessments, including willingness to recommend against options that would be more profitable to the bidder.

1. Compliance with the mandatory isolation requirements in Appendix A (CR-2) and the strength of the evidence offered for each.

1. Credibility of the performance figures and honesty about the cost of security controls, assessed against Appendix A (CR-3).

1. Completeness of the NIST 800-234 and HIPAA control mapping, and of the audit evidence model. (CR-1)

1. Completeness and accuracy of the compliance matrix against Appendix A and Appendix B.

1. Quality of the infrastructure-as-code deliverable and the realism of the handover model. (TR-7)

1. Deliverability against the readiness target, including honesty about lead times and schedule risk.

1. Total cost of ownership over five years.

1. Operational simplicity and the degree to which Empire AI staff can operate the platform independently after handover.

1. Quality of installation, documentation, training, maintenance, and support services.

1. Demonstrated experience with regulated data in research computing environments specifically.

Submission and terms

1. Responses are due by 09/28/2026 and should be submitted to Abadali Sheikh (asheikh@empireai.edu), Cesar Arias (carias@empireai.edu), Kiran Keshav (kkeshav@empireai.edu), and Loreley Giraudon (lgiraudon@empireai.edu)

1. Questions must be submitted in writing by 09/18/2026.

1. This RFP comprises this document, Appendix A (Compliance and Isolation Requirements), and Appendix B (Technical Requirements). All three are issued together and read together.

1. Environment details required for the design assessments will be released to bidders under NDA.

1. Pricing must remain valid for [90] days from submission.

1. Empire AI reserves the right to award in part, to award to multiple vendors, to request clarification or revised pricing, or to make no award.

1. Empire AI is not liable for any cost incurred by bidders in preparing a response, and submission of a response creates no obligation on the part of Empire AI.