# The Unofficial Guide to Apple's Private Cloud Compute

Jonathan Mortensen, Confident Security | AI Engineer World's Fair 2025 | 20:36

Source: https://www.youtube.com/watch?v=CCsWZ5bJlO8
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/the-unofficial-guide-to-apples-private-cloud-compute
Published: 2025-07-30
Tags: deployment, inference, privacy, security

## TL;DR
- Apple combines anonymous requests, attestation, hardware protection, and software transparency to run AI remotely without treating the server as trusted.
- Remote attestation binds a server's identity and software claims to a public key, so the client encrypts data only for the code it has approved.
- Private Cloud Compute reduces privacy risks by giving up latency, custom models, usage tracking, simple operations, and support for third-party developers.

## Summary
Jonathan Mortensen explains how Apple's Private Cloud Compute sends AI requests from an iPhone to remote servers while limiting what Apple can learn or retain. The design starts from an untrusted server and adds five guarantees: stateless computation, enforceable restrictions, non-targetability, no privileged runtime access, and verifiable transparency. Six components support those guarantees, including Oblivious HTTP, blind signatures, secure enclaves, secure boot, a hardened operating system, remote attestation, and a transparency log. Mortensen focuses on attestation, which lets an iPhone check the software and hardware claims made by a server before encrypting data for it. The transparency log lets reviewers compare those claims against publicly recorded software releases. He is also direct about the costs: PCC is limited to Apple devices and official apps, adds latency and encryption overhead, does not support custom models or fine-tuning, and complicates operations. He closes by mapping similar techniques to non-Apple hardware and cloud systems.

## Key ideas
### Private AI needs remote compute without making the server fully trusted
[02:08](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=128s)
Mortensen frames the basic conflict around phones and AI. AI models need more compute than a phone can provide, while Apple wants AI to remain a privacy feature. Sending data to a remote service reduces privacy because the recipient can potentially retain or inspect it. A dedicated H100 for every phone would be too expensive, so Apple needs remote compute that is both private and affordable. The server begins as a black box. PCC changes the relationship by giving the iPhone ways to check what the remote service is running and when it may decrypt the request.

### PCC defines five guarantees that code must enforce
[03:53](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=233s)
Apple's requirements begin with stateless computation, meaning received data is used only to answer the request and cannot be logged or reused. Enforceable guarantees remove capabilities instead of relying on policy, such as removing SSH access and storage. Non-targetability makes it difficult to isolate one user's data, using anonymous requests and separated authentication. There is no privileged runtime access that could bypass the restrictions in production. The final requirement is verifiable transparency: the system must provide evidence that the other guarantees are actually in place.

### Anonymizers and blind signatures prevent the service from easily identifying a user
[05:31](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=331s)
PCC sends requests through an anonymizer so Apple's service does not receive the individual user's IP address. Mortensen compares this to laundering everyone's requests together, which makes it harder for an internal attacker to select one person's data. Blind signatures separate authentication from identity. His arcade example uses a coin machine: a person exchanges money for anonymous coins, then spends those coins without revealing which machines they used. In PCC, the iPhone can prove that a request is authorized while keeping that request difficult to link back to the user.

### The system removes ordinary ways to retain or access request data
[07:02](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=422s)
Mortensen describes several direct restrictions. The server has no SSH daemon, so operators cannot bypass the production controls through a privileged login. It has no disk, which removes an obvious place to write request data. With no disk and no access path, the server has little to do with the data beyond producing a response. A hardened, limited version of iOS and signed software make modification harder. These restrictions support stateless computation and make the privacy promises properties of the running system rather than internal rules.

### Remote attestation lets the client approve the exact software running on a server
[10:22](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=622s)
In Mortensen's abstract attestation flow, a client asks a server what it is running. The server returns signed claims and a public key. The claims can identify genuine hardware, a genuine GPU, the bootloader, the Linux version, and the software set. The client decides which claims it trusts, then encrypts its data with the returned public key. The claims and key are bound together, so the server can decrypt the data only while it continues running the approved configuration. This turns the remote server from a black box into something the client can inspect before sending sensitive data.

### A transparency log gives reviewers a reference for attested software
[11:54](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=714s)
The transparency log records software releases and their hashes, with each component signed by a particular person. Reviewers can inspect the publicly available binaries offline and assess their behavior. When an attestation reports a binary hash, the client or reviewer can compare it with the log and check that the reported software is one that was recorded. Mortensen says the log is append-only and uses a Merkle tree, so its contents cannot simply be changed. An attestation that does not appear in the log indicates that the system has been compromised or the connection has been interfered with.

### Attestation and the log work together before the iPhone sends data
[13:22](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=802s)
The iPhone first routes a request through the anonymizer and asks for an attestation package. It checks whether the claims match software in the transparency log. If the result is trusted, the iPhone encrypts its data for the public key in that package. The AI engine can decrypt the data only while it is still running the exact configuration described by the attestation. If the software changes, the binding between the key and the claims fails, so the engine cannot use the encrypted request. The log supplies the recorded reference, while attestation reports the live server state.

### PCC accepts significant operational and product trade-offs
[15:09](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=909s)
PCC still requires trust in Apple. Mortensen points out that Apple controls much of the supply chain and re-signs nodes, but users cannot guarantee that Apple generated or handled every credential correctly. Consumer access is limited to Apple devices and official apps. Requests sent to Apple's data centers add latency, and multiple encryption layers add compute cost. PCC does not allow custom models or fine-tuning. Its client libraries must coordinate anonymization, authentication, attestation, and log checks. Operators cannot SSH into machines, there is no ordinary logging, and Apple cannot provide normal per-customer usage tracking without weakening anonymity.

### Developers can assemble similar pieces outside Apple's hardware
[17:33](https://www.youtube.com/watch?v=CCsWZ5bJlO8&t=1053s)
Mortensen maps PCC's components to existing systems. Oblivious HTTP and blind-signature libraries are available outside Apple. Intel and AMD systems commonly provide TPMs, and cloud providers offer virtual TPMs for storing keys tied to platform state. Remote attestation is partly available through TPMs, although standards are still developing. Sigstore and Sigsum provide open transparency-log options. Cloud confidential VMs with GPUs are also emerging; Mortensen says H100 and H200 systems support encrypted memory. Non-Apple environments have another advantage: open-source code and reproducible builds can connect source code to binaries and give researchers more ways to inspect what a server runs.

## Notable quotes
- "The question that Apple is trying to answer in their PCC system is how do you get remote compute while remaining private and cheap." (02:28)
- "The most important one is verifiable transparency." (04:45)
- "You can only decrypt my data if you're still running that code." (07:20)
- "PCC still requires you to put all of your trust in Apple." (14:52)
- "The client libraries are very complicated." (16:43)

## Tools & references mentioned
- Apple Private Cloud Compute
- DeepSeek
- ChatGPT
- OpenAI
- Cloudflare
- Oblivious HTTP
- TPMs
- Sigstore
- Sigsum
- H100
- H200
- Azure AI
- Meta
- WhatsApp
- Llama
- Confident Security

## Who should watch
- You are building an AI feature that sends sensitive data to a cloud service and need a concrete model for reducing trust in the server.
- You want to understand remote attestation, blind signatures, TPMs, or transparency logs through one production-oriented architecture.
- You are weighing private inference against latency, custom-model support, observability, and operational simplicity.

## Related talks

- [GPU-less, Trust-less, Limit-less: Reimagining the Confidential AI Cloud](https://aietalks.com/talks/gpu-less-trust-less-limit-less-reimagining-the-confidential-ai-cloud) (Mike Bursell, Super Protocol, 43:41)
- [Privacy-Preserving Intelligence](https://aietalks.com/talks/privacy-preserving-intelligence) (Steve Korshakov, Bee (acq. Amazon), 15:53)
- [Personal, Local, Private AI Agents](https://aietalks.com/talks/personal-local-private-ai-agents) (Soumith Chintala, Meta, 20:32)
- [Why MLX](https://aietalks.com/talks/why-mlx) (Prince Canuma, Neywa Labs, 23:10)
- [Why Eval++ Is the Next Great Compute Primitive](https://aietalks.com/talks/why-eval-is-the-next-great-compute-primitive) (Sunil Pai & Matt Carey, Cloudflare, 24:51)