Can Remote Attestation Prove an AI Service Is Not Logging Prompts?

August 11, 2026

Remote attestation can verify approved environment claims, but it cannot by itself prove that an AI application never records your prompts.

No. Remote attestation can provide cryptographic evidence about the hardware, software measurement, configuration, and policy claims of an AI workload. It does not, by itself, prove that the approved application never writes prompts to a log. An attested workload can still contain logging code, send data through an allowed network path, or pass prompts to another service outside the measured boundary.

Attestation becomes much more useful when it is joined to reviewable code, exact image digests, restrictive key-release rules, controlled egress, and evidence about the full request path. The right buyer question is not simply, “Is this AI attested?” It is, “Which claims are attested, which artifact do they identify, and what can that artifact do after it receives my prompt?”

Who This Guide Is For

This guide is for security and privacy buyers evaluating an AI vendor that advertises confidential computing, trusted execution environments, enclaves, confidential VMs, or verifiable inference. It is also useful for builders deciding whether an attestation token supports a specific promise such as “the cloud operator cannot inspect prompts” or “we do not log prompts.”

Those are related claims, but they are not the same claim.

What Is Confirmed

Remote attestation is a real and useful security mechanism. The IETF's Remote ATtestation procedureS architecture describes an attester that produces evidence, a verifier that appraises the evidence against policy and reference values, and a relying party that uses the attestation result to make an authorization decision.

Current cloud implementations expose concrete, machine-verifiable claims:

• Google Confidential Space can issue an attestation token containing claims such as the workload container's image digest, image reference, command arguments, explicitly passed environment variables, debug status, and trusted-computing-base information. Its confidential-resource guide shows how an access policy can require specific claims before the workload receives access to protected data.
• Microsoft Azure Attestation describes itself as a way to verify a platform and the integrity of binaries running in a trusted execution environment. Its claim-set documentation includes claims such as an SEV-SNP launch measurement, debug state, security-version numbers, policy hash, runtime claims, and report data that can bind a key to the attested environment.
• NVIDIA's current confidential-computing trust model explains that isolation and attestation can protect model weights and inference data from the host, cluster administrator, and other infrastructure outside the confidential workload—when the stated assumptions hold.

The strongest practical pattern is conditional secret release. A key service checks fresh attestation evidence and releases a decryption key only when the measured workload and its policy claims match an approved set. The AI service then cannot decrypt a prompt or model artifact merely by launching an arbitrary replacement image.

That is meaningful evidence. It is still evidence about an approved execution boundary, not a universal statement about everything the approved software will do.

What Remote Attestation Actually Proves

Think of remote attestation as a signed answer to a bounded set of questions.

Depending on the design, a relying party may be able to verify that:

1. The workload is running on a supported confidential-computing platform.
2. Debugging is disabled.
3. The platform's measured firmware or launch state matches accepted reference values.
4. A particular container image digest or launch measurement is present.
5. The evidence is fresh because it includes a nonce, validity window, or session binding.
6. A key or protected resource should be released only if those claims satisfy policy.

Google's attestation-token reference is a useful example of this precision. It lists individual claims rather than making a blanket claim that an application is private. The token can identify an image digest and launch arguments, for example, but the privacy meaning of that image still depends on what code and configuration the digest represents.

An attestation result is therefore closer to “this measured environment satisfied this policy at this time” than “this service can never retain a prompt.”

Why It Does Not Prove “No Prompt Logging”

The central gap is simple: trusted execution protects an approved workload from certain outside actors; it does not make the approved workload benevolent.

NVIDIA states this limitation unusually clearly. Its threat model says confidential computing does not protect against a malicious workload image, vulnerable inference code inside the confidential pod, payload logging by the application itself, a compromised attestation or key-release administrator, or side channels.

An application inside an attested boundary could still:

• write prompt text to an encrypted database;
• emit prompt fragments through structured telemetry;
• include user content in crash reports or traces;
• send requests to an allowed model, search, voice, file, or safety provider;
• return sensitive data in outputs that another component records;
• hold prompts in a queue, cache, backup, or retry store;
• expose an administrative export path; or
• log only “exceptional” requests under a safety or abuse rule.

Every one of those actions can be intentional code in the exact image whose digest was successfully attested.

This is also why “no chat history” does not mean “no logs”. User-visible history, operational records, safety retention, provider processing, and training are separate data paths. An attestation badge does not collapse them into one promise.

The Five-Link ATTEST Test

Use this five-link test when a vendor says remote attestation proves its AI is private. A break in any link narrows the conclusion you can draw.

1. Assertions

Read the token schema and the acceptance policy. Which claims are actually checked: hardware type, debug state, firmware versions, image digest, command line, environment, model identifier, or something else?

“Attestation supported” is not enough. A token that proves only that a confidential VM started is weaker than a policy pinned to a reviewed workload image with debugging disabled.

2. Target Artifact

Map the accepted measurement or digest to an exact artifact. Can the buyer inspect source code, a reproducible build, a signed software bill of materials, or at least a versioned security assessment? Who can replace the accepted reference value?

A hash is a strong identifier. It is not an explanation of behavior. If buyers cannot determine what the hash identifies, they cannot infer that logging is absent.

3. Secret Release

Check what attestation gates. Does a separate key holder release prompt-decryption keys only to the approved workload? Is the key bound to a fresh session or proof-of-possession key? Can an operator bypass or broaden the policy?

Microsoft's Azure Attestation overview describes this pattern: attestation validates measurements and can be used to release keys from a managed HSM or key vault. This is stronger than merely displaying an attestation result on a status page.

4. Egress And Extensions

Draw every path out of the trusted boundary. Include the model endpoint, web search, tools, file conversion, content moderation, voice transcription, image generation, telemetry, error reporting, queues, storage, and support access.

