Consortium forVerified Computing

I-0013 / On-chip & hardware

Apple Private Cloud Compute

Apple's cloud AI inference service, in which user devices send requests only to servers that attest to running software published in a public transparency log.

R3 In productionSource reviewed 2026-09-25Provider-reported evidence

01 / The mechanism and its boundary

What the technique establishes

Private Cloud Compute (PCC) is Apple's server system for Apple Intelligence requests that need larger models than a device can run. Apple reports that user devices send a request only to servers that attest to running a software release listed in a public, append-only transparency log. Apple publishes the software images, a virtual research environment that boots them, and part of the source code. Independent researchers found flaws in how PCC authenticates requests, and one, working in Apple's research environment, reports that a node with tampered configuration files passed attestation until Apple fixed the bug that allowed the tampering. In June 2026 Apple announced an extension of PCC to Google Cloud on Intel TDX and NVIDIA confidential computing. Independent researchers with physical access to such hardware have forged TDX attestations and relayed NVIDIA ones.

Threat model
Semi-trusted prover
Adversarial evaluation
Independent red-team
Hardware needed
Existing hardware features
Prover cooperation
Required
Confidentiality
Preserving
Category
On chip & hardware

Claims and scope

A direct link identifies the intended claim. A supporting link supplies part of the evidence. Neither establishes that a complete verification system has been demonstrated.

Readiness for a stated use

R3 In production

Assessed use: showing users which software serves their AI requests, not which model

medium confidence · current · assessed 2026-09-25 · rubric 1.1

This is the source map’s editorial assessment. Production use is not evidence of resistance to every adversary.

PCC is a production service whose attestation, transparency log and research tools are public, but no independent evaluation has examined its attestation chain as a whole.

  • R1 met: Apple published the design, the claim that devices send data only to nodes that attest to publicly listed software, and a threat model that includes attackers with physical access to a node S-1800.
  • R2 met: the software images, a research environment that boots them and part of the source code are public S-1800 S-1801. Independent researchers sent queries to the production service from macOS and iOS clients between December 2025 and March 2026 S-1803.
  • R3 met: PCC is production-grade and available as the server side of Apple Intelligence (provider-reported) S-1800, and independent researchers have used the production service S-1803. Its transparency log, binaries and research environment are public S-1801. The attestation check is made by Apple's own client software, and no other party is documented relying on it for a verification decision.
  • R4 not met. The two independent public analyses are narrow. A peer-reviewed study reverse-engineered the client and found request-authentication flaws, which Apple addressed only in its documentation. Its subject is request privacy, not attestation S-1803. A researcher working in Apple's research environment reports that a node with tampered configuration files passed Apple's attestation check, and Apple fixed the path-handling bug behind it S-1804 S-1805. Neither evaluates the attestation and transparency chain as a whole. The 2026 deployment on Google Cloud uses Intel TDX and NVIDIA confidential computing S-1802. Independent researchers with physical access forged TDX attestations and paired them with relayed H100 attestations S-1202. No published work tests whether Apple's use of two independent roots of trust resists that attack.

Evidence needed for the next level

  • An independent public evaluation of the attestation and transparency-log chain, including what attestation covers at runtime, that leaves no critical flaw open.

  • Evidence that the Google Cloud deployment's attestation resists attackers with physical access to TDX and NVIDIA hardware.

  • Reproducible builds, so that published binaries can be checked against published source.

Limitations, flaws, and blockers

These are attributed assessments from the source map. Absence of a listed flaw is not a security guarantee.

significant / mitigated / demonstrated attack

Tampered node configuration passed attestation

Working in Apple's Virtual Research Environment, an independent researcher used a path traversal in darwin-init, which unpacks software archives when a node boots, to write files as root that survived the node's userspace reboot. The change redirected a logging daemon's telemetry and exposed per-request metadata such as token counts and timings. The researcher reports that Apple's attestation verifier treated the tampered node and a clean one identically. The researcher concludes that attestation appears to measure the installed software but not the writable configuration files that drive daemons at runtime S-1804. Apple's CVE record describes an attacker in a privileged network position and a fix through improved path validation, in releases from 5E290.3 S-1805.

S-1804S-1805

significant / open / open question

Google Cloud attestation combines affected TEE components

