The Unofficial Guide to Apple’s Private Cloud Compute

What makes an AI service private: a promise about how it handles your data, or technical limits on what it can do? Jonathan Mortensen approaches that question from both AI and security. His background includes a PhD in biomedical informatics and data science, two sold companies spanning AI/data and cybersecurity/infrastructure, and work at South Park Commons building Confident Security. This is his unofficial, public-source explanation of Apple’s system, not an account on Apple’s behalf. Privacy and security overlap, but protecting a service from attackers does not by itself prevent its operator from retaining your requests.

The first example is DeepSeek’s exposed database. Wiz’s original disclosure reported over one million exposed log lines, including chat history and other sensitive information. That is more precise than treating the count as distinct conversations or confirmed stolen records. Mortensen then polls the room: Who cares about privacy? Who uses ChatGPT? Who considers it private, or uses its private mode? The tension is familiar: people can care about confidentiality while relying on a service whose internal handling of their data they cannot inspect.

The next example is a court order to preserve ChatGPT logs. Mortensen describes the obligation as covering everything, including private interactions, and calls API Zero Data Retention a default. Those details need a historical distinction: OpenAI’s account excluded qualifying Zero Data Retention API arrangements and Enterprise/Edu services; ZDR was a distinct arrangement, not the ordinary API default. Its later update says the prospective retention obligation ended September 26, 2025. The architectural question survives that correction: a privacy setting does not necessarily remove the provider’s ability to retain data.

Apple’s problem begins with a mismatch: some AI tasks require more compute than a phone can provide, while privacy is a major reason people buy the phone. Sending data elsewhere introduces another party into its handling. Giving every phone its own dedicated cloud H100 would be an extravagant answer; the practical requirement is remote compute that remains both private and affordable.

Imagine an iPhone facing an untrusted server. The server is a black box: once the phone submits data, it cannot see what happens inside. Private Cloud Compute, or PCC, attempts to give the client evidence about the system receiving that data, plus enforceable restrictions on its behavior. Mortensen organizes the design around five requirements and six technical components, then examines remote attestation and transparency logs in depth.

The distinction between policy and capability is concrete. “Administrators should not SSH into this instance” leaves an access path available. Removing SSH removes that path. Mortensen similarly uses removing the disk as a conceptual illustration of preventing persistence. The objective is that user data cannot be logged or reused for unrelated purposes, and that the client can verify the system supporting that objective.

Start with an ordinary service: an authentication layer fronts an AI engine, an SRE can access the engine, and the engine can write to disk. Adding an anonymizer hides the request’s network origin, but it does not solve the whole identity problem. If the phone still presents identifying authentication credentials downstream, those credentials can reconnect the request to its user.

Blind signatures separate obtaining authorization from spending it. Mortensen’s analogy is an arcade: first exchange money for coins, then spend those coins at machines. A machine accepts a valid coin without learning which purchase of coins produced it. Likewise, the inference service needs evidence that a request is authorized without receiving a credential that identifies the person who obtained it. Combined with the anonymizer—loosely compared to Tor—this reduces the information available to someone trying to locate a particular user’s requests.

Next, change the order of disclosure. Before sending the sensitive input, the phone asks, “What are you running?” It accepts a particular software configuration and only then submits encrypted data. Mortensen describes the intended binding as allowing decryption only by the trusted configuration. Removing sshd and preventing persistent retention then limit what that configuration can do with the plaintext. Verification and capability restrictions work together: knowing the software matters because the accepted software is supposed to enforce the data-handling rules.

The conceptual changes map onto six technical components. The first two separate identity from inference:

• Oblivious HTTP: an independent relay forwards the request so the destination sees the relay’s IP address rather than the user’s. Mortensen identifies Cloudflare as the relay for PCC requests; the essential architectural property is the separation between the requester’s network identity and the inference destination.
• Blind signatures: the service can validate authorization without linking redemption to the user who obtained it. This supplies the anonymous arcade coin that an anonymizer alone cannot provide.

Mortensen points to specifications and existing libraries for these mechanisms rather than suggesting that developers invent the cryptography themselves.

The next components establish and constrain the machine’s identity:

• Secure Enclave: separate hardware protects private keys from export. If another machine could copy the identity key, it could impersonate the genuine engine. Mortensen introduces TPMs as a non-Apple analogue for this role.
• Secure boot and a hardened operating system: a restricted, signed software environment reduces opportunities to modify the server. Mortensen describes it as a limited iOS-derived system; Apple’s architecture draws on both iOS and macOS foundations.

The remaining components expose evidence to the client: remote attestation describes the running system, while a transparency log records published software so the client can compare that description with a public record.

Remote attestation can be understood independently of the iPhone:

1. The client requests evidence about the server.
2. The server returns signed claims and a public key.
3. The client checks the claims against its acceptance policy.
4. If the evidence is acceptable, the client encrypts its request for the corresponding key.

Claims might identify genuine hardware, a GPU, the bootloader, the operating-system version and the application software. An acceptance policy might require a trusted signer or reject an older Linux kernel. The server provides evidence; the client decides whether that evidence describes an acceptable environment.

The key must be bound to the attested environment. Otherwise, a server could present reassuring claims but ask the client to encrypt for an unrelated recipient. Mortensen explains the binding as decryption remaining possible only while the accepted claims hold. At this conceptual level, that describes the security objective, not a continuously polled software check: the details depend on protected keys, cryptography, certificate chains and vendor trust. The black box becomes more translucent because the client receives authenticated evidence about the destination before disclosing its input.

An attestation can identify software without explaining whether that software deserves trust. A transparency log supplies the public record needed for review. Mortensen’s example is a record saying that Bob signed a compiled binary, identified by its hash, on November 1, 2024. Records can describe whole releases or individual components. Reviewers obtain the published binaries and inspect their behavior offline; later, a client can recognize the same binary hash in an attestation.

