Confidential computing for AI, explained

Summary

Confidential computing protects data while it is processed, by running the computation in a hardware-isolated trusted execution environment (TEE) that can prove which code it runs. In remote attestation, a client checks hardware-signed evidence from the TEE before sending anything; for AI inference, it then encrypts the prompt so that only that environment can read it. Transparency logs and reproducible builds tie each measurement to public source code, and oblivious relays separate who asks from what is asked. The approach narrows trust without removing it: side channels, the hardware vendor and the code inside all remain. Brello 1.0 has no server; Brello Super Intelligence, in development, is being designed to use sealed compute only after a device verifies it.

The Confidential Computing Consortium defines confidential computing as “the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment”.
In remote attestation, as described in RFC 9334, a verifier checks hardware-signed evidence of which code an environment runs, and a client sends data only if every check passes.
Attestation identifies code but does not vouch for it, so transparency logs and reproducible builds are needed to tie each measurement to source code that anyone can inspect.
The CCC treats sophisticated physical attacks, hardware supply-chain attacks and denial of service as generally out of scope, and side-channel attacks such as Foreshadow have broken TEE isolation in practice.
Brello 1.0 has no server; Brello Super Intelligence, in development, is being designed to send a task to sealed compute only after the device verifies the server, and to send nothing if a check fails.

What is confidential computing?

Confidential computing is the protection of data while it is being processed. The computation runs inside a trusted execution environment, an area of a processor isolated by hardware, and the hardware can prove to a remote party which code is running there. It closes the gap that encryption at rest and in transit leaves open.

The Confidential Computing Consortium (CCC), an open community under the Linux Foundation, defines it as “the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment” 1, and notes that the definition covers user devices and edge deployments as well as cloud servers. Data exists in three states: at rest on a disk, in transit across a network, and in use in memory while a program works on it. Encryption for the first two is routine. The third is harder, because a program has to read data to compute on it, so on a conventional server the data sits as plaintext in memory that the operating system, the hypervisor and the machine’s administrators can in principle reach.

For AI, this is the gap that matters. A language model can’t answer a prompt it can’t read, so a prompt sent to a server is decrypted somewhere on it; fully homomorphic encryption, which computes on encrypted data, remains far too slow to run a large language model at conversational speed. Confidential computing instead lets the prompt be read only inside isolated memory, and lets the sender check what will read it. Figure 1 follows that sequence, using the roles defined in RFC 9334 2; the next two sections explain each part.

The server runs the model inside a trusted execution environment. The processor encrypts that memory and blocks outside access, so the host system, the hypervisor and the server’s administrators can’t read or change what runs there.
At launch, the processor measures the code. It hashes everything loaded into the environment. The hash identifies the exact software: change one byte and the hash changes.
The client sends a fresh nonce. This random value, used once, has to come back inside the evidence, which proves the evidence is new rather than replayed.
The environment returns signed evidence. The processor’s attestation key, certified by its manufacturer, signs the measurement, the nonce and a public key K that was made inside the environment.
A verifier checks the evidence before anything is sent. The signature must chain to the manufacturer, the measurement must match a published reference value and the nonce must match. If any check fails, the client sends nothing.
Only then does the prompt leave the client, sealed to K. Only code inside the environment holds the matching private key, so the prompt is decrypted only there. The host relays ciphertext, and the answer returns encrypted.

Figure 1Remote attestation in the background-check pattern described in RFC 9334, where the client passes the evidence to a verifier before it sends anything. The hash and nonce values are illustrative.

What is a trusted execution environment?

A trusted execution environment (TEE) is a part of a processor whose memory the rest of the machine cannot read or alter, including the operating system, the hypervisor and the people who administer the server. Code and data inside it stay protected while they run.

The CCC defines a TEE by three properties, each stated against “unauthorized entities” 1:

Data confidentiality: “Unauthorized entities cannot view data while it is in use within the TEE.”
Data integrity: “Unauthorized entities cannot add, remove, or alter data while it is in use within the TEE.”
Code integrity: “Unauthorized entities cannot add, remove, or alter code executing in the TEE.”

Those entities include other applications on the host, the host operating system and hypervisor, administrators, service providers and the infrastructure’s owner. The processor enforces the properties by encrypting the TEE’s memory with keys it never exposes to software, so anything written out to the memory chips is ciphertext, and by refusing access to that memory from outside the TEE.

