Security Checklist for Running AI Workloads on Rented Cloud GPUs

Renting a GPU means running your model, your data and often your credentials on a machine someone else owns. That trade is worth it: on-demand H100S are now available from about $1.78 an hour on GPU marketplaces, but only if security comes with it. 

This checklist covers running AI workloads on rented cloud GPUs safely: how to vet a provider, lock down access, protect data, harden containers, limit network exposure, monitor jobs, and tear everything down cleanly afterward.

Why rented GPUs need their own security model

A rented GPU isn't a typical cloud VM. On a marketplace, the machine may belong to an independent provider, not the platform. On a specialist cloud, you may get root on bare metal. Either way, the threat model changes.

The main risks look like this:

Every one of these risks gets easier or harder to manage depending on the platform, which is why choosing it is the first control on this checklist.

1. Vet the provider before you rent

Price comparisons are easy. Security comparisons take a few more questions, but they matter more.

• Does the platform verify the hardware, or just trust the listing?

• Is there a confidential computing option (Intel TDX, AMD SEV-SNP) for sensitive work?

• Are uptime, reliability and location visible per machine?

• What happens if a host drops your rental mid-job?

• Where is the machine physically located, and does that matter for your data rules?

Lium, a marketplace for renting cloud GPUs for AI, is a good example of what passing these questions looks like without paying a premium: H100s from $1.78 per GPU-hour, every GPU probed by independent verifiers before listing and re-checked afterwards, and a confidential VM option on some nodes. 

Each listing also shows uptime, a reliability score, location and measured network speed, and a provider who drops a live rental is penalized while the renter is credited. On open marketplaces where hosts aren't verified, you'd need to check all of that yourself.

2. Lock down access

Most compromises on rented infrastructure start with weak access and leaked keys. Treat every pod as if it's internet-facing, because it usually is.

1. Use SSH keys only. Never password logins.

2. Generate a separate key pair for GPU rentals, not your main workstation key.

3. Store platform API keys in a secrets manager, never in notebooks or Git.

4. Rotate API keys after a project ends or a teammate leaves.

5. Enable multi-factor authentication on the provider account.

The renting workflow on Lium is built around this: sign up, top up, paste an SSH key, pick a Docker template and deploy. API keys, SSH keys and private registry credentials are managed separately in the account, which makes rotation simple.

3. Protect the data and the model

Your training data and model weights are often the most valuable things on the machine. The CISA, NSA and Five Eyes guidance covered later recommends treating AI models and their training data as sensitive assets, including permanently deleting them when they're no longer needed.

In practice:

• Upload only the data a job actually needs, not the whole data lake.

• Encrypt datasets at rest and decrypt only inside the job.

• Strip or pseudonymize personal data before it leaves your environment.

• Use persistent volumes for checkpoints instead of leaving them on local disk.

• Keep backups of anything you can't recreate, on storage you control.

For regulated or proprietary workloads, a confidential VM is the strongest option available on rented hardware. Intel TDX encrypts the VM's memory with keys the host can't read, which closes the biggest gap in the rented-GPU model: an untrusted machine owner.

4. Harden the container and the software stack

AI stacks pull in a lot of third-party code: base images, CUDA libraries, Python packages, model files from public hubs. Each one is a supply-chain risk.

• Use official or internally built base images, pinned by digest.

• Scan images for known vulnerabilities before you push them.

• Pin Python package versions and check hashes where you can.

• Prefer safetensors over pickle-based model files from unknown sources.

• Run processes as a non-root user inside the container when the workload allows it.

Pickle-based model files deserve a special mention. Loading an untrusted pickle can execute arbitrary code, and on a rented GPU that code runs next to your data and keys.

5. Control network exposure

Jupyter, TensorBoard and quick inference demos are easy to expose by accident. I'd treat every open port as a finding until proven otherwise.

The basics: bind development tools to localhost and reach them through an SSH tunnel, put authentication in front of any API you expose, and close ports when the demo's over. If you're running a public inference endpoint, add rate limiting and log every request.

These controls map directly onto general cloud infrastructure security practice: least privilege, segmented networks and no default exposure. Rented GPUs just make the stakes higher, because the machine isn't yours.

6. Monitor while the job runs

A rented pod is short-lived, but that's not a reason to fly blind. Keep logs of logins, process launches and outbound connections, and ship them off the machine so they survive teardown.

Watch for unexpected outbound traffic, especially large uploads, new processes you didn't start, and GPU usage that doesn't match your job. A compromised image quietly running someone else's compute job shows up as GPU load you can't explain, and that's often the first visible sign.

7. Tear down cleanly

Teardown is where most teams get sloppy, and it's where data quietly leaks. A good exit routine looks like this:

1. Copy results and checkpoints to storage you control.

2. Wipe datasets, weights and caches from local disk.

3. Remove SSH keys and any secrets you placed on the machine.

4. Delete the pod, then delete volumes and backups you no longer need.

5. Revoke or rotate any API keys used during the job.

Automating the first step makes the rest easier. On Lium, scheduled termination ends a pod at a set time so it stops billing and stops existing, and scheduled backups protect the work before it does.

Map it to official guidance

None of this is invented from scratch. The international joint guidance "Deploying AI Systems Securely," published in April 2024 and led by the NSA's AI Security Center with CISA, the FBI and partners in Australia, Canada, New Zealand and the UK, covers the deployment environment, continuous protection of the AI system and secure operation. Rented GPUs sit squarely inside that scope.

Here's the whole checklist in one view:

The Bottom Line

Running AI workloads on rented cloud GPUs is safe enough for most teams, as long as you choose a platform that verifies its hardware and you treat every pod as hostile ground. In my view, the best value today is a marketplace that pairs low prices with real controls, and Lium does that well, with verified GPUs, confidential VM options, and H100S from $1.78 an hour. 

Pick the platform carefully, follow the checklist every time, and the cost savings won't come at the expense of your data.