Muse vs Grok Bot vs Instinct: What Each Agent Can See

Quick comparison

Original comparison checked against each vendor's published pages on September 9, 2026, with custom tools added September 12 and Grok Bot availability and logging refreshed September 29. All three products are moving quickly, so confirm against the primary source before acting on any single row. The last row is also what decides whether an agent can operate a fleet of background workers through WorkerKit, Muse over direct API calls or its CLI and Grok Bot over MCP, which is covered in Giving them a fleet.

Meta Muse

Muse is the most architecturally careful of the three, and that is worth saying before anything critical. Meta built a real permission boundary and then published a detailed engineering write-up about it, titled How We Built Safety Into Muse.

Meta's announcement describes Muse as "rolling out in the US on iOS, Android, and muse.ai, and coming soon to AI glasses", and says it is "free for most of what people need, with subscription plans for people who want to do more."

How Muse gets in

The core design decision is that the agent does not hold your secrets. A separate component called Sentinel handles permissions, and Meta describes it plainly: "Sentinel is the sole permission authority for connector actions and network egress." On credentials, Meta writes: "The agent never sees real tokens, which means any attempt to coerce the agent to reveal the actual secrets via prompt-injection or otherwise is futile."

That is a meaningful property. A prompt injection cannot talk the agent into handing over a token it has never held. Connector tokens, Meta writes, are stored "in a separate isolated container in your VM, not in other Meta services."

Permissions are per connector, and Meta's help centre documents five approval options: "Allow once" (Muse proceeds this one time), "Allow for this task," "Allow for this site," "Always allow," and "Deny." There are two ask-modes, "Ask for some actions" and "Always ask." Meta also separates the two kinds of access: "Read actions let Muse view your information" while "write actions let Muse make changes and manage information on your behalf."

Muse is also the only one of the three that can narrow a grant below the OAuth scope the provider hands out. From Meta's security write-up: "Muse also provides fine-grained control over exactly which actions the agent can take on behalf of the user beyond the coarse groups that are usually exposed as OAuth scopes. (For example, if you grant Muse the Gmail read-access OAuth scope on the Gmail side, you can remove the ability to access Gmail settings that usually comes along with it)."

Worth knowing before you connect anything: Facebook, Instagram, and Threads are, in Meta's words, "connected automatically if you have your accounts in the same Accounts Center." And Meta does not publish a per-connector permission matrix, so how finely the read and write split applies to any given connector is not documented.

What you can see afterwards

Muse gives the user a visible browser they can watch and take over, and an in-product view of what it has been doing. For a consumer product that is genuinely good, and better than what the other two offer their users.

What is absent is anything an organisation would need. We could not find a documented machine-readable export of that activity record, an admin console, or a stated retention period on Meta's Muse help pages, privacy policy, or security write-up.

Disconnecting a connector does not purge what the agent already used. Meta's help centre states: "Information that Muse previously used to perform tasks with that Connector might still remain in Muse's memories and your conversation history."

xAI Grok Bot

First, disambiguation, because this trips people up. Grok Bot is not the @grok account on X, and it is not Grok on grok.com. It is a separate always-on agent product that runs on a persistent cloud computer, and it signs in through Cursor even for eligible SuperGrok subscribers. The documentation is explicit: "Members sign in to Grok Bot with their Cursor account, so your existing Cursor SSO configuration applies." It remains in beta.

How Grok Bot gets in

The thing to understand about Grok Bot is the shape of the container, and xAI is refreshingly direct about it. Under a heading reading "One computer, shared by all your Bots," the docs say: "Every Bot on your account uses the same computer: Browser cookies and signed-in sessions are shared; Files are visible to every Bot." On the separation between working surfaces, they add: "The screens are separate work surfaces, not separate security boundaries." The security and privacy page puts it as an instruction: "Do not use separate Bots as a security boundary."

So the natural mental model, one bot for expenses and another for recruiting each with its own reach, is not how the isolation works. Connectors follow the same pattern: "Installed connectors are account-wide. Their availability is not isolated to one Bot."

Network reach is broad unless a team narrows it. The security documentation notes that "teams without a policy default to allow-all."

What you can see afterwards

Enterprise teams can enable Action Recording, which is off by default. It records metadata about Bot actions, including scrubbed shell commands. Enterprise audit logs separately cover admin, security, and control-plane events. To export hosted MCP tool arguments and results, admins must also opt in to conversation content export. See the current security FAQ.

Control-plane audit events are not a complete record of what a Bot read or changed, and Action Recording is neither enabled by default nor a payload export.

To their credit, Grok Bot is the only one of the three with real team administration: SSO applies, and Enterprise teams can configure network policy and Action Recording.

Instinct

