← Back to compare

Receipt vs Grok Bot: A Computer for Every Person, or Controls for the Organization

Receipt vs Grok Bot: A Computer for Every Person, or Controls for the Organization

Grok Bot draws its boundary around each member and the cloud computer their Bots share. Receipt draws it around the organization's workspaces, their connections and the record of what agents did through them.

When an employee leaves, IT can switch off their accounts in an afternoon. The harder part is the agents that employee was running. What could those agents touch, and does any of it stop when the account does?

Receipt vs Grok Bot is a useful comparison because the two products answer that question from opposite ends. Grok Bot, documented by xAI and run in Cursor's cloud, gives each member a persistent computer. Their Bots act as that member. Receipt, from Kentron, gives an organization workspaces whose connections, rules and records belong to the organization, not to any one person.

Both are serious designs for enterprise AI agents. This article compares where each one puts the boundary and walks one finance process through both.

What Is Grok Bot?

Grok Bot is a computer-use agent documented by xAI at docs.x.ai. It runs in Cursor's cloud, and members sign in with a Cursor account. Access comes with paid Cursor plans, and individual SuperGrok and X Premium+ subscribers can link those accounts instead.

The product centers on Bots: named, long-lived teammates with a role, memory, skills and routines. Each member gets one persistent cloud computer with a browser, terminal and filesystem, shared by all of that member's Bots. Work continues while the laptop is closed, and desktop and mobile apps handle chat, review and approvals.

Bots use connectors where they exist. These are MCP servers installed as plugins and governed by the team's Cursor connector policy. Elsewhere, Bots drive the browser and desktop directly. They can work in parallel and hand coding tasks to Cursor Cloud Agents. Team Bots let an owner publish one configured Bot to the whole team.

Grok Bot is generally available to individuals and self-serve Cursor Teams, where it is on by default. Enterprise access is rolling out, and that plan carries most of the security and audit controls.

What Is Receipt?

Receipt is Kentron's hosted agent product for organizations. An organization holds members, roles and billing. Inside it, workspaces hold connections to business apps from a catalog of about 60, plus the members allowed to use them.

People reach Receipt from web chat, Slack, Microsoft Teams and the receipt CLI. Coding agents such as Claude Code and Codex connect through a hosted MCP server. Substantive requests become durable background runs, executed in sandbox containers, that report back to the original thread.

Every connected-app tool call through Receipt's gateway is written to a SHA-256 hash-chained receipt before the provider is called. If that receipt cannot be written, the call is refused. Run state is rebuilt from those receipts. Admins can also require approval before each background run starts. Dollar budgets stop new background work once recorded spend reaches a limit.

Receipt does not offer SSO, SCIM, per-action approvals or an outbound network policy today. Its controls sit on connections and runs.

The Architectural Difference

Before an agent calls a tool, the system must settle one question: on whose authority? Grok Bot and Receipt settle it at different layers.

In Grok Bot, authority starts with the member. A Bot uses the member's connectors, browser sessions and stored secrets. Grok Bot's security page puts it plainly: "A Bot has no identity or credentials of its own." Team-managed connectors are the documented exception, since they may use service-account credentials. Team policy then narrows the member's reach. The connector policy allows or blocks MCP servers, while approval cards and Auto Review screen individual actions. All of a member's Bots share one computer, and each member's computer is a separate Firecracker microVM.

In Receipt, authority starts with the workspace. A run acts for the person who asked, but through connections the workspace owns. Receipt's integration server holds connection credentials and attaches them server-side for gateway calls. Owners and admins choose which operations each connection exposes, and writes stay off until enabled. On each call, the gateway re-checks membership and the allowlist, writes an intent receipt, and then calls the provider.

So policy attaches to different things. Grok Bot attaches it to the actor: this member, these Bots, these approval rules. Receipt attaches it to the resource: this connection, these operations, this workspace. A new teammate inherits the workspace's rules on day one. A departing one takes no connection with them.

Each choice has a cost. Grok Bot's reach is as wide as what each member can sign into. Receipt's governed reach stops at its connector catalog, and downstream systems see the connecting account, not the requester.

Receipt vs Grok Bot

The table compares where each product places identity, policy, execution and evidence.

DimensionReceiptGrok Bot
Unit of controlWorkspaces inside the organizationEach member and their cloud computer
Who the agent acts asThe requester, through workspace-owned connectionsThe signed-in member; Bots have no identity of their own
App credentialsHeld server-side for gateway calls; sandbox CLI helpers can fetch themConnector tokens on Cursor's backend; browser and CLI logins on the member's computer
Tool governanceOperation allowlists per connection; writes off until enabledConnector policy allows or blocks servers; MCP allowlist on Enterprise
Action-level controlOptional approval before a whole background runApproval cards and Auto Review per action; enforced team rules on Enterprise
ReachAbout 60 catalog apps, plus native CLIs such as aws in the sandboxConnectors, plus computer use in browsers and desktop apps
ExecutionFresh container per task, removed afterward; shared host kernelPersistent Firecracker microVM per member, shared by that member's Bots
Network egressNo outbound network policy on sandboxesEnterprise allowlist; allow-all without a policy
Record of actionsSHA-256 hash-chained receipts, written before each gateway callEnterprise Action Recording, off by default, exported via OpenTelemetry
When someone leavesRemoval blocks their runs at the next gateway callRemove from the team or via SCIM on Enterprise; revoke identity-provider sessions

