Mused and Abused: Living Off the Agent

On September 8, Meta introduced Muse, a personal AI agent designed to do considerably more than answer questions.

Muse gets its own dedicated virtual machine. It has a browser. It can connect to applications. It can interact with email. It can book travel, fill out forms, make purchases, work on long-running tasks, and generally operate across a user’s digital life rather than merely discuss it. Meta says credentials are kept separately from the model, sensitive actions can require approval, and a separate Sentinel agent reviews what Muse sends to the internet. (Meta)

Which is sensible.

Because once you build software whose job description is approximately:

“Give me access to everything and I’ll take care of it.”

security becomes somewhat important.

Thirteen days later, macOS researcher Patrick Wardle published not-a-mused, a proof of concept targeting the Muse desktop client.

The bug was not a sophisticated escape from Meta’s secure VM.

It was not a prompt-injection breakthrough.

Nobody spent six months fuzzing a custom parser until an integer wrapped around and the heavens opened.

It was a setting.

An undocumented setting called:

endo_voyager_dictation_endpoint

And an unprivileged process running as the logged-in user could change it. (GitHub)

That setting controlled where Muse sent dictation traffic.

So, naturally, changing it changed where Muse sent dictation traffic.

This became a problem.

Be My Muse

Muse’s macOS client supports voice input. When the user dictates a prompt, the client sends that traffic to Meta infrastructure for transcription.

Wardle found that the destination was configurable through that undocumented preference. His proof of concept changes the endpoint and places itself in the middle of the dictation path. (source)

Conceptually, the normal flow looks roughly like this:

User
  │
  │ speaks
  ▼
Muse.app
  │
  │ authenticated dictation traffic
  ▼
Meta transcription infrastructure
  │
  ▼
Muse

After the preference is modified:

User
  │
  │ speaks
  ▼
Muse.app
  │
  │ authenticated dictation traffic
  ▼
Attacker-controlled endpoint
  │
  ├── observe prompts
  ├── observe authentication material
  └── influence returned content
         │
         ▼
       Muse

That’s already undesirable.

It gets more interesting when we inspect what Wardle’s code actually does.

His PoC watches the redirected connection for an authorization bearer token—an ABRA token in the implementation—and can use that token with Meta’s account APIs to verify the account, retrieve the user’s leased Muse VM, and communicate with the agent environment. The PoC contains functionality for retrieving chat information and invoking agent commands such as notifications, file writes, and camera-related actions. The source explicitly notes that something such as photo capture still depends on Muse having the corresponding camera permission. (source)

That last part is important.

The vulnerability does not magically create every permission on the machine.

It does something more subtle.

It gives the attacker an opportunity to use authority that someone else already accumulated.

And that is where this stops being an amusing preference-file bug.

“But the Attacker Already Has Code Execution”

Correct.

Wardle’s attack requires code executing in the victim’s local user context. His own README explicitly says so. Meta made the same point after disclosure: this was not an unauthenticated remote compromise of a clean Mac. Meta subsequently issued a hotfix. (README; Meta on X)

This is a perfectly legitimate distinction.

It is also where the interesting part begins.

An application running as a user and an application possessing all of the authority accumulated by that user’s AI agent are not necessarily the same thing.

Modern operating systems, browsers, identity providers, and SaaS applications spend considerable effort separating those concepts.

The fact that malware executes under Alice’s account does not automatically mean it has every OAuth grant Alice has ever issued, every application session Alice uses, every TCC permission granted to another application, every cloud integration configured elsewhere, or every remote service connected to Alice’s agent.

Muse, however, is specifically designed to collect useful authority.

That is how it becomes useful.

Meta says users can connect applications, permit Muse to read or send email, allow it to operate through its browser, and authorize it to take actions across multiple services. The agent then operates through its dedicated cloud environment on the user’s behalf. (Meta)

So the relevant security question isn’t:

Did the attacker already have code execution?

It is:

How much more authority became reachable once the attacker gained control of the agent?

That is a very different question.

Your Malware Has Hired an Intern

Traditional malware generally needs capabilities.

If it wants a file, it needs a way to access the file.

