Before you list a single GPU, ask these 12 questions: tenant isolation, what the host agent can reach, data wiping to NIST 800-88 Rev 2, certifications, abuse and liability.
Before you list a single GPU, ask these 12 questions. A common security question is whether a platform is safe for the person renting the GPU. A host faces the opposite question: what can the platform's software do on my machines, can a tenant reach my network, who is liable when something goes wrong, and what happens to data when a job ends. This guide gives 12 questions for gpu provider security, covering gpu hosting security and gpu cloud security from the host's side, grouped into six areas, with what a good answer sounds like and what should worry you. One disclosure: packet.ai lists supplier capacity, so we have an interest in this topic. The guide is platform-neutral, it does not describe packet.ai's security model, and the examples from other platforms come from their public pages as of November 2, 2026. It is general information, not security or legal advice.
Key takeaways
A security questionnaire normally flows from the buyer to the vendor: a vendor security questionnaire, a vendor risk assessment questionnaire and most other vendor questionnaires probe how a platform protects the customer's data. A GPU host sits on the other side of the table. The host hands a platform control over expensive hardware inside its own network, and then runs strangers' code on it. The risks that follow are different: a tenant escaping its container, an agent with more access than expected, abuse that lands on the host's name, and data left on disks after a job. Secure gpu hosting starts with treating the platform like a supplier and running supplier due diligence on it before you connect a machine. The same logic applies if you manage GPUs for clients, as in how MSPs and integrators can add a GPU revenue line.
Tenant isolation, and in particular multi tenant isolation on shared GPUs, is the first thing to understand, because it decides how much damage one bad tenant can do. Multi tenant gpu platforms generally use one of four approaches.
GPU-level isolation and host-level isolation solve different problems. A MIG partition can separate GPU resources, but it does not by itself create a separate host operating system or remove privileged access to the machine. Virtual machines give each tenant its own guest kernel, though the hypervisor and host stay in the trust model, and bare metal gives one tenant a dedicated machine without removing the provider's privileged access through host administration, firmware or management systems.
Public platform documentation shows the range. Vast.ai's compliance and security pages say every workload runs in an unprivileged Docker container, with separate namespaces and cgroups, network isolation, file system isolation and process isolation, and that data is destroyed when a client deletes an instance. That is a reasonable container design. It is also still a container, which is why the 2024 and 2025 vulnerabilities matter.
Question 1: What isolates tenants from each other and from my host machine? Listen for a specific answer about gpu isolation, not a brand name. Question 2: How fast do you patch the GPU container stack, and were you exposed to the toolkit escapes? The NVIDIA Container Toolkit is software that most GPU container platforms rely on, so any nvidia container toolkit vulnerability is a platform-wide risk. In 2024, Wiz found CVE-2024-0132, a container escape in it. In July 2025 it disclosed CVE-2025-23266, nicknamed NVIDIAScape: a three-line Dockerfile could abuse the way the toolkit's container-creation hook inherits environment variables from the container image to escape the container and gain root on the host. For a host, a gpu container escape like this means a tenant gains control of your machine. It scored 9.0 on the CVSS scale, and NVIDIA published its security bulletin on July 15, 2025. The bulletin lists the Container Toolkit up to 1.17.7 as affected (fixed in 1.17.8) and the GPU Operator up to 25.3.1 (fixed in 25.3.2), along with the Kubernetes Device Plugin and MIG Manager, and notes that systems using crun as the low-level runtime are not affected by this CVE, so check NVIDIA's current bulletin for the full list. A host should ask when a platform patched, which toolkit and GPU Operator versions it runs now and how it verifies patch status across its fleet, how it learns about such flaws, and whether it adds VM-level isolation. Wiz's own conclusion is that containers should not be the sole isolation in multi-tenant environments and that at least one strong barrier, such as virtualization, should sit underneath. Question 3: Can a tenant get privileged access, or reach my network or the machine's management controller? A tenant should never be able to see the host's other machines or its baseboard management controller.
Our view
Ask for the answer in writing, with dates. A platform that can say when it patched NVIDIAScape and what changed afterward is showing you how it handles the next one. A vague reassurance about "enterprise-grade isolation" is not an answer.
Most platforms ask a host to install an agent. It is the software that connects your machine to their control plane, so it deserves the same scrutiny as any program with privileged access to your network. Question 4: What does the agent run as, what can it access, and does it need inbound ports? Platforms answer differently. RunPod's Hybrid Cloud page describes a host agent that connects outbound over an encrypted overlay with no inbound ports, scoped to the customer's organization, and says it does not provision or touch the customer's cloud accounts. That is a concrete, checkable description, and it is a useful benchmark for what a clear answer looks like, though it describes RunPod's hybrid product and not every platform. By RunPod's own description that product is early and limited-access, and its capacity is private to the owner's organization, which is a different model from listing GPUs for other tenants to rent, so treat it as a description of design and not a track record. Also ask which actions the agent can perform and what credentials it holds, because its privileges and the control plane's privileges are not necessarily the same, and whether its permissions are limited to the tasks it needs.
Question 5: Can I put the machines on their own network segment? In our view a host should keep GPU nodes on a separate subnet or VLAN, with no route to the rest of the business network and no tenant access to the management network, whatever the platform promises. Ask which outbound destinations and ports the agent needs, so you can write firewall rules that allow only those. Question 6: What happens if the agent or the control plane is compromised, and can I uninstall cleanly? RunPod's page says the agent uninstalls and workloads stay as standard containers, which is the kind of exit that leaves you in control. Ask what the agent leaves behind, how updates are signed and who can push them.
Question 7: How is tenant data wiped when a job ends, and to what standard? Data wiping is the part of host security that is easiest to skip and hardest to prove. The reference to know is NIST 800-88, formally NIST SP 800-88, Guidelines for Media Sanitization. Its Revision 2, published in September 2025, supersedes the December 2014 Revision 1, so a policy that still cites Revision 1 cites a superseded document. The revision keeps three levels: Clear, which uses logical techniques such as overwriting, Purge, and Destroy. It says multi-pass overwriting is not needed for Clear, counters what NIST calls the obsolete DoD 5220.22-M language that mandated a number of passes and patterns, and says purge should be used instead of clear when possible. A footnote in the NIST document adds that DoD removed overwriting specifications from its operating manual in 2006. It also addresses cryptographic erase, which sanitizes the encryption keys so the data can no longer be read, and shifts its focus from describing wipe techniques to running a sanitization program, pointing to current standards such as IEEE 2883 for the techniques themselves.
For a host, that translates into practical asks. Local NVMe that held tenant data should be wiped or cryptographically erased between tenants and when the drive is retired, and the platform should say which method it uses. A three-pass overwrite is not the benchmark any more, and NIST warns that on flash storage with spare cells and wear levelling, overwriting cannot reach every area where data was stored. Deleting a volume, revoking a tenant's access, cryptographic erasure and sanitizing the media are different outcomes, so ask what is removed, from which layer, by which method, how completion is validated and what evidence you receive. NIST separates verification, whether the technique completed, from validation, whether the target data was effectively sanitized, and its sample certificate of sanitization records both, so ask for both and not only a certificate. Ask also whether GPU memory is cleared between tenants.
Question 8: Can the platform or a tenant see my data, and can I see theirs? Vast.ai's security FAQ says clients can only access their own data, and also says provider security varies significantly and that individual hosts may have less formal security measures. For a host, the mirror question is what you can see on your own machine. Confidential computing is the technical answer, and confidential computing gpu support now spans Hopper and Blackwell. NVIDIA's confidential computing mode on Hopper and Blackwell GPUs has two parts: the workload runs in a confidential virtual machine on a CPU with AMD SEV-SNP or Intel TDX, and the GPU has its own hardware root of trust, a signing key fused at manufacturing that NVIDIA says is never exposed to software, firmware or the host. NVIDIA's attestation service checks the GPU report and the CPU measurements before secrets are released into the confidential VM, and NVIDIA says the combination protects data and model weights during active inference. Requirements differ by platform and configuration. NVIDIA's HGX B300 benchmark shows a relative throughput impact of roughly 1% to 8%, and it notes that smaller units of work are affected more, so cost depends on the workload. It needs supported CPUs and specific platform configuration, which NVIDIA covers in a deployment guide, so ask whether a platform supports nvidia confidential computing and what your servers must have for it.
Question 9: Which reports and certifications do you hold, and what is in scope? A badge says less than it appears to, including the soc 2 gpu cloud badges common in this market. SOC 2 is an attestation report by a licensed CPA firm against the AICPA's Trust Services Criteria, and management decides which systems and which criteria are in the report. ISO 27001 certifies that an organization's information security management system meets the standard, issued by an accredited certification body.
The key question for a host is whether the platform's agent and the hosting arrangement are inside the boundary. A report covers only the system its description sets out, so machines owned by independent hosts are inside it only if the description says so. RunPod's guide, for example, says the third-party data centers underneath its Secure Cloud maintain their own certifications in addition to RunPod's own, which shows why a headline badge cannot answer the question of who secures the machine your tenants run on. Read the system description before you read the logo. Ask directly whether the report or certificate covers the GPU hosting service, the management plane, the physical data center or only corporate systems, and how subservice organizations such as the data center operator are treated. A platform running in a secure facility inherits that facility's physical controls, but its own agent, control plane and tenant configuration remain its own.
Question 10: How are abuse and incidents handled, who investigates, and what do I get to see? Hosts are exposed to what tenants do with their hardware: cryptocurrency mining that burns power, attacks launched from an IP address, or illegal content. Ask who monitors workloads, because answers differ. RunPod's own guide states that it does not actively monitor workloads on Secure Cloud, which is a legitimate design with a clear consequence for who detects abuse. Ask how a report reaches the platform, how quickly you will be notified of an incident affecting your machines, what information you will be given, who investigates, what happens to affected workloads, how evidence is preserved, what logs are kept and for how long, and who talks to law enforcement.
Our view
Make the platform tell you, in advance, the difference between what it monitors and what it does not. The risk is rarely a platform that does too much. It is a gap where each side assumes the other is watching.
Question 11: Who is liable for tenant misuse, data breaches and hardware damage? Read the agreement for four things: who is responsible if a tenant uses your hardware or IP address for something unlawful, whether the platform indemnifies you and up to what limit, whether your own insurance covers a tenant-caused loss and the platform's activity, and what the platform's liability cap is in comparison with the value of your hardware. Technical responsibility and legal liability are not the same thing: a platform can be technically responsible for a component while its contract caps what it owes you, so ask for both answers. If you manage machines for others, the same questions apply to your client contracts, as covered in how MSPs and integrators can add a GPU revenue line. Hosts running in a colocation facility should also check how the facility's terms interact, a topic in what colo owners earn as landlords versus operators.
Question 12: What happens at exit? Ask for the notice period, how and when tenant data is deleted and how you can confirm it, how fast the platform releases the hardware, whether you can audit its handling of your machines, and what happens to unpaid balances. A clean exit is a security property, not just a commercial one: it determines how long a departed platform's agent and credentials stay on your network.
This gpu security checklist fits on one page, and it doubles as a host security checklist you can send to any platform as a questionnaire. Depending on the question, useful evidence can be a written policy, architecture documentation, an audit report, configuration details or a contractual commitment, so note which kind of evidence each answer comes with.
To work through this with a platform, send the twelve questions as a written security questionnaire and ask for written answers, then compare. If you want to put the same questions to packet.ai, use the contact page to ask the team about security. For terms used here, the GPU provider glossary defines multi-tenant, bare metal and SLA, and the five ways to turn idle GPUs into revenue and why neoclouds are adding a second demand channel cover the routes to market.
Retrieved November 2, 2026. Platform pages change, so check the live page and its date before relying on any claim about a specific platform. Third-party summaries are noted as such.
Last reviewed: November 2, 2026. This is general information, not security, legal or compliance advice. It describes no packet.ai security controls, and statements about other platforms reflect their public pages on the date shown. For packet.ai's supplier information, see the supplier page.
Same models. Same API. Fraction of the cost. Start free — no credit card required.
Start building →