not-a-mused for exposing Muse dictation endpoint hijacking on macOS research

not-a-mused is a proof-of-concept showing how an unprivileged local process can redirect muse.ai dictation traffic via an undocumented setting, intended for authorized macOS security research.

Tool	pwardle/not-a-mused — Python PoC demonstrating hijacking of Muse's undocumented dictation endpoint from an unprivileged local process
Category	local attack surface research / proof-of-concept
Primary Use	Demonstrating, in an authorized lab, how the undocumented endo_voyager_dictation_endpoint setting lets local code redirect Muse dictation traffic and inherit the app's granted access
Safe Use	Run only in isolated research VMs or on systems you own during authorized security assessments; the README itself frames the project as security research and educational material
Telemetry Note	Defenders can watch for modifications to Muse's configuration storage containing endo_voyager_dictation_endpoint, and for dictation traffic from Muse flowing to unexpected network destinations

not-a-mused is a Python proof-of-concept from Patrick Wardle (pwardle/not-a-mused, currently around 43 stars) that documents a zero-day weakness in Muse, the AI assistant from muse.ai. The core issue is architectural rather than a memory-safety bug: Muse relies on an undocumented configuration setting named endo_voyager_dictation_endpoint that controls where dictation traffic is sent, and any process running as the local user — with no special privileges — can modify it. Once that endpoint is pointed elsewhere, the assistant's own trusted channel becomes an exfiltration and injection path. The repo is deliberately scoped as research material, and the README carries an explicit disclaimer positioning it for security research and educational purposes.

The attack model is worth understanding precisely because of what it is not. This is a local attack: the README is blunt that the attacker must already be able to execute code as the local user. On its own, that sounds unremarkable — ordinary malware already runs as the user. The interesting part is the amplification angle. If Muse has been granted broad access — files, screen recording, accessibility permissions, authenticated cloud services — then a run-of-the-mill unprivileged process that hijacks the dictation endpoint effectively inherits that access. As the README puts it, Muse's access can become the attacker's access.

Mechanically, the PoC works by rewriting the value of endo_voyager_dictation_endpoint so that dictation audio and prompts are delivered to an endpoint the researcher controls instead of muse.ai's legitimate infrastructure. The README enumerates the consequences of that redirection: capture of dictated audio and prompts, prompt injection back into Muse, theft of the app's authentication material, and abuse of whatever entitlements the user has granted the assistant. Each of those follows directly from the fact that the redirected endpoint sits in the middle of a channel the app implicitly trusts.

What elevates this beyond a simple egress-redirection trick is the command surface the PoC maps. According to the README, Muse exposes more than fifty commands, and not-a-mused implements a subset of them — enough to emulate the server side of the interaction once traffic is redirected. That server emulation is what makes the demonstration compelling in a lab: the researcher doesn't just see dictation traffic arrive, they can observe how the client behaves when the fake endpoint responds, including how injected prompts are processed and how authentication material is handled. The tool's README is thin on implementation detail beyond this, but the architecture — local config tampering plus a mock endpoint — is clear.

Operationally, the tool is minimal. The README offers a single invocation, ./not-a-mused -h, to list available options, and instructs the researcher to click the microphone button in Muse and dictate a prompt to trigger the flow. That's the entire usage section, which tells you this is a targeted research artifact rather than a general-purpose framework — there is no scanning, no persistence, no remote delivery. Everything happens inside a single-user session on a machine the operator already controls, which is exactly the right shape for a disclosure-adjacent PoC.

For defenders, the value here is diagnostic rather than offensive. The existence of endo_voyager_dictation_endpoint in a writable, unprivileged location is a detectable design flaw: endpoint protection agents can flag writes to that configuration key, and network monitoring can baseline where Muse dictation traffic is supposed to go and alert on deviation. Because the attack requires no kernel privileges and leaves configuration changes behind, it is more observable than many local post-exploitation techniques — provided anyone is watching AI assistant egress in the first place. The broader lesson is that AI assistants with broad OS entitlements create new trust boundaries that traditional endpoint hardening doesn't cover.

The finding also fits into a wider pattern of AI-application attack surface that Wardle and others have been documenting: applications that hold powerful, user-granted capabilities while exposing mutable configuration to unprivileged code. Dictation, in particular, is sensitive because it is a firehose of user intent — dictated prompts often contain credentials, personal context, and confidential content that users would never paste into a file. Redirecting that stream is a privacy compromise even before you consider prompt injection or token theft, and the PoC's emphasis on prompt capture reflects that hierarchy.

For a purple-team audience, not-a-mused maps neatly to two MITRE-adjacent behaviors worth adding to detection engineering backlogs: unauthorized modification of application configuration (the endo_voyager_dictation_endpoint write) and abuse of application access tokens held by a trusted process. Emulating this in a lab requires only a research VM with Muse installed, which makes it a low-cost exercise for teams assessing whether their macOS fleet has visibility into assistant-app configuration and egress. The Python implementation keeps the code readable for exactly that purpose — understanding the mechanics rather than deploying them.

A note on responsible scope: this article documents the PoC analytically and does not provide a redirection recipe, sample endpoints, or any chain that would weaponize the flaw against a third party. Anyone reproducing the research should do so exclusively on systems they own or are contractually authorized to test, and should treat captured dictation data in the lab as sensitive. The value of publication here is pressuring vendors toward hardened, privilege-checked configuration for AI assistants — the same argument the README itself makes by framing Muse's broad access as an amplification risk rather than a direct flaw.

In summary, not-a-mused is a compact, well-scoped research artifact that turns a single undocumented preference key into a case study on AI-assistant trust boundaries. For macOS security engineers and detection authors, it's a concrete prompt to inventory which assistant-style apps on your fleet store mutable endpoint configuration in user-writable locations, and to extend egress baselining to cover them before an unprivileged process does it for you.

Official project repository for pwardle/not-a-mused.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.