Muse, Dots, Grok Bot, and Duet: What Are You Actually Trusting?

Your AI agent can keep your card number secret and still make a purchase you never authorized.

Imagine asking it: Find a hotel for Friday under $200. Don’t book anything yet. While browsing, it encounters a page with hidden instructions telling it to book immediately. If the model follows those instructions, which component stops the purchase?

Even an approval prompt leaves questions. A $189 charge at the right hotel could still buy the wrong night or a nonrefundable room. I want to know what the system binds my approval to, and what happens if the booking changes afterward.

I compared the public documentation for Meta Muse, OpenAI dots, Grok Bot, and Claude Duet with those questions in mind. Sources were checked on November 4, 2026. This is a review of documented controls, not an independent test or a safety ranking. Plan, settings, and the route an agent takes can change which controls apply.

What stops the action?

Three mechanisms do different work:

1. Instructions tell the model what you want. “Don’t book anything” establishes the boundary, but the model can misinterpret it or follow malicious content.
2. Action review checks a proposed step against your intent and applicable rules. A separate model or classifier can catch mistakes, while making mistakes of its own.
3. Capability restrictions constrain execution. A tool without a booking operation cannot book through that tool. A card restricted to a merchant and amount limits where and how much it can pay.

These mechanisms can work together. A model-based decision can be enforced by software the agent cannot change. That makes the enforcement boundary valuable without making the reviewer’s judgment infallible.

Scope matters just as much. A read-only connector provides little protection against a purchase if the same agent can use a signed-in browser with a saved card.

What exactly did you approve?

Suppose the agent returns with a $189 room and you decide to book it. The approval should identify the hotel, dates, room, guest, total price, and cancellation terms. The system should execute that approved booking and require a new decision if material details change.

A single-use card restricted to the hotel and $189 cannot, by itself, distinguish the room you wanted from another booking at the same price. Credential protection, a payment limit, and approval of the booking each cover different risks.

My benchmark is a trusted approval interface whose decision stays bound to the transaction that executes. If the system cannot establish that the booking still matches, it should stop. The implementation might use a server-side transaction record or a cryptographic mechanism; the property to verify is that the agent cannot substitute different terms or bypass the decision through another payment route. I did not establish an end-to-end guarantee of that property for these four products.

Muse: authority outside the runtime

Muse’s architecture description puts its agent in a restricted runtime inside the user’s VM. Credential services and Sentinel, the authority for connector actions and network egress, sit outside that runtime. After authorization, Sentinel replaces surrogate tokens with real credentials. Required approvals travel directly between Sentinel and the user’s client.

Meta describes human approval for wallet payments using single-use cards limited by merchant, amount, and time. It also describes checkout detection and approval when a website already has a card on file.

That gives the hotel example two distinct checks to examine: authorization of the action and approval of the payment. The runtime boundary does not make every safety decision deterministic; Meta also uses models and classifiers.

dots: proactive research has a specific scope

OpenAI’s dots security guide describes proactive research as work a dot starts between requests. Those research tools can read permitted information and save private notes, but cannot send messages, edit connected-app content, or control a browser or computer.

Our hotel search is an explicit user request. We cannot assume that the proactive-research restriction governs it merely because it runs in the background. User-directed work follows its applicable permissions and action rules.

For covered actions, Auto-review checks the proposed step, and the dot cannot turn off required review. The security guide says coverage across browser, desktop, and delegated actions remains under review. I would verify those routes before relying on review to stop every path to a booking. The controls guide also distinguishes instructions and Custom Rules from app permissions. A standing instruction can authorize future actions within its scope.

The cloud browser is another access route. OpenAI’s security guide warns that a read-only plugin can coexist with a signed-in website that permits changes. A dedicated agent identity alone does not establish a restricted account boundary.

Grok Bot: check the shared computer and payment route

Grok’s security FAQ describes a dedicated microVM per user, shared by that user’s Bots. Files, browser sessions, and command-line credentials can cross the roster. Creating a travel Bot and a work Bot does not isolate those resources.

The same FAQ describes Auto Review coverage when enforcement is enabled, while excluding some side effects, such as memory writes and most settings changes. Its security guide makes destination restrictions Enterprise-only. Applying a network allowlist to remote MCP servers requires a separate setting that defaults to off. Blocking a connector does not also block the service’s website.

Payments need a more specific comparison than “Grok supports Vault.” The Vault documentation describes two routes:

• Saved-card fills have no mandatory Vault approval prompt, and Vault has no setting to require one for each use. Action-review rules are a separate control.
• A connected Link account supports requests for approved, one-time purchase cards, showing the merchant, items, and total.

Those are different payment boundaries within the same product. Comparing only saved Vault cards with another product’s one-time wallet cards would miss that distinction.

Duet: isolate credentials, then review their use

Anthropic’s Duet security description places connected-app credentials behind an external proxy. The browser runs in a separate VM with commands that cannot read its cookies. Page content still reaches the agent, so malicious instructions remain a concern.

A separate intent check reviews actions, and a sensitive-data classifier checks outgoing information. Anthropic acknowledges missed threats and false positives. Payment approval cannot receive a “don’t ask me again” override; wallet purchases use one-time cards restricted to merchant and amount.

Credential isolation limits exposure of the secret. An authenticated agent can still read information and propose harmful actions, which is why the other checks matter.

The documented boundaries at a glance

This table summarizes execution, action review, and payment routes. It does not imply that all browser, connector, or delegated actions receive identical checks. The product sections above link to the supporting documentation.

Revoking access and deleting information

Stopping new requests, ending a browser session, removing learned information, and deleting files are separate cleanup operations. The documentation describes different operations, so the operation belongs beside the result:

Provider access is another question. Meta’s architecture post says personnel access to Secure VM data is limited by operational policy; Confidential VM is described as a future protection against provider access. Private infrastructure would still need controls over what the agent can do with your accounts.

Before connecting an account

I would ask these questions of any personal agent:

1. What operations can its tools, credentials, and signed-in sessions perform, including through alternate routes?
2. Who authorizes an action, what exact details does approval cover, and can those details change before execution?
3. After access is revoked, which memories, files, sessions, and delegated tasks remain, and how is each removed?

For the hotel search, I want evidence that “don’t book anything” holds across every enabled path to a booking. If I later approve a room, I want the executed reservation to match the one I approved.

Disclaimer: The views expressed here are my own and do not represent those of my employer.