threat-model.md's A1 entry may overstate what TPM-only deployments guarantee against a rogue operator

[kingztech2019]

docs/spec/threat-model.md, adversary A1 (rogue operator / privileged insider):

Cannot read TEE-encrypted memory (SEV-SNP, TDX) or TPM-sealed secrets

This groups SEV-SNP/TDX and TPM together as if they give the same protection against A1. I don't think they do, and I want to check before assuming the doc is just being loose with language.

The distinction: SEV-SNP and TDX encrypt guest memory while the VM is running, so an operator with root on the host genuinely cannot read or modify what's happening inside, for the whole time it's running. TPM is different: it measures the boot state and can seal a secret so it only unseals when PCRs match a known-good boot, but that's a boot-time / at-rest guarantee. It doesn't encrypt or otherwise protect a running process's memory from a host with root access.

What that would mean for a tpm-only deployment (no SEV-SNP/TDX underneath — i.e. bare-metal TPM, not the Azure vTPM-behind-SEV-SNP case LIMITATIONS.md already documents separately): the TPM can attest that the gateway booted with the right measured components, but once it's running, a rogue operator with root on that host may still be able to reach into the process and change what's happening — including, concretely, flipping a Cedar DENY to an ALLOW — without the TPM catching it, because that's not what TPM's guarantee covers.

This is different from the already-documented TPM limitation (#453, the missing AK certificate chain to a pinnable root). That one is about verifying a TPM quote's provenance. This is about whether TPM alone protects the running decision the way SEV-SNP/TDX do, which is closer to what #124's "a deny inside the enclave cannot be bypassed by the host" is asking for.

What I'm not certain of: I don't have TPM-only hardware (no SEV-SNP/TDX underneath) to test this against, so I can't confirm whether a real attack along these lines is actually possible on this codebase specifically, or whether something else in the design (a measurement re-check, a runtime integrity check I haven't found) already closes this. Flagging it as a question against the docs' current wording rather than a confirmed finding.

If this is already understood and just imprecisely worded, happy to send a doc-wording PR. If it's a real gap, it's probably worth being explicit in STATUS.md's tpm row and in the threat model about which of the two guarantees (sealed at boot vs protected while running) a tpm-only deployment actually gets.

[github-actions]

🟡 Contributor Check: MEDIUM

Check	Result
Profile	MEDIUM
Credential	LOW
Overall	MEDIUM

Automated check by AgenTrust Contributor Check.

[imran-siddique]

You are right, and it is not the document being loose with language. Fixed in #583.

The line is exactly as you quote it, at docs/spec/threat-model.md:22, and the reason it matters is two lines above it: the same entry already grants A1 root on the host. So that bullet is the load-bearing one. It is the sentence saying what root cannot reach, and it named two guarantees that are not the same guarantee.

Your distinction is the correct one. SEV-SNP and TDX encrypt guest memory while the VM runs, so the protection covers the whole execution. TPM sealing binds a secret to PCR values at unseal time, which is boot-time and at-rest. On bare-metal TPM an operator with root can reach into the running gateway and flip a Cedar decision, and the TPM does not detect it, because detecting that is outside what a TPM does.

Your worked example is the part that makes this a change rather than a note. "Flipping a Cedar DENY to an ALLOW" is precisely the thing a deployer chooses this product to prevent, and someone reading A1 as written would have concluded the tpm tier prevents it. Overstating a hardware guarantee in the document whose job is to bound it is the worst place for us to do it.

Scoping it away from #453 and from the Azure vTPM case was the right call and saved a round trip. #453 is about whether a TPM attestation can be verified at all; this is about what a verified one proves. And the Azure vTPM sits on top of SEV-SNP, so the memory-encryption line genuinely applies there, which is why LIMITATIONS.md treats it separately. Getting both exclusions right in the report meant the fix was one bullet rather than an argument about three overlapping issues.

The fix splits A1's third bullet so each tier states its own guarantee, and says outright that the tpm tier defends against a tampered boot rather than a live privileged insider. The SEV-SNP and TDX position is unchanged; it was accurate.

I also checked whether the same grouping appears elsewhere in that file. It does not; line 22 was the only instance.

The needs-review:MEDIUM label on this issue is our contributor-check bot and carries no signal about the report.