Zero trust fixed the wrong implicit trust first—and that was still progress
The first wave of zero trust had a clear enemy: the flat network and the idea that “inside = safe.”
We got better at:
- Strong identity for users and services
- Device health signals
- Least-privilege access to applications
- Segmentation and continuous authorization
- Reducing VPN-as-a-personality-trait
I have no interest in mocking that work. It closed real attack paths.
But production security has a habit of moving trust around instead of removing it. After we stopped trusting the network, many architectures still treated these as basically safe:
- The cloud account boundary
- The Kubernetes control plane operators
- The hypervisor
- Root on the node
- “Privileged but reputable” admin tools
If your threat model includes a compromised admin identity, a malicious insider on the platform team, a supply-chain hit on a host agent, or a co-tenant breakout story—and modern ones should—classic zero trust controls do not fully cover data in use.
That is the opening for what I’m calling Zero Trust 2.0 with a hardware layer: keep the identity-centric control plane, and add hardware-enforced isolation so infrastructure privilege ≠ data privilege.
The untrusted infrastructure assumption
Confidential computing’s threat model is almost rude in its clarity. The Confidential Computing Consortium’s framing has long included the host OS, hypervisor, system administrators, and infrastructure owners among entities that should not automatically see data inside a TEE (CCC outreach whitepaper).
NVIDIA’s zero-trust AI factory architecture applies the same spine to AI: host OS, hypervisor, and provider are untrusted; workloads run in hardware-backed environments; secrets release only after remote attestation succeeds (Building a Zero-Trust Architecture for Confidential AI Factories).
That is zero trust grammar applied to compute, not only to network sessions.
What “hardware layer” means without mysticism
You do not need to worship silicon. You need three mechanical ideas:
- Root of trust in hardware — measurements start from something harder to spoof than a host process
- Memory isolation / encryption for data in use — privileged host software is not a legitimate reader of workload plaintext
- Attestation — remote parties verify “what is running” before they treat the environment as acceptable
On CPUs, that conversation is Intel TDX, AMD SEV-SNP, and similar technologies. On AI GPUs, Hopper-class confidential computing (H100/H200 lineage) extends isolation into the accelerator. The combined story matters: protecting only the CPU guest while leaving GPU memory exposed is an incomplete answer for LLM work.
Zero Trust 1.0 vs 2.0 (as I use the terms)
| Layer | Zero Trust 1.0 emphasis | Hardware-augmented zero trust |
|---|---|---|
| Network | No implicit trust based on location | Still true; not replaced |
| Identity | Users/services continuously verified | Still foundational |
| App access | Brokered, least privilege | Still foundational |
| Host platform | Often trusted if “managed” | Treated as hostile for data-in-use |
| Secrets | Vault + IAM | Vault + IAM and release gated on attestation |
| AI models/data | Controlled by project IAM | Encrypted until enclave proves out |
If someone says “we are already zero trust” and cannot answer how a node root user is blocked from reading workload memory, they are describing a partial deployment. That’s fine—just don’t oversell it.
Why AI and regulated data force the issue now
Three pressures hit at once:
- Sensitive content in prompts and fine-tunes — more personal data and confidential business data in motion through models
- Model IP on someone else’s machines — foundation model distribution, vendor-hosted inference, multi-team clusters
- Admin blast radius — platform engineering access is wide by design; identity controls on humans help, but host privilege remains a structural risk
In data protection work, I keep seeing security reviews stop at encryption in transit to the model endpoint. Good. Insufficient if the endpoint host is in-scope for inspection risk.
Building blocks that map to CISSP architecture thinking
Policy decision / enforcement still exist—you add a new evidence type Your PDP/PEP story gains attestation results as inputs: “allow secret X only if TEE type ∈ allowlist AND measurements match AND GPU CC = on.”
Trust boundaries get redrawn The boundary is not “the VPC.” It is “the attested enclave.” Everything outside is a transport and control plane problem.
Least privilege becomes two-dimensional
- Least privilege for identities (classic)
- Least privilege for infrastructure visibility (hardware-enforced)
Logging and monitoring need redesign Host-level introspection shrinks. You must plan enclave-aware telemetry that does not re-exfiltrate sensitive content to untrusted agents.
A reference control flow (use this in design reviews)
- User/service authenticates (ZT identity)
- Authorization checks resource policy (ZT access)
- Workload schedules into confidential compute capacity
- Environment attests (CPU ± GPU)
- Key broker validates evidence against policy
- Keys/data released into TEE only
- Output egress controlled; storage re-encrypted
- Session and machine evidence continuously re-evaluated where the platform supports it
Steps 1–2 without 4–6 are the glass floor.
What still breaks if you only buy TEEs
Hardware zero trust is not a personality transplant for a weak program.
You still need:
- Patch discipline for guest workloads
- Secure SDLC for model servers and tools
- Network encryption outside the enclave
- Strong identity for humans and service accounts
- Careful handling of prompts/outputs in application logs
- Supply chain controls for container images and models
TEEs reduce a class of host inspection risk. They do not make “admin can delete the cluster” go away, and they do not stop an application from voluntarily sending secrets to the internet.
NVIDIA’s architecture notes are explicit about residual scope: application vulnerabilities, availability attacks, and network/storage outside the CoCo boundary remain your problem (NVIDIA zero-trust AI factories post).
Operational friction—expect resistance
Platform teams will worry about debuggability and performance. They’re not wrong; answer with measured overhead and better guest-side tooling, not slogans.
Security teams will try to bolt attestation on as a quarterly checklist. It has to sit in the key path or it will be disabled during the first outage.
Procurement will ask whether this replaces zero trust vendor X. No. It complements identity-centric ZT with compute-centric guarantees.
Compliance will ask for proof. Keep attestation policies, reference values, and change records. “We enabled confidential VMs” is not evidence by itself.
Cost shows up as capacity fragmentation (CC-capable nodes), engineering time, and sometimes throughput tax on GPU CC paths. Budget the program, not just the feature flag.
How I talk to leadership without hype words
I use a simple story:
We already refuse to trust the network path. We still trust the computer too much. Hardware isolation lets us run sensitive AI and data workloads on infrastructure we do not fully trust—including our own admins’ host access—without giving up modern platforms.
Then I show one workflow where a secret cannot be retrieved unless attestation passes. Executives understand door locks. Attestation is a door lock with a serial number check.
Practical maturity steps (not a fake 1–5 score)
- Step A: Threat model host/hypervisor admin as in-scope for one crown-jewel AI or data service
- Step B: Deploy confidential VMs for that service’s control path
- Step C: Add GPU CC if GPUs process the sensitive material
- Step D: Bind KMS/key release to attestation
- Step E: Feed attestation posture into the same governance cadence as device posture
- Step F: Red-team with “assume host compromise” scenarios
If you jump to E without D, you built reporting, not enforcement.
Sources
- NVIDIA: Building a Zero-Trust Architecture for Confidential AI Factories
- NVIDIA: Confidential Computing on H100 GPUs
- Confidential Computing Consortium whitepaper (TEE threat model includes host OS/hypervisor/admins): PDF
- Microsoft technical community material on confidential computing and zero trust (TEE allows treating software outside as untrusted): Azure confidential computing / zero trust PDF discussion
Actionable takeaway
Zero trust without a hardware layer still leaves an implicit trust island: the host and hypervisor. TEEs and attestation extend zero trust principles into data-in-use, which is exactly where modern AI and high-value processing live. Keep identity, segmentation, and continuous evaluation—and stop treating platform privilege as harmless. If secrets can flow before the machine proves what it is, you are still practicing partial zero trust with better branding.