No Privileged Runtime Access

Overview

In traditional cloud services, operations teams rely on administrative access, such as SSH or remote debugging tools, to maintain systems and respond to incidents. That same access provides a direct path to user data for an operator or an attacker holding an operator’s credentials.

Private Cloud Compute must confine management, observability, and debugging to narrow, audited mechanisms. A PCC node offers no general-purpose administrative access: no remote shell, no interactive debugger, and no unbounded interface for introspecting a running node, even during an outage or incident response.

PCC’s Enforceable Guarantees make this durable: a node measures its entire software stack, and the authorized set is fixed before the node accepts user data, so adding a privileged interface means shipping a different release into the Release Transparency. A production node on either platform does not run an SSH server and cannot load debugging tools at runtime; an Apple silicon node additionally cannot enable Developer Mode, a precondition for attaching a debugger.

Operating the service without privileged access

Like any large-scale service, PCC has management, observability, and debugging needs. Those needs sit in tension with the enforceable guarantee that user data must not leave the PCC node, so PCC meets them through narrow, audited mechanisms, governed by five principles:

• PCC’s software may emit only output permitted by a published allow list. Only Log filtering and Metrics that Apple reviews and approves before a release ships can leave a node: audited individually for components whose address spaces can hold user data, and admitted as a whole for components that never receive user data. Because the allow lists ship in the node’s hermetic software, researchers can inspect exactly what a node may emit. Configuration that the PCC control plane delivers while a node is running may narrow what the node emits but never add to the reviewed set, so the allow list shipped with a release remains an upper bound. The allow lists govern the software PCC runs; platform software beneath it reports on its own operation through The telemetry pipeline.

• PCC must redact and rate-limit data it cannot audit in advance. Unlike a log line or metric, a Crash reporting or backtrace is a snapshot of whatever state the system held at the moment of failure, so we can’t enumerate ahead of time what it might disclose. PCC strips the fields most likely to carry user data, then rate-limits and samples the rest to bound the total risk of data leakage.

• Diagnostics must expose only a fixed set of functions. Where a node offers a diagnostic interface, that interface exposes specific, predefined functions rather than general-purpose access. An Apple silicon node’s Remote diagnostics and monitoring expose functions such as connectivity checks, external-interface packet capture, resource statistics, and backtraces.

• PCC must decorrelate any signal derived from user data before export. Where a metric’s value or export timing could reveal something about a request’s content, In-node aggregation withholds values below a threshold and adds noise to the remaining values, so no exported metric links back to the request that produced it.

• Security monitoring must report event metadata, never content. Detecting a compromise is part of operating the service, so a node reports a bounded set of Security events, such as process launches and sandbox violations. The monitor’s exported records are limited to a fixed set of fields compiled into the node’s measured software.

These five principles keep every operational output within a bounded channel, helping ensure that an adversary who reaches the management interfaces cannot recover user data from them.

Limitations

Without privileged access, Apple cannot diagnose a node in place. Apple reboots or replaces a failing node rather than logging in to inspect it live, so a fault is diagnosable only from what the allow list permits the node to emit: the reviewed metrics and log lines, and the redacted crash reports.

Filtering a node’s output against the allow list, and reviewing each line on that list before a release ships, reduce but can’t eliminate the risk that user data is revealed outside the trust boundary. Apple’s review process considers each line’s argument types, but a line that interpolates a string reveals little about what that string holds at runtime: the description of an object can look safe on inspection and still carry unintended data. Review is also a human process applied to a large and changing codebase, so Apple supplements it with System observability, and enables external researchers to do the same through PCC’s Verifiable Transparency and the research environments for Virtual Research Environment and Google Cloud Research Environment nodes.