Security

​

Shared responsibility

For every infrastructure layer, Hyperbolic is your accountable party and single point of contact, whether we operate the layer directly or through the datacenter partner under our direction. If you reprovision nodes with your own images, in-OS controls become yours after handover; everything below the OS stays with us.

​

Tenant isolation

Private Cloud deployments are isolated at five layers:

1. Allocation — each physical host is assigned to exactly one customer at a time. No co-tenancy on a node.
2. Access — only your designated users and keys can authenticate to your nodes.
3. Network — nodes in your cluster can talk to each other; traffic between different customers’ environments is denied by default.
4. Storage and data — your data stays local to your nodes and is wiped before any hardware is reused.
5. Lifecycle — a node must pass sanitization and validation before it can be assigned to anyone else.

​

Network

• Perimeter. Ingress is controlled by firewall or security-group policy scoped to your environment. Default posture is SSH only, with all other inbound ports closed; additional ports are opened on request for identified services. Where a site doesn’t expose provider-side network controls, the same policy is enforced with host firewalls, instance-scoped access, and cross-customer deny rules.
• Source-IP allowlisting of SSH and management access is available and recommended. A bastion — one hardened entry point on a non-standard port, allowlisted, with compute nodes not directly exposed — is the standard pattern. If you don’t have stable egress IPs, a customer-managed VPN or overlay (Tailscale, for example) or restricted user allowlists work instead.
• Compute fabric. InfiniBand and RoCE fabrics are partitioned per tenant. On InfiniBand your nodes sit in a dedicated partition (P_Key) with full membership and the default partition is restricted, so nodes outside your partition cannot exchange RDMA traffic with yours. Partition membership is set at the subnet manager and tested end to end (cross-partition RDMA and IPoIB reachability checks) before handover.
• Out-of-band management. BMC/IPMI is not exposed to customers by default; reimage, console, virtual media, and power operations are done by our operations team on a ticket. Where BMC access is extended to you by arrangement, it is reachable only from your allowlisted source IPs and scoped to your cluster.

​

Host hardening at handover

For clusters we provision and configure:

• Key-based SSH only. Your public keys are installed and password authentication is disabled in the SSH daemon (PasswordAuthentication no, KbdInteractiveAuthentication no, AuthenticationMethods publickey, PermitEmptyPasswords no). Default OS account passwords are locked. Hardening lives in configuration drop-ins that take precedence over provisioning-time defaults, so it survives reprovisioning.
• Named accounts. SSH is limited to your designated accounts and keys; AllowUsers allowlisting is applied on request.
• No third-party accounts. Provisioning, installer, and partner accounts are removed or disabled before handover. No shared or template credentials remain on delivered nodes; anything needed for handover is delivered through a secure channel and rotated at handover.

Where nodes are provisioned by the datacenter partner we require and validate the same posture. See Cluster Handover for what is checked before delivery.

​

Data lifecycle

• Between tenants: storage is wiped, customer keys and accounts removed, the node re-imaged and re-validated before it can enter another customer’s environment.
• At contract exit: your data is deleted. The same exit and deletion requirements are imposed on datacenter partners through our due-diligence framework.

​

Operations

• Monitoring and incident response. Hardware and fabric health (GPU and ECC state, link health, performance baselines) are validated at onboarding and re-validated after any remediation. In-service issues are tracked through a shared ticketing pipeline with severity-based response targets — see Getting Support. Security events follow a defined process: containment (isolating or removing affected nodes), credential rotation, log collection across host and partner layers, root-cause analysis, and customer notification with remediation status. Partner-side log retention varies by site and is assessed during datacenter partner due diligence. During a security investigation we collect the host and partner logs that are available for your environment; if a specific retention period matters for your compliance program, raise it with your account team so it can be written into your agreement.
• Change management. Firmware, BIOS, and driver updates on your cluster are tested before rollout and scheduled with you in coordinated maintenance windows. We require change-control visibility from partners for the layers they operate.
• Physical security. Clusters are hosted in enterprise datacenters with badged and escorted access, surveillance, and redundant power and cooling. Facility security is assessed as part of partner due diligence.

​

Security program

• SOC 2. Type I audit complete; the report is available under NDA. A Type II engagement is underway and the report will be available on completion. Current status and documents: trust.hyperbolic.ai.
• Continuous control monitoring through a GRC platform with automated evidence collection and drift alerting.
• Vulnerability management on defined SLAs: critical and high within 30 days, medium within 60, low within 90.
• Access governance. Least privilege with periodic access reviews; MFA enforced on corporate identity, code repositories, and production tooling; employee background checks.
• Datacenter partner due diligence. Every partner behind dedicated capacity is assessed on operating history and incident record, facility power and cooling, network and fabric architecture, tenant-isolation requirements, firmware/BIOS/driver change control, log retention, access management, spare-capacity and remediation commitments, and exit and data-deletion requirements. Capacity passes acceptance testing — performance and fabric-health benchmarks included — before it is offered to a customer, and is re-tested after material fixes or infrastructure changes.