[Design Issue]Current hardware attestation design does not provide additional integrity guarentee: the manifest hash is guest-supplied and never measured by the TEE

[QinyuanWu]

Hello Opaque team! I attended the Confidential Computing Summit 2026 and was super excited about this project launch after hearing the keynote, especially given it's open source ☺️ As a security professional I strongly agree that AI agent transparency and governance is a critical blocker for AI adoption in enterprises and solutions are urgently needed. I was especially intrigued by Opaque's solution of leveraging TPM/SEV-SNP/TDX hardware to provide additional security guarentees on the agent manifest so I took a close look at the current(Commit b8ad1f9) documentation and code. I did find concerning evidence that the current hardware attestation solution does not match what was promised, and with the help of my agent I've put together the following report.

Executive Summary

The hardware-attestation design in Agent Manifest rests on a fundamental misunderstanding of what TEE attestation hardware does. SEV-SNP, TDX, and TPM measured boot attest the boot-time firmware/launch state of a confidential VM and protect guest memory against the host. They cannot measure or protect the integrity of individual files, policy documents, or in-memory objects after the guest has booted.

By computing SHA-256(manifest.json) in guest software and placing it in a caller-controlled report field (REPORT_DATA, a runtime RTMR/PCR extend, or TPM qualifying data), the project asks the hardware to sign back a value the guest itself supplied. The hardware never inspects the file. The list of issues include:

• The manifest-hash extension provides no integrity guarantee about the agent's artifacts beyond "booted on trusted firmware" and "memory encrypted against the host" — both of which a confidential VM already provides for free.
• The "freshness proof" (attest_runtime_state()) does not detect a compromised agent, because the compromised component is the one reporting its own state. It is self-attestation.
• Attestation Level 3 (OPAQUE) actually provides the least benefit: it performs the "attestation" on a remote machine that never runs the agent. The TRACE claim attests OPAQUE's service, not the agent's environment; there is no hardware measurement of the actual manifest or of the agent at all; the claim's tee_platform field misattributes OPAQUE's silicon to the agent; and the SDK never even verifies the claim's signature. Marketing this as the "highest assurance level" is the opposite of reality — it is the weakest binding to the agent.
• The documentation contains an outright factual error (HOST_DATA is host-supplied and cannot be written by the guest), the per-platform profiles are mutually inconsistent, and the code paths were demonstrably never run against real hardware (fabricated SNP IOCTL number and ABI, wrong report offsets, an RTMR extend that is documented but never performed, a TDREPORT mistaken for a Quote, and verification routines that check no hardware signature at all).

Looking forward, I strongly suggest the team to read this article Why Should I Trust Your Code? and understand the scope of hardware attestation and how additional software services such as code transparency can bring significant value to auditability and trust in the agent workload.

---

Contents

• 1. What the project claims to be
  • The specific security claims made
  • Dream vs Reality
• 2. The fundamental misunderstanding
• 3. Documentation-level errors
  • 3.1 SEV-SNP HOST_DATA is host-supplied, not guest-supplied (C4) — factually wrong
  • 3.2 The core logical error: hashing a file and echoing it proves nothing about the file (C1, C6)
  • 3.3 TPM/PCR claim is the same error (C6)
  • 3.4 "Impossible controls" is an overstatement (C3)
  • 3.5 Inconsistent and unsupported per-platform profiles (C5)
  • 3.6 The "freshness proof" does not detect runtime compromise (C7) — self-contradiction
  • 3.7 "Strongest locally-verifiable hardware guarantee" (C8) is unverifiable as shipped
• 4. Code-level errors in python/src/agent_manifest
  • 4.1 SEV-SNP: wrong field, wrong offsets (_hw_providers.py)
  • 4.2 SEV-SNP: the IOCTL ABI is fabricated
  • 4.3 TDX: claims an RTMR extend that never happens
  • 4.4 No report is ever cryptographically verified — verify_manifest_in_report is hollow
  • 4.5 verify_runtime_report checks software arithmetic, not hardware (_verify.py:549)
  • 4.6 TDX returns a TDREPORT, which is not remotely verifiable
  • 4.7 Runtime-attestation SNP path repeats the HOST_DATA confusion