Two designs are in common use. Process-level enclaves, such as Intel’s Software Guard Extensions (SGX), protect a region of memory inside a single application 3. Confidential virtual machines protect a whole virtual machine from the hypervisor that hosts it: AMD’s SEV-SNP, for example, adds integrity protection to a virtual machine’s encrypted memory 4, and Intel TDX and Arm’s Confidential Compute Architecture take the same approach. Enclaves keep the trusted code small but require software to be split to fit them; confidential virtual machines run largely unmodified software but must trust a whole guest operating system.

“Trusted” here means relied upon, not proven trustworthy. Everything whose failure would break the protection makes up the trusted computing base. A TEE shrinks it by removing the host operating system, the hypervisor and the operator’s staff; the processor, its firmware and the code inside the environment stay in.

How does remote attestation work?

Remote attestation is how a TEE proves to a party elsewhere which code it is running, and on what hardware, so that the party can decide whether to trust it before sending any data. The proof is a report signed with a key built into the processor.

RFC 9334, the IETF’s architecture for remote attestation procedures (RATS), defines the roles 2. The attester is the system being checked, here the TEE. The verifier “appraises the validity of Evidence about an Attester and produces Attestation Results”. The relying party acts on those results: here, a client deciding whether to send a prompt. A typical exchange has five steps.

Measure. When the TEE starts, the processor computes a cryptographic hash of the code and configuration loaded into it. This measurement identifies the software exactly: change a single byte and the hash changes.
Challenge. The relying party sends a nonce, a random value used once. In the words of RFC 9334, the nonce “is then signed and included along with the Claims in the Evidence”, so the evidence must have been produced after the challenge and can’t be a replay.
Report. The TEE returns evidence: its measurement, the nonce and a public key it generated inside, signed with the processor’s attestation key. The manufacturer vouches for that key with a certificate, which RFC 9334 calls an endorsement.
Appraise. The verifier checks that the signature chains back to the manufacturer, that the nonce matches, and that the measurement equals a reference value: the known-good measurement of software that someone has published.
Bind. If every check passes, the client encrypts its data to the public key from the evidence. Only code inside that TEE holds the matching private key, so only that code can read the data. If any check fails, the client sends nothing.

The verifier can be a separate service or code on the client itself. RFC 9334 describes two arrangements. In the passport model, the attester takes its evidence to a verifier and shows the result to relying parties, much as a traveller shows a passport. In the background-check model, the relying party passes the evidence to a verifier, much as an employer runs a background check 2. Figure 1 uses the second.

Attestation answers a narrow question. It tells the client which code is running, on genuine hardware, right now. It doesn’t say whether that code is any good: a TEE running software that copies every prompt into a log would pass every check. That is why attestation is paired with published code, as section 5 explains.

How does confidential computing apply to AI inference?

Applied to AI, confidential computing aims to let a model answer a prompt on a server whose operator cannot read the prompt or the answer. The client attests the server and encrypts the prompt to it, and the prompt is decrypted only inside isolated memory, where the model runs.

Everything that touches the prompt has to sit inside the protected boundary and be covered by the measurement: the model’s weights, the inference runtime and any code that prepares or filters requests. Large models run on graphics processors and other accelerators rather than on the main processor, so the protection has to extend to the accelerator’s memory and to the link between processor and accelerator. Research such as Graviton showed how a GPU could host trusted execution of its own 5.

Isolation alone isn’t enough, because code inside the boundary could still keep what it sees. A confidential inference service also needs software built to keep nothing, with no prompts in logs or on disk, and no shell or debugger through which staff could look inside while it runs. Those are properties of the software rather than the hardware, which is why the software and its measurements need to be public.

Apple’s Private Cloud Compute is one published design of this kind. Apple’s security research blog described it on 10 June 2024 and set out five core requirements: “Stateless computation on personal user data”, “Enforceable guarantees”, “No privileged runtime access”, “Non-targetability” and “Verifiable transparency” 6. Apple states that a user’s device “will wrap its request payload key only to the public keys of those PCC nodes whose attested measurements match a software release in the public transparency log” (checked 5 October 2026). The last part of that sentence is the subject of the next section.

What do transparency logs and reproducible builds add?

A transparency log publishes every software release a server may run, permanently and in order, so a client can refuse code that hasn’t been published. Reproducible builds let anyone rebuild a release from its source and confirm that it gives the same measurement. Together they connect the hash in an attestation report to source code that people can read.

The model is Certificate Transparency, specified in RFC 6962 in 2013, which records the certificates that websites use in public, append-only logs 7; version 2.0 is specified in RFC 9162 8. Each log is a Merkle tree, a structure in which a short inclusion proof shows that an entry is in the log, and a consistency proof shows that today’s log extends yesterday’s without rewriting it. Independent monitors watch the logs, so an entry can’t be added unseen. Applied to attestation, a client accepts a measurement only with proof that it is in the log. An operator could still run harmful software, but not secretly and not for a single target, because the release would be on the public record.