Instinct is the newest and smallest of the three, invite only, and by a distance the most permissive on paper. Its public web presence is essentially three pages: a homepage, terms of service, and a privacy policy. There is no published API or developer documentation.

Because there is so little documentation, the terms and the privacy policy are the product specification. They are unusually revealing.

How Instinct gets in

The grant users give is broad, and stated as such. From the terms: "You also authorize us to access, copy, collect, and index data from your Connected Services, exchange data with your Connected Services and take Actions on Connected Services on your behalf."

Where Meta and xAI both work to keep secrets away from the model, Instinct's privacy policy contemplates the opposite. It describes users providing "your username and password for third-party accounts so that the personal assistant can sign into these accounts on your behalf."

There is no published scoping mechanism, and the terms hand that responsibility back to the user: "You remain responsible for configuring any additional safeguards or restrictions on Actions, including appropriate security settings, permissions, and sharing settings on each Connected Service." In practice that means any narrowing has to happen on the account side, before Instinct ever connects.

In August 2026, TechCrunch reported that several early testers raised privacy and security concerns about the product. Among them, Alex Cohen described testing whether the assistant could be phished. In his own words, quoted in that piece: "I wanted to see how easily Instinct could be phished, so I created a brand new Gmail account and emailed my real personal account with instructions for Instinct." He also said, "I don't think we're at the point where it's safe to give AI read/write access to your inbox," and he deleted his account. We have not independently reproduced any of the tester reports in that article, and we link to it so you can read the reporting directly.

What you can see afterwards

Instinct's own terms contain the least reassuring sentence in this comparison: "Records of Actions available through the Services may not always be accurate."

Disconnecting is explicitly not deletion: "Note, even if you disconnect a Connected Service, we may still use the indexed Connected Service Input data unless you follow the instructions to request deletion." We could not find any retention period stated in the privacy policy.

One thing Instinct does state clearly, and it deserves credit, is a carve-out that Google's Limited Use rules require: "We do not use information received from Google Workspace APIs to evaluate, fine-tune, train, or improve AI models, or for serving ads, including retargeting, personalized or interested-based advertising."

The four axes that matter

1. Who holds the credential

Meta is clearest here, and the strongest of the three: the agent never sees real tokens. Grok Bot's position is more nuanced, because signed-in browser sessions live on a computer shared by every bot on the account. Instinct's privacy policy contemplates users handing over passwords outright.

The part worth being precise about, because it is easy to over-read: keeping a credential away from the agent is not the same as narrowing what the agent can do with it. In all three products the agent acts with the authority of the connected account. Protecting the secret protects the secret. It does not shrink the blast radius.

2. How narrow the grant can be

Muse wins this one outright. It is the only one of the three that documents narrowing a grant below the scope the provider issues, and its own example, stripping Gmail settings access out of a Gmail read grant, is exactly the kind of control the other two lack. The caveat is that Meta publishes no per-connector permission matrix, so how far the split goes on any given connector is undocumented.

Grok Bot's connectors are account-wide by design. Instinct publishes no scoping primitive at all. Scope is what sets your blast radius, and where it is coarse, one bad instruction reaches everything the account reaches.

3. What revoking actually does

Two of the three say in writing that disconnecting is not deleting. Muse keeps connector-derived information in memories and conversation history. Instinct keeps indexed data until you separately request deletion.

The mental model most people carry, that switching a connector off makes the agent forget, is not what either policy describes. That matters most in the case you actually care about, which is an employee leaving or a contract ending.

4. What the log contains

There is an inversion worth noticing. The consumer product has the best user-facing view and no documented admin export. The product with real team administration reserves detailed action recording for Enterprise and leaves it off by default. The startup warns you its records may not be accurate.

Grok Bot's optional Enterprise export can include hosted MCP arguments and results. For the same per-request evidence across multiple agents and integrations, a shared data boundary remains useful.

What all three have in common

Strip away the differences and the same architecture is underneath: a persistent agent holding standing access to someone's mail, calendar, files, and payments, acting when nobody is watching.

More to the point, two of the three tell you in their own documentation that they cannot fully prevent an agent being steered by content it reads. Meta: "Prompt injection remains an open problem in the industry." Cursor, on Grok Bot: "These controls reduce, but don't eliminate, risk from malicious content, which is another reason to keep consequential actions behind approval."

That is not a criticism of either vendor. It is an honest statement of where the field is, from the people with the most reason to know. And it points at the same conclusion both of them reached in their own products: do not ask the model to police itself. Put a deterministic boundary between the agent and the data, where an injected instruction gets no vote.

Sentinel is exactly that: a separate authority the agent cannot override, deciding on connector actions and network egress. Meta built that boundary for its own agent. The same boundary is what any other agent needs, and what a company needs across all the agents its people are already running.

Adding a data layer underneath