• 5. Level 3 (OPAQUE managed TEE): attestation runs on the wrong machine
  • 5.1 The TEE that signs the report is not the TEE the agent runs in
  • 5.2 "Measures it in silicon" is false
  • 5.3 The TRACE claim's tee_platform is misleading
  • 5.4 The SDK never verifies the TRACE claim
  • 5.5 Violation of the project's "non-self-attestation" principle
• 6. Where to go from here

---

1. What the project claims to be

Agent Manifest's stated goal is to close what the spec calls the "attestation gap": the inability to prove, to a third party who does not trust the operator, that the agent running right now is the agent that was approved — the same system prompt, policy bundle, tool schemas, model, RAG corpus, memory, decision trace, delegation chain, supply-chain provenance, and human-in-the-loop records.

The project binds these ten artifacts into a single JSON manifest, hashes it, signs it (Ed25519), and — for "Level 1+" conformance — extends that manifest hash into a hardware Trusted Execution Environment (TEE) so the binding is "hardware-rooted" and "tamper-evident." The headline pitch is "Prove what your agent was, not just who called it."

The specific security claims made

#	Claim	Source
C1	A verifier "can prove, without trusting the operator, that a specific agent instance ran specific code under specific policy with specific tools, produced specific decisions."	spec §Abstract
C2	Hardware attestation defeats: replacing the system prompt in memory after signing, swapping the model at runtime, silently extending tools, injecting into RAG without changing the hash, forging HITL records.	spec §1.2
C3	"Software-signed manifests are tedious controls… Hardware-attested manifests are impossible controls — the measurement happens in silicon before any user code runs."	spec §1.2
C4	SEV-SNP: the manifest hash is carried in the HOST_DATA field, "purpose-built for guest-supplied data."	spec §3.3.1, hardware-attestation.md, _hw_providers.py
C5	TDX: the manifest hash is "extended into RTMR[1]" (tutorial/code) / RTMR[3] (spec) using TDG.MR.RTMR.EXTEND.	spec §3.3.1, tutorial, _hw_providers.py
C6	TPM: extending the manifest hash into a PCR "ensures the PCR value is deterministically bound to the exact manifest that was approved."	_providers.py
C7	attest_runtime_state() produces a freshness proof that detects an attacker who "compromises the agent process after startup (modifying the system prompt in memory, swapping the policy bundle, injecting a tool)."	ADR-0010, LIMITATIONS.md, tutorial
C8	"Level 2 provides the strongest locally-verifiable hardware guarantee."	tutorial

Every one of C1–C8 rests on the same assumption — that placing a guest-computed hash into a TEE report makes the contents of individual files hardware-attested. That assumption is incorrect, and it propagates into both the documentation and the code.

Dream vs Reality

Property	Claimed by project	Actually provided
VM booted on genuine, unmodified platform firmware	✅	✅ (this is automatically achieved by launching a CVM)
Guest memory confidential/integrity-protected vs. host	✅	✅ (also the CVM baseline)
Manifest file contents measured by hardware	✅ (C1, C4–C6)	❌ hardware only echoes a guest-supplied digest
Detects system prompt/policy/tool modified in memory after boot	✅ (C2, C7)	❌ hash is self-reported; a compromised guest can forge a good hash
Report is cryptographically verifiable by a third party	✅ (C8)	❌ no signature/VCEK/quote verification in the SDK
"Hardware-attested manifests are Impossible controls"	✅ (C3)	❌ manifeset hash is controlled by the guest code not the hardware
Level 3 (OPAQUE) is the "highest assurance" binding	✅	❌ attestation runs on a different machine that never sees the agent (see section 6)

---

2. The fundamental misunderstanding

TEE attestation measures the boot-time launch state of the VM (firmware, loader, kernel/initrd image) and provides confidentiality + integrity of guest memory against the host. It does not measure, hash, or protect the integrity of individual application files, in-memory objects, or policy documents after the guest has booted.

Two distinct mechanisms get conflated throughout this project:

1. Hardware-rooted measurement (MEASUREMENT on SNP, MRTD on TDX, PCR0–7 on a measured-boot TPM). The firmware/hardware computes these over code before that code is allowed to run — the measurer is more privileged than the measured. This is what makes the value trustworthy.

2. Guest-supplied report fields (REPORT_DATA, the TPM "qualifying data", a runtime RTMR extend, or tpm2_extend into PCR15). Here the guest itself hands the hardware some bytes, and the hardware faithfully echoes them back, signed. The hardware performs no inspection of what those bytes represent.

Agent Manifest puts the manifest hash into guest-supplied report fields and then markets it as if it had the properties of hardware-rooted measurement. The hardware never opens manifest.json, never reads the system prompt, never parses the Cedar policy. It signs back exactly the 32 bytes the guest process chose to submit.

Consequence: the only things the TEE actually attests are (a) the VM booted on genuine, unmodified platform firmware, and (b) guest memory is encrypted/integrity-protected against the host. Both of those are provided automatically by any SEV-SNP or TDX confidential VM the moment you launch it — with or without this project(check out AMD SEV-SNP white paper and Intel TDX white paper for their security promises). The manifest-hash extension adds no hardware-verified guarantee about the agent's files on top of the CVM baseline.

---

3. Documentation-level errors

3.1 SEV-SNP HOST_DATA is host-supplied, not guest-supplied (C4) — factually wrong

The docs and spec state the manifest hash is placed in HOST_DATA:

• docs/tutorials/hardware-attestation.md:59: "places the 32-byte digest in the first half of the HOST_DATA field… HOST_DATA is 64 bytes reserved for user-defined binding data."
• spec §3.3.1: "manifest_hash_in_report is extended into the HOST_DATA field… (32 bytes, purpose-built for guest-supplied data)."
• _hw_providers.py:8 docstring: "HOST_DATA is a 64-byte field specifically reserved for user-defined data — ideal for binding a manifest hash."

This is wrong on multiple counts:

1. HOST_DATA is supplied by the hypervisor/host, not the guest. It is set once, at VM launch, through SNP_LAUNCH_FINISH. A guest running inside the VM cannot write it. Its entire purpose is to let the host bind launch-time data the guest can read but not forge — the opposite of what the docs claim. Reference: AMD SEV-SNP Firmware ABI Specification (#56860)
2. It is 32 bytes, not 64. The docs variously call it 64 bytes and talk about "the first half." (ABI #56860, ATTESTATION_REPORT structure.)
3. The field a guest actually controls is REPORT_DATA (64 bytes), populated from the user_data member of the report request — see the Linux SEV guest API docs. If you want a guest to bind a value into an SNP report, REPORT_DATA is the field — not HOST_DATA.

3.2 The core logical error: hashing a file and echoing it proves nothing about the file (C1, C6)

Placing SHA-256(manifest.json) into REPORT_DATA/RTMR/a PCR does not cause the hardware to measure the manifest. The guest computes the digest in ordinary software and hands it to the hardware, which signs it back. A verifier therefore learns only:

"Some software running inside this TEE asserted that the manifest hash is X."

It does not learn that the agent is actually running the artifacts that hash to X. If the guest software is buggy or compromised, it can submit the digest of a known-good manifest while loading a completely different system prompt and policy. The signed report is identical in both cases. There is no additional security value beyond "booted on trusted firmware, memory encrypted against the host" — which, again, the CVM already gives you.

This directly refutes claim C2: "replace a system prompt in memory after the manifest is signed" is listed as an attack hardware attestation supposedly makes impossible. It does not. The boot measurement covers the launch image, not the live in-memory prompt; and the manifest-hash field is whatever the (possibly compromised) process chose to write.

3.3 TPM/PCR claim is the same error (C6)

_providers.py:230 claims extending the digest into PCR15 "ensures the PCR value is deterministically bound to the exact manifest that was approved." A PCR extend of an application-computed digest binds nothing about the file at runtime. This is fundamentally different from measured boot, where each stage measures the next stage into a PCR before transferring control — there the measurer is more trusted than the measured (see the TCG PC Client Platform Firmware Profile Specification). Here the application measures itself: an attacker who has modified the policy file simply calls tpm2_extend with the good hash and proceeds to run the bad policy. PCR15 then contains the "approved" value while the agent runs unapproved state.

3.4 "Impossible controls" is an overstatement (C3)

spec §1.2's claim that hardware-attested manifests are "impossible controls" because "the measurement happens in silicon before any user code runs" conflates the firmware launch measurement (which does happen before user code) with the manifest-hash extension (which happens in user code, at or after startup, via an IOCTL/CLI the agent itself invokes). The manifest hash is precisely a control that runs as user code, so it inherits exactly the "determined operator rewrites them" weakness as software signing.

3.5 Inconsistent and unsupported per-platform profiles (C5)

The TDX target register is specified three different ways:

• spec section 3.3.1: RTMR[3]
• docs/tutorials/hardware-attestation.md:111 and code RTMR_INDEX = 1: RTMR[1]
• spec section 3.3.1 also says TDX measurement is SHA-384/MRTD, while the TPM profile demands SHA-384 PCRs but the code extends the SHA-256 bank (-g=sha256).

More importantly, the code never extends any RTMR at all (see section 4.3) — so the documented RTMR[1]/RTMR[3] mechanism does not exist in the implementation regardless of which index is "correct." (RTMR extension is a distinct operation — TDG.MR.RTMR.EXTEND, exposed as the TDX_CMD_EXTEND_RTMR ioctl — per the Linux TDX guest API docs and Intel TDX white paper.)

3.6 The "freshness proof" does not detect runtime compromise (C7) — self-contradiction

LIMITATIONS.md:60-62 correctly admits boot-time attestation cannot detect "an attacker who compromises the agent process after startup (modifying the system prompt in memory, swapping the policy bundle, injecting a tool)." It then claims (lines 64-80, and ADR-0010) that attest_runtime_state(nonce, context_hash) closes exactly that gap by proving "context_hash covers the live system prompt, policy, and tool catalog."

It does not, and the reasoning is identical to section 3.2:

• context_hash is computed by the agent process itself (compute_context_hash() runs in the guest).
• The hardware sets its caller-controlled field to sha256(nonce || context_hash) and signs it. The hardware never reads the live prompt/policy — it signs the bytes handed to it.
• A compromised process supplies the good context_hash while running modified state. The nonce only proves the report is fresh (not replayed); it proves nothing about whether context_hash reflects reality.

So attest_runtime_state() is self-attestation: the same untrusted component that may be compromised is the one reporting that it is healthy. The document admits the boot attestation can't catch in-memory tampering, then offers a "freshness proof" that can't either — for the same reason.

3.7 "Strongest locally-verifiable hardware guarantee" (C8) is unverifiable as shipped

The tutorial markets Level 2 as the "strongest locally-verifiable hardware guarantee," yet the SDK never verifies the hardware signature or certificate chain of any report (see section 4.4). A guarantee you cannot verify is not a guarantee; it is an assertion.

---

4. Code-level errors in python/src/agent_manifest

These confirm the conceptual problems above and additionally show the hardware paths were never exercised against real silicon.

4.1 SEV-SNP: wrong field, wrong offsets (_hw_providers.py)

user_data = digest + bytes(32)            # placed in the request's user_data
...
"host_data": self._report_bytes[0x140:0x180].hex(),   # get_attestation_report
actual = self._report_bytes[0x140:0x140 + 32].hex()   # verify_manifest_in_report

In the SNP attestation report ABI the field offsets are (per the AMD SEV-SNP Firmware ABI Specification (#56860), ATTESTATION_REPORT table):

Field	Offset	Who writes it
REPORT_DATA (64)	0x050	guest (user_data in the request)
MEASUREMENT (48)	0x090	firmware
HOST_DATA (32)	0x0C0	hypervisor
REPORT_ID (32)	0x140	firmware
REPORT_ID_MA (32)	0x160	firmware

So the code:

• Writes the digest into user_data, which the firmware copies to REPORT_DATA (0x050) — not HOST_DATA (and the guest could not write HOST_DATA even if it tried).
• Then reads back offset 0x140, calls it "host_data", and compares the manifest hash against it. 0x140 is REPORT_ID — neither the real HOST_DATA (0x0C0) nor the field where the digest actually landed (0x050). The round-trip assert verify_manifest_in_report(...) in the tutorial would never pass against a real report.

4.2 SEV-SNP: the IOCTL ABI is fabricated

_SNP_REPORT_IOCTL = 0xC0A00300  # claims _IOWR('s', 0, snp_report_req)
...
buf = bytearray(4096)
fcntl.ioctl(dev, _SNP_REPORT_IOCTL, buf)
self._report_bytes = bytes(buf)        # expects the report in-place

Decoding 0xC0A00300 gives type=0x03, size=160 — it is not 'S'-typed. The real SNP_GET_REPORT is _IOWR('S', 0x0, struct snp_guest_request_ioctl) = 0xC0285300 (type 'S', size 40). Furthermore the real ABI passes a struct snp_guest_request_ioctl containing pointers (req_data, resp_data) to separate request/response buffers; the kernel does not read/write the report in place in a single 4 KB buffer. And the response is wrapped in a header (status u32, report_size u32, 24 reserved bytes) so the report begins at offset 0x20 of the response, meaning even the MEASUREMENT read at 0x90 would be off by 0x20. This code cannot have run successfully on an SEV-SNP guest. (ABI per the Linux SEV guest API docs, which define struct snp_guest_request_ioctl with req_data/resp_data and struct snp_report_resp carrying the report inside data.)

4.3 TDX: claims an RTMR extend that never happens

The class docstring and tutorial say the provider "extends the manifest hash into RTMR[1] using TDG.MR.RTMR.EXTEND." The implementation does no such thing — it only places the digest in reportdata and issues TDX_CMD_GET_REPORT:

reportdata = digest + bytes(32)
buf = bytearray(1088)
buf[:64] = reportdata          # only REPORTDATA is set; no RTMR extend issued

An RTMR extend requires a separate TDX_CMD_EXTEND_RTMR IOCTL, which is never called. So the entire "RTMR[1] application measurement" narrative (and the RTMR-index guidance table in the tutorial) describes behavior the code does not implement. What it actually does is the REPORT_DATA-echo pattern of section 3.2 — with the same lack of guarantee.

4.4 No report is ever cryptographically verified — verify_manifest_in_report is hollow

• SEV-SNP/TDX: vcek_cert_chain_verified is hard-coded False and the signature is never checked. require_vcek_verification=True simply raises AttestationUnavailableError("not yet implemented") — so you literally cannot obtain a verified report; the only non-raising path is the unverified one (with a warnings.warn). Because nothing authenticates the report bytes, an attacker can fabricate an entire report blob and verify_manifest_in_report() will still pass. Level 2 is unattainable with the shipped code, despite being marketed as the strongest local guarantee. (Authenticating an SNP report means fetching the per-chip VCEK from AMD's KDS and chaining it to the AMD root — see the AMD VCEK Certificate and KDS Interface Specification)
• TPM: verify_manifest_in_report (_providers.py:283) does no PCR replay and no quote signature check. It computes the manifest hash and compares it to itself (report.manifest_hash == self.manifest_hash_value(manifest_json)) — a tautology that is True for any well-formed manifest, regardless of what the TPM contains. The docstring even concedes "a full PCR replay verification requires the pre-extension PCR value, which callers must supply" — i.e., the actual verification is left unimplemented.

4.5 verify_runtime_report checks software arithmetic, not hardware (_verify.py:549)

qualifying = hashlib.sha256(nonce + ctx_bytes).digest()
expected = "sha256:" + hashlib.sha256(qualifying).hexdigest()
return hmac.compare_digest(report.report_data_hash, expected)

This recomputes sha256(sha256(nonce || context)) in pure software and compares it to a field the report carries. It verifies no hardware signature (the docstring admits this). An attacker can hand-construct a RuntimeAttestationReport with matching fields and it returns True. Combined with section 3.6, the "freshness proof" provides zero hardware assurance: the state value is self-reported and the report itself is unauthenticated.

4.6 TDX returns a TDREPORT, which is not remotely verifiable

get_attestation_report() returns the raw TDREPORT produced by TDX_CMD_GET_REPORT. A TDREPORT is a locally MAC'd structure intended to be exchanged with the on-platform TD-Quoting Enclave to obtain a signed, remotely-verifiable Quote. The SDK never performs that conversion. Shipping a TDREPORT to a remote relying party gives them an artifact they cannot verify — it is only checkable by the local platform that holds the MAC key. (The TDREPORT → Quote flow and the role of the integrity-protecting MAC are documented in the Linux TDX guest API docs and Intel's Runtime Integrity Measurement and Attestation in a Trust Domain.)

4.7 Runtime-attestation SNP path repeats the HOST_DATA confusion

attest_runtime_state() writes qualifying into user_data (→ REPORT_DATA) but the returned dataclass again labels offset 0x140:0x180 as "host_data" (section 4.1). The naming and the field are inconsistent with each other and with the hardware.

---

5. Level 3 (OPAQUE managed TEE): attestation runs on the wrong machine

Level 3 is marketed as the top of the assurance ladder:

• tutorial table (hardware-attestation.md:42-44): "OPAQUEProvider | Any — delegates to OPAQUE's managed TEE… Level 3 adds a hardware-signed audit chain managed by OPAQUE inside their TEE."
• _hw_providers.py:333-341 docstring: the service "Accepts the manifest pre-image, Measures it in silicon (AMD SEV-SNP or Intel TDX), Returns a TRACE claim with hardware-signed audit_chain_root. The signing key never leaves the TEE — this is the highest assurance level."
• docs/index.md:60 ranks OPAQUE assurance as "Highest."

This is backwards. Level 3 is the weakest binding to the agent, not the strongest, and the TRACE claim it produces is meaningless as a proof about the agent.

5.1 The TEE that signs the report is not the TEE the agent runs in

The defining feature of Level 3 is "No local hardware is required" (hardware-attestation.md:144). The agent runs wherever the operator deploys it — a general purpose VM, a container, a developer laptop. extend_manifest_hash() then does this:

pre = self.manifest_pre_image(manifest_json)
digest = hashlib.sha256(pre).hexdigest()          # hashed in plain software, locally
...
response = httpx.post(f"{self._url}/v1/attest",
                      json={"manifest_pre_image": base64.b64encode(pre).decode()}, ...)
self._trace_claim = response.json()               # whatever the URL returns

The agent serialises its manifest, hashes it in ordinary local software, and POSTs the bytes over HTTPS to a remote OPAQUE service. That remote service's TEE receives a blob of bytes over a socket and signs a claim about them. It has no visibility whatsoever into the machine the agent is actually running on — it cannot see the agent's memory, its loaded system prompt, its policy, or its process. It is measuring an HTTP request body, on a different computer.

A TEE attestation is only meaningful for the workload inside that TEE. Here the workload inside OPAQUE's TEE is "an HTTP handler that hashes a request and signs it" — not the agent. So the TRACE claim attests OPAQUE's own service, and tells a verifier nothing about where or how the agent ran. Extending "the manifest hash" to a remote box does not measure the manifest's execution environment; it just relocates the section 3.2 echo problem onto a third party that is even further removed from the agent than the agent's own process was.

5.2 "Measures it in silicon" is false

The docstring's step 2 — "Measures it in silicon (AMD SEV-SNP or Intel TDX)" — does not describe a hardware measurement. A hardware launch measurement (MEASUREMENT/MRTD) is computed by firmware over code before that code executes, on the machine that will run it. What happens here is a remote web service calling sha256() on a request body inside a TEE. Running a software hash inside an enclave does not make its input hardware-measured; the input is attacker/operator-supplied data that arrived over the network. There is no hardware measurement of the actual manifest, and none of the agent.

5.3 The TRACE claim's tee_platform is misleading

The sample TRACE claim (hardware-attestation.md:175-184) contains:

{ "manifest_hash": "...", "audit_chain_root": "...", "tee_platform": "amd-sev-snp", ... }

tee_platform: "amd-sev-snp" describes OPAQUE's infrastructure. A relying party reading this claim would reasonably conclude the agent ran on SEV-SNP — when in fact the agent may have run on an ordinary, non-confidential host with no memory encryption at all. The claim imports the trust properties of OPAQUE's datacenter and silently re-labels them as properties of the agent. This is the single most misleading artifact in the attestation design.

5.4 The SDK never verifies the TRACE claim

verify_manifest_in_report() for OPAQUE (_hw_providers.py:438-441) is just:

return report.manifest_hash == self.manifest_hash_value(manifest_json)

It re-hashes the local manifest and compares it to the manifest_hash the client itself stored — it never checks the TRACE claim's signature, never validates the EAT, never verifies OPAQUE's own enclave measurement. Any endpoint the operator points OPAQUE_ATTESTATION_URL at (or any party holding the API key) can return an arbitrary JSON blob and verification passes. The "signing key never leaves the TEE" property is asserted in a docstring and checked nowhere in code.

5.5 Violation of the project's "non-self-attestation" principle

The spec's trust-root principle (section 2, line 86) demands "a trust root that is not controlled by the entity being attested" — the same separation of Attester, Verifier, and Relying Party that RFC 9334 (Remote ATtestation procedureS architecture) is built around — and defines an attestation_service.service_measurement field (spec section 3.3, line 638) precisely so verifiers can confirm the attestation service's own TEE identity. The OPAQUE provider:

• lets the operator choose the attestation service URL (OPAQUE_ATTESTATION_URL) — the attested entity controls its own attester; and
• never reads or verifies service_measurement — the one field that would establish the service's TEE identity is ignored.

So Level 3 fails the spec's own anti-self-attestation requirement while being sold as the level that most fully satisfies it.

Net effect of Level 3: you take a value computed in untrusted local software, send it to a machine that does not run your agent, and receive back a signed statement about that other machine — which the SDK then does not even verify. Far from the "highest assurance level," it is the configuration with the least connection between the attestation and the running agent.

---

6. Where to go from here

I want to stress that these are not just bugs. Please don't hand this report to a coding agent and ask it to fix them. The offset and IOCTL errors are surface issues; the root issue is that the product's security promises were written for a capability the hardware does not have, and no amount of code repair changes what SEV-SNP/TDX/TPM actually measure.

The right first step is a threat-model and claims re-assessment by the product team, before any more code is writte. The team should decide precisely what they want to prove, to whom, against which adversary, and then map each promise to a mechanism that can actually deliver it.

Concretely, I'd suggest the team:

1. separate what the CVM baseline already gives you for free (genuine firmware + memory confidentiality/integrity vs. the host) from what you are claiming to add, and stop marketing the former as the latter
2. re-scope the manifest hash honestly — a guest-supplied value in REPORT_DATA/a PCR can be bound to a genuine TEE, but the hash can only be trusted under the assumption that the guest workload has not been compromised.
3. for the artifacts that genuinely need to be hardware-rooted (model binary, container image, policy bundle), move them into the launch measurement — bake them into the measured guest image / initrd so firmware measures them into MEASUREMENT/MRTD before the agent runs, rather than self-measuring them after boot. Note that this approach would require a reboot everytime you update any of these artifacts and the attestation baseline.
4. accept that continuous runtime integrity of in-memory state is largely outside what today's coarse-grained VM attestation can prove, and instead address customer's need of auditability through code transparency such that the policy and harness running the agent can be audited on every release(a great example is illustrated in this article: Why Should I Trust Your Code?).

[imran-siddique]

@QinyuanWu great writeup, thank you. Genuinely one of the most useful issues we've gotten, and the core of it is right. Let me split it into what we're fixing and a couple of places I'd push back, since this distinction comes up constantly in this space.

Where you're right and we have work to do (tracking issues opened, linked below):

• HOST_DATA is just wrong in our docs and code. It's host-supplied at launch via SNP_LAUNCH_FINISH, 32 bytes, and the guest can't write it. The guest-controlled field is REPORT_DATA (64 bytes). Spec §3.3.1, the tutorial, and the _hw_providers.py docstring all need correcting. Clean catch. (fix(docs,code): correct HOST_DATA vs REPORT_DATA field and byte counts #203)
• The SDK doesn't verify the attestation chain or the TRACE claim signature. That's the real hole. A quote/VCEK/measurement you don't verify proves nothing, and today we don't verify it. (fix(verify): verify attestation chain and TRACE claim signature in SDK #204)
• The hardware providers are reference-stub quality and were described as more than they are. The SNP IOCTL/ABI and offsets, the RTMR extend that's documented but never performed, and the TDREPORT-vs-Quote handling are real defects. We'll mark them experimental until correct. (fix(hw): correct SNP/TDX provider defects; mark providers experimental #205)
• The §1.2 threat-model language overreaches. "Impossible controls" and the implication that the binding detects an in-memory prompt/policy swap need rewriting to state plainly what the CVM baseline gives you versus what the manifest binding adds. (docs: rewrite threat model (§1.2) and attestation levels #206)

Two places I'd push back, because the distinction matters:

1. "No additional security value beyond the CVM baseline" is too strong. Echoing a guest-supplied hash is worthless on its own, agreed. But binding the manifest hash into REPORT_DATA becomes meaningful once two things hold: the signing key is sealed to the boot measurement, and the verifier checks the full quote. Then the binding ties a specific manifest to a specific, fresh attestation of a specific enclave, which defeats replay and relay. The value isn't zero, it's unrealized until we add chain verification and key sealing. That's a "finish the design" gap, not a "the idea is wrong" gap.
2. C3 ("measurement happens in silicon before any user code runs") is true of the launch measurement, you've just caught us applying it to the wrong thing. MEASUREMENT/MRTD/PCR0-7 genuinely are computed before user code runs. Our error is implying the runtime manifest hash inherits that. Worth sharpening your critique to "you conflated the launch measurement with the runtime report field," because the silicon-before-user-code claim is correct for what it actually covers.

On Level 3: the OPAQUE managed runtime is where the agent actually executes, so the attestation there is of the environment the agent runs in, not a remote bystander. The valid part of your point stands: we still must verify the returned claim's signature, and we don't. I'll get you the architecture detail so section 5 lands on the real gap.

Net: you found a real set of bugs and a real "shipped the binding without the verification" gap, and you sharpened how we describe all of it. Tracking issues are #203, #204, #205, #206, credited to you. Would value your eyes on the corrected threat model. Nice work.

[imran-siddique]

@QinyuanWu update on the fixes, all merged:

• Field + byte-count corrections (REPORT_DATA vs HOST_DATA across spec, tutorial, ADRs, docstrings): fix(attestation): correct SNP REPORT_DATA vs HOST_DATA in spec/docs; mark providers experimental #207
• Threat-model rewrite (§1.2 "impossible controls" dropped; §1.3 table footnoted to separate signature-binding from hardware measurement; conformance/provider levels reframed): docs: scope threat-model claims to what TEE attestation actually provides #208
• Code fixes (SNP REPORT_DATA read at offset 0x50; TDX RTMR-extend and TDREPORT-vs-Quote claims corrected; providers marked experimental): fix(hw): read SNP REPORT_DATA at 0x50; correct TDX RTMR/Quote claims #209

Remaining, tracked in #204: real attestation-chain and claim-signature verification (VCEK/quote/measurement checks, TDX Quote conversion via the Quoting Enclave). This is the substantive "shipped the binding without the verification" gap you identified. It needs hardware and vendor-library validation, so it lands as its own PR series rather than blind edits.

On Level 3 (your section 5), to be precise about the trust model: in the OPAQUE managed runtime the agent executes inside the managed TEE, so the attestation is of the environment the agent runs in, not a remote bystander. The valid gap you flagged is the crux, though: the SDK does not verify the returned TRACE claim's signature against OPAQUE's published key, so nothing currently checks the claim is authentic. That verification is part of #204.

Thanks again. This materially improved both the spec and the code.