That record helps only if a measurement can be traced to source code. The Reproducible Builds project gives the test: “A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts” 9. If a release is reproducible, a researcher can build the published source, compare the result with the logged measurement and know that the code they reviewed is the code that runs. Debian and other software distributions have adopted the practice to protect their supply chains 10.

Reproducibility doesn’t settle everything. A 1984 paper, “Reflections on Trusting Trust”, showed that a compromised compiler can insert behaviour that appears in no source code 11, so the build tools must themselves be trusted or independently reproduced.

What does an oblivious relay add?

An oblivious relay separates who is asking from what is asked. The relay sees the client’s IP address but not the encrypted request; the server sees the request but not the address, so neither alone can link a person to a prompt.

Oblivious HTTP, published as RFC 9458 in January 2024, specifies this pattern for web requests 12. The client encrypts its request to the public key of an oblivious gateway, using hybrid public key encryption (HPKE, RFC 9180) 13, and sends it to an oblivious relay. The relay forwards the request without being able to read it, and the gateway receives it without learning the client’s address. The aim is that a server can’t link requests to the client that made them, or to each other. That holds only if the relay and the gateway are run by parties that don’t collude.

For AI, a relay supports what Apple’s design calls non-targetability: an attacker should not be able to compromise one particular person’s requests without attempting a broad compromise of the whole system. Apple states that Private Cloud Compute requests pass through a relay operated by a third party, which hides the device’s IP address before a request reaches Apple’s infrastructure 6. A relay doesn’t hide everything. It still sees that a client uses the service, and when, and an observer on the network can see the size and timing of traffic.

What are the limits of confidential computing?

Confidential computing narrows whom you have to trust; it doesn’t remove trust. The hardware vendor, side channels and the code inside the environment all remain routes by which data could leak. Table 1 sets out what each layer leaves open.

Table 1What each layer of a confidential AI service protects, and what it leaves open. Compiled from the sources cited in this article.
Layer	What it protects	What it leaves open
Encryption in transit	Data crossing the network	Data once the server decrypts it
Trusted execution environment	Data and code in use, from the host system, hypervisor and administrators	Side channels; the vendor’s hardware and firmware; the code inside
Remote attestation	Knowing which code runs, on genuine hardware	Whether that code is trustworthy
Transparency log	A public, append-only record of every accepted release	Review of what each release does
Reproducible builds	A link from published source to each measurement	Trust in the build tools
Oblivious relay	Separation of the client’s address from its request	Collusion between relay and gateway; the size and timing of traffic

Side channels

A TEE hides data from direct reads, but code running on shared hardware can still reveal information through timing, caches or power use. The CCC notes that a TEE’s assurance “rests on some assumptions, a key one being that there are no exploitable side-channels” 1. That assumption has failed in practice. Foreshadow, published in 2018, abused speculative execution in Intel processors to leak secrets from SGX enclaves, and its authors extracted keys used for SGX’s remote attestation 14. Vendors respond with microcode and firmware updates, and attestation reports typically include the firmware version, so a verifier can refuse machines that haven’t been patched.

Vendor trust

Every attestation chains back to a key the manufacturer placed in the processor, so the manufacturer’s design, firmware and handling of keys are part of what must be trusted. The CCC lists threats that are generally out of scope for confidential computing: sophisticated physical attacks that need long-term or invasive access to the hardware, such as probing a chip under an electron microscope; attacks on the hardware supply chain, at manufacturing or when keys are generated; and availability attacks such as denial of service 1. An operator can always switch a machine off. What it shouldn’t be able to do is see inside.

Accelerators

Protection for accelerators is less mature than for processors. A GPU has its own memory, firmware and drivers, each of which joins the trusted computing base, and data moving between processor and accelerator has to be encrypted, which adds overhead. Accelerator TEEs have also had less public analysis than processor TEEs.

The code inside

Isolation can’t catch ordinary flaws inside the boundary: a bug that writes a prompt to a log, or a model steered by instructions hidden in its input. The defences are published, reviewable code and testing of the system as a whole, covered in ‘Prompt injection, explained’ and ‘AI safety evaluations, explained’.

Why are we studying it for Brello Super Intelligence?

We’re studying confidential computing because Brello Super Intelligence, which is in development, is being designed to send some tasks off the phone, and we intend those tasks to reach only servers that a device has verified. Brello 1.0 doesn’t use it: it has no server, and its models run on the phone.