These agents govern what the agent may do once it holds your data. PortEden governs what it can see in the first place. The two are complementary, and the second is the layer you control.

Instead of handing an agent a broad token to your mailbox, you connect the data source to PortEden once and give the agent a scoped view. Every tool call is checked against your rules and then allowed, redacted, or denied, per contact, per folder, per range, per document, or free-busy only on a calendar.

And every call is written down. To be precise about what that record holds, because the distinction matters: PortEden logs the tool call request, the allow or deny decision, and the redacted response. It never sees your prompt and never sees the model's output. That is the per-request artifact none of the three agents above produces, and it is deliberately narrower than a transcript.

The same move helps for a reason unrelated to security. An agent pointed at a narrow, well-shaped surface performs better than one handed a huge tool catalogue and a whole mailbox. Fewer tokens spent on tool definitions before the task starts, and less irrelevant context to rot over a long session. The scoping that shrinks the blast radius also makes the agent more reliable.

With Muse

Muse is built around skills. Meta describes them as "detailed instructions to Muse" on getting the most out of each connector, and Meta wrote them for the connectors it shipped. That is the shape PortEden takes here. The PortEden skill gives an agent a scoped path to email, calendar, and files, with your rules applied on every call and the result logged, rather than a broad grant to the whole account.

The practical difference: connect a mailbox directly and the agent works against a mailbox-wide grant. Route it through PortEden and the request can only reach the slice you allowed, with sensitive fields redacted before the agent sees them. Meta has not published a third-party skill directory, so treat this as the integration shape rather than a listing in a store.

With Grok and Grok Bot

For Grok on grok.com this works today. xAI documents bringing your own MCP server: go to grok.com/connectors, choose New Connector, then Custom, and point it at an endpoint such as https://mcp.porteden.com/email. The server has to be reachable on the public internet, which the hosted PortEden endpoints are. We have a full walkthrough of Grok connectors.

Grok Bot is a separate case. Because it signs in through a Cursor account rather than a Grok or X account, connectors added at grok.com are not documented to reach it, and the Grok Bot settings expose a plugin marketplace rather than a form for pasting a server URL. When this piece was first published we declined to claim a custom server could be added at all. Since then, Cursor staff have confirmed on the community forum that Grok Bot "manages connectors through the chat itself": you tell the bot to add your MCP server, and the endpoint has to be "a public HTTPS URL, using streamable HTTP or SSE" because the bot runs in the cloud. The hosted PortEden endpoints meet that requirement, so the same https://mcp.porteden.com/email style of server can be added to a bot in chat. Two caveats stand: the connector is account-wide once added, so every bot on the account can reach it, and the record of what a bot read is still off by default unless you turn Action Recording on.

With Instinct

Nothing to offer here, honestly. Instinct publishes no API and no connector configuration, so there is nowhere to insert a data layer.

That makes it the clearest illustration in this comparison rather than an integration target. If you are evaluating Instinct or anything like it for work that touches client or company data, the questions worth putting to the vendor are the ones its own terms leave open: what is the retention period, what can be scoped below a full account grant, and can you get an accurate, exportable record of what the agent read.

Giving them a fleet: WorkerKit

Each of the three already runs unattended work, and each runs it the same way. Muse's background and scheduled tasks share the conversation's context, model, and identity. Grok Bot's routines run on the one computer every bot on the account shares. Instinct publishes nothing about how its standing jobs are isolated. In every case the job carries the full access of every account connected to the agent. That shape is the root of the blast-radius problem, and it is also why these agents get worse as you hand them more: the chat fills with machine output, the expensive model runs the cheap jobs, and one injected email reaches everything.

The alternative is not a different assistant. It is a fleet: narrow background workers, one per job, each with its own grant, operated from the assistant you already talk to. That is what WorkerKit provides, and it publishes integration paths for two of the three agents in this comparison: WorkerKit for Meta Muse and WorkerKit for Grok Bot. Disclosure: PortEden and WorkerKit are partners. The claims below are taken from WorkerKit's published pages, dated September 10, 2026.

One agent versus a fleet

A WorkerKit worker is a background agent with its own instruction, memory, schedule, budget, model, and app permissions, hosted around the clock. Each run executes sealed in its own context, settles its own cost, and returns a short digest. Workers ship as kits, which are pre-instructed, pre-permissioned, and pre-scheduled for one job, so a monitor, a triage worker, or a daily briefing takes about a minute to install rather than an afternoon of wiring. Against the four axes this comparison is built on, the differences look like this.

The detail that matters most for this comparison is the credential the assistant holds. To operate a fleet, Muse or Grok Bot is given a manager key, and WorkerKit is specific about its reach: the key carries explicit scopes, is shown once and stored hashed, and "reaches the fleet only: no scope on it reads a mailbox, a calendar or a CRM." Workers reach apps under their own grants, and the assistant that dispatches them never does. That is the inverse of the pattern the first half of this article documents, where the assistant itself holds standing access to everything.