Apple reports that PCC on Google Cloud uses Intel TDX, NVIDIA confidential computing and Titan. Components that could exfiltrate user data if compromised have at least two independent vendor roots of trust, and attested keys are held in a separate confidential VM S-1802. The TEE findings document physical-host TDX forgery and an H100 relay demonstration S-1202 S-3126. Whether PCC's combined protections resist those attacks remains an open question.

S-1802S-1202S-3126

What still blocks use or stronger assurance

  1. Published binaries cannot be rebuilt from source and carry no symbols, so checking what the attested software does needs reverse engineering.

    S-1803

  2. Outside developers can use PCC only with an entitlement from Apple, which is limited to small developers.

    S-3125

Connections in the research map

Depends on

  • TEE remote attestation for AI workloads

    Relies on hardware attestation: the Secure Enclave on Apple silicon servers, and Intel TDX, NVIDIA confidential computing and Google's Titan chip on Google Cloud.

Mechanisms implemented

Concepts used

Sources and provenance

  1. S-1800 / Tier C

    Private Cloud Compute: A new frontier for AI privacy in the cloud ↗

    Apple Security Engineering and Architecture (SEAR) · 2024 · Apple Security Research blog

    Supports: design goals, Apple silicon servers, signed trust cache, integrity protection of code and model assets, device-side attestation check against the transparency log, publication of images, threat model with physical attackers (provider-reported)

    Version and catalogue details
  2. S-1801 / Tier C

    Security research on Private Cloud Compute ↗

    Apple Security Engineering and Architecture (SEAR) · 2024 · Apple Security Research blog

    Supports: Virtual Research Environment, published source components and licence, bounty (provider-reported)

    Version and catalogue details
  3. S-1802 / Tier C

    Expanding Private Cloud Compute ↗

    Apple Security Engineering and Architecture (SEAR) · 2026 · Apple Security Research blog

    Supports: Google Cloud deployment with NVIDIA confidential computing, Intel TDX and Titan; two roots of trust; protections ramped up during a summer preview; research mode on live nodes (provider-reported)

    Version and catalogue details
  4. S-1803 / Tier A

    Unlocking Apple's Private Cloud Compute: An Analysis of Privacy-Preserving Artificial Intelligence ↗

    Y. Dittmar, M. J. Stephan, T. Völkl, M. Hollick, J. Classen · 2026 · Proceedings of the 19th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec '26)

    Supports: independent reverse engineering of the client; queries to the production service; no reproducible builds or symbols; request-token flaws; Apple's documentation-only response; no third-party API at the time of the study

    Locator: abstract; §3; limitations

    Version and catalogue details
  5. S-1804 / Tier C

    Beyond Prompt Injection: Hacking Apple's Private Cloud Compute ↗

    D. Selmanaj · 2026 · Sentry blog

    Supports: independent finding that a tampered node passed attestation; metadata exposure; bounty

    Version and catalogue details
  6. S-1805 / Tier B

    CVE-2026-20685 (Apple Private Cloud Compute Server Software) ↗

    Apple (CVE Numbering Authority) · 2026 · CVE Program

    Supports: CVE description, affected versions and fix (vendor-assigned)

    Version and catalogue details
  7. S-1202 / Tier A

    TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition ↗

    J. Chuang, A. Seto, N. Berrios, S. van Schaik, C. Garman, D. Genkin · 2026 · 2026 IEEE Symposium on Security and Privacy (SP)

    Supports: independent forgery of Intel TDX attestations and H100 attestation relay

    Locator: Abstract; §1.1; §8.3

    Version and catalogue details
  8. S-3125 / Tier B

    Private Cloud Compute (Apple Developer) ↗

    Apple · 2026 · Apple Developer

    Supports: third-party developer access to PCC: eligibility and entitlement (provider-reported)

    Version and catalogue details
  9. S-3126 / Tier A

    DDRop: Active Memory Interposer Attacks on Confidential VMs by Dropping DDR5 Writes ↗

    J. De Meulemeester, S. Gloor, P. Jattke, D. Moghimi, D. Oswald, M. Thompson, K. Razavi, I. Verbauwhede, J. Van Bulck · 2026 · 2026 ACM SIGSAC Conference on Computer and Communications Security (CCS '26)

    Supports: independent forgery of TDX attestation reports with a DDR5 interposer

    Locator: Abstract; case studies

    Version and catalogue details
Source review date
2026-09-25
Drafted by (source map)
ai
Review handles (source map)
codex-review