Apple's pitch for Private Cloud Compute (PCC) is unusually strong for a cloud service: every production software build that can handle your Apple Intelligence requests is recorded in a public, append-only, cryptographically tamper-evident transparency log, and your device is supposed to refuse to send data to any build that isn't in it. Apple also lets you export a record of your own requests — Settings → Privacy & Security → Apple Intelligence Report → Export Activity.
Two halves of a promise. The catch is that, until now, nothing connected them for a normal person. "PCC is verifiable" was a claim you couldn't actually act on unless you stood up Apple's full Virtual Research Environment — macOS-bound, and gated behind a restrictive source license. The third-party tools that existed were report viewers: they pretty-print the export, but they don't check any of the cryptography.
So I wrote pcc-verify: an open-source, pip-installable tool that takes your exported report and checks each cloud request's attestation against Apple's live transparency log — the same researcher endpoints Apple points auditors at, reachable from an ordinary machine with no Apple entitlements. This post is about what that check actually proves, and — just as importantly for anything wearing the word "verify" — where it stops.
What's actually in the export
The interesting discovery is that the export is genuinely cross-referenceable. For each request that went to the cloud, the report carries, per PCC node, an attestation bundle containing two things that matter:
the node's software measurements — the AP boot ticket plus the per-slot cryptex image measurements (a "sealed hash ledger"), i.e. a fingerprint of exactly which OS and components were running; and
a full transparency-log inclusion proof — the leaf bytes, the Merkle path to the root, and a signed log head.
In other words, the device didn't just record "I talked to a cloud node." It recorded a fingerprint of that node's software and a cryptographic proof that the fingerprint's release sits in Apple's public log. That pairing is the whole reason a post-hoc verifier can exist. (Apple documents this deliberately, so researchers can inspect the attestations returned to their devices.)
What pcc-verify checks
For every cloud request, for each node that carries a non-empty bundle, the tool runs five checks:
Inclusion proof. Recompute the Merkle root from the leaf and the sibling hashes along its path (the log uses the RFC 9162 hashing scheme — SHA-256(0x00 ‖ leaf) for leaves, SHA-256(0x01 ‖ left ‖ right) for interior nodes), and require it to equal the root in the signed log head the device trusted.
Signature. Verify that log head's ECDSA P-256 / SHA-256 signature over the raw log-head bytes, against Apple's published log key — fetched live from the researcher endpoint, and cross-checked so the key's own hash matches the key identifier embedded in the bundle.
Measurement binding — the crux. Recompute the release digest from the bundle's own tickets, following Apple's documented canonicalization (null out the per-device personalized fields, drop the per-node signature and certificates, keep only the manifest body — because two nodes running identical software differ in exactly those dropped fields), and require that digest to equal the one committed in the log leaf. This is the step that makes the proof mean something: without it you've shown "some release is in the log," not "this node's actual software is the release in the log."
Freshness. Check the release leaf hadn't expired at the time of your request (in-use releases are periodically republished with new expiry, so the same digest legitimately recurs).
Log consistency (online). Fetch the current log head and confirm the log has only grown consistently since your device's view — an independent vantage point that feeds exactly the "split-view" detection the design is meant to enable.
Run it and you get per-request verdicts, not a single green light:
$ uvx pcc-verify Apple_Intelligence_Report.json
Requests routed to Private Cloud Compute: 12 (plus 34 handled on-device)
9 verified — attestation chains cryptographically to a release in Apple's public log
3 not verifiable — the export carries no attestation data for these entries
verified, proof-invalid (a real red flag — should never happen for genuine data), incomplete, not-verifiable, and on-device are all distinct. Requests handled on-device are reported as exactly that: nothing left the device, so there's nothing to check against a cloud log — the tool says so rather than implying a pass. Empty bundles are reported not-verifiable, never silently waved through. Honesty is the point of the exercise, so it's the point of the output.
What a green check does not mean
This is the part I care most about getting right, because a security tool that overstates is worse than none. A verified result proves one specific thing: the PCC software your device recorded talking to was a build Apple publicly committed to in its transparency log, and the proof binds to that build's actual measurements. Here is what it does not establish:
The report is unsigned JSON, produced by the very device stack being examined. pcc-verify checks Apple's log commitment against what the device recorded; it cannot prove the device recorded truthfully or completely. Verifying the device stack itself is what Apple's VRE and security bounty exist for.
Runtime properties leave no trace in the export. Whether the OHTTP relay actually concealed your IP, whether your data was statelessly deleted after processing, how encryption keys were released — none of that is in the file, so no post-hoc tool can speak to it. Those remain Apple claims, checkable only through source review and the research environment.
Full SEP-attestation semantic validation is out of scope in this version. Pinning the node's certificate chain to Apple's data-center CA and evaluating the Secure Enclave register policy isn't done yet — the fields are surfaced, not judged. That's stated plainly rather than blurred into the pass.
So the honest one-line version is: this narrows "trust Apple's word" down to "trust that your own device reported honestly," and makes everything after that point cryptographically checkable by anyone. That's a meaningful reduction in what you have to take on faith — and it's a bounded one. Both facts belong in the same sentence.
Two things worth flagging for the security-minded
It's a clean-room implementation. Apple's own security-pcc repository ships under an internal-use license that forbids redistribution and covers not just code but the data, fixtures, and .proto files. pcc-verify contains none of it — every protocol fact (field numbers, endpoints, algorithms, the canonicalization rules) is reimplemented from Apple's public PCC Security Guide and cited to it in the source; the test fixtures are synthesized to match the documented schema, not copied. Apple's pccvre proves the workflow is real and supported; what didn't exist was a portable, non-macOS, license-unencumbered verifier anyone can run. That's the niche.
It independently verifies something your own device skips. For requests routed through a Trusted Proxy, Apple's on-device daemon does not fully verify the proxied compute node's attestation (there's a comment to that effect in Apple's own client). When such bundles show up in the export, pcc-verify checks them anyway — and labels a pass on those as its own independent verification, not a re-confirmation of something the device already did. That's a genuine value-add, and it's marked as one rather than quietly folded into the same green check.
Why bother
The reason "verifiable" matters as a word is that it's supposed to mean you don't have to trust me — check it yourself. For PCC that promise was technically real but practically out of reach: the tooling assumed you were an Apple-entitled researcher on a Mac. Collapsing that to uvx pcc-verify Apple_Intelligence_Report.json — no account, no entitlement, your report never leaving your machine (the only network calls are to Apple's own transparency-log endpoints, allowlisted in the code; --offline disables even those) — is the point. Transparency logs are only as good as the number of independent parties actually looking at them.
It's v0.1.0, and it will need maintenance: Apple already changed the bundle encoding once (JSON before OS 26.4, Base64 protobuf after), which is exactly why the parser versions its assumptions and cites the doc revision it implements. SEP semantic validation is the obvious next piece. But the core — inclusion proof, signature, and the measurement-binding digest — verifies fully offline today, against real exports.
Try it
sh
uvx pcc-verify Apple_Intelligence_Report.json # or: pip install pcc-verify
To get a report: Settings (iOS/iPadOS) or System Settings (macOS) → Privacy & Security → Apple Intelligence Report → set the duration to 7 days (the 15-minute default captures almost nothing) → use Apple Intelligence for a while → Export Activity. Flags worth knowing: --verbose for per-check detail, --json / --markdown for reports, --offline with --keys to pin Apple's log keys once and verify with no network at all, and a non-zero exit on proof-invalid so it can gate automation.
Source, and the full feasibility write-up documenting what the export contains, how the log is accessed, and every boundary above: github.com/NagaYu/pcc-verify. Every load-bearing claim in that write-up was verified firsthand — Apple's published fixtures parsed directly, the license read in full, the production transparency-log endpoints probed live from a non-entitled machine. Anything that couldn't be established is listed as such rather than assumed. Same standard I'd ask of anyone else's "verify" tool.