Brello Super Intelligence · In development

How Brello approaches it

Design intent, not a shipped system. No hardware or vendor has been chosen, and nothing described here has been built or measured.

Default: The device. Work is intended to leave the phone only when a task needs more than the device can give.
Sealed compute: Hardware-isolated, stateless servers designed to keep nothing: no logs, no retention, no human access (Charter v1.0, section 4).
Verification: The device is being designed to check a server’s attestation against a public transparency log before sending any part of a task, and to send nothing if a check fails.
Relay: An independent relay, as in Oblivious HTTP, is intended to keep the device’s IP address from the server that handles the task.
Publication: We will publish a description of the architecture, including what runs where and what each layer can and cannot see, before anyone outside the team uses it (Charter v1.0, section 4).

In Brello 1.0

Where the AI runs: On the phone’s GPU (on Android, through OpenCL) or on its CPU, using Google’s LiteRT-LM runtime. There is no cloud AI and no Brello server.
What leaves: Model downloads, from Hugging Face. With web search on, the search text and requests for up to four result pages go directly from the phone to a search engine and those sites, which see a normal web request, including the phone’s IP address.
What to verify: Nothing remote. Questions, photos and answers are processed and stored on the phone. On Android, chats are excluded from cloud backups and device-to-device transfer.

The design is set out in ‘Private compute you can verify: the design space’, with its threat model and a sketch of an attested request. Under commitment 08 of the Brello Charter, we will publish what independent researchers need to verify what runs, where it runs and what it keeps, before anyone outside the team uses sealed compute. How to make verifiable privacy simple enough for people who aren’t experts is still an open question. How Brello handles your questions, photos and answers describes Brello 1.0’s data flow in full, and ‘How AI assistants handle your data’ covers the wider picture.

References

Reviewed 5 October 2026. Web pages were checked on that date.

Confidential Computing Consortium (2022). “A Technical Analysis of Confidential Computing.” Version 1.3, 2 November 2022. Accessed 5 October 2026. confidentialcomputing.io
Birkholz, H., Thaler, D., Richardson, M., Smith, N. and Pan, W. (2023). “Remote ATtestation procedureS (RATS) Architecture.” RFC 9334, IETF, January 2023. rfc-editor.org/rfc/rfc9334
Costan, V. and Devadas, S. (2016). “Intel SGX Explained.” IACR Cryptology ePrint Archive, Report 2016/086. eprint.iacr.org/2016/086
AMD (2020). “AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More.” White paper, January 2020. Accessed 5 October 2026. docs.amd.com
Volos, S., Vaswani, K. and Bruno, R. (2018). “Graviton: Trusted Execution Environments on GPUs.” Proceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 2018), 681–696. usenix.org/conference/osdi18/presentation/volos
Apple Security Research (2024). “Private Cloud Compute: A new frontier for AI privacy in the cloud.” 10 June 2024. Accessed 5 October 2026. security.apple.com/blog/private-cloud-compute
Laurie, B., Langley, A. and Kasper, E. (2013). “Certificate Transparency.” RFC 6962, IETF, June 2013. rfc-editor.org/rfc/rfc6962
Laurie, B., Messeri, E. and Stradling, R. (2021). “Certificate Transparency Version 2.0.” RFC 9162, IETF, December 2021. rfc-editor.org/rfc/rfc9162
Reproducible Builds. “Definitions.” Accessed 5 October 2026. reproducible-builds.org/docs/definition
Lamb, C. and Zacchiroli, S. (2022). “Reproducible Builds: Increasing the Integrity of Software Supply Chains.” IEEE Software 39(2), 62–70. arxiv.org/abs/2104.06020
Thompson, K. (1984). “Reflections on Trusting Trust.” Communications of the ACM 27(8), 761–763. doi.org/10.1145/358198.358210
Thomson, M. and Wood, C. A. (2024). “Oblivious HTTP.” RFC 9458, IETF, January 2024. rfc-editor.org/rfc/rfc9458
Barnes, R., Bhargavan, K., Lipp, B. and Wood, C. (2022). “Hybrid Public Key Encryption.” RFC 9180, IRTF, February 2022. rfc-editor.org/rfc/rfc9180
Van Bulck, J., Minkin, M., Weisse, O., Genkin, D., Kasikci, B., Piessens, F., Silberstein, M., Wenisch, T. F., Yarom, Y. and Strackx, R. (2018). “Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution.” Proceedings of the 27th USENIX Security Symposium, 991–1008. usenix.org/conference/usenixsecurity18/presentation/bulck

Version history

1.05 October 2026First published.