Name the adversary.
Confidential against whom? A claim without a named threat cannot be assessed and is usually assessed generously.
At rest. In transit.
In use.
Confidentiality claims are only meaningful against a stated threat. The interesting case for AI is data in use, when the model must read plaintext to work.
READ THE DEFINITION ↓IN USE · TENANCY · THREAT MODEL
01 / DEFINITION
The short answer first.What is confidential AI?
Confidential AI is the protection of data while a model is processing it, not only while it is stored or transmitted. Because inference requires plaintext input, the question becomes who or what can observe memory and logs during processing — which is a matter of tenancy, isolation and operator access.
Encryption at rest and in transit are settled problems. Data in use is different: a model cannot reason over ciphertext, so the input exists in plaintext in memory for the duration of the request. Every confidentiality control for AI is therefore about who can reach that memory, and about what persists after the request completes.
02 / WHICH THREAT ARE YOU ADDRESSING?
Controls mapped to adversaries.| Threat | Control that addresses it | What it does not address |
|---|---|---|
| Another tenant on shared infrastructure | Dedicated instances or on-premise hardware | Your own operators and administrators |
| The provider's staff or subpoena exposure | Inference inside your own boundary | Anyone with access inside that boundary |
| A compromised host operating system | Hardware-based trusted execution environments | Application-level flaws and over-broad permissions |
| Your own over-privileged staff | Access control, log restriction, audit | Anything about where the compute runs |
| Data persisting after use | Explicit retention rules for logs, caches and indexes | Exposure during the request itself |
The most common mismatch is buying infrastructure-level confidentiality to address a risk that is actually about internal access. A trusted execution environment protecting a model from the host operating system does nothing about a prompt log that the whole engineering team can read, and the second is the more likely route to an actual disclosure.
03 / WHAT CONFIDENTIAL COMPUTING ADDS
A realistic account.Useful,
and narrower than
it sounds.
Hardware-based trusted execution environments — including GPU-based variants now available for inference workloads — aim to keep data encrypted in memory and unreadable by the host, with attestation that the expected code is running. For organisations that must use shared infrastructure and need a technical rather than contractual assurance against the operator, this is a genuine addition.
Three qualifications are worth stating. The protection is against a specific adversary — the host and the operator — and not against application-level flaws, over-broad retrieval permissions or an over-privileged internal user. It adds operational complexity, in attestation, key management and supported configurations. And the guarantees rest on hardware and firmware whose own vulnerability history is not empty.
For a great deal of confidential work the simpler architecture is also the stronger one: run the model on hardware you own, inside a network with no outbound path, and the question of who else can observe memory does not arise. That is the arrangement Privilege AI builds — local model execution with explicit hardware, network and operational constraints, with MKC2 running entirely offline. See on-premise AI.
04 / WRITING A CLAIM YOU CAN DEFEND
What a confidentiality statement should contain.List the plaintext locations.
Everywhere the material exists unencrypted, including memory during inference, caches, logs and indexes.
State the persistence.
What remains after the request, for how long, and who can read it. This is where most real disclosures originate.
A claim written this way is testable, which is the point. A reviewer can enumerate the plaintext locations and check each one, rather than assessing an adjective. The same discipline applied to the request path produces the verifiable statement described in private AI inference, and the derivative-copy inventory in AI data security.
05 / QUESTIONS
Asked when a confidentiality claim needs assessing.Can a model process encrypted data?
+
Not usefully at production scale today. Approaches exist in research — homomorphic encryption and secure multi-party computation among them — and their performance cost is prohibitive for language model inference. In practice the input is plaintext in memory, and the controls are about who can reach that memory.
Is confidential computing necessary for private AI?
+
Not if you own the hardware. Its purpose is to protect against the infrastructure operator, which is a threat that does not exist when the operator is you. It becomes relevant when you must use shared infrastructure and need a technical assurance rather than a contractual one.
What is the difference between confidential AI and private AI?
+
Private AI is about location: inference happens inside your boundary. Confidential AI is about observability during processing, including on infrastructure you do not own. Private deployment is one way to achieve confidentiality; it is not the only framing.
Does a dedicated cloud instance make inference confidential?
+
It addresses the other-tenant threat and leaves the operator threat and every internal access question in place. Whether that is sufficient depends entirely on which adversary the requirement is written against.
What is the most common confidentiality failure in practice?
+
Logs. Prompt and response logging recreates the sensitive corpus in a store built for engineering convenience, usually with far broader read access than the source system. It defeats an otherwise careful architecture and is cheap to fix.
Name the threat.
Then design.
Privilege AI builds systems where the data boundary, model authority and operational constraints are stated explicitly.