The matching rule is small enough to illustrate directly. In this TypeScript example, reviewedHashes represents a local policy decision made after review. Both inputs to the function are already authenticated evidence; the function performs only the final membership and acceptance check.

type PublishedBinary = {
  signer: string;
  publishedOn: string;
  sha256: string;
};

function acceptPublishedBinary(
  attestedHash: string,
  authenticatedEntries: readonly PublishedBinary[],
  reviewedHashes: ReadonlySet<string>,
): boolean {
  const published = authenticatedEntries.some(
    entry => entry.sha256 === attestedHash,
  );
  return published && reviewedHashes.has(attestedHash);
}

A published binary is not automatically a trusted binary. The log establishes that it is publicly recorded; review and client policy determine whether it is acceptable.

An attestation for software absent from the log should fail that gate. Mortensen treats such a mismatch as a sign of compromise, potentially including a hijacked connection. The log itself has restricted writers and an append-only Merkle-tree structure: cryptographic proofs make unauthorized changes to its history detectable. That is stronger than trusting an ordinary mutable database to keep an honest release history.

The phone first requests an attestation package through the anonymizer. It evaluates the package before sending sensitive input. If it accepts the environment, it encrypts for the key bound to that environment; the intended result is that a different, unaccepted environment cannot decrypt the request. The transparency check connects the attested software to Apple’s public release records, whose binaries can be examined offline.

Around that exchange, Oblivious HTTP hides network origin, blind signatures provide anonymous authorization, and the Secure Enclave protects keys in hardware separate from the AI engine. Secure boot and operating-system hardening constrain the runtime. These are complementary boundaries: the relay does not establish software integrity, and attestation does not by itself make an identifying credential anonymous. The assembled architecture needs both.

Attestation does not eliminate trust in Apple. Apple controls the supply chain and checks nodes when they arrive at its data centers. Mortensen also describes provisioning identities called DCIKs, while tentatively expanding the acronym. The deeper dependency is key provenance: shared identity material, insecure key generation or a private key set to the same trivial value everywhere would undermine the evidence. These are hypothetical failures illustrating where trust remains, not allegations about Apple’s implementation. At the time of the talk, Mortensen describes PCC as confined to Apple devices and official consumer applications.

The performance path starts locally: a device uses local models when they are adequate and calls a data center when they are not. Network distance then matters, especially for real-time voice. Mortensen describes roughly six layers of encryption before the inference node, adding compute work. He provides no measured latency or cost comparison. The offering he describes also excludes custom models and fine-tuning.

Stateless inference does not mean a stateless client. The client must coordinate authorization, attestation, transparency checks and encryption rather than make a single ordinary HTTP request. If the phone fails after authenticating and loses its authentication keys, the client must recover from that lost state. The server’s refusal to retain request data makes the client protocol more consequential, not less.

Operations and accounting become harder too:

• Debugging: removing SSH and preventing request-data logging removes familiar diagnostic tools. Apple’s design still permits restricted operational metrics; the restriction concerns exposing or retaining user data, not eliminating all observability.
• Usage accounting: Mortensen uses a 2,000-token allowance as an example of the tension between customer-specific metering and unlinkable requests. Charging a named customer for particular inference work requires a linkage the anonymous request path is designed to avoid.
• Abuse controls: he acknowledges coarse fraud and abuse tracking even while fine-grained user linkage is restricted.

This is a design constraint for anyone building a similar service and passing costs to customers. Mortensen closes the trade-off discussion by reiterating that PCC was not available as a general third-party developer service in the offering he was describing.

Developers outside Apple’s ecosystem can assemble related mechanisms, though the hardware and trust boundaries differ.

Mortensen presents TPMs as widely available on contemporary Intel and AMD hardware, and virtual TPMs as a cloud option for the same key-management role. That functional analogy does not make every virtual TPM’s trust boundary identical to physical hardware. He describes attestation integration as less standardized and straightforward than the other pieces. For public transparency systems, he names Sigsum and Sigstore, whose relevant log component is Rekor.

Confidential VMs extend the discussion from protected keys to protected computation. For AI, that protection also needs to cover the GPU path. Mortensen identifies H100 and H200 as the confidentiality-capable GPUs in his account and explains the goal through a physical-memory-inspection example. The exact memory protections and supported hardware depend on the platform; that example should not be read as a blanket guarantee of encrypted GPU memory or immunity to physical inspection.

Open source and reproducible builds add another useful connection: reviewers can examine source code and establish that it corresponds to the published binary, rather than relying only on black-box binary testing. Mortensen contrasts this with Apple’s approach. Apple had also released selected PCC security-critical source under a limited-use license; that is different from making the entire production stack open source and reproducibly buildable. The engineering opportunity is to connect source review, binary identity, public release records and live attestation into one chain of evidence.

The closing discussion moves from components to adoption. Apple announced PCC in June 2024; Mortensen places its release in October 2024. He then points to Azure AI—explicitly correcting himself from Azure OpenAI—as pursuing private inferencing, with a September start and private-preview status in his account. Meta’s Private Processing announcement followed on April 29, 2025, describing an early architecture ahead of rollout. Mortensen characterizes its approach as essentially identical to PCC; the useful comparison is the shared privacy principles, not identical hardware or implementation. For WhatsApp, as for Apple, protecting private interactions is also a reputational concern.

Mortensen’s own commercial answer is Confident Security, which he pitches as a similar service for people outside Apple and WhatsApp. He closes by inviting questions afterward and offering privacy-themed merchandise, including a shirt he says confuses facial recognition in photographs. The shirt is a playful extension of the same concern that opened the talk: what happens to personal information once another system receives it?