Muse isn’t enterprise-ready yet. Your employees might be using it anyway.

Chris Lippi
Chief Product Officer
October 13, 2026

Somewhere in your company this week, an employee typed "connect my work email" into Muse, clicked through an OAuth screen, and if your email system wasn’t locked down, handed a personal AI agent the keys to their inbox. Copies of those emails may now sit in logs and storage on Muse’s cloud virtual machine, kept under Meta’s retention rules instead of yours. Unless the employee found the opt-out, Muse’s default settings let Meta use that data to improve its models. The customer names, contract terms, and colleagues’ personal details in that inbox came along too, and none of those people agreed to it. Nobody in security approved it, and nobody in security can see what Muse has done with that access since.

Meta launched Muse on September 8 as a personal agent that runs tasks on its own cloud virtual machine: it browses, fills out forms, books travel, sends email, and keeps working after the user closes the app. It climbed to the top of the App Store within days. Employees will bring it to work the same way they brought personal phones and Dropbox a decade ago, because it saves them hours. Many already may be as we’re getting questions from CISOs that are fielding requests from employees who want to add work systems so one personal agent can help across both their private and professional lives.

Barndoor provides the access layer that sits between AI agents and the systems they touch. My advice to security teams is to block Muse, unless you’ve gained control and visibility over it and have really understood the data policy tradeoffs against the rewards your business seeks. It’s full of risks. If you must or even if you just want to experiment, here are four things you should address beforehand.

Keep Muse off its stock connectors

Muse shipped with built-in connectors for Gmail, Google Calendar, Outlook, and Google Docs. Each one works through user-granted OAuth: the employee clicks Allow, and Muse receives a token carrying that employee’s full permissions in the app. From that moment, every read, send, and delete Muse performs looks to Google or Microsoft like the employee did it.

That gives a security team three problems:

• No record of agent activity. Your logs show the user, so you cannot separate what the employee did from what Muse did on their behalf.
• No policy on the action. OAuth scopes are coarse. A token that can read mail can usually send it too, including to an external address, and nothing in between asks whether that send should happen.
• No way to revoke centrally. The OAuth grant lives in each employee’s account. Finding and pulling hundreds of individual grants after an incident is slow, manual work.

The custom connector path is wider still. An employee can hand Muse any remote MCP server URL, and Muse will write its own client on the virtual machine, connect, and save the integration as a reusable skill. That means an unvetted third-party server can end up wired into your CRM, and the only record of it is a file on a virtual machine you don’t control.

Because Muse picks which tools to call at runtime, you cannot predict its access path ahead of time. A static, user-scoped token is the wrong credential to hand an actor whose next step you can’t predict.

Instead, route Muse through Barndoor

Muse already knows how to talk to a remote MCP server, which means the fix doesn’t require fighting the product. Instead of a dozen stock connectors, the employee connects Muse to one endpoint: Barndoor. Every app your company has approved for agent use sits behind that endpoint, and every tool call passes through it.

Here is what changes once Muse goes through Barndoor:

• Muse acts as the employee, and no more. The employee signs in through your identity provider, so Muse inherits that person’s existing permissions and group memberships instead of a broad token they granted on their own.
• You decide which tools Muse can use. Policy applies per app and per action. Muse can read Salesforce opportunities but not edit them, draft Gmail messages but not send outside your domain, and search Jira without closing tickets.
• Every call is on the record. Barndoor logs which agent called which tool, for which user, with what result, and you can review them in Barndoor’s Audit History or export them to your SIEM. When someone asks “what did Muse do in our CRM last Tuesday,” you can answer it.
• One config change turns it off. If Muse misbehaves, you revoke access in one place instead of hunting down OAuth grants account by account.

None of this is specific to Muse as IT should expect even more of these. IT should set any agent’s permissions by how much they trust it. A consumer personal agent like Muse, with unclear data retention and training defaults, zero logging or visibility, earns very little trust, so its permissions should be exceedingly narrow until that changes.

In Barndoor, once you have a narrow policy for this type of agent, when the next one comes along, you can just reuse the policy to contain it if you don’t want to block it outright.

Stop Muse from direct access

A gateway only governs the traffic that goes through it. If an employee can still click “Connect Gmail” inside Muse and get a token, the gateway becomes optional, and optional controls can get skipped.

Most SaaS admin consoles let you control which third-party apps can request OAuth access. You should use them if you don’t already:

• Google Workspace: In API controls, set unconfigured third-party apps to blocked, then explicitly trust only the clients you approve, including Barndoor.
• Microsoft 365: Turn off user consent for unverified apps in Entra ID and route requests through the admin consent workflow.
• Salesforce, Slack, Atlassian, and others: Restrict connected apps and app installs to an admin-approved list.

With the direct path closed, the only way for Muse to reach company data is through the governed path. Employees still get the agent they want, and you get one front door to watch.

Assess where the data goes

Access controls determine what Muse can touch. It does not address what happens to the data after Muse touches it, and this matters a lot with a free consumer product, with consumer terms.

When an employee connects Muse to a work inbox, your company’s data is processed under Meta’s consumer terms. You likely have no contract with Meta covering Muse: no data processing agreement, no retention commitments, no breach notification terms, and no audit rights. The employee clicked through an agreement on your behalf, and your legal team never saw it.

Meta is making real privacy commitments for Muse. It says Muse does not feed its ad systems, and it has announced a Confidential VM option where only the user holds the encryption key. Those are good steps. But the details (Sept 17th version) still deserve a careful read. It’s not exhaustive, but here are some things I picked up:

• Meta says the default setting shares user information for model improvement unless the user explicitly opts out. You can’t govern this in IT, so set a company policy at the least to have employees attest they’ve opted out.
• There are no clear safeguards for bystander data. Bystanders are your customers, your partners, and your colleagues, and any terms you may have with your bystanders cannot be therefore enforced with Muse. Be really careful here to not breach.

Barndoor helps here because it can control what data leaves your systems in the first place via our data protection policies. If Muse can only read the Jira projects and Salesforce fields your policy allows, and sensitive data is omitted, it never reaches Meta’s infrastructure, regardless of what the default settings say. Policy at the gateway is a far stronger guarantee than hoping every employee followed your internal policies.

Meta’s future enterprise version

This all will probably change. On September 28, Meta announced Meta Enterprise Platform, a new business line that will bring the Muse agent, Muse API, Muse Code, and the rest of its stack to companies. There seems to be real commitment towards enterprise requirements. I expect many of the concerns above will get answered as the platform matures. Personal agents will be a thing so it’s rational to assume Meta (and others) will make it right for enterprise.

From where we sit, a few capabilities will help Muse be more enterprise-ready:

• Admin control over which MCP servers Muse can use. An organization should be able to publish an allowlist, disable the stock connectors, and block employees from adding unapproved custom connectors.
• First-class support for custom MCP endpoints, including AI gateways. Today, connecting Muse to a gateway works because Muse can build its own client. That should be a supported, admin-managed configuration, so a company can point every employee’s Muse at its gateway on day one without worry.
• Enterprise identity. SSO and SCIM provisioning, so an employee’s Muse is tied to a corporate identity that IT can disable when they leave. Barndoor already helps here, but IT will reject Muse until they can off-board employees that leave the organization.
• A real contract. A data privacy agreement, retention controls, data residency options, and training opt-out as the enterprise default.

We would welcome all of it. An enterprise agent that ships with these controls is easier for our customers to adopt, and it lets Barndoor focus on enforcing consistent policy across every agent in the company. Until those controls exist, while Barndoor can help you reduce the risk, there are still too many holes for most organizations to adopt Muse. To learn more, take a product tour or schedule a demo.