I Found No Mention of Muse's Audit Trail in the Messages Dispute

The Meta Muse Messages dispute is a test case for the AI agent audit log. On September 19, 2026, Inc columnist Jason Aten reported that Muse had synced his Mac's Messages database to row 187,462, although the assistant had told him it only saw notification banners (Inc, Sep 19). Meta says that sync needs Full Disk Access plus the Messages connector, and Aten says Full Disk Access was off. Meta's launch post promises "a complete audit trail of everything it has done and plans to do", yet three weeks on I can find no log excerpt from either side. On October 2, Apple said it will tighten Full Disk Access, citing AI agents as a growing risk.

Update, October 9, 2026. Since I first published this on September 21, Meta VP of Communications Andy Stone repeated that Muse can read Messages only if both Full Disk Access and the Messages connector are on (TechCrunch, Sep 30). Apple posted a developer notice on October 2 promising new controls so that Full Disk Access takes "very explicit user action", and it cited AI agents as a growing risk without naming Meta. Security researcher Patrick Wardle also disclosed a separate Muse flaw on September 21 that Meta says it hotfixed (Ars Technica). And I got something wrong in the first version: it said Muse had no activity record. Meta's help center documents an Activity log, so the real question is what that log covers. I rewrote the section on it below.

What happened between Meta's Muse and a writer's Messages database?

Meta launched Muse on September 8 as a personal agent that runs on a dedicated cloud virtual machine and works across the apps a person connects. Aten installed it on an iPhone and on a Mac mini he keeps for testing. He wrote that Muse then pushed him a notification suggesting that a conversation with his podcast co host about the new iPhones would make a good column, and it flagged a message from his editor about a column due Monday.

Aten says he remembers choosing not to give it access to his messages, calendar and other personal information. So he asked Muse how it knew. It answered that the text of notifications on his paired Mac gets relayed to it, and that it could not open Messages, scroll threads or read history. Then he looked. In his words, the Messages source "had been activated and synced to row 187,462 of my Messages database."

That is the claim at the center of this story, and I treat it as his report, not as a verified fact about his machine. I have seen no underlying records from either side.

The Verge covered it the same day and landed on this: Muse probably cannot see your notifications, and it also has no idea how it works. Wired's separate review on September 20 argued Muse is more focused on collecting data than finishing tasks, and cited Sensor Tower for more than 900,000 downloads in its first week. The question I would ask first is what record exists of what the sync actually read.

The reply described the design and left Aten's machine open

Meta's David Singleton answered in a long thread on Threads the same day. It is a technical walkthrough, and it is better than most vendor replies to a privacy report. It also describes what the system permits, not what it did on one Mac.

His argument: the Messages integration in the Mac app is opt in, and Muse can read Messages only if macOS Full Disk Access is granted and the Messages connector is enabled. Granting Full Disk Access sends the user to a macOS approval screen, and macOS enforces that control in the kernel, so a bug in Muse could not get around it. If Full Disk Access is off, he wrote, the Messages options are greyed out. He also described the mechanism Muse had denied: the app does not watch notifications, it syncs data from Messages after the user enables access. And he said the wrong answer was Muse being confused about its own feature, that "That's on us", and that Meta is working to improve Muse's understanding of its own internals.

Singleton confirms Muse has a Messages sync feature, which contradicts what the assistant told Aten, though he does not say it ran on Aten's Mac. Every sentence in the thread is about the design. Meta says it audited the flow before launch and again that day. None of that is a statement about Aten's machine on that afternoon, because no artifact from that machine was offered. On September 30, Meta VP of Communications Andy Stone repeated the same claim in public (TechCrunch; Reuters, Oct 2), and Reuters quotes him adding that access can be revoked at any time.

There is also an outside challenge. Wardle told Ars Technica that with Full Disk Access, any non root file on the Mac is readable, and Ars reported that Meta's only reply to its question about this was to repeat Singleton's statement (Ars Technica, Oct 2). My read: that is where the permission story gets thin. Full Disk Access is a coarse grant, and whatever narrows it to "Messages only when enabled" lives in the app, not in macOS.

Meta's own help page for the Mac app adds one more detail worth reading closely. For apps that keep data locally, you choose Off, Read only or Read and interact. It defines Read only as the agent reading that information "when you ask it something".

My read: a push notification about a podcast chat that Aten did not ask about does not look like "when you ask it something". It may be a different feature from the one that help page describes. I cannot tell from outside, and that uncertainty is the point. One more loose end from the thread: a reader asked whether the Messages options default to off once Full Disk Access is granted. When I read the thread on October 9, I saw no reply.

Does Muse already have an AI agent audit log?

An AI agent audit log is a durable record, written by the code that does the reading, of every access the agent made: which connector, which source, how many records, when, and under which grant. The first version of this post said Muse had nothing like it. That was wrong, and the correction changes the argument.

Meta's launch post says Muse shows people a complete audit trail of everything it has done and plans to do. Meta's help center says you can open an Activity log from the assistant icon to see a chronological record of actions Muse has taken and permissions you have given it.

I read Aten's column, Singleton's thread and Stone's statements as quoted by TechCrunch and Reuters, and none of them mentions the Activity log, though I could see only part of Singleton's thread. That does not prove Aten did not check it. It does mean the public argument ran on testimony instead of a record, even though Meta says a record exists. The same help page also points to System Files for "a deeper look" at Muse's activity and says you can ask Muse for the sources behind a response. Another line on the Mac apps page says the agent "only uses the files and app information you ask it to work with", which is a policy statement a user cannot check without a record. I would also like to know where Aten found his row number, because that is itself a log like artifact.

What the documents do not say is whether the Activity log includes background connector syncs, such as pulling rows from a local Messages database, or only actions and permission grants. That is the whole question. An action log and a read receipt are different things. Here is how the accounts line up.

The design review question is what the product shows a user who asks what did you read. If the honest answer is "whatever the model says", the product cannot answer at all. It can only generate text about it. If the answer is "an Activity log", the next question is whether that log was written by the connector that did the reading.

Teaching the model to describe itself is not enough

Meta's stated remedy is partly a model remedy: Singleton said the team is working to improve Muse's understanding of its own internals. That helps with wrong explanations, but it cannot work as the evidence layer, for two reasons.

The first is empirical. Turpin and colleagues showed that chain of thought explanations can systematically misrepresent the true reason for a model's prediction. Biasing models toward wrong answers dropped accuracy by as much as 36% across 13 BIG-Bench Hard tasks, and the explanations often rationalised those answers without mentioning the bias. That 2023 test used GPT 3.5 and Claude 1.0, so it is old, but the finding is the one to keep: plausible yet misleading. Anthropic's interpretability team reported a more cautious result in its October 29, 2025 introspection research: some introspective awareness in current Claude models, but "still highly unreliable and limited in scope."

The second reason decides it. The Messages sync did not happen inside the model. My read: it ran in a connector process on the laptop, since Meta describes it as a sync from Messages, not something the model did. A perfectly introspective model still would not know it occurred unless something told it. If so, asking Muse what it read is asking one program to report on a sibling it cannot see.

Meta's own incident handling points the same way. On September 23, Singleton explained a different Muse problem, where users saw strange messages: a prompt change had landed in an order the model was not trained for, which caused hallucinations. He said Meta worked it out by reproducing the failure on test machines and inspecting trajectories, alongside the model's chain of thought (Singleton on Threads, Sep 23). He also cites the model's chain of thought as part of how Meta determined the model was confused.

Aten saw this too: "The robot chatting with me isn't lying and has no idea how it works." He is right, and giving it a better idea is still the wrong project. The fix is a log and a tool that reads it.

Meta's own documents on access records

Meta published a security architecture post by Tarek Sheasha on September 8. I searched its text for log, audit, history, activity and record on October 9. None of the matches describes a user facing access log or read history. I covered the isolation design at launch in my earlier post, and I still think it is strong engineering.

The post says each user gets an isolated Linux virtual machine. A separate component called Sentinel is the sole permission authority for connector actions and network egress. Approvals are bound to a specific connector and destination, and they can be one time, session scoped, task scoped, time bounded or perpetual. The bug bounty pays up to $300,000, including up to $130,000 for a prompt injection that affects one user. On data, it says the VM is the system of record for everything you put in Muse, and that you can inspect, edit and download those files.

That last claim is where the gap sits. The post also says the VM holds everything Muse generates or uses on your behalf, which is closer, but it still describes stored files, not a history of reads. Meta's documents describe approvals and an Activity log, so the pieces may exist. My read is that the security post is the document Meta points to as the authority on how Muse handles your data, and it would be the natural place to say what the log guarantees.

Separate from the Messages dispute, Wardle showed a different kind of failure. Ars Technica reported that any local app or terminal command could change undocumented Muse settings, including the endpoint used for transcription, and so capture the token that controls the account. More than 12 hours after the story went up, Meta said it had released a hotfix. A separate report by 404 Media, based on one anonymous Meta source and relayed by The Verge on October 5, claims Meta rushed fixes for a virtual machine escape bug before launch. I would treat that last item as unconfirmed.

Where the two accounts disagree

They disagree about consent state. On the mechanism, Meta and Aten agree that Muse has a Messages sync and does not tail notifications, and Meta calls the assistant's description wrong. What nobody can resolve from outside is how a sync ran with Full Disk Access reportedly off, and whether the grants were ever made.

Aten says the Muse settings pane shows Full Disk Access is not enabled, and that "it does not appear in the Security and Privacy settings at all." Meta says the flow requires it. Both can be sincere. Neither has produced a timestamp.

