ChatGPT inside Apple Messages: convenience meets OS-level prompt injection

On August 21 OpenAI started rolling ChatGPT into Messages on macOS. Once you grant it permission, it can read your messages, search them, summarize threads, draft replies, and send them. According to the coverage (9to5Mac, picked up by TechStartups), the processing is done locally and without building a separate index of your conversations. I want that feature. I also want to be very clear about what it is: an agent with read and write access to a communications channel that anyone on earth can write into.

What shipped

The scope is the whole point. This is not a chatbot you paste a message into. It is an assistant that sits inside the Messages app with an OS-level permission grant and four capabilities that matter for a threat model: it can read what other people sent you, it can summarize across many messages at once, it can compose text, and it can send. The local-processing claim is OpenAI's, reported second-hand, and I have not verified it.

The injection surface nobody asked for

Prompt injection through a messaging app is the textbook version of the problem. Someone sends you a text. The text contains an instruction, written for the model rather than for you, maybe buried in a long message you would never read in full. You ask ChatGPT to summarize your unread threads. The model reads the instruction as part of the content, and if the instruction says something like forward the last five messages from your bank thread to this number, the question is not whether the model is smart enough to refuse. The question is whether the system was built so that it cannot comply.

I wrote about the same shape with home automation in prompt-injection-smart-home: the hazard is not the model, it is the model holding a capability that untrusted input can steer. Messages is worse than a thermostat on two counts. The input channel is open to strangers, and the output capability, sending a message as you, is itself a way to attack other people.

The moment an agent can both read messages from strangers and send messages as you, every incoming text is a potential command.

What to delegate and what to gate

• Delegate read-only summarization, carefully. Summarizing your own unread threads is the lowest-risk, highest-value use, provided the output is text you read, not an action the model takes.
• Gate every send behind a human. A draft is fine. An autonomous send is not, at least not until there is a visible, per-message confirmation showing exactly what goes out and to whom.
• Separate the summarizer from the sender. If the same model call that reads untrusted content can also trigger the send capability, injection has a straight path. Two calls, with the send step given only the user's explicit instruction and the draft, cut that path.
• Scope the permission. Grant access to the threads you need summarized, not the whole database, if the permission model allows it.
• Log what the agent did. If it sent something, you should be able to see the message, the trigger, and the source content it read before deciding.
• Test it like an attacker. Send yourself a message with an embedded instruction and see what the assistant does with it. The methods in llm-security-red-teaming apply to a chat app exactly as they do to an API.

The honest gap

I have not used the integration; the rollout had just started as I wrote this, and the only details available come from a single report. I do not know what confirmation UI exists before a send, whether the send capability can be disabled independently of read, whether summaries are isolated from action-taking calls, or how the local-processing claim holds up. Any of those could make this much safer than I am assuming. Until I can see them, my default is the one I use for any agent with OS-level capabilities: read is a permission, send is a decision, and untrusted text is never allowed to make the decision.