Apple Intelligence Tokens Show Privacy Needs Device Binding

An academic paper submitted to arXiv on April 17, 2026 says researchers found a practical cross-device token replay attack against Apple Intelligence. The authors call the attack Serpent and say Apple confirmed the report, assigned a CVE, and awarded a bounty. The public abstract does not expose a public CVE identifier, patch note, or exploitation report, so the responsible reading is narrow: this is a confirmed research disclosure about an authorization design weakness, not evidence of broad abuse.

The finding matters because Apple Intelligence and similar private AI systems try to separate identity privacy from service authorization. Apple says Private Cloud Compute uses privacy-preserving routing, encrypted requests to validated nodes, and single-use credentials based on RSA blind signatures. Those choices can hide who is asking, but they do not automatically prove that a token is being used by the device that earned it. AI privacy needs both anonymity and binding.

The primary source is the arXiv paper "Too Private to Tell: Practical Token Theft Attacks on Apple Intelligence" by researchers at The Ohio State University. The abstract says the team investigated Apple Intelligence's two-stage authentication and authorization design using traffic analysis, reverse engineering, and comparison with Apple's public documentation. It then describes Serpent as a cross-device token replay attack that lets an attacker steal Apple Intelligence access tokens from a victim device and use them on a different device.

That is a serious claim, but its scope is specific. The public abstract does not say the researchers decrypted Apple Intelligence prompts in transit, broke the foundation model, accessed Private Cloud Compute nodes, or bypassed Apple's stated stateless processing guarantees. It says access tokens could be replayed across devices and that usage would be rate-limited against the victim. In practical terms, the weakness sits around authorization and session portability.

Apple's Private Cloud Compute design is built around a difficult privacy goal: cloud AI requests may need to be processed in plaintext inside a compute node, but Apple wants the surrounding service to avoid linking a request to a user, retaining personal data, or giving administrators broad runtime access. Apple's security writeup says PCC encrypts requests directly to validated compute nodes, routes through an OHTTP relay, publishes verifiable software measurements, and uses a single-use credential based on RSA blind signatures for request authorization.

Those are privacy controls, not a complete answer to token replay. A blind signature can help the issuer authorize a request without learning the final message. OHTTP can hide the client IP from the service behind a relay. Neither primitive, by itself, proves that the party presenting a credential is the same device, app instance, or hardware-backed key that obtained it. If a credential is valid wherever it appears, it has bearer-token properties even when it was issued in a privacy-preserving way.

The relevant attacker is not someone who simply guesses a token. Token theft usually comes from a compromised endpoint, malicious local tooling, debug proxying, crash logs, device backups, overbroad mobile management, browser extensions, developer instrumentation, or malware running where the client stores request material. For Apple Intelligence, the most sensitive path would be anything that can observe the local client as it prepares or authorizes a cloud AI request.

That distinction matters for response. A replay flaw can turn a local compromise into a cloud-service abuse path, but it does not make every user immediately exposed from the network. The risk is sharper for developers, journalists, executives, legal teams, incident responders, and high-value users whose devices carry both sensitive prompts and attractive service access. It is also relevant to enterprise fleets because token movement across devices is easier to miss than an ordinary account login from a new browser.

The durable fix pattern is proof-of-possession. In OAuth, Demonstrating Proof of Possession describes a way for a client to bind a token to a public key and prove possession of the corresponding private key when using that token. The general lesson applies beyond OAuth: a credential should not be enough by itself. The caller should also prove control of a device-held key, preferably protected by hardware or an operating-system key store.

For private AI systems, binding has to be designed carefully because the service also wants to avoid stable identifiers that defeat anonymity. A privacy-preserving design can still use short-lived credentials, per-request nonces, attestation to acceptable client code, and holder-of-key checks without making prompts linkable to a real-world identity. The engineering goal is not to make the user more trackable. It is to make a stolen token less portable.

Apple's developer documentation makes clear that Apple Intelligence is becoming a platform surface, not a single app. The Foundation Models framework, App Intents, Shortcuts, Image Playground, Visual Intelligence, and system writing tools can all pull application data, user context, and model access into ordinary product flows. That means AI tokens and local authorization state belong in the same security inventory as OAuth refresh tokens, session cookies, push credentials, wallet keys, and repository tokens.

Developers integrating AI features should keep model authorization state out of analytics, traces, support bundles, screenshots, and crash reports. They should avoid logging prompts or tool inputs while still recording enough structured security telemetry to identify abnormal client behavior: token reuse across device classes, impossible timing, unusual quota consumption, unexpected model routes, repeated failed proof checks, and token use after device logout or app reinstall.

The public paper abstract says Apple confirmed the issue with a CVE and bounty, but it does not name the CVE identifier. It also does not give a user-facing Apple security release note that readers can map to a specific OS build. Without that, it would be irresponsible to claim a particular patch level is sufficient or to say that every Apple Intelligence deployment was affected in the same way.

The useful action is therefore conservative. Keep devices and operating systems current, especially on fleets where Apple Intelligence is enabled for managed users. Watch Apple's security releases and the final paper for the CVE. Treat any endpoint suspected of malware or forensic compromise as a possible AI-token exposure path. If a vendor later publishes a precise affected-version matrix, update policy from that primary source rather than relying on the research abstract alone.

Private AI systems are trying to satisfy two goals that can pull against each other. They need to authorize service use, enforce quota, and stop abuse. They also need to avoid creating a durable identity trail for sensitive prompts. Apple has published one of the more detailed public designs for this problem, which is why independent research against the design is useful. It tests whether privacy controls and authorization controls meet in the right place.

Serpent's lesson is not that anonymous credentials are bad. It is that anonymity is only one property. A secure AI access token must also resist theft, replay, quota abuse, confused-device use, and silent migration into logs or developer tools. The right standard for private AI is higher than "the provider cannot see who asked." It should also be "a stolen authorization artifact is not useful somewhere else."