Apple's notice is the new fact here. It says some developers use Full Disk Access in ways that expose files, mail, messages and browsing history without users' full knowledge, and it says new controls are coming. It names neither Meta nor Muse, and it gives no date or macOS version. Ars Technica argued the timing and wording sit uneasily with Meta's claim that Full Disk Access alone is not enough to read Messages. That is Ars's reading, not Apple's statement. Apple declined to comment beyond the post (Reuters).

Apple's Mac User Guide explains how to change Privacy and Security settings, and you can flip Full Disk Access there at any time. It reports current state. It does not tell you when the switch flipped, what asked for it, or what got read afterwards. The Settings screen has the same blind spot one level down, though macOS may keep its own grant records that I have not examined, and that is why "check your settings" was never going to end this argument.

Six things to build if your agent touches a user's data

This is my opinion, drawn from building agent systems, not a Meta recommendation. None of the six is hard to build.

Write a read receipt for every fetch. Connector, source, record count, timestamp, and the grant that authorised it. The connector writes it and the model never touches it. If your sync reached position 187,462 in a database, the user should be able to see that line without opening the database. Cover background syncs, not only actions the user triggered.

Make the log the answer. When somebody asks what you read, render the log. Do not route that question to a completion. A product that answers an access question with generated text is guessing in front of the person least able to check it.

Log the grant, not just the state. Which surface, which device, which build, which time. Settings panes show you the present tense. Disputes are always about the past.

Default the scope to off after a coarse grant. When a user gives your app a broad operating system permission for one reason, every feature that could ride on it starts disabled and asks separately. This is the least privilege idea applied to a consent screen. Then say so in the interface, so nobody has to ask on Threads.

Keep the operating system permission and the product scope visibly separate. Full Disk Access is the key to the building. Your Messages connector is the key to one room. I wrote about the same collision when OpenAI shipped a Messages plugin whose real read scope depended on which macOS permissions you granted.

Give the model a tool that reads the log. If the assistant is going to answer at all, let it answer by querying a record instead of recalling a plausible architecture. That is a tool definition inside your agent harness, not a training run, and it is the version of Meta's stated fix that would hold up. For the broader instrumentation picture, see observability.

My read: the objection to all of this is rarely the engineering. An honest log makes visible how much an agent reads, and a product team may not want that number in the interface.

If you are weighing what an agent should be allowed to touch inside your own business, the AI readiness assessment walks through the access questions in the order that matters, starting with what you would need to prove later. I also build and monitor these systems myself, which is a sales interest worth knowing about, so you can see how I build AI agents.

Apple announced tighter Full Disk Access controls, and the switch is still blunt

My read: consumer agents inherited a permission model built for apps that act when you tap them. You grant once, you inspect current state, you assume nothing happens while you sleep. Agents break all three assumptions. They read on their own schedule, in the background, and what you can inspect afterwards is a switch rather than a history. Apple's October 2 notice suggests a platform owner sees the switch as too blunt for agents, though it talks about some developers in general and does not name Muse.

Amazon added a second dispute on September 20 by blocking Muse from shopping on Amazon.com. It said Muse does not identify itself when it browses and appears to capture and store customer credentials (GeekWire). Meta has said Muse cannot see passwords. I have no way to check either claim, and a user would have the same problem. Again there are two accounts and no record either side can hand over.

My read is that Meta's response was fast and technically specific, and that goodwill was never the missing piece. If Muse's Activity log covers background reads and Meta shows an excerpt, this story could end in one screenshot. Until then it is one user's word against a design document.

Frequently asked questions

Did Meta's Muse read private messages without permission?

That is unresolved. Meta says the Messages sync needs Full Disk Access plus the Messages connector, and that it audited the flow before launch. Jason Aten says Full Disk Access was off and that he declined those permissions. Neither side has published a timestamped record for his machine.

Why did Muse describe itself incorrectly?

Meta called the answer incorrect and apologised. A language model answers from training and context, not from observing other processes. My read is that the sync ran in a connector outside the model, so the assistant produced a plausible mechanism instead of the real one.

What is an AI agent audit log?

A durable record, written by the agent's connector and tool layer, of every read and write it performs: the source, the record count, the timestamp and the permission it acted under. It is shown to the user directly rather than summarised by the model. Meta says Muse has an Activity log. Whether it records background syncs is not documented.

What did Apple change about Full Disk Access?

On October 2, 2026, Apple said on its developer site that it will introduce additional controls so users can grant Full Disk Access only with very explicit user action, citing risks from AI agents. It did not give a release date or macOS version, and it did not name Meta or Muse.

Should I connect an AI agent to my email or messages at all?

That depends on whether the vendor can show you what it read. Connect a source when the product exposes per source access history you can check without asking support, when the scope for that source is separate from any operating system grant, and when you can revoke it and see the revocation take effect. If the only answer is the assistant's own account, treat that as an unanswered question.