--- title: Evaluating Private Cloud Compute framework: Private Cloud Compute Security Guide role: article role_heading: Article path: private-cloud-compute/attacks --- # Evaluating Private Cloud Compute PCC’s core requirements hold against attackers who exploit the service, against its operator, and against adversaries who attack its hardware. ## Overview Overview Core Security and Privacy Requirements groups PCC’s requirements into three layers, each addressing a broader class of adversary than the one beneath it: High-security inference, the first layer, defends against the threats that any production cloud service faces. Accidental disclosure: A log line, metric, crash report, or other operational data inadvertently contains user data. Stateless computation on personal user data requires that user data stay inside the trust boundary of a PCC node, so every path out of a node is built and reviewed to avoid collecting user data. External compromise: An attacker submits a request crafted to exploit the software that handles it. PCC is designed to Resisting exploitation, limiting the data that can be accessed by such an attack and preventing lateral movement. Physical or internal access: An attacker holds an operator’s credentials, reaches an internal interface, or stands in front of the machine. PCC’s requirement of No Privileged Runtime Access puts user data beyond the reach of any administrative credential or internal interface. Verified service and cloud, the second layer, defends against the operator of the service itself. A dishonest operator: The operator of a cloud AI service runs software that differs from what it publishes, or operates the service inconsistently with its published privacy promises. PCC is designed so that no one, not even Apple, has access to user data. Verifiable Transparency, Callout transparency, and Non-Targetability make PCC’s privacy promises verifiable, so anyone can analyze the system and verify these promises. Frontier security and privacy, the third layer, defends against the attacks that remain once a node’s software is open to verification and a user’s request is beyond being singled out. Frontier adversaries: A well-funded attacker reads user data through a side channel or subverts the system’s hardware roots of trust. PCC is designed for Resisting side-channel extraction and uses Hardware Provisioning processes to defend against these attacks. PCC serves requests across two platforms, Apple silicon nodes and Google Cloud nodes. Both platforms enforce the same security and privacy guarantees; where the mechanisms differ, we describe the approach each platform takes. PCC has multiple layers of security for defense-in-depth protection, combining security mechanisms that prevent or hinder exploitation to help ensure that our core requirements withstand these adversaries. We also recognize that further improvements may strengthen the security properties of PCC, so we include known limitations of the current system and invite external researchers to do their own evaluation of our design. Accidental disclosure PCC’s fundamental privacy goal is stateless computation: user data serves only the request that carried it, and PCC discards that data after returning the response. The High-security inference includes every component with access to user data, or with the ability to influence how the system protects that data. For a single request, that boundary is the set of PCC nodes processing it. If any data were to leak across this boundary, it would be a violation of our requirement for stateless computation, regardless of how the data is subsequently handled. To consider the risk of accidental disclosure, we look at the paths that data takes in and out of a node: the encrypted request channel, node observability output, and local storage. Request encryption Keeping user data inside the boundary starts with encrypting requests end to end between a user’s devices and the nodes that serve them. PCC protects data in transit at three points: The user’s device encrypts each request end to end to a Node selection. No intermediary services can access the request, and responses are encrypted back to the client using the same encrypted connection. A PCC proxy node Transitive Trust to every other PCC node involved in processing the request. Processes computing on user data are isolated from processes that On-Node Request Termination. On an Apple silicon node, sandbox profiles enforce this isolation and deny the computing processes outbound network connections. On a Google Cloud node, each component’s Workload hardening declares whether it shares the Workload VM’s network namespace or runs in an empty one of its own, and the process that decrypts the request and the inference runtime each run in an empty namespace. In both environments, Apple auditors and security researchers can monitor these configurations to identify changes in the processes that are exposed on the network. When a model spans an Distributed inference on Apple silicon, member nodes exchange user data in flight. Those nodes encrypt that data in transit, and maintaining PCC’s transparency promises requires two further properties: the software measurements of each destination node match the measurements that the user’s device or a proxy node acting on its behalf verified and accepted, and the set of nodes that can join the ensemble is fixed before the request arrives and is visible to that device or proxy. Ensemble attestation supplies both. Key negotiation succeeds only among members reporting identical measured releases, and the leader’s attestation carries a commitment to each member’s Certificate ceremony process, recorded in the node’s attested configuration at boot. Using that negotiated key to exchange user data keeps the data inside the set of trusted nodes processing the request. Some requests involve interactions with services outside the PCC trust boundary. Where possible, PCC keeps tools inside the trust boundary or uses cryptographic techniques to protect query privacy: a Private Information Retrieval (PIR) query uses homomorphic encryption, so the database server returns a record without learning which record the query selected. For tools that must reach outside the boundary, such as world-knowledge lookups, PCC uses External tool calls. Each call sends cleartext to a tool gateway and its downstream provider, because external services and world knowledge reside outside the trust boundary; Callout transparency lets privacy researchers audit the data leaving the system on this path. System observability Effective operation of PCC requires nodes to emit targeted, specific data about the runtime behavior of the system. This data includes custom, privacy-aware exporters for logs and metrics, using industry-standard protocols. We designed the PCC node to centralize the export of observability data into a small number of exit points: Each exit point filters the data it allows to leave the node, and Apple has processes in place to help ensure multistage review of new data that the filters enable. Pre-release audits inspect telemetry definitions and compile the approved output into Operating the service without privileged access, enumerated individually for the components that handle request data. A particular challenge is that log format strings can appear safe on static inspection but produce user data at runtime, for example, when string interpolation invokes an object’s description method, which may traverse properties that contain user data. The review process considers the data types included in each log line to help identify these cases. Some diagnostics resist advance review because their contents depend on the state of a running process, so those get dynamic treatment instead: Crash reporting redact memory state likely to hold user payloads, and rate limits and random sampling bound how many leave a node. PCC Agent can also block a request through server-side mechanisms: a Safety overrides rejects unsafe content in a request or in the model’s response, the Content-safety guardrail rejects unsafe request content, and Recitation prevention blocks output that reproduces content verbatim. Because these mechanisms act on request content, observing their behavior could reveal information across the PCC trust boundary. To address this, we designed PCC so these mechanisms keep the specific reason for a block inside the node: the error a client receives does not distinguish one blocking mechanism from another, and the log lines that name a match are approved for internal environments only. The operational metrics that do leave a node are counts and latencies. Where a count would itself distinguish a block from a normal completion, an Apple silicon node applies In-node aggregation to decouple it from individual requests, adding noise and withholding the value until it clears a threshold. Other operational metrics, such as internal networking errors causing a fail-closed block, are exported directly. Inferring whether a particular request was blocked requires correlating log records across processes, and recovers only the coarse outcome of a check, while the matched content and user input remain private. PCC’s observability data filtering limits the accidental export of user data through diagnostic tools, though residual disclosure hazards remain. Enabling research and auditing of the data exposed by these tools helps discover and remediate issues quickly. When possible, PCC software releases include easily readable data files containing policy information used for data filtering, so Apple auditors and security researchers can inspect and analyze policy changes for issues. In addition to enabling offline analysis, both research environments let a researcher analyze a running system: the Virtual Research Environment (VRE) supports Inspect diagnostic logging emitted from an Apple silicon node, and a Google Cloud Research Environment offers the equivalent through Inspect telemetry egress. If user data were to be accidentally exposed, PCC enforces strict data-handling policies to protect data confidentiality: connections used to transmit observability data require mutual TLS, access is restricted, and data is maintained with a limited retention period. Despite these steps, observability data can still include user data accidentally. Log data typically produces the largest volume per request and is the most likely to contain unintended data at runtime, and a novel technique for extracting meaning from logging information might cause innocuous-seeming log lines to expose user data after all. For these reasons, Apple performs regular audits of the log data emitted by PCC nodes, encourages submission of reports based on analysis of log data in the research environments through the Apple Security Bounty, and endeavors to quickly resolve any issues discovered. User data isolation We designed the PCC node to limit unnecessary access to user data by managing the paths that user data might take. User data is handled in specifically designated processes that communicate only with well-known services. These techniques simplify security analysis and help prevent accidental disclosure of user data to unintended processes. The enforcement primitives are based on the capabilities of each node’s operating system: Neither platform keeps user data readable across a reboot. An Apple silicon node runs with Ephemeral Data Mode: the Secure Enclave randomizes the data volume’s key hierarchy at every boot, so any data accidentally written to the volume becomes unreadable once the node restarts. A Google Cloud node’s Workload VM runs without device-attached persistent storage, so its writable state exists in VM memory and ends with the VM. Apple silicon nodes maintain Persistent asset caches exclusively for measured, shared assets such as model weights and Private Filter Service filter tables. Access controls restrict write permissions to dedicated asset-management processes operating outside the request-handling path, and the system revalidates asset measurements at every boot. External compromise Our security model also considers compromise through an attacker-controlled inference request. An attacker who succeeds gains access to the user data a node is actively processing. PCC’s security mechanisms aim to prevent initial compromise, detect it if it occurs, contain it to minimize the data and capabilities an attacker could acquire, limit the duration of the compromise, and diffuse attacks across the incoming requests. Preventing compromise To help prevent a compromise of PCC node software, we take advantage of the exploit mitigations each node’s operating system supports: We also minimize the attack surface of both platforms by shipping only what a server workload needs. An Apple silicon node ships no system shell, interpreter, or debugger, and nothing that compiles or loads new CPU code at runtime, so an attacker who gains execution finds no scripting primitives available for horizontal movement. Google Cloud host and guest images similarly ship a pared-down package and kernel-module set, and the hypervisor is built with QEMU’s auxiliary tools and guest agent disabled. Most external input arrives in structured formats such as Protobuf, so the parsing surface a request can reach stays small. Some workflows require additional formats: Visual Generation accepts HEIC images, and HomeKit Secure Video Analysis accepts H.264 and H.265 camera fragments from third-party hardware. When memory-safe parsers are not available for decoding attacker-controlled inputs with these complex formats, PCC isolates these tasks on dedicated worker nodes with per-request processes; for example, the Media Decoding worker parses these formats and returns raw pixel buffers for further processing. External inputs also include responses from third-party services. The response to an External tool calls arrives from outside the trust boundary, so Outbound requests to external services validates it as untrusted input before returning it to the cloud application: responses provide payload data within the typed structuredContent object, and PCC rejects responses that omit it. Detecting compromise If a compromise occurs, we need to detect it quickly so we can stop it and expel the attacker. While PCC’s privacy goals can be in tension with collecting the data typically used for detection techniques, each PCC node includes a security event monitor that reports limited security events in a privacy-safe way: On both platforms, PCC’s verifiable transparency promises cover the event schemas, so privacy researchers can inspect them. Over time, we continue to iterate on our detection techniques to improve efficacy and help ensure they prevent accidental disclosure of user data. Containing compromise If an attacker establishes an initial foothold on a PCC node, the node’s architecture restricts the scope of the compromise with the following techniques: Improving the strength of compromise containment is always possible, especially when it comes to policies like sandboxing. While the current sandbox profiles in PCC significantly limit the attack surface exposed from each process, they are more coarse-grained in their access than those in WebKit or BlastDoor. One exception is the Media Decoding worker used by untrusted-media workflows such as HomeKit Secure Video Analysis and Visual Generation, which decodes untrusted video and images under a restrictive sandbox similar to the one used for enhanced security helper extensions. Using this enhanced-security profile on a dedicated worker node, with a per-request decode process, helps ensure that a codec-vulnerability compromise is contained to the decode worker and to the lifetime of a single request. Time-bounding compromise In addition to containing the scope of a compromise, PCC bounds any compromise in time. An attacker who wants to keep a foothold must continually and aggressively repeat the exploit, and each repetition increases the likelihood of detection. Several techniques help enforce that bound: Per-request isolation handle the initial parsing of a request’s contents for each cloud application, including The Inference Engine and PCC Agent. An attacker must migrate horizontally out of that process to persist beyond the request that carried the exploit. On a Google Cloud node, the equivalent unit is a container and namespace set created for each request, and systemd forces its teardown to complete even when the request’s processes do not exit on their own. Periodic recycling of long-lived inference processes evicts any attacker resident in a shared process that holds user data: on an Apple silicon node, tie-controllerd terminates and restarts tie-inference; on a Google Cloud node, tie-controllerd Recycling the AFM Runtime. Encrypted multi-turn conversation caching bounds state retention across turns. On Apple silicon, ensembletransportd manages Cross-node blob transport with timeouts and eviction policies, while per-job ensembleporterd instances release ephemeral turn keys upon request termination. On Google Cloud, the Per-user KV cache holds multi-turn state under a per-turn key supplied by the user’s device. Across both platforms, continuing a multi-turn session requires the client to supply fresh key material once ephemeral keys expire from memory. Bounded request-decryption key lifetimes mean that neither platform uses persistent request-decryption keys. On Apple silicon, the Secure Enclave binds the Apple silicon (REK) to the operating system boot instance and Software Sealed Registers; the key cannot outlive that boot session or survive software modifications. On Google Cloud, the Protecting request keys isolates KEM key pairs in confidential VM memory and enforces an autonomous lifespan after which it deletes each key, and the verifier that caches a node’s KEM public key rotates it on a fixed schedule with fresh paired attestations. Note that the recycling behavior of long-lived application processes such as tie-inference ensures that the data for completed requests is removed from the system in a well-bounded amount of time, rather than immediately wiped following every individual request. Within the bounds of the recycling behavior, certain aspects of data life cycle depend on Swift memory management and the behavior of the system allocator. Physical or internal access PCC’s core requirements include that user data must never be available to anyone other than the user, not even to Apple staff, not even during active processing. As with any cloud service, the systems used by staff responsible for hardware and software development, the deployment and management of data centers, and the operational management of the service could be potential sources of a service compromise. Apple already has mature operational security practices, and for PCC we’re setting an even higher standard to support our enforceable guarantees: PCC’s design requires that even staff in one of these privileged positions can never have access to user data. Protecting against insider access is a complex task. With the initial release of PCC, we believe that a single staff member could not access user data, even with authorized access to internal inputs that would typically be considered privileged and therefore restricted to a designated group. The set of parties who would have to collude differs by platform. On Apple silicon, the chain runs through several Apple organizations, and an independent third-party auditor witnesses the Certificate ceremony process, so subverting a node’s root of trust takes a breach that reaches multiple organizations within Apple as well as Apple’s external auditor. On Google Cloud, the chain spans separate companies. Apple builds the workload and approves each release by publishing its measurements to the transparency log. Google builds the operating systems and platform firmware and operates the machines. A node’s attestation rests on Multiple hardware roots of trust that Google, Intel, and NVIDIA each hold independently. Privileged access to the data center In addition to each platform’s physical site controls, our threat model considers how an attacker with physical access to a node would attempt to exploit it directly. The hardware answers follow each platform’s machine design: Physical operation remains decoupled from data access: data-center operators can manage physical power and instance scheduling, but each platform’s design prevents access to active user data. Privileged access to the PCC service We designed PCC node software without privileged internal interfaces or capabilities: all interfaces that accept external input are treated as untrusted in PCC’s threat model. Both platforms exclude remote administrative shells. Apple silicon production images permanently disable Developer Mode, and the Remote diagnostics and monitoring a node does answer return a fixed set of reports rather than interactive access. Google Cloud production images Management tooling the images omit. Following any reboot, Ephemeral Data Mode cryptographically erases prior data volumes, preventing diagnostic or non-production software loaded after a power cycle from recovering previous session state. Beyond the node itself, an attacker might gain control of other PCC infrastructure. The Node selection is responsible for routing requests, and an attacker controlling it might try to leverage that access: The PCC Gateway could issue the same request to several nodes to exploit a side-channel attack, partially bypassing each node’s anti-replay protection. Only nodes whose attestations the device validated, or whose attestations a proxy node validated on the device’s behalf, can decrypt the request. A proxy node the device encrypted to but the PCC Gateway did not select responds with a negative acknowledgment, in the form of an empty finalized Request execution log, which tells the device that the node doesn’t process the request or make outbound calls for it. Those acknowledgments appear in the Appendix: Apple Intelligence Report. A node cannot always send an acknowledgment, for example, when it is unreachable or has rebooted; researchers can nevertheless monitor how often one is missing to detect anomalous behavior. The PCC Gateway could bias routing toward a small number of nodes with compromised hardware. Target diffusion applies to the initial set of proxy nodes. A downstream hop from a proxy node takes one of two routes. While the request’s non-targetability is intact, the PCC Gateway selects and reserves a single node. Once a step weakens it, such as an external tool call, the proxy node and the PCC Gateway choose the node through Node selection for requests from proxy nodes: the PCC Gateway supplies a candidate set and the attested proxy node narrows it, so the PCC Gateway cannot choose the node alone. Bias toward a small set of nodes appears in the request execution log that proxy nodes return to the device; routing anomalies are therefore detectable in both internal telemetry and client Apple Intelligence Reports. PCC nodes receive runtime configuration and dynamic assets from the control plane after boot. Because boot attestation precedes these updates, PCC requires that a dynamic asset not alter a node’s security or privacy boundaries, and every consuming daemon treats a dynamic payload as untrusted input. An Apple silicon node records in the request execution log the identifier, version, and cryptographic hash of each asset that Cloud asset distribution delivered to it, so the Apple Intelligence Report can show which such assets were available to a request. Assets that arrive in a cryptex are covered instead by the node’s attested release. Across both platforms, the operational control plane manages fleet deployment but lacks privileged access to user data: Whatever its operational details, the control plane is bound by the same no-privileged-access and non-targetability properties that hold across platforms. Compromised engineer credentials For an Apple silicon node, modifying the hardware during design or manufacturing jeopardizes every transparency claim that rests on it. Designing and validating silicon spans multiple years and passes through sign-offs from several organizations within Apple, so a hardware backdoor requires a long-term and wide-reaching compromise across the company. An Apple silicon node’s hardware identity rests on keys the SEP provisions and records during manufacturing. The Cryptographic identity is fused inside the SEP’s own trust boundary using a dedicated random number generator, and neither it nor the private half of any derived key is ever exposed to software, including software running on the SEP itself. Several organizations across Apple manage the Certificate ceremony process, and a third party observes it. Apple software engineers write the code that powers PCC. They sign their commits with hardware-backed keys, and Apple’s secure build system builds and signs the result. The measurements of those binaries then enter the PCC transparency log, and Apple publishes the binaries themselves so anyone can obtain them and check that they match. On Apple silicon, this is the same software supply chain we use to build iOS and macOS. A Google Cloud node’s workload is assembled from a manifest held in a single repository under branch protection and mandatory review, alongside the unit files that determine what each component runs and what it can reach; component images are addressed by digest or source commit, and a structurally invalid manifest fails evaluation instead of producing an image. Verifiable transparency turns a successful attack on either supply chain into an observable artifact: to be deployed, the modified software must enter the public log, where a researcher can find it. A dishonest operator Defenses against external attackers and data-center personnel rely on software choices that an operator could unilaterally alter; our architecture treats the operator as a potential adversary. The verified service and cloud layer eliminates trust in Apple and its partners through technical guarantees enforced independently by users’ devices and public transparency logs. The requirements model identifies software modification, user-targeted substitution, and callout manipulation as operator attacks, and PCC counters each with a requirement enforced outside the operator’s control. Serving unpublished software An operator could attempt to subvert user privacy through software modification, running software whose data handling differs from its public commitments. Verifiable Transparency eliminates trust in operator assertions by having users’ devices independently verify node software before sending requests. On Apple silicon, software requires both Apple Code signing and inclusion in the public transparency log. On Google Cloud, Composing and publishing a release in the log constitutes authorization. In either case, the system rejects any node whose measured state is unlisted. To prevent an operator from serving different log views to targeted users, the transparency log uses append-only Merkle tree structures, similar to Certificate Transparency. Users’ devices verify consistency proofs through third-party MASQUE proxies, and a divergence in the log history that a later view of the log does not resolve raises an alert on the device. Log entries have defined lifespans, so an active release must be published continuously to keep serving traffic. Releases are Binary transparency, and each platform has a research environment in which researchers can exercise a release. For Apple silicon, the Virtual Research Environment loads the same user-space images as we deploy into the production service, providing a very close approximation of the production service, and it offers that inspectability to anyone without the need to apply for a physical Security Research Device. To enable the PCC software to run under virtualization, the VRE is subject to some limitations: The VRE operates with a paravirtualized GPU, using the host system’s graphics drivers and firmware. The VRE uses a virtualized SEP. This enables a new capability for researchers, debugging and analyzing SEP code, but cannot invoke the real SEP functionality in silicon. A Google Cloud node’s trusted computing base is an x86 Confidential computing stack, so research on that platform runs against real cloud infrastructure rather than a virtualized node. The Google Cloud Research Environment offers two kinds of instance, and they differ in both availability and attestation coverage: A research instance that Apple provisions runs with GPUs attached on the machine type that serves production traffic, so its attestation covers the whole stack, GPU measurements included. Capacity for that machine type is limited, so Apple shares its reserved capacity with invited researchers as time-based reservations rather than on demand. An instance a researcher provisions runs on a widely available machine type with no GPU attached, and exercises attestation, the encrypted request path, configuration delivery, the execution allow list, and telemetry egress. Its ability to reproduce the production attestation flow is limited: firmware, GPU, and TPM attestations may be absent or different. Inspecting a running node from the inside requires a Appendix: Google Cloud Debug and Hardened Images, because the production image contains no SSH daemon. A debug image reports different measurements than the production image, so a researcher must reproduce a finding from the debug image against the production image before reporting it. Due to these limitations, it is not always possible to dynamically exercise every code path that runs in the production PCC service, requiring some manual inspection of the binaries. To further support analysis of the published binaries, we also publish portions of the PCC software Source Code for both platforms, including many of the most critical PCC security mechanisms. However, this source does not include the capability for reproducible builds, so it is not possible to prove that the published PCC binaries are compiled from the published source code, limiting its use to that of an analysis aid. Further boundaries apply to what is published with a release. Binary transparency can lag its log entry while an embargo applies. Model weights are measured and recorded in the log; they are considered proprietary and not published as part of our transparency commitment, and they are constrained to numerical formats that hold no control flow. On Google Cloud, some Third-party firmware relies on golden reference measurements published by the vendor, rather than measurements of the firmware binaries. Diffusing compromise User-targeted substitution singles out a chosen user and routes that user’s request to compromised software or hardware. An operator that publishes and attests honestly for the population as a whole could still single out one person. Non-Targetability prevents this through properties that help ensure a targeted attack costs as much as a broad one. Request routing uses anonymous, unlinked credentials. PCC authorizes requests with Client authentication built on RSA Blind Signatures; the blind signature severs the cryptographic link between a spent credential and the exchange that issued it. Network transport strip source IP addresses before requests reach the PCC Gateway, so recovering a client’s network address takes a joint compromise of both the relay and the PCC Gateway. A client accepts a relay or credential-issuer key only after confirming it appears in the public transparency log, so a key issued to a single device would have to be logged, where a researcher can see that more than one key is in use. Candidate node selection is bounded and decentralized. A device encrypts its request to a bounded subset of candidate nodes selected at random from prefetched attestations. The user’s device itself enforces the maximum candidate count; selection therefore stays under the device’s control whatever the PCC Gateway recommends. For models spanning an Apple silicon ensemble, the candidate bound applies to the ensemble as a single unit. The device audits request routing. The Request execution log streams back the validated attestation of every node that received a request from a proxy node, including any Delegated tool calls nodes used for delegated tool invocations, so a user or a researcher reading their own Appendix: Apple Intelligence Report sees the complete set. The device’s own choice of nodes is statistically auditable as well: an attacker who compromises a node and takes complete control of the PCC Gateway still cannot bias that choice toward the compromised node without the skew appearing in the distribution that devices opting into analytics report. Nevertheless, operational considerations may allow some bits of information about the user’s device to be visible outside the encrypted request. To enable routing to nearby data centers, the rough geographical region of the user’s device is exposed by the local instance of the third-party relay in use. To enable troubleshooting, the PCC client submits requests with headers containing basic, non-identifying information about the user’s device, such as the product and the operating system build version. If a user of interest to an attacker is significantly distinguishable by these properties, this information might be used in a semi-targeted attack. If an attacker has the ability to intercept encrypted requests in transport, such as by compromising the PCC Gateway, then the strength of target diffusion is limited by the size of k, the number of nodes that can decrypt each incoming request. PCC Selecting the size of k against its latency and utilization goals. For Multi-Turn Agent, the persistent connection model preserves these properties: session and interaction identifiers carried in multi-turn metadata travel exclusively inside the encrypted request body and remain scoped to the interaction. When a request makes an External tool calls, its contents are exposed to the tool gateway and the downstream tool provider. An attacker controlling either could potentially use what they observe to steer subsequent processing of the request toward a compromised host. To prevent this, once a request has made an external tool call, it opts into Node selection for requests from proxy nodes for the selection of any further PCC nodes. To reach a node the request hasn’t used yet, the PCC Gateway offers a set of candidates and the attested proxy node chooses among them. PCC Agent can also block a request through a server-side Safety overrides or the Content-safety guardrail. We designed both so they cannot be aimed at a particular user. PCC Agent selects override rules by the inference identifier in the request’s routing parameters, and selects guardrail categories by use case, so the rules a request receives depend on the feature it invokes, not on who sent it. The assets that define those rules are recorded in the Request execution log or PCC’s transparency log, so a rule set served to one user and not to others is visible in the record. A rule can still be written to match particular content, but a match can only reject the request. The rejection appears in the user’s Apple Intelligence Report, and neither mechanism exports which request it blocked or why, so a content-targeted rule can deny a request without disclosing what it contained. While target diffusion increases the necessary attack scale and risk of detection, fleet software homogeneity remains: because all PCC nodes run identical or very similar software, an exploit against a single node may apply across the fleet. Each node reached by an exploit can decrypt only the requests in flight on that node, and the architectural boundaries covered in Stateless Computation and containing compromise confine a process compromise to a single workload. Manipulating an external call Inference pipelines interact with third-party tools and services to support agentic workflows such as world-knowledge lookups. Callout transparency makes every such call auditable by the user whose request produced it: Each call includes a subset of the routing metadata the client device sends outside the encrypted body of the original request — the calling application and feature, and the request’s identifiers — together with the node’s own software version. None of those values identifies a device or user, so non-targetability survives the hop outside the boundary. A tool provider is also an input path back into the request. A compromised provider could return a hostile prompt injection that steers later reasoning steps. PCC caps the number of tool calls a request may make across all of its turns. The execution log records what the request sent rather than what the provider returned, and once a request has made such a call, the PCC Gateway can route to a new node only through Node selection for requests from proxy nodes. Content matching as an extraction oracle A mechanism that inspects model output and fails the request on a match is a one-bit oracle over that output. An operator could load a filter that matches something other than what it claims to match, and read each block as the answer to a question about what a user’s request produced. PCC’s Recitation prevention has that shape: it fingerprints generated text with a finite state machine and probes those fingerprints against a keyed Bloom filter that the Private Filter Service hosts. We bound what such a filter could extract in the following ways: Apple does not publish the filter contents, because publishing a deny list would limit its effectiveness. A researcher can confirm that a node runs the published matching engine, and that the filter a request probed is the one the node’s attested descriptor names, without being able to read what that filter matches. These assets sit in the same position as the model weights: anchored in the attested descriptor a node reports for each lookup, and inspectable only in their effects. Cost-feedback correlation channels Starting with iOS and macOS 27, the Cost feedback adds an auth-and-billing path alongside the inference path: clients submit accumulated cost tokens to the PCC Cost Aggregation Service and redeem the resulting cost denominations when requesting new one-time tokens. Because the same client authenticates to the Client authentication under an identifiable account, an observer of Apple-operated metering endpoints could try to re-link that identity to an otherwise unlinkable usage profile through the timing and amounts of these submissions. A cost token includes a bucketed cost unit, issuer metadata, and an hour-granularity timestamp, so an aggregated submission reveals at most a coarse histogram of activity over time. Both the submission and the token batch request transit Network transport, shielding the client’s network identity from both endpoints. Frontier adversaries Verification and non-targetability leave two attack classes open to a well-funded or state-sponsored adversary: reading user data through a channel that crosses an isolation boundary without breaking it, and attacking the hardware roots of trust that underpin every other guarantee. Side-channel extraction Code running on the same machine as an otherwise hermetic workload shares caches, memory controllers, page tables, performance counters, and the clock, and an adversary can recover data from how the workload uses them. Researchers have repeatedly turned those shared resources into extraction paths against isolated workloads. Foreshadow read enclave memory out of the L1 data cache and recovered Intel SGX’s attestation key, which let an attacker forge attestations for enclaves that never ran. Such an attack relies entirely on co-residency on the machine, succeeding even against invulnerable workload software. PCC’s primary defense against microarchitectural attacks is strict machine tenancy: a PCC workload is the only workload on its machine, denying an adversary any co-resident vantage point for observing on-die caches, memory controllers, or execution units. Hermetic environment makes that claim checkable, because every software layer executing on the machine is measured and attested before the node accepts user requests. The two platforms reach sole occupancy through different machine designs: All Apple silicon designs also undergo extensive testing to identify and mitigate side-channel attacks before fabrication. Tenancy controls address the channels available to code on the machine. A network observer occupies a different vantage, and traffic analysis attacks have long posed a risk to the privacy of user data. Research demonstrating effective attacks using interactive user timings for SSH goes back decades, and more recently, analysis of packet sizes that reveal token lengths has effectively revealed content as well. PCC implements mitigations for the attacks that research has demonstrated against the channels it exposes: Traffic analysis is a dynamic field; if future research demonstrates additional traffic analysis attack opportunities, we will work to rapidly and systematically mitigate them in PCC. Both research environments expose live node traffic for exactly this kind of study, and we encourage reports through the Apple Security Bounty. Subverting the hardware supply chain Software attestation builds on the hardware roots of trust built into the node. An attacker who controls these roots can forge attestation evidence for unverified software, and an attacker with access to data-center systems could attempt to provision fake or inauthentic hardware. Hardware Provisioning counters both through multi-party authorization and public transparency logging: Both platforms publish node certificates in the public transparency log, and attestation evidence binds to that ledger, so clients and auditors can verify fleet membership. Residual risk PCC’s requirements hold against these adversaries, though residual risks remain from software vulnerabilities and hardware subversion: Minimizing these risks requires careful consideration of the data accessible in PCC, as well as the timing and scope of that access. Challenges for private AI services The requirements PCC meets are not particular to PCC; any cloud AI service that processes personal data faces the same adversaries. Apple publishes this guide so that other services can build to the same bar and researchers can hold any service to it. Building verifiable private AI services still presents open technical challenges across the industry: PCC’s novel requirements present one further challenge: the risk of an unforeseen attack. We welcome reports of instances where PCC falls short of our security and privacy requirements, and we will work continuously to improve PCC to achieve them.