/ THE SHORT ANSWER
The product documents meaningful isolation, network, approval and audit controls, but several are Enterprise-only and some boundaries are per user rather than per Bot. Buyers need a control-by-control test tied to their own identities, destinations and high-impact actions.
- 01SpaceXAI says each user receives a dedicated Firecracker microVM, while every Bot run by that user shares the same computer.
- 02Network Controls, Action Recording and several organisation-wide controls are documented as Enterprise-only.
- 03Auto Review can allow, stop or deny actions, but documentation says it does not inspect every side effect.
- 04NIST identifies agent identity, least privilege, delegation, auditability and prompt-injection mitigation as core enterprise questions.
/ dotSuper point of view
A persistent agent should be governed as an active software identity with delegated authority, not licensed as if it were only a productivity application.
What the enterprise release adds
SpaceXAI announced Grok Bot for Enterprise on 3 September. The release describes access, network and audit controls intended to let organisations govern Bots that work autonomously inside the same applications and websites used by employees.
The architecture documentation says each user works in a dedicated Firecracker microVM with hardware-level isolation from other users. A Bot starts with no access and uses only accounts and connectors granted by the member or team. Sensitive steps can be routed through approval gates and an independent review model called Auto Review.
The controls are not uniform across plans. SpaceXAI documents Network Controls, Team Setup, Action Recording, computer management and the organisation-wide enable switch as Enterprise features. Self-serve Teams without a network policy default to allow-all destinations, which is a material procurement distinction.
- Per-user isolation is documented, but Bots within one user share the same computer.
- Connector policy and browser network policy are separate control layers.
- Enterprise audit logs cover admin, security and authentication events.
- Action Recording is a separate Enterprise setting and is off by default.
The six controls buyers should test
Identity comes first. Every action needs a traceable human or service principal, a defined delegation path and a revocation mechanism. NIST has highlighted identification, authentication, authorisation, delegated authority and non-repudiation as open design requirements for enterprise agents.
Permission scope is next. Blocking a connector does not necessarily block the same service in a browser. Buyers should test both structured integrations and browser destinations, then verify that the least-privileged account is used downstream. A model-level approval is not a substitute for permissions enforced by the source system.
Observability must cover business actions, not only sign-ins and configuration changes. A useful audit record should answer what the Bot attempted, which evidence informed it, which account acted, what changed, who approved it and whether the outcome was accepted or reversed.
- Identity: bind every Bot action to an authorised user or service identity.
- Egress: allowlist necessary destinations and test browser paths separately from connectors.
- Approval: stop publishing, purchasing, deletion, permission changes and production actions.
- Evidence: preserve source links, proposed parameters and resulting system state.
A practical enterprise rollout gate
Build a capability and control matrix before enabling the product. Map each proposed job to required systems, data classes, actions, destinations, identity, approval mode, logging source, retention rule and incident owner. Confirm which controls exist on the purchased plan rather than relying on a general security statement.
Run adversarial tests using realistic untrusted inputs. Include prompt injection in documents and websites, conflicting instructions, stale credentials, excessive data aggregation, an attempted prohibited destination and repeated execution after a timeout. Record whether the Bot stopped at the expected boundary.
Begin with a small user group and read-only work. Stream available logs to the security workflow, review action records, and establish a kill path for routines, sessions and credentials. Expansion should require evidence that controls work during failure, not only during a successful demonstration.
- Separate high-risk jobs with separate users or scoped service identities.
- Keep local-computer execution disabled unless a workflow clearly requires it.
- Revoke source-system tokens when access is no longer needed.
- Re-test after product updates, connector changes and website redesigns.
What this page cannot conclude
- 01This analysis relies on current public documentation and does not replace contractual, architectural or penetration-test evidence.
- 02Some documented controls are limited to Enterprise customers and may not exist in self-serve Teams.
- 03Auto Review is model-based and the documentation states it does not review every side effect.
- 04Security outcomes also depend on customer identity, source-system permissions, user settings and operational monitoring.
Sources
- 01Grok Bot for EnterpriseSpaceXAI · accessed Sep 9, 2026
- 02Grok Bot for teams and enterprisesSpaceXAI Docs · accessed Sep 9, 2026
- 03Grok Bot security FAQSpaceXAI Docs · accessed Sep 9, 2026
- 04New Concept Paper on Identity and Authority of Software AgentsNIST · accessed Sep 9, 2026
- 05LLM06:2025 Excessive AgencyOWASP Gen AI Security Project · accessed Sep 9, 2026
Our editorial standard · Found an error? Send a correction with its source.
/ CITE OR SHARE THIS GUIDE
Make the evidence easy to verify.
When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.
dotSuper Research Desk. (September 9, 2026). Grok Bot is available for enterprises. Governance must reach every action.. dotSuper. https://dotsuper.net/feeds/daily-briefing/2026-09-09-grok-bot-enterprise-governance