Confidential Computing Pentest: The GPU Changed, Attestation Did Not
- We ran an autonomous confidential computing pentest against a hostile-host trust boundary: an AMD SEV-SNP confidential VM with an NVIDIA Blackwell GPU in confidential-compute mode. The attacker was the host operator, with root on the hypervisor.
- The encryption held. Guest RAM stayed unreadable, VRAM was scrubbed after teardown, and direct writes to the session-key field were blocked every time. Thirteen defences were documented as working.
- The trust model around it did not. The CPU attestation report and the GPU security state were never cryptographically bound, so the GPU could change mode while the proof stayed identical.
- Numbers: 52 zero-day attack hypotheses, 22 execution tasks, 32 trust invariants tested — 14 violated, 9 held, 6 partially violated — and one validated 9-step chain.
- We’ll be straight about the limits too: this was our own research platform, the findings are sanitized, and none of it means “AMD and NVIDIA are broken.” It means composition is where the proof gets thin.
What a confidential computing pentest actually tests
Confidential computing makes a strong promise. Run your workload on somebody else’s hardware, and the operator of that hardware — the cloud, the colocation provider, whoever holds root on the box — still cannot read your data. The CPU encrypts memory. The GPU encrypts its own. Both sign a statement saying so.
A confidential computing pentest asks the only question that matters about that promise: is the statement true, and does it cover everything you think it covers?
Most security testing never gets near this. It stops at the application — the OWASP Top 10 layer, where the bugs are familiar and the tooling is mature. That work matters. But if the platform underneath your application is lying about its own state, a clean application report tells you almost nothing.
So we pointed an autonomous agent at the platform instead. The target: an AMD SEV-SNP confidential VM with an NVIDIA Blackwell GPU attached in confidential-compute mode, on our own research hardware. The rule: the host is the adversary.
What follows is sanitized. No customer, no environment identifiers, no exploit code. The mechanisms are real, the measurements are real, and we have published the same material openly because we think the finding is more useful shared than hoarded.
Those numbers describe research depth, not scanner volume. Fifty-two hypotheses is not fifty-two vulnerabilities — it is fifty-two distinct theories about how a trust boundary could break, each one written to be provable or disprovable. Twenty-two of them earned a purpose-built execution task.
The threat model was hostile by design
Weak threat models produce comfortable results. We gave the attacker everything the platform is supposed to survive.
The host operator had root on the hypervisor. Device access. Reset control. Full observation of any state the host can see. And critically: no guest cooperation was required at any point. Nothing inside the confidential VM had to be tricked, misconfigured, or persuaded to help.
Run a confidential computing pentest under a weaker model and you get a comfortable report that proves nothing. Against a fully hostile host, five guarantees are supposed to survive: guest memory confidentiality, VRAM protection, device identity integrity, cryptographic session isolation, and truthful attestation. Those are the promises. A confidential computing pentest exists to test them one at a time, under exactly these conditions.
Here’s why that matters commercially. If you are running inference on regulated data, model weights worth more than the servers, or a multi-tenant GPU fleet, the hostile-host model is not paranoia. It is your actual deployment. You chose confidential computing precisely because you did not want to trust the operator.
AMD SEV-SNP and NVIDIA Blackwell: two trust domains, one missing binding
The architecture has a seam in it, and the seam is where we spent most of the engagement.
On one side: the CPU trust domain. AMD SEV-SNP runs the confidential VM and produces an attestation report — a signed statement about the VM’s launch measurement and platform state.
On the other: the GPU trust domain. The NVIDIA Blackwell GPU maintains its own security state, its own firmware, and an SPDM session for device authentication — its own GPU attestation, entirely separate from the CPU’s.
Between them: VFIO, PCIe, and SPDM — all of it mediated by QEMU/KVM and the IOMMU, which is to say, mediated by the host we just declared hostile.
Two attested parties. One transport. And no cryptographic binding between their security states. The CPU report is silent about the GPU. The GPU’s session says nothing about which VM it belongs to. Each proof is individually sound and jointly incomplete.
Finding that seam is most of the value of a confidential computing pentest. That gap is not a coding mistake. It is a composition problem, and it is genuinely hard — the industry knows it, which is why work on layered and composite attestation continues. But “known hard” is not the same as “handled in your deployment,” and a confidential computing pentest is how you find out which one you have.
What our confidential computing pentest found
Let’s start with what worked, because a test that only reports failures is marketing, not research.
The defences that held
Encrypted guest memory did its job. With root on the hypervisor and every tool we could point at it, host-side reads of guest RAM produced nothing usable. SEV-SNP held.
VRAM was scrubbed after VM destruction. We looked for workload remnants across teardown cycles and recovered none. The scrubber works.
Byte-level FSP field protection held under repeated attack. When we tried to write directly into the session-key field, the write was rejected — consistently, not occasionally. That is a real control doing real work.
CPU TEE isolation held. Enclave boundaries stayed intact and host visibility into the enclave stayed at zero, by design and in practice.
In total, our confidential computing pentest documented 13 positive defences. In our experience that half of the report is the half clients reread, because it tells them which controls they can actually rely on when someone asks.
What the NVIDIA GPU control plane exposed
Now the uncomfortable half. The data plane was never the weak point — the control plane was.
The host did not need to break encrypted guest RAM or recover VRAM canaries. Sensitive GPU control-plane state was reachable underneath the data plane: SPDM session material including keys and transcripts, protocol staging buffers containing cleartext metadata and nonces, and live GSP firmware state exposing task queues, scheduler context, and runtime policy decisions.
Read together, that material is enough to reason about device attestation impersonation and trust-chain forgery. Not because the cryptography was weak, but because the state that the cryptography depends on was sitting somewhere the adversary could reach.
The NVIDIA GPU changed mode. GPU attestation did not blink.
This is the finding that named the research, and it is the one worth understanding even if you never buy a confidential computing pentest from anyone.
The NVIDIA GPU was in confidential-compute mode, with the guest running. From the host, the device was moved through a weaker debug state and then returned to confidential-compute mode. Throughout all of it, the guest kept running.
Three things happened during that window. GSP firmware state became visible. Session state remained. And the VM never reported an error.
Meanwhile, the AMD SEV-SNP attestation report was unchanged. Not stale, not suspicious — identical, and legitimately so, because CPU attestation was never designed to carry GPU attestation evidence, and the GPU’s mode was never in scope for it.
This is precisely the class of gap a confidential computing pentest exists to surface. The security posture changed without changing the proof. If your policy engine is admitting workloads based on that proof, it admitted a machine whose GPU had just taken a detour through a weaker state, and it had no way to know.
The agent surfaced this by differential analysis: capture a clean state, capture a manipulated one, and compare until the hidden boundary becomes visible. The mode flipped from confidential to standard. The attestation algorithm went from SNP to none. The measurement length dropped from 48 to zero. Certificate data lost its issuer and its signature. The signal was never in a single reading — it was in the delta.
Nine steps, four trust failures
Individual primitives are interesting. Chained primitives are what an actual adversary does, and a confidential computing pentest that stops at isolated findings never shows you the compound impact.
Late in the engagement, the agent audited its own coverage and did something we did not ask for: it flagged that no test had ever exercised a realistic multi-stage sequence across components, and no test had validated that the system’s invariants held under adversarial combinations. It then wrote those two tests itself and ran them.
Six confirmed primitives were connected into one controlled, timestamped operation, with before-and-after evidence captured and the environment fully restored afterwards. Confidentiality broken. Integrity compromised. Attestation misleading. Persistence achieved. Executed and validated end to end — not sketched on a whiteboard.
One step deserves its own note. During GPU function-level reset recovery, the agent detected the control plane coming back and immediately attempted protocol-data injection. The window was 100.6 milliseconds. Of eight injection attempts, three were fully accepted and processed without rejection, three remained active for at least 30 seconds, and five were partially blocked by controls that did fire.
A hundred milliseconds is not a window a human tester hits by hand. That is the honest argument for autonomy here — not that the machine is smarter, but that it is awake at the right microsecond and never gets bored waiting for one.
The workload ended. The session state did not.
The lifecycle finding is the one with the clearest multi-tenant consequence, so it gets its own section.
Tenant A establishes an SPDM session and trust bindings. Tenant A’s VM is destroyed. The GPU goes idle. Then, before tenant B is provisioned, we looked at what was still there.
The data plane was clean. VRAM had been scrubbed, exactly as designed.
The control plane was not. SPDM session material — keys, certificates, transcripts — remained resident. BAR0-exposed context and trust registers were retained. We measured the same pattern across three separate lifecycle events: confidential-compute mode transition, function-level reset, and full VM destruction. In all three, session state persisted while the data plane was correctly scrubbed.
Wiping the data is not the same as retiring the trust, and only a confidential computing pentest that spans lifecycle events will tell you which one your platform does. If the trust state that identified tenant A is still resident when tenant B arrives, the boundary between them is thinner than the architecture diagram suggests.
Why a scanner cannot run a confidential computing pentest
Every finding a confidential computing pentest of this kind produces shares one property: no signature would have caught it.
There is no CVE for “these two attestation reports are individually valid and jointly meaningless.” No plugin fires when a GPU changes mode and the proof stays constant. No scanner knows that the session key surviving VM destruction is a problem, because a scanner does not carry a model of what the lifecycle was supposed to guarantee.
What this work needed was a hypothesis, a way to test it, and the discipline to discard it when the evidence disagreed. At one point the agent assumed an entire GPU memory range was sensitive and persistent, and rated its own confidence as high. Testing proved it wrong. Only part of the range persisted; another part was protected and inaccessible; a third showed no signal at all. The agent narrowed its claim, restated its confidence as moderate, and said so explicitly in the output.
That is the behaviour we care about most. Autonomy that only ever confirms itself is a false-positive generator with good marketing. Autonomy becomes trustworthy at the moment it can prove it was wrong — the same reason time-boxed manual testing misses whole classes of bug that only surface when something reasons about state across thousands of iterations.
How SelfHack AI runs a confidential computing pentest
Our confidential computing pentest methodology starts from an admission: there was no predefined attack path. The chain was discovered, not supplied.
The loop is simple to describe and hard to do well. Map the surfaces that can influence trust. Generate diverse hypotheses about how a boundary could break. Build a safe, isolated test for each one. Compare expected state against actual state. Self-correct when the evidence disagrees. Chain what survives. Then expand coverage into whatever the evidence just opened up.
For this engagement that meant mapping the NVIDIA GPU control surfaces that could affect trust without ever defeating encrypted workload memory: BAR0 MMIO, SPDM session state, the GSP firmware region, and FSP-protected fields. The GPU data plane stayed encrypted and out of scope. We did not chase the data first. We mapped trust first.
Firmware and platform integrity are not new concerns — NIST SP 800-193 has been telling people to protect, detect and recover platform firmware for years, and NIST’s work on hardware roots of trust points the same direction. What changes with confidential computing is that the platform is now the thing you are supposed to be able to prove to a third party. Proof raises the bar on measurement.
The same autonomous approach is what we bring to LLM and AI application testing and to everything you expose to the internet. The surfaces differ. The method — hypothesise, test, falsify, chain — does not.
Give any agentic pentesting system the same hostile-host threat model. No web application. No deliberately vulnerable benchmark. No predefined attack path. Ask it to test the CPU TEE, GPU confidential compute, firmware, hypervisor, SPDM, attestation and key lifecycle — then require it to prove what held, correct its own false positives, identify its coverage gaps, build one end-to-end chain, and restore the environment. Autonomy should be demonstrated at depth, not asserted in a datasheet. We published our numbers; we would genuinely like to compare.
How to scope a confidential computing pentest
If you are buying a confidential computing pentest, the scope document decides whether you learn anything. A few things we would insist on.
Name the adversary, not just the asset
“Test our confidential VM” is not a threat model. “Assume the host operator is hostile, has root on the hypervisor, controls reset and the IOMMU, and receives no cooperation from the guest” is. Every finding in this article depends on that sentence being in the scope.
Put the control plane in scope explicitly
If the scope says “GPU,” a lot of testers will read that as the data plane and stop. Say BAR0 MMIO, SPDM session state, firmware regions and protected fields out loud. The interesting failures live there.
Include lifecycle events, not just steady state
Mode transitions, function-level resets and VM destruction are where guarantees quietly stop applying. A confidential computing pentest that only tests a running system misses the remanence question entirely — and in a multi-tenant fleet, remanence is the finding that matters most.
Demand the negative results
Ask for the list of controls that held, with evidence. A report that is all findings and no defences is a report that stopped looking once it had enough to sell you something.
Require restoration and evidence
Before-and-after captures, timestamps, and a restored environment. If a chain cannot be replayed and cleaned up, it cannot be verified either.
FAQ — confidential computing pentest
Does this mean AMD SEV-SNP or NVIDIA confidential computing is broken?
No, and we would push back on anyone who summarised it that way. Both vendors’ core protections held under a fully hostile host: memory encryption, VRAM scrubbing, field-level write protection and TEE isolation all did what they claim. The gap we measured is in composition — two separately attested domains with no cryptographic binding between their security states, mediated by a host you do not trust. That is an architecture problem the whole industry is working on, and it happens to be invisible unless someone tests for it.
How is this different from a normal cloud or infrastructure pentest?
A normal engagement assumes the platform is trustworthy and hunts for misconfigurations above it. A confidential computing pentest inverts that: the platform is the target, the operator is the attacker, and the question is whether the cryptographic promises survive. Different threat model, different surfaces, completely different findings.
Do you need physical access to the hardware?
No. Everything described here was done from the host software layer — hypervisor root, device access and reset control. That is deliberate, because it mirrors the realistic case: a compromised or malicious cloud operator, or an attacker who has already reached the host. Physical attacks are a separate discipline with a separate threat model.
Can you run this against our production GPU cloud?
Usually not as-is, and we will say so early. A full hostile-host confidential computing pentest requires host-level control, which most tenants do not have and most providers will not grant. What we can do is test the layers you do control, review the attestation policy your workloads actually enforce, and run the full hostile-host assessment against a representative platform you own or can stand up. Scoping that honestly is the first conversation, not the last.
What should we fix first if we run GPU workloads on shared infrastructure?
Start with what your admission policy actually verifies. Most teams check that an attestation report is valid and stop there. Ask whether it covers the accelerator’s security state, whether your policy would notice a mode change, and whether session material is rotated or zeroised at lifecycle boundaries rather than left resident. Those three questions cover the majority of what we found.
Does NVIDIA confidential computing protect model weights from the cloud provider?
It is designed to, and the encryption side of that held in our testing — the host could not read guest memory or recover VRAM contents after teardown. The caveat is what sits around it. NVIDIA GPU attestation and AMD SEV-SNP attestation are produced separately, and if nothing binds them, a verifier can hold a valid CPU report while the GPU beneath it has changed state. For model weights specifically, that means the encryption is probably fine and the admission decision is the part worth auditing.
What is GPU attestation and why does it matter here?
GPU attestation is the accelerator’s own signed statement about its identity, firmware and security mode — the GPU equivalent of the CPU’s attestation report. It matters because the two are independent. A verifier that only checks CPU attestation learns nothing about whether the GPU is even in confidential-compute mode, which is precisely the gap this research measured.
Is 52 zero-day attack hypotheses the same as 52 vulnerabilities?
It is not, and we are careful about the wording for exactly that reason. A hypothesis is an original, testable theory about how trust could break — generated by the agent, not pulled from a database, and not observed in the wild. Twenty-two became execution tasks. A smaller number became validated findings. Anyone quoting the 52 as a vulnerability count is misreading it.
Where this leaves you
Confidential computing is a real advance, and nothing here argues otherwise. The encryption works. The scrubbing works. The isolation works. We tested all three adversarially and they held.
What our confidential computing pentest found is that the guarantees are uneven. Of 32 trust invariants, 14 were violated, 9 held cleanly, 6 were partially violated, and 3 did not apply. Security was not simply broken — it was patchy in ways nobody had measured, because measuring it requires someone to state each promise out loud and then genuinely try to violate it.
Four root causes sit underneath everything above: control-plane state reachable from a hostile host, session material that is not consistently rotated or zeroised across state transitions, modified protocol state that is not fully re-validated after setup or reset, and CPU attestation that never measured the complete GPU security state. Patching any one finding does not repair a trust chain with those properties.
The practical takeaway is smaller than the research and more useful. If you run confidential workloads, find out whether your policy verifies GPU attestation at all, and what that attestation actually covers. Not what the datasheet implies — what the policy verifies, on your hardware, when someone is trying to move the parts it does not measure. If you have never checked, the honest answer is that you do not know.
That is the entire argument for a confidential computing pentest: application testing is not enough when the thing making the security claim is the thing you need to verify. We test whether “secure” is actually true — beyond the application, into the root of trust.
Want this depth against your platform?
SelfHack AI runs autonomous, evidence-driven security research against the boundaries your application testing never reaches — confidential compute, firmware, attestation and key lifecycle included. Tell us what you run and what you are required to prove about it, and we will tell you honestly whether a confidential computing pentest is the right engagement. Talk to us →
Sources and further reading: NIST SP 800-193 — Platform Firmware Resiliency Guidelines · NIST — Hardware Roots of Trust · OWASP Top 10 · NIST SP 1800-19 — Trusted Cloud · Confidential Computing Consortium. Related SelfHack research: AI pentest benchmark 2026 · connected vehicle pentest · blockchain pentest.
