Core Security and Privacy Requirements

Overview

Secure and private AI processing in the cloud poses a formidable new challenge. Apple uses on-device processing to keep user data on the device wherever possible, though more sophisticated Apple Intelligence features need larger models than a device can run. Powerful AI hardware in a data center can fulfill these complex requests, but this approach requires unencrypted access to the user’s request and accompanying personal data. We believe end-to-end encryption is our most powerful defense for protecting the most sensitive data, and its strength rests on both endpoints being ones the user controls. A cloud AI service adds an endpoint the user neither controls nor can inspect. Cloud AI applications typically rely on traditional approaches to cloud security instead.

Such approaches have three common properties, each intrinsic to the traditional cloud-service security model:

• Security and privacy guarantees are difficult to verify and enforce.

• Runtime transparency is difficult to provide, so a service cannot conclusively show what software is running and how it is being used.

• Strong limits on privileged operator access are hard to enforce.

These challenges mean that conventional cloud AI requires the user to trust a large surface area with their data: the software that processes a request, the staff who can reach the machines that run it, the organization operating the service, and the hardware supporting it all.

By contrast, when on-device processing is possible, the security and privacy advantages are clear: the user controls their own device, Apple retains no privileged access, and researchers can inspect both hardware and software, so their security is verifiable rather than assumed.

Our goal for Private Cloud Compute is to make cloud AI processing an extension of the security and privacy of the user’s own device, removing the need for the user to trust the service that processes their data.

Meeting that goal takes an extraordinary set of requirements, which we group into three layers:

High-security inference

Provides an auditable, hermetic pipeline designed to defeat the typical attackers that any production cloud service faces, including external intruders, insiders, and attackers in the software supply chain. By constraining how the pipeline handles user data and making the pipeline auditable, PCC lets the operator technically enforce that this pipeline uses user data only in accordance with the operator’s stated policies.

Verified service and cloud

Removes the operator from the set of parties a user has to trust. Anyone must be able to analyze the components that critically contribute to the guarantees of the overall PCC system, and a user’s device must confirm that a node runs the published software before entrusting it with user data. Every call that sends data outside PCC must be recorded where the user can see it, and no operator may route a chosen user’s request to hardware or software it has compromised.

Frontier security and privacy

Reduces reliance on any single root of trust. Audited provisioning processes or independent roots of trust from separate vendors anchor the integrity of the fleet, so no single organization or vendor can make a node appear genuine on its own. Full-stack attestation must cover everything that can execute on a node, leaving an adversary no co-resident code from which to launch a side-channel attack.

High-security inference

Requests that need larger models than a device can run go to a PCC node instead. High-security inference holds that node to the protections a user’s own device provides: data stays encrypted until it reaches a runtime that uses it to answer the request and keeps nothing afterward.

That runtime rests on an auditable, hermetic inference pipeline, which addresses the threats any production cloud service faces: requests crafted to exploit the pipeline, lateral movement onto internal interfaces from elsewhere in the network, compromised privileged credentials and malicious insiders, attacks on the software supply chain, and the accumulation of user data in observability and analytics systems.

Each component with access to user data, or with the ability to influence how the pipeline protects that data, contributes to the trust boundary of a cloud AI service. Everything inside this trust boundary is both something the user has to trust and an entry point for an attacker. A high-security inference pipeline must therefore be analyzable, not merely well-intentioned. Its design must consider the entire trust boundary: the pipeline must minimize the number of components inside the boundary, so that an analysis of the boundary can support strong statements about the handling of user data, and each component inside it must maintain the security and privacy properties of the pipeline as a whole.

Stateless computation on personal user data

Private Cloud Compute must only use the personal user data it receives to fulfill the user’s request. User data must never be available to anyone other than the user, not even to Apple staff, not even during active processing. And once the session with the user’s device terminates, PCC must not retain access to that data, in logs, for debugging, or in any other form.

