Your enclave trusts more than it can attest.
Attestation proves which code a TEE booted. It says nothing about the firmware that signed it, the keys it can release, or the state it loads at startup. untrust checks all of it, from build to runtime, on AWS, GCP and Azure, GPU clouds, or AMD and NVIDIA hardware in your own racks, in any cloud or on your own hardware.
The hosted console, shown with demo data: one view of the trust boundary from build to runtime.
A path traversal from 1998 defeated a hardware trust boundary
In a real adversarial simulation, a single storage write permission was enough for root code execution inside a hardware-isolated enclave. The attestation was sound. The state the enclave downloaded at boot was not. Every TEE workload receives something from outside the measured image — and none of it is covered by the attestation guarantee.
Gate the build, probe the boundary, watch it run
Scan
Point the CLI at a deployment with the credentials you already have. It reads storage, identity, keys and the enclave host, and writes a report of what passed and what failed.
Pipeline & registry
In your app pipeline, untrust scans every enclave image as it is built. In your infrastructure pipeline, it scans the Terraform plan before apply. It also scans your image registry itself — ECR, GHCR or Artifact Registry — checking that every image is pinned to a digest, signed by someone you trust, and measures what your keys expect. Run it as a step in your deploy pipeline and a failed check stops the deploy.
Probes & fuzzing
An enclave has no network of its own: everything it loads, from S3 state and databases to model weights, arrives through the host and its vsock channel. untrust tests each route. Probes plant harmless canaries in the storage around the enclave and confirm whether they get through. The fuzzer sends malformed input at the host boundary to find what the enclave mishandles, so run it against a staging deployment rather than production. Canary probes ship in the open-source CLI; fuzzing is part of untrust Cloud.
Collect evidence
A small collector on each confidential host answers a fresh challenge with signed hardware evidence. untrust verifies it with AMD or NVIDIA and turns it into findings: firmware below your floor, debug allowed, an unexpected launch measurement. Your cloud accounts are connected with short-lived, read-only access you grant and can revoke.
Detect & govern
Scans are a snapshot; detection never stops. untrust matches cloud audit logs, enclave-host signals and collector reports against its rules every few minutes, and every hit stays open until it is resolved. Release gates turn everything it knows into one go / no-go: production sign-off stays blocked until they pass.
One view of the trust boundary, from build to runtime
A TEE deployment fails long before attestation runs, and long after it passes. untrust follows the workload across its whole lifecycle and keeps the evidence for each stage in one place.
The whole trust boundary on one screen
A single view of every deployment: what is failing, which attack paths are fully open, and what changed since the last report.
Findings are symptoms. Attack paths are the disease.
untrust links failing checks into exploit chains and ranks them by outcome, so you fix the one link that breaks the chain.
See the boundary attestation does not cover
Your deployment drawn as a trust boundary, with every unmeasured input called out and coloured by the checks that cover it.
Catch it in the image, before it is measured
Every enclave image is scanned as CI builds it: generic code flaws plus a TEE overlay for attestation bugs, debug builds, unsafe host input and leaked secrets. A confirmed high finding fails the build.
The image that boots is the image you signed
Every image is resolved to its exact digest, its signature checked against signers you trust, and its measurement matched to the one your keys expect.
Every host's root of trust, judged by the chip vendor
Firmware level, certificate chain and launch measurement for every SEV-SNP host and NVIDIA GPU, verified with AMD and NVIDIA.
Scanning is a snapshot. Detection keeps watching.
Audit logs and host signals are matched against detection rules, and every hit stays open in the console until it is resolved.
Attestation is only as good as the silicon that signs it
An attestation report is a claim from the hardware. untrust checks that the claim holds up: the certificate chain reaches the chip vendor, the firmware is current, the launch measurement is one you released, and debug is off — on every host, continuously, with the vendor's own services as the judge. None of it depends on a cloud provider.
Also covers Azure confidential VMs, through Azure's attestation layer, and NVIDIA H100 GPUs, verified by NVIDIA's attestation service. Intel TDX and SGX quote verification through Intel PCS is not available yet. Checks a collector cannot observe, such as key-broker policy, are reported as not visible rather than passed.
Every major confidential-computing stack, the same report shape
Every check reports PASS / FAIL / SKIP with the evidence it used and concrete remediation. --read-only skips the canary-write probes and host commands. Azure confidential VM and host-attestation support are on the open-source main branch ahead of the next PyPI release. Running your own SEV-SNP or TPM2 hardware? See hardware root of trust.
Nitro Enclaves
Confidential Space
GPU Confidential Computing
Confidential VMs · SEV-SNP
Run it on your laptop, or run it for your whole org
Start with the open-source scanner in minutes. Move to untrust Cloud when a team needs continuous coverage: detections, hardware fleets, release gates and shared evidence.
The open-source scanner, on your machine. Everything you need to audit a deployment yourself.
Everything in the CLI, plus continuous coverage and the workflow a team needs.
Same report format both ways · your reports stay portable
Grounded in real attack paths, not a checklist someone imagined
Every check maps to a way a real misconfiguration has undone a confidential workload — a writable state bucket, a key policy bound to an identity instead of a measurement, an attestation nobody verifies. If a control would not have changed the outcome of a real incident, it is not in untrust.
What untrust will and will not touch
A scan is read-only on request: --read-only skips every write. Canary probes write harmless objects and delete them again, and the fuzzer sends malformed input to find what an enclave mishandles, so both are opt-in and meant for staging. untrust never breaks attestation or ships exploits.
An open-source scanner you can read
The untrust scanner is MIT licensed on GitHub, and every check documents the exact API calls it makes and the IAM permissions it needs. Demo mode runs with no credentials at all — see the report shape before you trust it with anything.
Presented at DEF CON 34
The Enclave Is Lying to You: Breaking TEE Trust Boundaries Through Boot-Time State (August 2026) walks through the adversarial simulation behind untrust: how one storage write permission became root code execution inside an attested enclave.
In research: a TEE security model Not released
We are training an open-weight security model for confidential computing. Given the code, policies and deployment declarations around a TEE, it judges whether the trust boundary holds — attestation binding, nonce freshness, fail-open verification, key release, bootstrap state — and cites the evidence behind each verdict. It is evaluated against a benchmark built from untrust's checks, including prompt-injection cases, and will only become part of untrust once it measurably adds detection.
Proven on real clouds and real chips
Every platform untrust supports has a live lab we deploy in a vulnerable and a hardened posture. Hardware verification is checked against attestation evidence captured from real chips, kept as regression tests that every release must pass.
The real-hardware evidence
Version-5 report signed by the VLEK, chained through AMD's ASVK to the Milan root. Nonce, measurement and TCB floor pinned.
Version-5 report signed by the VCEK, chained through AMD's ASK to the Milan root, with the VCEK supplied by Google.
Quote over PCRs 0–7 and a 38 KB firmware event log that replays to the quoted PCRs, with Secure Boot measured into PCR 7.
Real signed GPU attestation report: vulnerable posture 10 FAIL, hardened posture 14 of 14 PASS, and a live write probe on the weights bucket.
Attestation is necessary. It is not sufficient.
Audit the trust boundaries attestation forgets — in minutes, read-only if you need it.