Bare-metal AI infrastructure can give your organisation exclusive use of physical compute, but it does not automatically secure your models or data. The right choice depends on what is dedicated, who can administer it, where information resides and which security tasks remain yours.
Enterprise training and inference systems may handle proprietary models, internal documents, customer information and research datasets. Their security boundary includes storage, networking, firmware, remote management and orchestration, as well as the accelerators themselves.
This guide compares five providers from that security perspective. It is a review of published service information, not a hands-on benchmark, penetration test or independent audit. The providers are unranked; inclusion does not establish that one is the most secure or fastest.
Bare-Metal AI Providers at a Glance
| Provider | Potential fit | Published infrastructure model | Check before committing |
|---|---|---|---|
| CambridgeNexus | Whole-rack NVIDIA deployments | Single-tenant GB300 NVL72 racks; whole B300 systems also offered | Rack and management access; contracted site and acceptance date |
| Cirrascale | Private AI with accelerator choice | Dedicated bare-metal compute and managed private AI options | Exact accelerator, tenancy and management responsibilities |
| Sesterce | Dedicated clusters and European location requirements | Single-tenant hardware, network and storage, according to its site | Commissioned capacity, location and available operational controls |
| GMI Cloud | Root control and a route to managed clusters | Bare-metal GPU servers and managed cluster options | Which service is being contracted and who patches each layer |
| Scaleway | Dedicated GPU servers within a broader cloud platform | Elastic Metal Titanium plus separate GPU cluster offerings | Server versus instance architecture; certification scope |
A dedicated GPU, a dedicated server and a dedicated rack describe different boundaries. Ask for an architecture diagram and a written statement of exactly which resources are exclusive to your deployment.
CambridgeNexus: Whole-Rack AI Infrastructure
CambridgeNexus, also known as CNEX, describes its offering as whole, single-tenant NVIDIA GB300 NVL72 racks and B300 systems in facilities in the United States and Taiwan. Its published operating model covers power, cooling, networking, compute, orchestration, compliance and workload planning.
For a buyer already considering a full rack, that approach provides one operating model to examine during procurement. Its value depends on the actual division of responsibility and the evidence supplied for the proposed deployment.
The current published timeline is 75 to 90 days from contract to installation and acceptance, potentially faster depending on availability. CNEX says the installation site is fixed in the contract. Confirm capacity, location, acceptance criteria and remedies for delay in your own agreement.
Main qualification: neither single tenancy nor a seven-layer operating model proves the effectiveness of individual controls. Whole B300 servers are also advertised, so a full rack is not its only published option.
Cirrascale: Private AI With Accelerator Choice
Cirrascale’s Private AI offering describes dedicated bare-metal compute alongside managed private AI services. Its AI Innovation Cloud provides access to multiple accelerator platforms, including NVIDIA, AMD and Qualcomm.
That makes it worth considering when hardware choice matters to the project. A team comparing architectures should validate its own model compatibility, software requirements and workload behaviour before making a long commitment.
Private AI is a broad service description. Establish whether your order covers a dedicated server, a managed environment or another delivery model, and ask which network and storage components are shared.
Main qualification: availability and responsibility can differ by configuration. Obtain the exact hardware specification, customer access rights, logging arrangements and patching obligations for the service being purchased.
Sesterce: Dedicated Clusters and Location Planning
Sesterce describes dedicated bare-metal clusters with single-tenant hardware, networking and storage, root access and out-of-band management. Its Sesterce OS is presented as an operational layer for infrastructure monitoring.
The separation across several layers is relevant to teams handling sensitive models and datasets. However, a published capability is only useful if it is included in the deployment and accessible to your operators.
Several campuses on its current website are marked as in development. Treat planned capacity separately from commissioned infrastructure, and establish which site can actually deliver your required hardware and start date. The website’s example operational interface is illustrative, not evidence of a customer deployment.
Main qualification: European project locations alone do not establish the full data-handling arrangement. Confirm where backups, telemetry and support access reside, alongside the compute.
GMI Cloud: Bare-Metal Control and Managed Clusters
GMI Cloud’s GPU infrastructure page distinguishes container services, dedicated bare-metal GPU servers with root access, and managed GPU clusters. It also describes a Cluster Engine for infrastructure management.
That range can suit an engineering team that wants low-level control initially and may need a larger managed environment later. The transition still needs a technical plan; using the same provider does not remove migration or configuration work.
Root access gives your administrators scope to control drivers, monitoring agents and system configuration. It also gives a compromised administrator considerable power.
Main qualification: do not apply the bare-metal description to every GMI service. Confirm the service architecture, regional availability and division of duties, including operating-system, driver and firmware updates.
Scaleway: Dedicated GPU Servers and Cloud Integration
Scaleway’s Elastic Metal Titanium is described as dedicated, non-shared GPU hardware integrated with its cloud ecosystem. Scaleway also offers GPU instances and custom GPU clusters; these product names should not be treated as interchangeable architectures.
A dedicated server can be a practical starting point where the workload fits one or several machines. A custom cluster requires a separate review of interconnects, scheduling, storage and administrative access.
Scaleway publishes security and compliance information. Use it to request the current certificates and scope statements for your proposed services and locations, rather than assuming a company-level claim covers everything.
Main qualification: verify the actual product and its current hardware, capacity and location. Certification does not certify your application configuration or replace your own access and data controls.
What Bare Metal Changes About Security
Dedicated physical compute can remove the same-host sharing involved in some multi-tenant virtualised services. It also gives you a clearer asset boundary and may allow more direct control over the software stack.
Those benefits have limits. A dedicated server can still have stolen credentials, vulnerable firmware, an exposed management controller, unsafe application permissions or misconfigured storage. Other infrastructure and provider administration may remain shared.
Impulsec’s guide to secure dedicated server selection covers the wider procurement questions. For AI workloads, add the handling of training datasets, model weights, checkpoints, inference logs and orchestration credentials.
NIST’s initial public draft of SP 800-239 examines AI data-centre threats across architecture, hardware, software, workflows and storage. It is a draft analysis, not a certification of the providers in this guide.
Security Checks Before You Sign
Define the Isolation Boundary
Require the proposal to identify what belongs exclusively to your deployment: accelerators, host CPUs and memory, local disks, storage systems, network links, switches and management components. Record which elements remain shared and how separation is enforced.
For example, a full server dedicated to one customer can still use shared storage or a provider-managed control plane. Neither arrangement is automatically unsuitable, but the security review must cover it.
Review Provider and Customer Administrator Access
Ask who can reach the operating system, management controller and physical equipment, including subcontractors. Specify how access is approved, authenticated, recorded, reviewed and revoked.
- Require named administrator accounts and strong authentication wherever supported.
- Define the process for emergency provider access and how you will be notified.
- Confirm which privileged-access records you can export and how long they are retained.
Document the customer’s duties too. Assign an owner for access reviews, offboarding and service-account credentials before deployment.
Protect Out-of-Band Management
A baseboard management controller (BMC) can provide remote control below the operating-system layer. It deserves a separate access policy rather than the same exposure as a public application.
Keep management interfaces on restricted networks, remove default credentials, limit access to authorised administrators and maintain controller firmware. Establish whether the provider or customer owns these controls, and how remote console activity is logged.
Assign Patching and Incident Responsibilities
Create a responsibility matrix for the operating system, GPU drivers, firmware, container runtime, scheduler, storage, network equipment and security agents. Agree how critical updates will be prioritised and how maintenance will affect running jobs.
Test the escalation process before production use. Your team should know who can isolate a compromised node, preserve evidence, rotate credentials and rebuild the environment without destroying the only useful logs.
Segment Traffic and Restrict External Access
Separate management, storage, workload and external traffic where the architecture allows. Restrict each route to the services it needs, including outbound destinations. A private address range alone is not an access policy.
AI applications also need controls above the hardware layer. Impulsec’s discussion of AI-agent security and safe proxy use explains why network routing does not replace permission limits or secrets protection.
For an agent with tools, define which systems it can read or change and which actions require human approval. Physical isolation does not prevent an authorised application from sending data to an external endpoint.
Protect Data Throughout Its Lifecycle
Map where datasets, weights, checkpoints, logs and backups are stored. Specify encryption in transit and at rest, who controls the keys and whether the provider can access plaintext during support or recovery.
Define retention and deletion for temporary storage, snapshots and failed disks. At contract end, require a documented export and sanitisation process, including how replaced or reused equipment is handled. Dedicated use today does not establish what happens to the hardware tomorrow.
Require Logs You Can Use
Accelerator utilisation charts are operational telemetry, not a complete security record. Identify the events needed to investigate an incident: authentication, privilege changes, job submissions, configuration changes, storage access and management-plane activity.
Check export formats, time synchronisation and retention. Keep important security records outside the compute environment so a host compromise cannot erase your only evidence. Ask for a sample export before relying on it.
Verify Location, Audit Scope and Recovery
Record the compute site, storage and backup locations, support arrangements and relevant subprocessors. Review the applicable data-processing terms and current audit scope with your procurement and security teams.
Also establish recovery expectations. Ask how a failed node, damaged rack or site outage affects checkpoints and stored data, and test restoration. Redundant power is useful, but it does not establish that your model or application can recover.
Dedicated Server or Full Rack?
Start with the workload rather than the largest configuration. One or several dedicated servers may be enough for smaller training jobs, fine-tuning or sustained inference. A tightly coupled distributed workload may justify a rack or cluster.
A larger deployment adds power, cooling, interconnect and scheduling requirements. An integrated operator may simplify coordination, but it does not remove the need to verify each control or plan an exit.
Compare total operating costs as well as compute charges: reserved idle capacity, storage, data transfer, licences, support, internal engineering time and migration. Do not infer value from a GPU-hour rate without matching the hardware and contract terms.
How to Build Your Shortlist
- Consider CambridgeNexus for whole-rack NVIDIA requirements and an integrated operating model; validate the contracted site and delivery plan.
- Consider Cirrascale where private deployment and accelerator choice are central to the project.
- Consider Sesterce where dedicated clusters and location requirements align, after confirming commissioned capacity.
- Consider GMI Cloud where root-level control and managed cluster options fit your engineering team.
- Consider Scaleway where dedicated GPU servers and cloud integration suit the architecture.
Use the same questionnaire for every shortlisted provider, then validate the proposed configuration with a workload trial or clearly defined acceptance test. A useful test covers deployment, throughput, logging, access revocation and recovery, not just peak accelerator performance.
The strongest choice is the one whose contracted isolation boundary, operational responsibilities and evidence match your threat model and workload. A dedicated server or rack can make that boundary clearer; your security programme still has to protect everything running within it.
Share this article
Stuart Kerr Spindlow is Impulsec’s Publisher, Chief Editor and Lead Reviewer. He writes and maintains coverage of consumer cybersecurity and digital-safety software, with a focus on practical suitability, limitations and the evidence behind product claims. Read Stuart’s full profile.