Efficient inference is in tension with statelessness, because reusing computed state is what keeps a long interaction fast. Cryptographic key control relieves that tension. When PCC caches state, such as during a Multi-Turn Agent, it caches that state encrypted with a key the user’s device provides. PCC does not retain a copy of that key between turns. We designed this statelessness across the turns of an interaction to ensure that PCC can decrypt the cached state only if the user’s device sends another request that includes the cache decryption key.

To learn more about this requirement, see Stateless Computation.

Enforceable guarantees

Security and privacy guarantees are strongest when they are entirely technically enforceable, which means every component inside the trust boundary must be one we can constrain and analyze. Standard service components that cannot be constrained this way, such as TLS-terminating load balancers, must therefore have no access to user data. Only code Apple authorizes and cryptographically measures may execute on a node, forming an immutable runtime that is sealed before the node accepts user data. This requirement extends to operational needs as well: collecting server metrics and error logs must be supported by mechanisms that do not undermine privacy protections.

To learn more about this requirement, see Enforceable Guarantees.

No privileged runtime access

Private Cloud Compute must not contain privileged interfaces that could enable staff on Apple’s site-reliability team to bypass PCC privacy guarantees, even during an outage or another severe incident. This also means that PCC must not support any mechanism that might enlarge the privileged access envelope at runtime, such as by loading additional software. Such interfaces are also incompatible with a hermetic runtime: a node exposing an unbounded debugging or administrative interface is no longer analyzable.

To learn more about this requirement, see No Privileged Runtime Access.

Verified service and cloud

A high-security inference pipeline defends a node against attackers other than the operator running it. The operator chooses what software to deploy, so even the absence of privileged runtime access lasts only as long as the operator keeps deploying software that has no such interfaces. A user cannot check that from outside, so protecting sensitive data means removing the operator from the set of parties they have to trust.

PCC does so by making the fleet independently auditable: a node proves through attestation that it runs software recorded in the Release Transparency, and user data reaches it only if that proof holds.

Three attacks remain available to a service operator, each answered by one requirement of this layer:

Software modification

The operator runs software whose data retention or use differs from its public claims.

Callout manipulation

The operator leaks data out of the trust boundary through the calls the inference pipeline makes to external services.

User-targeted substitution

The operator singles out a user, routing that user’s request to software or hardware it has compromised, so reaching a chosen person costs no more than subverting a few nodes.

Verifiable transparency

Security researchers need to be able to verify, with a high degree of confidence, that our Private Cloud Compute privacy and security guarantees match our public promises. We require our guarantees to be enforceable, so security researchers with sufficient access to the system could verify them. But verifiable transparency goes one step further and does away with the hypothetical: security researchers must be able to verify the security and privacy guarantees of Private Cloud Compute, and they must be able to verify that the software that’s running in the PCC production environment is the same as the software they inspected when verifying the guarantees. Enforcement of this property must be anchored on the user’s device, which encrypts the request only to nodes whose attested measurements appear in the public transparency log.

To learn more about this requirement, see Verifiable Transparency.

Callout transparency

Some capabilities expected of a modern agentic AI system, such as querying world knowledge, depend on information or services that are infeasible to host inside Private Cloud Compute: a node’s software and assets are fixed and measured before it accepts user data, and world knowledge changes continuously. PCC makes outbound calls so that a request can reach that information, and they necessarily send query-derived data outside PCC. These calls must therefore offer the same level of privacy and inspectability as if they occurred on-device: they must be made without user-identifying metadata, and a record of every outbound call must be returned to the user’s device for inspection. Because that record reaches the user, an operator cannot quietly route data outward through a call nobody sees.

To learn more about this requirement, see Callout transparency.

Non-targetability

An attacker must not be able to compromise personal data that belongs to specific, targeted Private Cloud Compute users without attempting a broad compromise of the entire PCC system. Verifiable transparency and callout transparency cannot supply non-targetability on their own: an operator that publishes and attests honestly for the population as a whole could still route one user’s request to hardware or software it has compromised.

Three properties are required:

Anonymous request routing