Attesting the central inference container does not automatically attest these downstream services. This is the same boundary problem that makes confidential computing different from a promise that a provider cannot read prompts.

5. Time And Updates

Verify freshness, expiry, revocation, update behavior, and rollback protection. What happens when the provider patches the image? Does a new digest require review before key release? Can an old vulnerable but previously approved measurement still attest successfully?

Attestation is a decision made from evidence and policy at a point in time. A durable privacy claim needs an operational process for every version, not one screenshot from one launch.

A Practical Verification Exercise

If a vendor offers attestation evidence, ask for one complete proof chain for a real request:

1. Obtain a fresh token using a nonce you supplied.
2. Validate the token signature, issuer, audience, expiry, nonce, and debug-state claim.
3. Extract the image digest or launch measurement;
4. Map that value to the vendor's reviewed build and privacy-relevant configuration;
5. Confirm that prompt-decryption keys are released only after the policy accepts those values;
6. Inventory every permitted outbound destination and storage sink; and
7. Repeat after an update to see whether the old and new measurements follow the documented approval process.

This exercise produces a useful result even when it does not prove “zero logging.” It tells you whether attestation is connected to the request's confidentiality or is merely an infrastructure feature with no buyer-verifiable link to prompt handling.

The most defensible conclusion is usually layered:

• Strong conclusion: a fresh token identifies an approved measured workload, and a separate key service releases secrets only to that workload under a stated policy.
• Additional evidence: reviewed code and configuration do not intentionally persist prompt content, while egress restrictions and telemetry controls reduce alternate paths.
• Remaining boundary: bugs, compromised policy administrators, allowed downstream services, client-side records, and unmeasured components may still affect privacy.

That is more honest—and more useful—than treating “attested” as a synonym for “no logs.”

What Is Still Unclear

Public attestation claims rarely answer the entire prompt-lifecycle question. For any specific AI service, buyers may still need the provider to document:

• whether the model server, router, safety layer, and tool calls share one measured boundary;
• whether model weights and runtime configuration are covered by the measurement;
• which logs exist inside and outside that boundary;
• whether operators can change egress rules or accepted reference values;
• how safety investigations, abuse handling, support, and legal requests affect retention;
• whether backups, crash reports, and queues inherit the same controls; and
• whether a customer can independently validate the evidence for each request.

An absence of public evidence that prompts are logged is not proof that they are not logged. Conversely, the existence of operational attestation logs does not show that prompt bodies are recorded. Microsoft even documents logging for the attestation service itself, illustrating why the word “logs” must always be tied to a specific system and data type.

How Remote Attestation Fits With Other Privacy Controls

Remote attestation is strongest as one layer in a larger design:

• Encryption in transit protects data on the network.
• Confidential computing can protect data in use from specified infrastructure actors.
• Remote attestation lets another party evaluate measured claims before trusting that environment.
• Application design determines what happens after the prompt is decrypted.
• Retention and deletion policy determines what records remain and for how long.
• Training policy determines whether prompts, files, or outputs can improve models.
• Client-side storage determines what remains on the user's browser or device.

Key ownership matters too. If the same operator can approve measurements, alter policy, and release keys without independent controls, attestation may provide less separation than the marketing suggests. Our guide to who holds the encryption keys for an AI chat explains why encryption and operational authority must be evaluated together.

Where OpenVeil Fits

OpenVeil takes a narrower, documented approach to private AI work. Normal chat history is stored in the browser rather than as a server-side chat-history record, and OpenVeil says prompts, uploads, media, and outputs are not used to train foundation models.

OpenVeil is still a hosted service. Active requests require processing by OpenVeil and necessary providers, and limited operational, billing, security, and abuse-prevention records can exist. OpenVeil does not currently claim that every request is remotely attested, fully offline, anonymous, zero-log, or protected from every downstream risk.

That boundary is the reason to try OpenVeil for sensitive drafting, analysis, and file work when browser-local normal chat history and no foundation-model training fit your needs—without translating those controls into claims the product does not make.

Frequently Asked Questions

Does remote attestation prove which code handled my AI prompt?

It can identify a launch measurement or image digest and show that it satisfied a policy. To know which code that represents, you still need a trustworthy mapping from the measurement to a reviewed build, plus assurance that the prompt actually reached that attested workload and not an unmeasured path.

Can an attested AI workload still log prompts?

Yes. The approved workload can intentionally write prompts to storage, telemetry, traces, crash reports, or an allowed downstream service. Attestation verifies specified claims about the workload; it does not automatically prohibit application-level logging.

Can remote attestation make a no-logging claim stronger?

Yes. It can strengthen the claim when keys are released only to a reviewed no-prompt-logging build, egress is restricted, telemetry is controlled, policy administration is separated, and customers can validate fresh evidence. Those additional controls do the work that the attestation token alone cannot do.

Is confidential computing the same as remote attestation?

No. Confidential computing supplies an isolated execution environment intended to protect data in use from defined threats. Remote attestation supplies evidence about that environment so another party can decide whether to trust it. Many useful designs combine them.

Does attestation prove an AI provider cannot read prompts?

Not by itself. That conclusion depends on who controls the approved workload, keys, policy, egress, downstream services, and administrative paths. A provider might be blocked at the host layer while its application remains designed to receive or retain prompt content.

Bottom Line

Remote attestation can prove that an AI workload presented evidence matching specific measurements and policy claims. It can help bind decryption keys to an approved environment and reduce the need to trust cloud infrastructure blindly.

It cannot alone prove that the approved AI application never logs prompts. To support that claim, require a complete chain from fresh evidence to a reviewed artifact, conditional key release, constrained egress, documented retention, and independently checkable update behavior. Trust the exact claims in the token—not the larger promise someone places around it.