How each agent reaches the fleet

The same fleet answers from any host. What changes per agent is only the door it walks through.

Paths as documented on WorkerKit's pages for each agent, September 10, 2026. The manager key is the same object on every path, and so is its limit: it operates workers and grants no access to any connected app.

Muse as fleet operator

With a fleet, Muse becomes the operator. You ask it in plain language which workers failed today or to run the briefing now, it picks the matching operation, and the worker executes in its own context on its own runtime. Results come back on two paths: Muse reads the digest and settled cost from the fleet feed, and people receive it through the worker's delivery channels, such as Slack, Teams, email, or Notion.

The integration shape follows how Muse reaches outside services. Meta's security write-up says Muse "can also write its own custom connectors for other services you care about if they have their own APIs or CLIs," and WorkerKit is exactly that kind of service. Muse connects over the plain-HTTPS WorkerKit API, or through the WorkerKit CLI inside its own VM: an account admin creates a manager key with the scopes the job needs, the key is entered through Muse's own hosted API-key entry, and the agent installs the WorkerKit skill file that carries its operating rules. WorkerKit publishes the whole procedure, written for the agent doing it, at workerkit.ai/muse/setup. The human's part is two steps.

Grok Bot as fleet operator

Grok Bot is the cleaner fit, because it speaks MCP natively and, as noted above, adds custom remote servers in chat. WorkerKit arrives as two hosted MCP mounts: a public directory mount for browsing the kit catalogue, which needs no key at all, and a workers mount for operating the fleet, which takes the manager key as a single bearer header. Grok Bot asks for an explicit yes before it adds each server. The step-by-step procedure is at workerkit.ai/grok-bot/setup.

This is also the most direct answer to the shared-computer design documented earlier. Cursor tells you not to use separate bots as a security boundary. A WorkerKit worker is one: each worker holds its own key and its own per-app grant, hosted outside the bot's computer, so the standing jobs that should not share a browser session with everything else get moved off that computer entirely. Grok Bot routines stay the right tool for "ping me in this chat"; a worker is for "run unattended against my apps, with its own grant, and deliver to Slack."

Instinct: no documented path

Instinct publishes no API and no connector configuration, so WorkerKit does not publish an Instinct page and there is no documented procedure to point you at. What Instinct does describe, in its own terms, is connecting to services and taking actions on them on your behalf. WorkerKit, for its part, is built to be set up by the agent itself: the fleet API is plain HTTPS behind a single manager key, the MCP server is hosted, and the documentation is written for an agent to read.

So the practical route is to ask Instinct directly. Create a manager key in your WorkerKit account, hand it to Instinct, and ask it to connect to WorkerKit over the WorkerKit API, or through the WorkerKit MCP server if it can add one, following the same guide Muse uses. We have not tested this, and whether it works depends on what Instinct will do with a key you give it. If it does work, the key Instinct holds reaches the fleet only and grants no access to any connected app, which is a narrower thing to hand over than the account passwords its privacy policy contemplates.

And if the reason you are looking at Instinct is unattended work, that work does not need an agent holding your passwords in the first place. A triaged inbox, a watched calendar, or a Monday report is exactly what a kit does, with a per-worker grant and a per-run receipt.

At the time of writing, WorkerKit offers a free plan with no card required, and connecting Muse or Grok Bot is not a paid feature. The kit directory shows the jobs that already exist.

What to do about it

If you are choosing one for personal use, Muse has the most serious published security engineering of the three, and Meta wrote enough detail to be held to it. Weigh that against the absence of a stated retention period and the fact that disconnecting does not purge.

If you are running Grok Bot on a team, check the defaults rather than the feature list. Action Recording is off until someone turns it on, network policy is allow-all until someone sets one, and bots on an account share a computer and its signed-in sessions.

Whichever you pick, keep the standing jobs off the assistant's own identity. Muse and Grok Bot can both operate a fleet of scoped background workers through WorkerKit, holding a key that reaches the fleet and nothing else. That is the shape that shrinks the blast radius instead of growing it, and it has a second property this article has been arguing for: the workers, their grants, and their schedules stay put when you change assistants. The fleet outlives the choice of agent, in the same way the access decision should.

If you are looking at Instinct, read its terms before connecting anything that holds other people's data.

Underneath whichever you pick, the durable question is not which vendor you trust most. It is whether the decision about what an agent may reach gets made outside the agent, per request, and written down. That decision belongs to you, it should survive switching agents, and it should look the same whether your team runs one assistant or a fleet of narrow agents across different workflows.

That is the layer PortEden provides. See how it works, or start with the MCP servers for email, calendar, and drive.