Having recently completed Stanford's Advanced Cybersecurity Program, I found that some of the ideas from the program fundamentally changed how I think about trust in GPU and cloud infrastructure — especially relevant as NeoClouds, GPU PaaS providers, and data center AI infrastructure scale rapidly. Here are the five that stuck with me most
GPU non-determinism breaks training verification — a real, unsolved trust problem
When two different GPU generations (NVIDIA A100 vs. H100) train the "same" model on the "same" data, floating-point rounding differences (a + (b + c) ≠ (a + b) + c) produce completely different model weights. This means an auditor can't simply rerun training to verify a provider did what they claimed — the field is actively building solutions (recording rounding directions, SNARKs/zk-proofs) to make training auditable across hardware. This is directly relevant to any NeoCloud/GPU PaaS trust model where customers need proof their training job ran correctly.
GPUs "provide no security" by design — the trust boundary problem
The Slalom (Tramèr & Boneh, ICLR 2019) research treats the GPU explicitly as untrusted hardware, pairing it with a CPU hardware enclave (Intel SGX-class) to get integrity and privacy guarantees the GPU itself cannot provide, achieving ~10x speedup over enclave-only computation. The core insight: confidential AI compute isn't "trust the GPU," it's "architect around the GPU's lack of security" — critical framing for anyone building GPU-as-a-Service with confidential computing claims (Intel TDX, AMD SEV, AWS Nitro all came up as the modern equivalents).
Model extraction and IP theft are practical, not theoretical, on hosted inference
Real published attacks (Carlini et al.) extract LLM weights just from an API's log-probability outputs — meaning a GPU PaaS or inference-hosting platform has to think about model theft as a first-class threat, not an edge case.
Cloud-native security has its own OWASP Top 10 — and it's the one that matters for data center AI infra
Distinct from the classic web OWASP Top 10: insecure container/orchestration config, CI/CD and software supply chain flaws, over-permissive network policies, inadequate compute resource quota limits, and improper asset management are the top real-world risks in multi-tenant GPU clusters — not classic web app vulnerabilities.
Kubernetes' own control plane is an attack surface
The Kubelet API specifically was highlighted as an exploitable path into the cluster, reinforcing that container orchestration security — least privilege, read-only containers, mutual TLS, layerwise image scanning — is foundational, not optional, at data-center scale.
The common thread
None of these are about locking things down harder. They're about architecting systems that can prove their own correctness — verifying computation rather than blindly trusting hardware, and building governance into the infrastructure layer itself rather than bolting it on after.
I wrote more about applying these principles hands-on in my previous post on integrating Claude Desktop with Salesforce via Model Context Protocol — this program deepened the security thinking behind that work considerably.
Top comments (0)