Opinion · August 24, 2026

The AI Didn't Break Your Encryption. It Became a New Endpoint.

The claim going around

When OpenAI shipped an Apple Messages plugin for the ChatGPT desktop app on August 20, the sharpest version of the reaction was that OpenAI had killed end-to-end encryption for Apple. That framing is memorable, and it is also wrong. The way it is wrong matters, because the real story is worse than a broken cipher and will not be fixed by a better one.

No cryptography was attacked, and iMessage's end-to-end encryption still does exactly what it claims: it protects your messages in transit and at rest on Apple's servers, with the decryption keys living only on the sender's and recipient's own devices. Apple's own security documentation is blunt about the guarantee: message content is "secured with end-to-end encryption so that no one but the sender and receiver can access them," and "Apple can't decrypt the data." That guarantee holds in full with Advanced Data Protection enabled; in the default configuration, an iCloud Backup escrows a copy of the message key that Apple can reach, so the strongest form of the promise is the one you opt into. Either way, the PQ3 protocol underneath iMessage, with its post-quantum rekeying and machine-checked proofs, remains untouched, and nobody has defeated it.

The viral claim is therefore imprecise, yet it points at something real, and dismissing it as "just wrong" misses the point as badly as repeating it does.

What actually happened

End-to-end encryption is a promise about the space between two endpoints. It says nothing about what happens to a message after a legitimate endpoint decrypts it, because it cannot. The whole point is that your device holds the keys.

Your Mac, having received a message, does the only thing it can: it decrypts the message and writes the plaintext to a local database, ~/Library/Messages/chat.db. That file is not encrypted with your iMessage keys; it sits on your disk in the clear, the way it has to be for the Messages app to show you your conversations.

The ChatGPT plugin reads that file. To do so it needs Full Disk Access, a broad macOS permission the user grants in System Settings, plus Contacts and Automation, because there is no official Apple API for this; it drives Messages through AppleScript and the accessibility layer. Full Disk Access is all-or-nothing: the same grant that lets ChatGPT read your texts also exposes Mail, Safari data, and Time Machine backups. As one analysis put it, "the plugin runs locally, but local read access during a session is still full read access."

The "runs locally" framing quietly sidesteps the decisive point. OpenAI says the plugin runs on the Mac, does not build a persistent index, and that message content is "stored locally on a user's computer and is not saved to the company's servers." Read carefully, those are claims about file access and storage, not about inference. ChatGPT Work and Codex, where this plugin lives, have no on-device language model, so inference runs on OpenAI's servers even where a code agent executes locally on your Mac. The message content you select for a request has to go somewhere to be reasoned over, and there is no local model to reason over it. OpenAI has not directly answered what message text reaches its network during a request; reporters noted the plugin "does not fully explain which message content, if any, may reach OpenAI's network while a request is processed." We will not claim more than the reporting supports, but "stored locally" is not the same as "never transmitted," and that distinction is what matters.

The encryption held; the endpoint leaked because you authorized a program on it that forwards decrypted content to a third party.

This is exactly what was warned about

None of this is a surprise. In March 2025, Signal president Meredith Whittaker described the mechanism a year and a half before it shipped, on a SXSW panel. An AI agent that acts across your apps, she said, "would need to be able to drive that [process] across our entire system with something that looks like root permission, accessing every single one of those databases, probably in the clear, because there's no model to do that encrypted."

That phrase, "in the clear," describes chat.db before the fact. She named the structural cost, too: agents threaten "to break the blood-brain barrier between the application layer and the OS layer by conjoining all of these separate services [and] muddying their data." The convenience is real, and she captured it exactly: "we can just put our brain in a jar because the thing is doing that and we don't have to touch it." The price is just as real. She was equally clear about where the thinking happens. "There's no way that's happening on device," she said. "That's almost certainly being sent to a cloud server where it's being processed and sent back."

Proton's CEO Andy Yen has made the constructive half of the argument: "Privacy in the AI era is possible." His position, that useful AI can run on your own phone and laptop rather than shipping your life to someone else's servers, is the design brief the industry keeps declining to accept.

The pattern behind the plugin

With the branding stripped away, the shape is generic. A convenience feature reads the most intimate record you keep: who you talk to, when, and about what. To be useful at cloud scale, it moves the plaintext to a company's servers. Once it lands there, it lives under that company's retention terms and within reach of legal process: court orders, warrants, and, through cross-border mechanisms, requests from other governments. This is a structural outcome rather than a flaw in one plugin: it is the default consequence of putting a cloud model between you and your own data. Data that never leaves your machine can still be compelled, but it must come from you, through a device seizure, rather than quietly from a third party who happens to be holding a copy.

The encryption debate has spent a decade on the wire. The agent moves the fight to the endpoint, where encryption was never designed to help.

How it should be built

There is another way to build AI into your private life, and it rests on a property you can check rather than a policy promise.

Privt Voice runs its entire speech model on your Mac, on-device via Apple's CoreML and Neural Engine. On the free tier no user content is transmitted at all; the only network activity is fetching the speech model at first launch, with occasional re-contact of the model host solely for cache repair. Transcripts are encrypted on-device into a vault using XChaCha20-Poly1305 with per-item keys and a root key gated by the Secure Enclave and Touch ID or an Argon2id passphrase, so what's stored is ciphertext the operator can't read even on the optional Pro sync. The audio buffer is overwritten in memory once the transcript is delivered; the keystroke buffer is overwritten after the text is typed; the process denies its own core dumps so a crash can't dump process memory to disk. We are candid about the limit: a transcript held briefly in a managed-language Swift string can't be reliably scrubbed at all, unlike the raw audio, which we can and do overwrite, and we say so in the code rather than pretend otherwise.

Privt Voice is a dictation and meeting-notes tool. It does not read your Messages, and we're not announcing that it will. The point is narrower and more durable: an assistant that helps with your words without ever needing to move them off your machine is proof that the trade the cloud keeps offering isn't the only one available. Local-first is the direction, and it's a direction you can audit line by line.

The calm version

"OpenAI killed encryption" is the wrong sentence, and there is value in being the person who states the right one. The right sentence is quieter and more useful: your encryption is fine, and it was never the thing standing between your messages and a cloud server; the endpoint was. The moment you hand an agent root-level reach into your decrypted life and route its thinking through someone else's datacenter, you've moved your conversations across a line no cipher defends.

The durable fix is to avoid building the leak in the first place, keeping the model, and the plaintext, on the machine that already holds your keys, rather than layering a stronger lock on the wire. That approach is buildable today, and we know because we build it.