If it wants a cloud account, it needs the relevant credentials or session.

If it wants to interact with some SaaS platform, somebody needs to understand the API, steal the authentication material, implement the requests, and deal with whatever controls exist around the application.

If it wants access to a camera, microphone, remote service, browser session, or connected device, it needs some path to those resources too.

This is why serious post-exploitation frameworks accumulate modules.

Different objective.

Different capability.

Different implementation.

Then we invented personal AI agents.

A personal AI agent is essentially an application whose product requirement is:

“Please integrate with as many useful things as possible, understand arbitrary instructions, and perform those instructions for me.”

This creates a rather appealing proposition for an attacker.

Why implement fifty separate capabilities when the victim may already have a signed, trusted, regularly updated application that exposes fifty of them?

Wardle’s own PoC says Muse exposes more than 50 commands and implements only a subset. (GitHub)

We have spent years talking about living off the land: attackers abusing legitimate operating-system binaries and administrative tools because those tools are already present, trusted, capable, and difficult to distinguish from ordinary activity.

AI agents create the next logical version.

Living off the agent.

The attacker doesn’t necessarily bring the capability.

The victim did.

Not Privilege Escalation. Authority Amplification.

Calling this traditional privilege escalation muddies the issue.

Wardle didn’t demonstrate:

user → root

The more interesting transition is closer to:

local user process
        │
        ▼
compromise agent identity
        │
        ▼
reach capabilities delegated to agent
        │
        ▼
exercise broader effective authority

Call it a confused deputy.

Call it capability hijacking.

Call it delegated-authority abuse.

Call it permission laundering if marketing requires something catchier.

The important property is the authority delta.

Consider the model conceptually:

The exact blast radius therefore varies by user.

That qualification matters.

But it does not weaken the architectural problem.

It defines it.

The more capable the agent becomes, the more valuable control of the agent becomes.

This Is Not Really an AI Vulnerability

And that may be the funniest part.

For all the discussion around securing AI agents, this particular weakness was brutally ordinary.

Meta publicly describes a reasonably sophisticated architecture around Muse. The agent operates in a dedicated Muse Secure VM. Credentials are stored separately. Sentinel sits alongside Muse and evaluates outbound activity. Users can constrain integrations, and critical operations such as sending email or making purchases may require confirmation. (Meta)

There is a lot happening there.

Models.

Agents.

Policy enforcement.

Isolation.

Credential brokers.

Approval workflows.

Secure virtual machines.

And then a local desktop preference decides where authenticated traffic goes.

Security architecture has an irritating habit of being exactly as strong as the least glamorous trust assumption inside it.

The lesson isn’t necessarily that Wardle “bypassed Sentinel.”

That would overstate what the public research establishes.

The more useful lesson is that controls like Sentinel operate inside a larger system of assumptions.

If Sentinel evaluates an instruction believing that instruction came through a trusted channel, compromising the trusted channel changes the problem before Sentinel gets to participate.

The model can behave perfectly.

The agent can follow policy perfectly.

The guardrail can approve exactly what it was designed to approve.

And the system can still lose because the provenance of the instruction was wrong.

That’s not AI magic.

That’s architecture.

We Spent All This Time Worrying About Prompt Injection

Prompt injection deserves attention.

So do tool abuse, malicious documents, poisoned retrieval, jailbreaking, insecure MCP servers, overprivileged connectors, and models making spectacularly questionable decisions.

But agents also have all the boring things software has:

• Desktop clients
• Authentication tokens
• Preference stores
• IPC
• Local APIs
• Browser automation
• Update mechanisms
• Callback URLs
• Connector configuration
• Tool manifests
• Model endpoints
• Device bridges
• Session state

The industry cannot model agent security exclusively as:

The real system looks more like:

                    ┌──────────────┐
                    │     User     │
                    └──────┬───────┘
                           │
                    ┌──────▼───────┐
                    │ Agent Client │
                    └──────┬───────┘
                           │
               ┌───────────┴───────────┐
               │                       │
        ┌──────▼──────┐         ┌──────▼──────┐
        │ Agent / LLM │         │ Identity /  │
        │   Runtime   │         │ Credentials │
        └──────┬──────┘         └─────────────┘
               │
        ┌──────▼──────┐
        │ Policy /    │
        │ Guardrails  │
        └──────┬──────┘
               │
        ┌──────▼──────┐
        │ Tools and   │
        │ Connectors  │
        └──────┬──────┘
               │
      ┌────────┼──────────┐
      ▼        ▼          ▼
    Email    Files     Browser
      │        │          │
      ▼        ▼          ▼
     SaaS   Devices    Internet

Every arrow is a trust boundary.

Every token is an attack surface.

Every configuration mechanism is potentially security-sensitive.

And every new integration increases the agent’s authority.

The LLM is just one box.

Congratulations, You Invented Another Service Account

Enterprise security teams may find this pattern strangely familiar.

Give an identity access to ten systems.

Let it operate unattended.

Make it useful enough that workflows depend on it.

Add more permissions whenever somebody needs another integration.

Allow it to authenticate automatically.

Then eventually discover that nobody can confidently explain everything the identity can reach.

We already have a name for this experience.

Service accounts.

AI agents add several characteristics that make the situation even more interesting.

A traditional service account executes predefined software.

An agent accepts natural-language instructions.

A traditional automation workflow follows predetermined branches.

An agent can dynamically decide which tool to invoke.

A traditional integration often has a relatively narrow purpose.

A general-purpose personal agent is explicitly designed to cross application boundaries.

The fundamental security problem isn’t new.

The programmability is.

A browser may contain authenticated sessions.

A password manager may contain secrets.

An RMM agent may control the endpoint.

An AI agent increasingly sits above all of them and provides something dangerously close to a universal instruction interface.

That is the difference.

EDR Is Going to Have a Wonderful Time

There is another consequence hiding underneath Wardle’s research.

Suppose an attacker performs an action by instructing or controlling the agent.

What does endpoint telemetry record?

Perhaps:

Muse.app → write → ~/Documents/example

Muse writing a document isn’t particularly suspicious.

Writing documents is something an agent is supposed to do.

Or:

Muse.app → access → camera

Again, if the user previously authorized that capability, the process itself may look entirely legitimate.

We traditionally lean heavily on actor provenance:

Who performed the action?

Agentic systems make that insufficient.

The more interesting question becomes:

Why did the actor perform the action?

Consider two superficially identical events:

and:

The final endpoint event may look nearly identical.

The process is legitimate.

The binary is signed.

The capability is expected.

The resource may even be something the application commonly accesses.

The difference exists upstream in the causal chain.

Security tooling therefore needs something it generally does not possess today:

agentic provenance.

A useful event graph may need to capture:

Now consider indirect prompt injection:

Or the Muse case:

At the bottom of all three chains, the log might simply say:

Muse did it.

Yes.

We know.

That is increasingly the problem.

Signed and Trusted Is Not the Same as User-Authorized

This distinction is going to matter enormously.

Endpoint security has historically used process identity as an important signal.

Is the executable signed?

Who published it?

Is it commonly installed?

Does it normally access this resource?

Agents weaken the usefulness of those questions because agents are intentionally general-purpose executors.

The same legitimate application may:

• read a file,
• send an email,
• open a browser,
• download something,
• invoke an API,
• talk to another application,
• or manipulate data,

all as completely legitimate behavior.

A signed binary therefore tells us what executed.

It does not necessarily tell us who intended the action.

That is going to force security products to move from process attribution toward intent attribution.

And that is not a small change.

Agents Are Permission Concentrators

Meta’s stated design gives users control over what Muse can access, which is exactly what a system like this should do. (Meta)

But there is an unavoidable architectural consequence.

Every permission granted to an agent increases the value of compromising that agent.

Every connected SaaS platform expands its potential blast radius.

Every new tool increases what an attacker may attempt to coerce, invoke, impersonate, or inherit.

The agent becomes a permission concentrator.

This is not unique to Muse.

The same principle increasingly applies to coding agents, computer-use agents, enterprise copilots, autonomous SOC systems, MCP-enabled assistants, browser agents, and whatever we decide to call the next category six weeks from now.

A coding agent may have GitHub access, shell access, CI/CD credentials, cloud credentials, package-manager access, and filesystem access.

A SOC agent may have SIEM access, EDR access, identity-provider access, ticketing access, threat-intelligence feeds, and the ability to isolate endpoints.

An enterprise assistant may have SharePoint, email, Slack, Salesforce, Workday, ServiceNow, and internal databases.

The AI doesn’t need to be malicious.

The AI doesn’t even necessarily need to be tricked.

Compromise the delegation layer and the permissions are already waiting.

Living Off the Agent

That is why Wardle’s Muse research matters.

Not because the preference was unusually sophisticated.

Precisely the opposite.

A mundane client-side weakness provided a path into something far more powerful than the component that was compromised.

That’s the architectural inversion worth paying attention to.

We used to ask:

What can this malware do?

Agentic environments increasingly require another question:

What legitimate software can this malware convince, impersonate, or hijack into doing it instead?

That changes attacker economics.

Why build browser automation if the agent already browses?

Why integrate ten SaaS APIs if the agent already has ten connectors?

Why request camera access if a trusted application already has it?

Why write a sophisticated post-exploitation framework if the endpoint contains an application explicitly designed to translate arbitrary objectives into actions?

Your malware does not need every capability anymore.

It may just need a manager.

So What Do We Actually Defend?

The Muse-specific issue was hot-fixed shortly after public disclosure. (The Verge)

Good.

The setting can disappear.

The larger problem doesn’t.

Agent deployments need security controls around authority, not merely around models.

That means understanding what every agent identity can reach, constraining connector permissions, protecting agent tokens as high-value credentials, monitoring modifications to agent configuration, validating the provenance of instructions, correlating tool calls with the user or event that caused them, and treating unexpected changes to model endpoints, MCP configurations, callback URLs, tool registries, or agent preferences as potential control-plane compromise.

Most importantly, security teams need to stop treating:

trusted_agent.exe performed action

as sufficient attribution.

The question is increasingly:

What caused the trusted agent to perform the action, through which identity, originating from what input, under whose authority?

That provenance chain needs to survive all the way from human intent to resource access.

Otherwise we will build enormously capable agents, surround them with increasingly elaborate policy systems, and then discover after an incident that all of our logs faithfully recorded what happened:

The AI did it.

Very helpful.

Mused. Abused.

Meta did several things that make sense.

Dedicated infrastructure.

Credential separation.

Agent isolation.

Action approvals.

A separate security agent.

Auditability.

Those are all reasonable ingredients.

Wardle’s research doesn’t prove those ideas are useless.

It demonstrates something much less comfortable.

The security boundary of an AI agent is larger than the AI agent.

It includes the desktop application.

The authentication flow.

The configuration surface.

The communication channel.

The connector ecosystem.

The local operating system.

The cloud control plane.

And every piece of delegated authority accumulated along the way.

The model is only part of the attack surface.

The agent is the identity.

The integrations are the privileges.

The tools are the capabilities.

And the control path tells them what to do.

Compromise that path and you may not need to compromise everything behind it individually.

You simply ask the deputy.

We’ve seen this pattern before.

Service accounts.

RMM.

Browsers.

CI/CD.

Identity providers.

Automation platforms.

Trusted software slowly accumulates enough authority that eventually the software itself becomes infrastructure.

AI agents are heading directly toward the same destination.

Except this time the infrastructure accepts English.

Mused.

Abused.

And welcome to living off the agent.

Sources & Further Reading

• Meta — Introducing Muse: The World’s First Personal AI Agent Built for Everyone: https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/
• Patrick Wardle — Not a Mused (GitHub): https://github.com/pwardle/not-a-mused
• Patrick Wardle — not-a-mused source (notamused.py): https://github.com/pwardle/not-a-mused/blob/main/notamused.py
• David Singleton (Meta Superintelligence Labs) on X: https://x.com/dps/status/2102248329111634067
• The Verge — Meta patches Muse exploit that let attackers control the AI agent: https://www.theverge.com/tech/998679/meta-muse-patch-zero-day-exploit-ai-agent