Verifiable Transparency and Non-Targetability

Suppose a provider runs every inference in an attested enclave and publishes the design. There are two moves left that break the privacy promise without breaking any cryptography. The provider can build a version of the serving image that copies prompts somewhere, sign it, and deploy it: attestation will certify it happily, because a measurement is an identity and this image is exactly what it claims to be. Or the provider can leave the software honest and instead route one particular user's requests to a node that is being watched, which requires no software change at all.

Both are targeting problems rather than confidentiality problems, and both need architectural answers. Apple's Private Cloud Compute is the most fully specified public attempt at those answers, built around five stated properties: stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, and verifiable transparency (Apple Security Engineering and Architecture, 2024, Private Cloud Compute: A new frontier for AI privacy in the cloud).

Transparency closes the "one bad build" move

The mechanism is borrowed from Certificate Transparency. Every production software image is published, with its measurement, to an append-only, cryptographically verifiable log. The client device checks the node's attestation against that log and refuses to send the request if the running image is not there. A malicious build is then not merely detectable in principle; it is globally publishable evidence, because to use it the provider must first enter it in a log that researchers are watching.

The property this buys is subtle and worth stating precisely. Transparency does not prove the image is safe. It makes it impossible to target silently: the provider cannot serve a special build to one user, because every build a client will talk to is in a log every user reads from. The attack is converted from an invisible one into one that leaves a permanent, signed record.

For that to be worth anything, the log entries must be tied to something inspectable. Apple publishes the binary images alongside the log for security researchers, which is weaker than source and stronger than nothing; an independent analysis notes exactly this limitation, that compiled binaries add "a layer of opaqueness" to much of the specification (Unlocking Apple's Private Cloud Compute: An Analysis of Privacy-Preserving Artificial Intelligence, 2026, arXiv:2605.24239).

Non-targetability closes the "watch this one user" move

Non-targetability is the requirement that an attacker cannot go after a specific user's data without attacking the entire fleet. It is enforced by removing the information that would let anyone route a known user to a chosen node.

The construction has several parts, and each is doing real work. Requests reach the fleet through an anonymising relay so that the nodes never see client IP addresses, and the relay never sees request contents. User identity is separated from the request payload, so a node processing a request does not know whose it is. Node selection is not under the requester's control. And nodes are stateless: data lives only in memory for the duration of the request, with no persistent logging, so a node seized afterwards holds nothing. Apple's stated threat model explicitly includes an attacker with physical access to a node and the sophistication to subvert some hardware protections, which is the assumption that forces statelessness rather than merely encrypted storage.

The 2026 expansion of PCC beyond Apple's own data centres, onto Google Cloud infrastructure with NVIDIA Blackwell GPUs, Intel TDX and Google's Titan security chip, kept these properties as the contract and added an append-only ledger of the third-party hardware admitted to the fleet (Apple, 2026, Expanding Private Cloud Compute). That ledger exists because "which machines are even eligible" is a targeting surface once the machines are not yours.

When it breaks

The client is the enforcement point. Every guarantee here is enforced by software on the user's device deciding not to send a request. A provider that also controls the client can weaken the check. Transparency protects users of an honest client against a dishonest server; it is not a defence against a provider who controls both ends and is willing to ship a modified client, though that too becomes a publishable artefact.

Logs need auditors. An append-only log with no one reading it detects nothing. The security property is "misbehaviour is discoverable", which is only realised if researchers actually have the images, the tooling and the motivation to look. Publishing a log is cheap; sustaining an audit community is not.

Statelessness fights operability. No persistent logs means no request traces to debug with, no replay of a failing prompt, no per-user audit trail. Teams that adopt the pattern without accepting that tradeoff quietly add "temporary" diagnostic logging and lose the property they were building toward.

Metadata escapes. Request timing, size, duration and frequency are visible to the relay and the infrastructure even when contents are not. Traffic analysis over a long enough window is a real attack on unlinkability, and no part of this architecture claims to stop it.