Questions to ask before you trust an attested AI request
It describes kinds of deployments, not companies.
| Document | confidential-ai-service.md |
|---|---|
| Version | 0.2 — peer review draft |
| Audience | People deciding whether to send private data to an AI service that runs in protected hardware: read Start here. Technical reviewers, including anyone who reviews such a service for an organization: read the full note. |
| Method | Follow the chain from a hardware signature to the software that answered one request. For each link, state what the evidence shows, what it leaves open, and what a customer can check. |
| Changes | See the changelog. |
| Scope | AI inference services that run models in trusted execution environments and offer remote attestation to customers. This is not a finding about any organization, an assessment of any product, or a review of hardware side channels or compliance. |
This section is for anyone weighing an AI service that promises to keep prompts private. You do not need to read code to use it. The rest of the note is the record behind each question.
What these services offer. You send a prompt to an AI model. The service says the model runs inside protected hardware, so that the company and its cloud providers cannot read your prompt. Before your prompt is sent, your software asks the service for a report about its hardware. The hardware signs that report about itself, and the service returns it. The report is called an attestation.
What an attestation can show. A signed report can show that real protected hardware answered, and that the report is fresh. It can also contain measurements: fingerprints of the software that the hardware started. A measurement helps only if someone compares it with a known value for approved software. Without that comparison, the report shows protected hardware, not which software ran.
The questions that matter.
How to judge an answer. A good answer shows you something you can check: a published reference value, a policy you can read and replace, a log entry. A weak answer repeats the claim in different words. A weak answer does not prove a problem. It shows that the claim is not proved yet.
What this note does not do. It does not rank services or say which one to use. It does not cover attacks on the hardware itself. The right weight for each check depends on what you need protection from.
A claim about confidential inference needs a defined object: one request, one attestation, one set of rules that judged it. “Encrypted”, “attested”, and “verifiable” describe different properties. None follows from the others.
The custody note lists four levels of build evidence. The last is “evidence that the device runs that binary.” For a remote machine, that evidence has two parts. Measurements compared with approved values show that the machine started a particular image: the identity stage in §2. Route evidence shows that the machine served your request: the route stage. Neither part supplies the other. The fallback note asks which code runs inside a file. This note asks which software a remote machine ran, and what a customer can confirm about it. See Who Can Move Your Bitcoin? §3 and Which Code Actually Runs? §1.
This note describes kinds of deployments and names none. §3 describes design patterns that a deployment can use. The note makes no statement about any particular service. The roles and terms follow the IETF architecture for remote attestation, RFC 9334.
A finding about a specific service should record: claim; service and date; public source or inspected artifact; verification performed; result; unresolved. Use the result terms in the custody note §1.1 and the fixed entries in the release note §1.1. A statement by a service about itself is recorded as that service’s statement.
Terms from the release note §1.2 keep their meaning. This note adds the following.
| Term | Meaning here |
|---|---|
| Trusted execution environment (TEE) | Hardware that runs a virtual machine whose memory the host cannot read. Current CPU forms include AMD SEV-SNP and Intel TDX. Some GPUs have a confidential-computing mode. |
| Attestation | A signed report about a TEE. RFC 9334 calls its content Evidence: “A set of Claims generated by an Attester to be appraised by a Verifier.” |
| Measurement | A hash of software or configuration that the hardware recorded at start-up. |
| Reference value | The measurement expected for approved software. In RFC 9334, reference values are what a verifier compares claims against. A measurement is pinned when the verifier requires it to equal a reference value. |
| Appraisal policy | The rules a verifier applies to the evidence. RFC 9334 defines it as “A set of rules that a Verifier uses to evaluate the validity of information about an Attester.” |
| Verifier and relying party | The verifier appraises the evidence. The relying party, here the customer’s software, acts on the verifier’s result. |
| Collateral | Certificates and status data from the chip vendor that a verifier needs to check a signature chain. |
| Transparency log | An append-only public log. For TEE images, it lets a customer see every image the operator has published and notice an unannounced one. |
A full assurance decision has stages. Each depends on the ones above it.
| Stage | What a customer would need | What it shows |
|---|---|---|
| Authenticity | A signature that chains to the chip vendor’s root | Real protected hardware produced the report |
| Freshness | A nonce from the customer, signed into the report | The report is current, not replayed |
| Configuration | Debug off, a minimum firmware level, production mode | The hardware is set up to protect memory |
| Identity | Measurements equal to reference values for approved software | Which software the hardware started |
| Provenance | Each reference value tied to public source and a repeatable build | What that software is |
| Route | Evidence that the attested machine served this request | That the protected software handled your data |
A pass at the first three stages shows that protected hardware answered. Only the identity stage connects that hardware to particular software. Provenance and route connect the software to its source and to your request.
RFC 9334 describes freshness by nonce: “an unpredictable nonce is sent by the appraising entity and the nonce is then signed and included along with the Claims”. RFC 9334 §10.2
Each pattern below is a design choice that a deployment can make, and each has a reason. None is a fault in itself. The question in each case is what a pass then establishes.
The pattern. The default appraisal policy checks configuration, such as debug mode and firmware level, and leaves the software measurements unpinned. A policy can accept any value for a measurement when its reference is empty.
Why it happens. Some measurements legitimately differ between hosts, firmware builds, and machine sizes. A policy that pins them must be kept current with every release and every host type.
What a pass then shows. Authenticity, freshness, and configuration. Not identity. The report shows protected hardware with debug off. It does not show which software image that hardware started.
What to ask. Which measurements does the default policy pin? Are reference values published for each release? Can the customer supply their own?
The pattern. The verifier fetches its appraisal policy from a server that the service operator runs. The collateral may also come from operator-run caches.
Why it happens. It lets the operator update policies as releases change, without a new client.
What a pass then shows. That the evidence met the operator’s current rules. A change to those rules changes what passes, without a change on the customer’s side. Collateral is signed by the chip vendor, so an operator cache matters less than an operator policy, provided the verifier anchors the vendor root itself.
What to ask. Where does the verifier get its policy? Can the customer pin a copy, or host their own? Is each policy version public and dated? Where does the verifier anchor the vendor root certificates?
The pattern. The client first asks the server which modules it has, such as a CPU TEE and an optional GPU. It then attests only the modules the server names.
Why it happens. One client can then work with several hardware configurations.
What a pass then shows. That the named modules passed. If the server names no GPU, no GPU check runs, and the model’s working memory on that GPU is outside the result.
What to ask. Can the customer require a GPU attestation, and fail if none is offered?
The pattern. The client verifies by default and stops before sending a request when verification fails. A setting or flag turns verification off.
Why it happens. Developers need to test without hardware, and some routes may not run in a TEE.
What a pass then shows. Nothing, if the setting was off. A request sent with verification off is not an attested request, though it may travel the same encrypted path.
What to ask. How would an organization know whether any of its clients turned verification off? Does the response record whether the request was attested?
The pattern. For clients that cannot run the vendor’s library, a local proxy encrypts outbound requests. The proxy holds the plaintext, the credentials, and the encryption keys.
What a pass then shows. Nothing about the proxy. The proxy is on the customer’s side of the boundary. Its compromise exposes content regardless of the TEE.
What to ask. Does the proxy itself verify the attestation? Who maintains it, and how is it updated?
The pattern. The attestation describes a machine. A request may travel through a gateway and a scheduler, and may be served by a model route that is not attested at all.
What a pass then shows. That attested hardware exists behind the endpoint. Not that it served this request, and not that every model offered by the service runs in a TEE.
What to ask. Is the request’s encryption key bound to the attested machine, so that only that machine can read it? Which model routes run in a TEE, and how does the response say which route served the request?
The pattern. The verifier and its policies are public. The image that runs the model is not public, has no repeatable build, or has no public log of releases.
What a pass then shows. At most, that a measurement matched a value the operator chose. Without the image source and a repeatable build, a customer cannot tie that value to code they can read. Without a log, a customer cannot tell whether the operator published one image to everyone.
What to ask. Is the image source public? Can a second builder produce the same measurement from it? Is there a transparency log of image releases, and where? These are the release note’s three checks, applied to a remote image. See What Can You Check About a Software Release? §2.
A service often publishes a summary security page, technical documentation, a status or roadmap page, and source code. They are all the service’s own statements, and they can describe one feature at different levels of detail.
A summary page and a status page can describe the same feature differently: one in the present tense, the other as planned. Transparency logs, open-source images, and repeatable builds are features worth checking this way. Where two sources differ, the more specific source is the better guide to what exists on the date read.
For each claim on a summary page:
| If the claim is | Request | If the artifact is missing |
|---|---|---|
| Every request is attested | The policy that judged it, who wrote it, and where the verifier fetched it from | A pass against unknown rules shows only that some rules passed |
| The enclave runs approved code | The reference values for each release, and the policy that pins them | Hardware evidence without a pinned measurement shows protected hardware, not which software |
| Builds are deterministic | The build definition, the published measurement for each release, and a second builder’s matching result | A build that only the operator can run is not a repeatable build |
| The code is open source | The source for the image that runs the model, tied to the measurement it produces | Open-source tooling around a closed image leaves the image unexamined |
| Changes are logged publicly | The log’s address, and an entry for the current image | A planned log is not a log |
| The GPU is attested | Whether the client requires a GPU, or accepts the server’s report that none is present | A check the server can opt out of is the server’s choice |
| Nobody can read your data | The binding between this request’s key and the attested machine, and the route that served it | Attestation of a machine does not show which machine served the request |
| You can verify it yourself | How to run the verifier with your own policy and your own reference values | Verification with the operator’s defaults checks the operator’s rules |
| Compliant with a named framework | The audit report, its scope, and its date | Alignment with a framework is not an audit |
Each source is listed once with the version consulted and the sections that cite it.
| Reference | What it defines | Cited in |
|---|---|---|
| RFC 9334 | Remote ATtestation procedureS (RATS) Architecture: roles, evidence, reference values, appraisal policy, and freshness. RFCs are immutable once published. | §1, §1.2, §2 |
| What Can You Check About a Software Release? | The three checks and the fixed entries | §1.1, §1.2, §3.7 |
| Who Can Move Your Bitcoin? | The four levels of build evidence, and the result terms | §1, §1.1 |
| Which Code Actually Runs? | Selection between two ways to do a job | §1 |
Newest first. Versioning follows STYLE.md. Version tags use the prefix confidential-v, and each version links to its tagged text.
| Version | Change |
|---|---|
| 0.2 — 14 October 2026 | Review fixes. Describes the seven patterns in §3 as design patterns that can occur, and removes the statements in §1, §3, §4, and §6 that the patterns were drawn from material read for the note, since that material is not recorded. Turns the §4 observation into guidance. Splits the §1 claim about the custody note’s fourth level of build evidence into the identity and route stages. Corrects the §1.1 reference: the result terms are in the custody note. In Start here, the service returns a report that the hardware signs. |
| 0.1 — 14 October 2026 | First draft. The verification chain, seven patterns in which a pass can mean less than it appears, a method for reading a service’s own sources side by side, and reviewable claims. Names no service. |