AI SecurityVulnerability ManagementCompliance
Private Cloud Compute is the most seriously engineered confidential-inference system any large vendor has shipped in public. Stateless nodes. Attested software images. A transparency log so researchers can verify what is running. A virtual research environment anyone can download. A bounty programme that goes to $1 million for the worst outcomes.
Drinor Selmanaj of Sentry took $150,000 out of it — the middle tier, the one Apple reserves for exfiltration of user request data or other sensitive information from the trust boundary. The vulnerability is CVE-2026-20685, a path traversal, CVSS 6.5, fixed in PCC release 5E290.3 and later. Selmanaj's technical writeup went up on July 31; the CVE and the bounty figure have drawn wider coverage over the past week.
No prompt text left the building. No response text. No token IDs or token strings. Apple's central claim survived the attack intact.
Something else left instead, and it is the part worth your attention.
darwin-init is PID 1 on a booting PCC node. It runs as root, and part of its job is unpacking the cryptex bundles that make up the node's software. It picked an archive extractor by looking at the first four bytes of the downloaded artifact. A tar archive puts its ustar signature at byte offset 257, so a tar file sails past the two safe, signature-checked handlers and lands in a generic extraction routine that appended entry names from the archive to the output directory without sanitising them.
From there it is the oldest trick in the archive-handling book. Four .. sequences walk out of /var/tmp/darwin-init/cryptex/<UUID>/ and into /var/db/, which survives a userspace reboot. Selmanaj built a hybrid archive — traversal entries plus a structurally valid cryptex bundle — so the node finished booting normally rather than hanging on a failed install and drawing attention.
The file he dropped was a configuration plist for splunkloggingd, the node's log forwarder. Change where the log forwarder points, and the node cheerfully ships its telemetry to an HTTP endpoint of your choosing. The researcher's own summary of the bug class is that it is "a thirty-year-old vulnerability class" — the Zip Slip family, unchanged.
The preconditions are real and they are steep: an adjacent network position, plus the ability to get a malicious cryptex registered with the configuration server during node provisioning. This was done in Apple's Virtual Research Environment, not against production Apple Intelligence. Nobody's iPhone was in danger. Apple fixed it and paid for it.
Here is the sentence in the research that deserves to be pinned above every architecture diagram for a confidential-AI deployment: attestation established which software was installed, not the integrity of the configuration files on the node.
Three of PCC's four headline guarantees held. Computation stayed stateless. The cryptex contents still matched their attestation measurements — the software was exactly what the transparency log said it was. There was no privileged runtime access; the attacker never touched a running inference process. What broke was the one nobody markets: the assumption that a node's observability plumbing is sealed and cannot be repointed.
That is a general lesson, not an Apple lesson. Every remote-attestation story in confidential AI — TEEs, enclaves, confidential VMs, signed images — is a story about the code. The measured boot chain tells you which binaries you are running. It has essentially nothing to say about the plist, the environment variable, the sidecar config, or the log destination that determines what those binaries do with your data. Config drift has always been the soft underbelly of hardened systems. Wrapping the system in an attestation certificate does not change where the underbelly is; it just makes it easier to overlook.
Look at what actually got redirected:
bundleID, workloadType, requestID, automatedDeviceGroupEvery enterprise AI policy in existence has a rule about prompts and responses. Almost none of them have a rule about this. It is telemetry — operational exhaust, the stuff you forward to a SIEM without a second thought.
But input token counts track prompt length. Length plus timing plus bundleID plus workloadType is a behavioural profile: which application is calling, on behalf of which device grouping, how often, how large the requests are, how long the answers run, and which model handled them. In a consumer context that is a privacy erosion. In an enterprise context — where the calling application might be the legal team's contract reviewer or the M&A workspace — request volume and payload size at 2am on a Sunday is a signal, and it is one that arrives without a single word of privileged text attached.
The industry has spent two years arguing about whether providers train on your prompts. That argument is now largely settled by contract. Almost nobody has asked the adjacent question: what does the provider's inference plumbing emit about your usage, where does it go, who else can redirect it, and would you find out?
There is a pattern forming this month, and it is worth naming. Here, the way out was the log forwarder. In the GhostJacking research presented at DEF CON on August 9, the way in was error logs, monitoring alerts and blocked-request messages from observability and security platforms, used to smuggle indirect prompt injections into coding agents that were trusted to read them.
Observability tooling is high-trust, high-privilege, wired into everything, and reviewed by roughly nobody. It sits inside the boundary by design. When the workload it observes is AI inference, "inside the boundary" means it sees prompt-shaped metadata by construction. Two independent pieces of research in one month landed on that plumbing from opposite directions.
Be clear about what this research does and does not say. Apple built the strongest confidential-inference system on the market, invited people to break it, paid well when someone did, and shipped a fix. That is the process working. The uncomfortable inference is not "PCC is unsafe" — it is that a best-in-class vendor inference environment still had a boot-time config path that redirected usage telemetry, and that no customer of that environment could have detected it, audited it, or reasoned about it from outside.
Obichat answers that by changing where the boundary sits rather than by asking you to trust a better one. It is a managed multi-model chat workspace that runs as SaaS on Obiguard-managed infrastructure or as a private deployment in your own AWS, Azure or GCP tenant via Helm chart or Terraform, where prompts, responses and files never leave your infrastructure. In that topology the log forwarder, the config files, the telemetry sink and the retention policy are yours — the same assets, under your change control, in your monitoring, in your incident scope.
The model layer follows the same logic. Obichat works with any OpenAI-compatible endpoint — Azure OpenAI, AWS Bedrock, Vertex AI, or self-hosted models via vLLM or Ollama — and each workspace has its own provider connections and its own model allow-list, set by an admin. For the workloads where "which third party's inference environment is this running in" is a question you would rather not have to answer, that question has a configuration answer instead of a procurement answer.
And the record is yours by construction. Every message passes the inspection layer under the policy set assigned to that workspace — sensitive-data redaction, block-lists, and jailbreak and prompt-injection detection — before it reaches any provider, so what a provider's telemetry can profile is bounded by what you allowed to leave. Security and compliance get a per-workspace activity log of conversations and events, exportable to CSV, with controls mapped to NIST AI RMF and ISO/IEC 42001. That is your own evidence, held independently of any vendor's log pipeline.
For the API and agent half of the estate, where AI reaches your applications rather than your people, Governance AI keeps the equivalent: allow-lists binding each credential to specific model IDs, tools, external domains and invoking identities, and an audit ledger with an immutable per-call record of prompt, response, tool calls, model and initiating identity. When a provider discloses something about its inference plane, the useful question is "what did we send through it, and when" — and that should be a query you run, not a request you file. The CoSnitch disclosure made the same point from the assistant side: exposure you cannot administer is exposure you cannot clear.
Apple's guarantee about your prompts held. The guarantee nobody thought to make — about the metadata describing those prompts — is the one that failed, and it failed through a log config file on a machine no customer will ever see. Explore Obichat or talk to us about what your AI provider's telemetry currently says about you.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →