Meta Muse and MCP Security: How Trusted Tools Become an Agentic Attack Surface

The most dangerous AI attack may not break the model, the VM or the application. It may convince the agent to use a trusted tool in an unsafe way.

That is the security problem around the Model Context Protocol (MCP), and Meta Muse is a useful live case because it supports MCP directly.

Parts 1 and 2 of this series covered the agent's authority and the runtime that contains it. This part moves outward to the tools:

What happens when an agent trusts a tool the attacker controls, manipulates or has compromised?

At a Glance

• MCP in Muse: Muse supports custom connectors that speak MCP. Partner documentation (Composio, Nansen, Postiz and others) describes adding one by asking Muse to create a custom connector for an MCP server URL. Muse reportedly has no dedicated MCP settings screen, and Meta reportedly opened connectors to developers about eleven days after launch.
• Two connector classes: directory connectors, which Meta reviews for function, security and legal requirements, and custom connectors, which it does not. Meta's Help Center says Meta doesn't review custom connectors or how they use your information.
• Where the code runs: Meta's blog says built-in connector logic runs outside the runtime cell in privsep workers with tightly scoped credentials. A third-party summary of Meta's documentation says custom connector code runs inside the runtime cell, without that extra separation. Confirm that detail against Meta's Help Center before relying on it.
• Controls that do apply: every outbound request passes through Sentinel; credentials are surrogate tokens swapped for real ones at the network boundary; users can set a per-connector policy (read-only, ask for every action, or allow).
• Reported incidents: none specific to Muse's MCP connectors in the coverage we reviewed. The MCP ecosystem has real, documented incidents (below).

What MCP Is

The Model Context Protocol is an open standard for connecting AI applications to external tools and data. Instead of a custom integration per application, a developer exposes capabilities through an MCP server and any MCP client can use them.

AI application → model → MCP client → MCP server(s) → databases, repositories, SaaS APIs

That standardization is why MCP is spreading, and why it matters for security: the model becomes connected to more things that can be attacked.

The Trust Problem: The Model Chooses the Call

In a normal API integration, the application decides exactly what request is sent. With an agent, the model decides which tool to use, when, and with what arguments, based on everything in its context, including text an attacker may have influenced.

User → agent → model interprets request → selects tool → generates parameters → MCP server → external system

An attacker does not need a malicious tool. Often they only need to influence how the agent uses a legitimate one. search_customer, export_records and send_email can each be legitimate while the sequence is an attack. The tool is trusted. The request may not be.

How Muse's Design Treats Tools

Meta's own principle is the right one: Muse proposes, only Sentinel can grant permission. Concretely, from Meta's published design:

• Sentinel decides. For connector actions, Sentinel sees the connector, method, class of action, scope and what the user asked for, evaluates the user's policy, and returns allow, deny or ask. Approvals are bound to the connector, destination and use case, and are presented in the client UI, not in the conversation.
• Credentials stay out of reach. The agent only sees surrogates; real tokens are inserted at the network boundary.
• Built-in connectors are split from the agent. Their business logic runs in sandboxed privsep workers with explicit credential allowlists, specifically because an agent coerced by prompt injection could otherwise rewrite tool code that holds credentials.
• Read and write are separated where the underlying service allows it, with finer-grained controls than typical OAuth scopes.

Custom MCP connectors are where the picture gets harder. They are unreviewed by Meta, user-added in conversation, and, per the third-party summary above, not given the privsep separation built-in connectors get. They still sit behind Sentinel for egress and approvals. That is a reasonable design, and it also makes the custom connector the weakest link by construction, which is the right place for a security team to look first.

Tool Poisoning: When the Description Is the Attack

MCP servers describe their tools in text that the model reads. If an attacker controls that text, or any part of the tool's schema or output, they can hide instructions there. Invariant Labs documented this as tool poisoning in April 2025: tool descriptions enter the agent's context as trusted content, so instructions hidden in a description can steer the model while remaining invisible to the user. The same research showed "rug pull" variants, where a server changes its tool definitions after the user approved it.

The attack surface moves from the tool's executable code to the information the model uses to understand the tool.

The MCP Incident Record

These are real, documented incidents, not hypotheticals. They show the failure modes that any MCP-connected agent, including Muse, inherits.

Severity scores and counts are as reported by the researchers and CVE records; check each source before quoting a figure.

Open Questions Worth Testing in Muse

These are questions to test, not reported flaws. We found no public report of any of them being exploitable.

1. Can untrusted content cause a connector to be created or used? Custom connectors are created by asking Muse. Does content the agent reads, such as a web page, count as "asking"? What approval does a newly added MCP server get?
2. What are the default approval settings for a fresh custom connector? Meta offers read-only, approve-every-action and allow policies. Which does a new connector start with, and does the user see what changed when a server updates its tool definitions?
3. Is tool metadata and tool output labeled untrusted like other external content in Muse's context?
4. Can a custom connector inside the runtime cell be coerced to behave differently from a built-in one, and what stops it from reaching credentials or the network beyond Sentinel's checks?
5. Are connectors an egress path? One developer reported Muse exporting an entire session filesystem to a connected Google Drive in response to chat prompts (one outlet's account). Whatever the intended behavior, it shows a connector can carry data out, which is what tainted egress is meant to gate.

Why MCP Makes Prompt Injection More Consequential

MCP does not create prompt injection, but it multiplies what a successful injection can do. Part 4 covers the injection itself. The chain looks like this:

Untrusted content → agent reads it → model interprets → trusted MCP tool → enterprise system → data or action

The malicious page never touches the enterprise API. It only has to influence the agent. The API request that follows can be perfectly authenticated and authorized, and still be an incident, because the agent was manipulated into making an authorized request for an unauthorized purpose.

The Tool Boundary Is Not a Trust Boundary

An MCP server should not assume "the AI selected me, so the request is trusted." The safer assumption is that the model may be manipulated, so every consequential request is validated outside the model:

Agent → tool request → policy broker (identity, scope, context) → MCP server → external system

The model requests. A control that does not depend on the model decides.

How to Secure MCP-Connected Agents

1. Least privilege per tool. The smallest scope that does the job; expose the support agent's search without delete, export or billing.
2. Separate read and write. Reading should not carry the right to modify.
3. Approval for high-impact actions. Deletes, payments, external messages, data exports, infrastructure changes.
4. Treat metadata and output as untrusted. Descriptions, schemas, documentation and results can all carry instructions.
5. Pin and monitor tool definitions. Alert when a server's tools change after approval (the rug-pull defense).
6. Validate model-generated parameters. An LLM generating an argument does not make it safe.
7. Monitor sequences. search_customer → export_records → upload_file deserves more scrutiny than any one call.
8. Vet the supply chain. Pin versions, review servers before connecting, prefer reviewed directories over arbitrary URLs.
9. Contain the runtime. Assume the agent can be manipulated and limit what happens next (see Part 2).

For a deeper treatment of tool permissions, see our guide to AI agent tool security and MCP and the OWASP agentic top 10 technical guide.

The Layered Model

IDENTITY  → who is the agent and what authority does it hold?       (Part 1)
RUNTIME   → where does it run and what happens if it is breached?   (Part 2)
TOOLS     → what can it call and what can those tools change?       (this part)
CONTEXT   → what content can influence its decisions?               (Part 4)
ACTION    → what real-world consequences can it trigger?

Failures at any layer can chain into the next. An attacker needs one weak link; defenders need each layer to contain the failure of the one before.

Sources

• Meta AI Research, How We Built Safety Into Muse
• Meta Help Center, custom connectors (quoted via partner documentation, including Nansen's Muse connector guide)
• Invariant Labs, MCP Security Notification: Tool Poisoning Attacks (April 2025)
• Cloud Security Alliance, Agentic MCP Security Best Practices for the CVE-2025-6514 and GitHub MCP summaries
• Koi Security's disclosure of the postmark-mcp backdoor (September 25, 2025), as summarized by Snyk and others

The Meta Muse Security Series

1. Part 1 — Identity: Meta Muse Zero-Day
2. Part 2 — Runtime: Meta Muse's Hidden Sandbox Problem
3. Part 3 — Tools (this article): Meta Muse and MCP Security
4. Part 4 — Context: Meta Muse and Indirect Prompt Injection

Frequently Asked Questions

Related Guides