"Isolated" GPU compute is three problems, not one. Most rentals skip network isolation, and a host can sometimes see your data. Here's what holds up.
Renting a container on someone else's machine feels private. But isolation is an architecture, not a feeling, and you can check whether it's actually there.
Disclosure: we're building a venture in this category. The analysis sticks to public figures and named sources, and we flag our own stake where it bears on the argument.
You rent a GPU. You get a container. It has your files, your model, your job. It feels like a private room.
Then you read the host's documentation, and the honest operator forums, and you find the room has thinner walls than the brochure suggested. The question worth asking before you send anything sensitive: isolated from what, exactly, and proven how?
"Isolated" gets sold as a single property. It is at least three, and a rental can have one without the others.
The first is compute isolation. Your job runs in its own sandbox so a neighboring tenant on the same box cannot reach into your process. Containers do some of this by default. Stronger boundaries (a virtual-machine layer, a hardened runtime) do more.
The second is network isolation. This is the one most rentals quietly skip. By default a container can usually reach the open internet, which means a compromised or curious job has a path to send your data somewhere it should never go. Closing that path is an architectural choice, not a setting most marketplaces make for you.
The third is host isolation. Can the operator of the physical machine see what you're running? On consumer-grade rentals the uncomfortable answer is sometimes yes. A widely-cited Hacker News thread on a major GPU marketplace put it plainly: "a host can snoop on your workloads" (Hacker News, discussion 36026101). Read that as a structural fact about renting time on hardware someone else administers, not as an accusation against any one operator.
The low price of rented compute comes from sharing. Many tenants, hardware nobody tenant owns, supply pulled from wherever it's idle. That model is genuinely useful. It's also the exact shape that makes a security reviewer nervous, because the savings and the exposure come from the same source.
The vendors are not hiding from this. They've responded by building a second, better lane. One large network steers regulated jobs to "Verified Data Center" nodes and openly warns against its community tier for SOC 2 or HIPAA data (a leading decentralized GPU network, vendor comparison, Apr 2026). A major marketplace adds a separately-certified "Secure Cloud" partner classification, with ISO 27001 and HIPAA on offer, for hosts that meet the bar (a major GPU marketplace, data-center application, 2026). Credit where it's due: both companies are honest that the default machine is not the right machine for sensitive work.
But read what that two-lane design is telling you. The default rental is treated as not-good-enough for the data that matters most, so a special tier gets built beside it. The second lane exists because the first one falls short.
Isolation that's promised is a sentence in a help doc. Isolation that's structural is a network boundary a workload physically cannot cross. Only one of those survives an audit.
Strip it to what an auditor would actually accept, and the checklist is short.
A boundary stronger than a shared kernel. A virtual-machine layer or a hardened container runtime, so a neighboring tenant has no reachable path to your process.
Per-job network tunnels. A workload that talks only to the coordinator that dispatched it, with no route to the open internet. This closes the exfiltration path instead of asking you to trust it's closed.
A host that can attest, not just assert. Hardware-rooted attestation (a TPM, a secure enclave) that lets a machine prove its state, rather than the operator vouching for it.
A record that outlives the job. Encryption in transit and at rest, plus a log of what ran where, that you can hand to a reviewer.
None of these are about the GPU being faster. Isolation is an infrastructure property, decided before the model ever loads.
No architecture makes your input data magically invisible to the silicon computing on it. Anyone promising perfect, absolute confidentiality on third-party hardware is selling the claim, not the capability. The right standard is documented risk reduction: structural boundaries, contractual control, attestation, an audit trail. That's a real thing you can buy. Perfect secrecy on a machine you don't own is not.
We went deep on the verification half of trust in Proof you can't fake: how verifiable inference changes who you can rent compute from, and on the demand this unlocks in The data you can't send to the cloud is the data most worth computing on. The supply-quality gap underneath all of it is the flagship: The sub-1% problem in decentralized compute.
For the record, since we have a horse in this race: the venture we're building, Griddly, holds itself to that checklist. Per-job WireGuard tunnels so a container sees the coordinator and nothing else. A hardened runtime with optional VM-grade isolation. TPM attestation as a trust boost. Isolation you can point at, not isolation you're asked to assume.
Nothing here is an offer to sell a security or investment advice.
Field notes on venture building, AI, and capital. No spam, unsubscribe anytime.
By subscribing you agree to receive AOS Insights e-mails. We use your address only for this newsletter - see our Privacy Policy.
