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

Quick comparison

Checked against each vendor's published pages on September 9, 2026. All three products are moving quickly, so confirm against the primary source before acting on any single row.

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. 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

The feature that records what a bot did is Action Recording, and the default matters more than the feature. Cursor's security page describes it this way: "It is a setting on the Grok Bot page, off by default. When a team enables it, Cursor records Bot actions, including scrubbed shell commands, in an internal store with a 90 day retention."

Read that as three separate facts. Off by default, so most teams have no record at all. Scrubbed, so it is not a full account of what was read. And ninety days, so it will not cover an investigation that starts late.

To their credit, Grok Bot is the only one of the three with real team administration: SSO applies, network policy is configurable, and Action Recording exists at all.

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 has its record of bot actions off by default and scrubbed. The startup warns you its records may not be accurate.

None of the three produces the artifact an auditor asks for, which is a per-request record: this tool was called with these arguments, the request was allowed or denied, and this is what came back.

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, and we are not going to overclaim it. 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 documentation describes adding plugins rather than pasting a custom server URL. So we will not tell you PortEden drops into Grok Bot today. If you run bots on a team plan, the things to ask for are a custom MCP entry a bot can use, and a record of what the bot read that is not off by default.

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.

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.

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.