Apple Publishes a Security Audit of Its AI Servers That Skips the AI
Apple has now posted four consecutive quarterly SOC 3 audit reports on the server fleet behind Private Cloud Compute, the system that offloads heavier Apple Intelligence requests to Apple's own data centers. A new report lands roughly every three months, each one covering the prior twelve.
Buried in Apple's fourth straight quarterly SOC 3 report on the servers behind Private Cloud Compute is a line saying the audit was never built to check whether the AI running on those servers actually works correctly, or keeps a prompt private, only the hardware and provisioning process around it.
An HN member with 22,000+ karma called the badge itself unremarkable: a SOC 3 is just a SOC 2 with the evidence stripped out. Another reader called every audit he's sat through a checkbox exercise.
Four quarterly reports, and a clause that quietly narrows what they prove
Apple has run Private Cloud Compute (PCC) since 2024, the server-side extension of Apple Intelligence that offloads AI requests too heavy for an iPhone or Mac onto a fleet of Apple-controlled servers, under a promise that no one, not even Apple, can read what passes through them. The page Apple just updated collects four SOC 3 audit reports on that fleet, one per rolling 12-month period ending April 30, 2026, January 31, 2026, October 31, 2025 and July 31, 2025, a new one landing roughly every quarter.
SOC 3 is an American Institute of CPAs (AICPA) framework: an independent auditor checks whether a company's stated controls for security, processing integrity and confidentiality held up over the period, then the company publishes the pass/fail summary without the underlying evidence. What's inside is narrower than the label suggests. The reports cover "provisioning, ongoing verification, and protection of information within compute nodes," the physical and procedural layer around PCC. Then comes the line that quietly undercuts the celebratory framing: the examinations "were not conducted to evaluate the performance or integrity of Apple's artificial intelligence services," and the auditor "does not express an opinion or any other form of assurance about Apple's artificial intelligence services." The audit signs off on the box, not on what runs inside it.
(One reader found the page unreachable where he was: a full-stack developer who hit a 301 redirect back to Apple's homepage instead of the report, and posted an archived copy that loads fine.)
"It's like saying I can afford $50k" — an HN veteran sizes up the badge
Nobody in the 47-comment thread caught the AI-exclusion clause itself. The pushback ran a different direction, questioning whether a SOC 3 badge means much of anything.
"a SOC3 is just a SOC2 with the audit details removed - it includes a high level statement from the company (Apple) and from the auditor (EY), that's it. Also Apple certainly does invest heavily in security and privacy but SOC2's are so commoditized that it's like saying "look I can afford 50k", it's not particularly interesting" — a longtime HN member with 22,000+ karma
A second reader doubted the process from personal experience rather than the paperwork:
"Every audit is a cooked book audit. At least every single one Ive been a part of. Check mark tests." — a commenter who says he's personally sat through corporate audits
One question went unanswered. An engineer who builds AI agent tooling wondered whether the audited nodes are excess or older Apple Silicon chips running a locked-down iOS variant, a reasonable guess that Apple's own report never confirms either way.
None of this makes Private Cloud Compute insecure; a SOC 3 catches process failures, not clever ones, and that is exactly what it's scoped to do. But the practical reader for this report isn't the iPhone owner wondering if Apple can read their prompts. It's an enterprise security team deciding whether to greenlight Apple Intelligence on a managed fleet, and for that purpose a quarterly auditor's sign-off checks the compliance box regardless of what the AI itself does with the data.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Nix wanted $ORIGIN in the kernel. It got eBPF-driven loader swaps instead.
At TacoSprint 2026, Farid Zakaria asked the Linux kernel mailing list to teach the kernel to resolve $ORIGIN, the token that already lets Nix binaries find their own directory. VFS maintainer Christian Brauner replied that the pieces already existed: combine binfmt_misc with an eBPF program, and he had a working example ready.