A Real-World Example

A finance team runs month-end with an agent. It pulls invoices from the billing system, reconciles them against the CRM, and corrects mismatched records. Then one analyst leaves the company.

In Grok Bot, the analyst builds a Bot and a monthly routine on their persistent cloud computer. The Bot acts as the analyst, with whatever access the analyst has, minus servers the connector policy blocks. Plugin tokens stay on Cursor's backend. Where a tool has no plugin, the analyst signs the Bot's browser in and takes over for two-factor steps. Every Bot the analyst runs can use that session. An ask-first rule can hold each CRM correction for approval, and Auto Review screens other risky steps. On Enterprise, Action Recording and OpenTelemetry Export put each tool call, and the decision behind it, in the team's own collector.

In Receipt, the analyst asks from a Slack thread or web chat. The run acts for the analyst over the finance workspace's billing and CRM connections, whose credentials stay server-side for gateway calls. An admin enabled the CRM update operation; billing writes stay off. If the workspace requires run approval, the analyst or a workspace owner approves the whole run before it starts. Each task runs in a fresh container, and each gateway call is receipted before it reaches the provider. Investigators replay the run from those receipts.

When the analyst leaves, Grok Bot access follows the account. An admin removes the analyst from the team, or SCIM does it on Enterprise. Revoking the analyst in the identity provider ends their sessions on the computer. Routines run as their creator, so a colleague sets the job up again. In Receipt, an owner removes the analyst from the workspace, and their runs lose gateway access at the next call. The connections and receipts stay for next month. One caveat: the CRM's history shows the connecting account, so the analyst's name lives in the receipts.

Where Grok Bot Wins

Grok Bot reaches further. Computer use lets a Bot work in websites and desktop apps with no connector, which helps with niche finance and operations tools.

It gives each person a standing workspace that keeps working when the laptop is closed, with desktop and mobile apps.

Its isolation between users is hardware-level. The security FAQ is direct: "One user cannot reach another user's computer." Receipt's sandboxes are Docker containers on a shared host.

It controls individual actions. Approval cards and Auto Review can stop a single risky step, and Enterprise admins can enforce Auto-review with team-wide rules.

Its administration is deeper. Sign-in uses Cursor accounts with SAML SSO, and an Admin API manages settings. Enterprise adds SCIM, audit logs with SIEM streaming, Action Recording through OpenTelemetry and an egress allowlist. Anysphere, the company behind Cursor, holds ISO 27001 and 42001 certifications whose scope includes Grok Bot. Receipt has no SSO, SCIM, SIEM streaming, egress allowlist or certifications today.

A Bot never holds more access than its member, and its actions stay attributable to a named member. Coding work can also go to Cursor Cloud Agents.

Where Receipt Wins

Receipt wins where the work belongs to the organization rather than to one person.

Connections outlive the people who use them. They belong to a workspace, and owners and admins choose which operations each one exposes. Writes stay off until enabled, and an operation Receipt cannot classify counts as a write. Removing a member leaves the connections in place.

Access is re-checked on every call. The gateway confirms current membership and the current allowlist each time. A removal reaches runs already in progress at their next gateway call.

The record comes first. Each gateway tool call is written to a SHA-256 hash-chained receipt before the provider is called, and refused if that write fails. Run state is rebuilt from the receipts, so replay walks a run step by step without re-running anything.

One control surface serves several doors. Web chat, Slack, Teams, the CLI and coding agents over MCP use the same governed connections. Each background task runs in a fresh container, removed when it finishes.

The limits matter. Allowlists and receipts cover gateway calls, not shell commands in the sandbox. Receipts are unsigned and tamper-evident when verified.

Which Should You Choose?

Choose Grok Bot if your people need a capable assistant for their own work, especially across websites and desktop apps without connectors. It also suits teams already on Cursor that want per-action approvals now. Enterprise adds SCIM, audit streaming and egress rules.

Choose Receipt if several people and agents act in the same business systems. It fits when the organization should set AI agent permissions per connection and per operation. It also fits when connections must outlast any one employee, and you want a replayable, hash-chained record of gateway calls.

Use both when the work divides cleanly. Personal research and drafting can live in Grok Bot, while shared systems such as billing and the CRM are reached through Receipt.

Conclusion

The sharpest test of an agent design is the day someone leaves. In Grok Bot, the agent's reach leaves with the person, because it was always the person's reach. That is a clean property for personal work. In Receipt, the reach and the record stay with the workspace. That is the property a shared process needs. Each design fails in its own direction. A person-bounded process can leave with its owner, and a workspace-bounded one depends on getting the workspace rules right. AI agent governance starts with choosing which risk to own.

Grok Bot details are based on its official documentation and announcements as of October 7, 2026; Receipt details reflect the product as shipped on that date. Both change quickly, so check the sources below for current behavior.

Sources