Routing must depend only on metadata that cannot identify the user, so an attacker cannot steer a chosen user’s request onto a node it controls.

Target diffusion

Each node must be able to access only a small portion of incoming requests, so that an attacker must compromise many nodes to reach most requests.

Routing transparency

The user’s device must be able to audit which nodes handled its request, so an operator cannot bias routing unobserved.

We believe non-targetability is fundamental to a private cloud AI service, because it sets the terms for attacks across the whole design. Routing depends on no user-identifying metadata, so an attacker cannot choose which node serves a particular user. Catching a chosen user’s request instead means compromising nodes on a scale that Apple’s monitoring and independent audits are likely to detect. The same property bounds what a successful attack yields: because a request carries no user-identifying metadata, an attacker who reads an undisclosed side channel still has to attribute the leaks to the user who sent the request.

To learn more about this requirement, see Non-Targetability.

Frontier security and privacy

Once a node’s software is open to public verification and routing carries nothing that identifies a user, the system must still defend against frontier adversaries. These adversaries have the resources to attempt physical tampering or side-channel extraction, and two attack classes remain available to them:

• An adversary who becomes co-resident with an otherwise hermetic workload can exploit side channels to access user data indirectly.

• An adversary who compromises the hardware roots of trust anchoring a node’s attestation can forge that attestation, breaking verifiable transparency.

Before entrusting cloud AI with our users’ most sensitive data, we must weigh the risk these attacks pose in the hands of well-funded adversaries. These adversaries may use both their resources and their reach into the systems PCC itself depends on, such as the cloud infrastructure a node runs on or the offline hardware security modules used in a Certificate ceremony process, to carry out attacks beyond those that any production cloud service ordinarily faces. Two requirements defend against them: PCC must leave such an adversary no co-resident code to launch from, and it must root the integrity of its fleet in more than one party.

Side-channel resistance

Published research repeatedly shows side-channel attacks to be practical, including against language-model inference and against the isolation that confidential computing provides. Private Cloud Compute must therefore defend against them. Its primary defense is architectural: a node must leave no co-resident code from which an adversary might launch an attack. That requires Hermetic environment together with the transparency to check it: the attestation’s measurements must cover everything that can execute on a node, not only the compartment a workload runs in, and the measured software must be published so a researcher can confirm that nothing else can run there. Some channels remain observable from outside a node, such as those carried by network traffic, and PCC implements and documents mitigations for specific attacks.

PCC’s Resisting side-channel extraction follows from where the hermetic boundary is drawn.

Auditable and redundant hardware provisioning

Private Cloud Compute must not rely on a single source of provisioning to establish trust in the integrity of the fleet. Instead, PCC’s hardware provisioning process must have two properties:

Multi-party control

The provisioning of any component an attacker might use to exfiltrate user data must either derive from two different roots of trust held by two different suppliers or take place in the presence of an independent auditor.

Auditable provisioning

The hardware and cryptographic identities of every node admitted into the production fleet must be recorded in an append-only, cryptographically verifiable ledger, to enable anomaly detection and forensic analysis.

These two properties help ensure that admitting a subverted node requires a severe, multi-party breach.

To learn more about this requirement, see Hardware Provisioning.

Security by design

We believe this set of requirements represents a generational leap over any traditional cloud-service security model.

Confidential computing isolates a workload from the host it runs on and attests to what runs inside that boundary. That is a foundation for high-security inference, and it is where many cloud AI deployments stop. On its own, it still leaves a user trusting the service operator.

Meeting PCC’s requirements takes a system designed for these properties from the start. These requirements are properties of PCC as a whole rather than of any one kind of node: they hold identically whether an Apple silicon node or a Google Cloud node serves a request, and each platform is designed to meet them in full. Some risk remains even when all of them hold, because software and hardware both have bugs, and hardware defenses raise the cost of an attack rather than eliminate it; Evaluating Private Cloud Compute works through the threat scenarios these requirements are measured against and identifies where further hardening is possible.