Muse Said It Only Saw Notifications. Row 187,462 Says Otherwise.

Three parties have now described the same event, and they do not agree.

Meta's Muse told a writer it had only seen notification banners. An engineer at Meta Superintelligence Labs said the assistant syncs the Messages database after three separate permission grants. The writer went looking and found the sync had reached row 187,462 of his local Messages database.

Only one of those three is a record. The other two are stories, and one of them was produced by a language model that has no way to observe what a different process did on a different machine.

That gap's the story. Not the creepiness, not the apology. The gap.

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

On September 19, Inc tech columnist Jason Aten wrote that Muse surfaced the contents of a private conversation he never granted it access to. He had been messaging his podcast partner about the new iPhones. Minutes later Muse pushed him a notification suggesting the conversation would make a good column, and flagged a message from his editor about a Monday deadline.

Aten says he explicitly declined those permissions when he set the app up. In his words, he remembers "explicitly choosing not to let it have access to my messages, calendar, and other personal information."

So he asked Muse how it knew.

The assistant gave him a clean, confident, wrong answer. "When a notification pops up on your paired Mac, the text of that notification gets relayed to me," it said. Then it went further: "I can't open your Messages app, scroll threads, or read history. It's the incoming notification stream only, not access to your texts."

Aten checked. Muse had activated the Messages data source and, as he put it, it "had been activated and synced to row 187,462 of my Messages database." A row cursor in a SQLite file is not a notification stream. The assistant had described a mechanism that was not the one running.

When The Verge covered it the same day, it landed on a reasonable dek: Muse probably cannot see your notifications, and it also has no idea how it works. Wired published a separate hands on review the next morning, arguing the app is more interested in collecting data than finishing tasks, and reporting that Muse passed 900,000 downloads in its first week on Sensor Tower numbers. Neither piece asked the question I would ask first.

What did Meta's response actually prove, and what did it leave open?

David Singleton of Meta Superintelligence Labs replied in the same Threads conversation with a long, genuinely technical walkthrough. It is the best vendor response to a privacy report I have read this year, and it still doesn't settle the question. It proves what the system permits. It says nothing about what the system actually did.

His argument runs like this. "The Messages integration in the Muse Mac App is opt-in." Reading Messages needs "macOS system-level Full Disk Access" plus the Messages connector switched on. Granting Full Disk Access inside Muse hands you off to the macOS Settings pane, where you approve with a password or a fingerprint. When any app reaches for a protected location, the kernel checks policy through the tccd daemon and the TCC database.

For messages to reach Muse with that access off, he wrote, "a hardened macOS system control would have to have been circumvented, which is vanishingly unlikely," because the control is "enforced by the macOS kernel's TrustedBSD Mandatory Access Control framework."

He closed with an audit claim and a scope claim: "We have thoroughly audited this flow before launch and again today," and "Muse cannot gain access to a user's messages unless the user has granted Muse permission to do so on three separate interfaces, including an operating system settings dialog." He also confirmed the mechanism Muse had denied. The app "does not watch notifications on your Mac, but rather syncs data from Messages only after the user has specifically enabled access."

Read that carefully. Singleton is right about macOS and right about the mechanism. Aten's row cursor agrees with him and contradicts the assistant.

But every sentence is a statement about the design. Not one of them is a statement about Aten's machine on that day, because Meta hasn't got an artifact to point at either.

One more thing about that thread. A reader asked directly whether the Messages options default to off once Full Disk Access is granted, saying it was the one thing the screenshots did not make clear. When I read the thread, that question sat unanswered. It's also the precise place a surprise could live: a coarse operating system grant taken for one reason, a product scope that inherits it for another.

Why is an AI agent audit log the artifact this dispute is missing?

An AI agent audit log is a durable, user readable record of every read the agent performed: which connector, which source, how many records, at what time, under which grant. It's written by the code that does the reading, never by the model. Muse has no such surface, which is why a user with a reasonable question had to go spelunking in a sync cursor to answer it himself.

Think about what that costs.

Aten is not a typical user. He mentions more than 125 articles he has written about technology and privacy, and he is careful to say that is not a credential, just evidence he thinks about this constantly. He still had to go inspect his own agent's data source to find out what it had taken.

Everyone with less patience gets the model's answer and believes it, or does not, and either way learns nothing.

I build agent systems that touch mail, calendars and internal databases, and this is the design review question I keep coming back to. When a user asks what did you read, what does the product show them? If the honest answer's "whatever the model says," the product cannot answer the question at all. It can only generate text about it.

Can you fix this by teaching the model to describe itself?

No, and this is where the coverage stopped. The Verge got as far as noting that chatbots tell you what you want to hear, then left it there. Meta's stated remedy is a model remedy. Singleton apologised for the wrong answer and said the team is "working to improve Muse's understanding of its own internals so that it gives correct answers to questions about how it functions more consistently." That treats an instrumentation problem as a training problem, and it can't work, for two separate reasons.

The first is empirical.

Model explanations of model behaviour are unreliable in a way that has been measured. Turpin and colleagues showed that chain of thought explanations "can systematically misrepresent the true reason for a model's prediction," and that biasing a model toward wrong answers drops accuracy "by as much as 36% on a suite of 13 tasks from BIG-Bench Hard" while the models systematically fail to mention the bias that moved them. Their summary's the phrase to keep: plausible yet misleading.

Anthropic's interpretability team tested the opposite possibility and found something more careful. Their October 2025 work on introspection reports evidence of some introspective awareness in current Claude models, then states plainly that "this introspective capability is still highly unreliable and limited in scope." That's the strongest finding anyone has, and it's nowhere near strong enough to hang a privacy answer on.

The second reason's the one that actually decides it, and it's got nothing to do with model quality. The Messages sync did not happen inside the model. It happened in a connector process, on a laptop, writing to a data source in a virtual machine somewhere else. A perfectly introspective model still wouldn't know it occurred, because nothing about it ever entered the model's weights or its context window. Asking Muse what it read is asking one program to report on a sibling it cannot see.

Aten got to the same place without the citations. "The robot chatting with me isn't lying and has no idea how it works." He's right, and giving it a better idea of how it works is still the wrong project. The fix is a log and a tool that reads it.

What does Meta's own security post say about access records?

It doesn't mention them.

Singleton pointed readers to Muse's security architecture write up, a 20 minute post by Tarek Sheasha of Meta Superintelligence Labs. I searched the whole thing for the word log. The only hits are logic, login, dialog and technology. There's no access log, no audit log, no activity history anywhere in the document that Meta offers as the authority on how Muse handles your data.

What the post does contain is substantial, and I want to be fair about that. Every user gets an isolated Linux virtual machine holding their data and credentials. A component called Sentinel mediates interaction with the outside world and the agent can't override it. Browser classifiers watch for personal data leaving on an unrelated task. The bug bounty pays up to $300,000 for valid reports, including up to $130,000 for a prompt injection that affects a single user. Credentials sit in a separate isolated container. That's more engineering than most agent vendors have done, and I have written about the isolation design at launch approvingly.

The data section is where the shape of the gap shows. "Your dedicated VM is the system of record for everything you put in Muse," it says, and "You can inspect, edit and download these files freely, including Muse's memory about you." Both are true and both are good. Neither one is a history. A system of record for what you put in is not a record of what the agent went and took, and the second one is the question users ask when something surprises them.

Where do the two accounts genuinely disagree?

On consent state, and only there.

The mechanism is settled: Muse syncs the Messages database, it does not tail notifications, and the assistant's account of itself was simply wrong. Aten's row cursor and Singleton's description agree on that. What nobody can resolve from outside is whether the grants were ever made.

Aten's position is a claim about what his settings show. "The settings pane in the Muse Mac app shows that Full Disk Access is not enabled, and it does not appear in the Security and Privacy settings at all." Singleton's position is a claim about what the flow requires and what an audit found. Both can be sincere. Neither produces a timestamp.

Notice what macOS gives you here. Full Disk Access is a switch you can inspect at any time, and Apple documents exactly where it sits. It tells you what's true right now. It doesn't tell you when the switch flipped, what asked for it, or what got read afterwards. The operating system has the same blind spot the app does, one level down.

Which is why "check your settings" was never going to end this argument.

There is a third possibility worth naming without endorsing. Aten installed Muse on an iPhone and on a Mac mini. Singleton's proof covers one path, which is a Mac app reading a local database through TCC. It does not address which surface activated the data source or when. I'm not claiming another route exists. I'm pointing out that the proof and the complaint are about slightly different questions, and only a log would tell you which one to answer.

What should you build if your agent touches a user's data?

Six things, and none of them are hard. I have shipped versions of all six, and the first one pays for itself the first time a client asks a question you would otherwise answer with a shrug.

Write a read receipt for every fetch. Connector, source, record count, timestamp, and the grant that authorised it. The connector writes it. The model never touches it. If your agent read 187,462 rows, the user should be able to see that line without opening a database.

Make the log the answer. When somebody asks what did you read, render the log. Don't 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 product feature that could ride on it starts disabled and asks separately. 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. Showing both, side by side, with their real names, prevents the exact confusion at the centre of this story. I wrote about the same collision when OpenAI shipped a Messages plugin whose real read scope was wider than the coverage said.

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 by recalling a plausible architecture. This is the one line of work that makes Meta's stated fix meaningful, and it's a tool definition, not a training run.

In my experience the objection to all of this is never the engineering. It's that an honest log makes visible how much an agent reads, and nobody wants that number in the interface. Which is the whole reason it belongs there.

If you are weighing up 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 actually matters, starting with what you would need to prove later.

What this actually signals

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, across devices, and the thing you can inspect afterwards is a switch rather than a history.

I keep seeing the same pattern in agent incidents this year, and it's rarely malice. It's missing instrumentation, then a model asked to fill the silence, then a public argument that no artifact can settle. The same shape showed up in a permission prompt that disappeared into a product merge, in a containment failure nobody could reconstruct after the fact, and in the compaction failures that quietly dropped a confirmation requirement.

Every one of them would have been shorter with a log.

Here's the uncomfortable part for anyone hoping better vendors fix this. Meta's response was fast, specific and technically literate. Singleton walked through TrustedBSD policy enforcement on a social network. Meta pays six figures for a single user prompt injection. And with all of that, one user's question about one afternoon still cannot be answered by anybody. Goodwill was never the missing piece. The record was.

Frequently asked questions

Did Meta's Muse read private messages without permission?

That's the unresolved part. Meta says the Messages sync requires Full Disk Access plus an enabled connector, granted across three separate interfaces including a macOS dialog, and that it audited the flow before launch and again after the report. Jason Aten says he declined those permissions and that the Muse settings pane shows Full Disk Access off. Neither side has produced a timestamped record, which is exactly the problem.

Why did Muse describe itself incorrectly?

Because it was answering from its training and its context, not from observation. The Messages sync runs in a connector process outside the model. The model has no channel to that process, so when asked how it knew something, it produced a plausible mechanism instead of a real one. Meta called the answer incorrect and apologised for it.

What is an AI agent audit log?

A durable record, written by the agent's tool and connector 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. It's the difference between a product that can answer what did you read and one that can only talk about it.

Does Full Disk Access on macOS explain the whole dispute?

It explains the mechanism but not the disagreement. Full Disk Access is a Transparency, Consent and Control protection enforced by the kernel, and an app genuinely cannot bypass it from userspace. What the setting can't tell you is when it was granted, what prompted it, or what got read afterwards. It reports present state, and this argument's about the past.

Can better models solve this by knowing themselves?

No. Published work finds model self explanations to be plausible yet misleading, and even the most positive result calls introspective ability highly unreliable and limited in scope. More importantly, no amount of introspection lets a model observe a separate process on a separate machine. The fix is a log plus a tool that queries it.

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

It 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 available answer is the assistant's own account, treat that as an unanswered question rather than an answer.

What did Wired's review add to this story?

Wired covered a different failure. Its hands on review argued Muse pushes constantly for more data, noting the app opts users into model training by default, nudges for bank and passport details, and offers no switch to turn memory off entirely. The EFF's Rory Mir put the general point well: "Folks don't recognize that when you talk to an AI, you are talking to the company hosting the AI."

Sources: Muse synced to row 187,462 of the writer's local Messages database, per Jason Aten, Inc (Sep 19, 2026). Meta's engineering response, including the TCC and TrustedBSD explanation and the apology for Muse's incorrect self description, is on David Singleton's Threads thread (Sep 19, 2026). Coverage from The Verge (Sep 19, 2026) and the 900,000 first week downloads plus the data collection review from Wired (Sep 20, 2026). The VM architecture, Sentinel, the $300,000 bug bounty and the system of record language come from Tarek Sheasha, How We Built Safety Into Muse, Meta (Sep 8, 2026). On model self explanation: Turpin et al., arXiv:2305.04388 (2023) and Anthropic, Signs of introspection in large language models (Oct 29, 2025). Full Disk Access documentation from Apple's Mac User Guide.