Meta Vaulted Muse's Credentials. The Zero-Day Handed Over to the Agent Instead

Meta built the credential handling in Muse the way a security team would ask for it. Secrets sit in a vault outside the agent's runtime, and a separate approval component inserts them at the network edge, so the agent never holds a token for the services it uses. That design held, and the flaw went around it.

On September 21, 2026, four days after the Muse Mac app shipped, researcher Patrick Wardle disclosed a flaw that Meta patched within about a day. His proof-of-concept captured the token that authenticates the user's Muse account. In a system built around an agent, that token matters more than anything in the vault, because it controls the agent that is already cleared to use every credential inside it.

A small client bug handed over the agent's full authority

The flaw lived in the Muse macOS client. Any process running as the user could rewrite undocumented local settings without elevation. One setting pointed at the endpoint Muse used for cloud transcription, so redirecting that setting sent the dictation traffic and the account token to an attacker's server.

Coverage repeated that the attack needed no special macOS permission, and that detail matters least. macOS makes software ask before it reaches the camera or the files, and that prompt holds ordinary malware in place. An agent like Muse asks the user for those grants early, so its access has usually passed that gate before any attacker arrives.

Once an attacker holds the agent's token, he acts as the agent with everything the agent was given. Wardle's proof-of-concept made it write files and take photographs, sometimes without alerting the user. A hijacked session also pulled the location of a paired phone and started a Bluetooth scan from it. The attacker inherits unchecked authority and never has to ask for any of it.

One token reaches every service the agent was trusted with

Muse acts on the user's behalf. It sends email, books travel, fills forms, negotiates and makes purchases, working through a cloud VM that holds the credentials for the services the user switched on. Wardle's own assessment was that an attacker could steer the agent and use its privileges at will.

Whoever holds that token inherits the agent's standing access and would act under a name the underlying systems record as the legitimate user. Meta vaulted the credentials correctly and left the authority to spend them exposed on the client. Credential vaulting protects the secret and does nothing for a hijacked session that works through an agent already cleared to use it.

The token escaped through transcription, a supporting service that few threat models treat as sensitive. An agent's real attack surface includes every helper service it talks to, and those helpers get far less scrutiny than the headline features.

Why your identity reviews stay green while an agent acts

The enterprise version of this is quieter than malware. An employee installs a personal agent, gives it a corporate mailbox, and pastes in an API key. That API key creates no OAuth grant, so it leaves no record in the systems your identity team reviews. The access is real and standing, and governance misses it because governance inspects grants and this key never produced one. This is access nobody granted, nobody owns and nobody checks. The quarterly review passes, the SSO logs look clean, and the agent keeps acting.

The deeper mismatch is timing. Identity governance reviews authority when it is handed out, in access requests, consent screens and recertifications. An agent is dangerous when it acts, many calls later, each one inside permissions that already cleared review. The tool call is where the risk lives, and few security teams keep any record of it.

The mechanism is confirmed, and Meta has patched it. No one has reported exploitation in the wild. The token type, its storage and Muse's exact system permissions were not published, so the wider impact here is assessed from the proof-of-concept and Muse's stated capabilities.

Questions your board will expect you to answer about AI agents acting on your data

Which AI agents are already acting against our data, and who owns each one? The wrong answer is that IT has the list, because the riskiest ones arrive as a personal install that IT never approved. What does each agent's token reach, and would we see it if the token were used by the wrong hands? The wrong answer is that our OAuth review covers it, because an employee's API key creates no grant for that review to catch.

When an agent moves data, can we say which agent did it, under whose authority, and what it touched? The wrong answer is that the logs hold it, because today that takes weeks of log digging, if an answer exists at all.

How Unosecur governs agents at the moment of action

An attack like this calls for two controls. One is a record of which agents hold authority, and the other is a check on what they do with it. Unosecur delivers both as one control plane. Unosecur discovers the AI agents running across your cloud and AI platforms and lays out each one's model, permissions, knowledge bases and secrets, along with its evidence history and access graph. An agent that nobody reviewed becomes an identity with an owner and a known reach.

For AI clients and agents routed through it, Unosecur governs each tool call at the moment of action. Every call is allowed, limited, blocked or recorded. Each request is checked for tool intent, sensitive data and prompt injection, and just-in-time access replaces standing grants with permissions that expire. A stolen token still has to make a tool call to do harm. Authority cannot be locked away, so the tool call is the last place left to govern it, and that is where Unosecur sits.

‍