AI Agents
Grok Bot Enterprise Adds Controls With Documented Gaps
xAI made Grok Bot available to enterprises on September 3 with access, network, and audit controls. Its same-day security FAQ says Bots for one user share a computer, blocked plugins can still be reached through websites unless network policy closes the route, action recording is off by default, Auto Review misses some side effects, and model-allowlist enforcement is not guaranteed.
Citation-ready: xAI launched Grok Bot for Enterprise on September 3, 2026, while its security FAQ states that model-allowlist enforcement is not guaranteed and that several controls are Enterprise-only or off by default.
What happened and why it matters
No. The controls add useful layers, while xAI's documentation preserves important exceptions that administrators need to test and contract around before persistent agents receive sensitive access.
Official xAI release and same-day security documentation
Primary reference: SpaceXAI: Grok Bot for Enterprise. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | September 3, 2026 |
|---|---|
| Checked by Kaleido Field | September 4, 2026, 10:05 CST |
| Source function | current persistent-agent analysis separating enterprise availability, per-user isolation, shared user computer, connector and website paths, network controls, Auto Review, action recording, model allowlists, residency, hosting, credentials, and outcome evidence |
The unit of isolation is the user computer
xAI says each user gets a dedicated Firecracker microVM, but every Bot that user runs shares that computer. A login or file available to the computer is therefore available to those Bots unless the organization separates the workload into another user and credential set.
Map person, team, Bot, computer, durable disk, connector, browser login, credential, model, network destination, and data class before granting access. Test a denied path through both plugins and the browser.
Review and recording need separate checks
Auto Review can allow, require approval, or deny several action types, but the FAQ says it misses some side effects and members retain an off switch. Action Recording is separate, Enterprise-only, and off by default; OpenTelemetry export is another path again.
A production gate should verify enforced settings, logs in the intended system, recording coverage, model selection, egress, credential expiry, deletion, disabled-user behavior, incident evidence, and a harmless end-to-end denial test.
Evidence boundary
Official launch facts: enterprise availability, stated access, network and audit controls, isolated per-user environments, and temporary free usage for named customers. Official documentation limitations: Bots under one user share a computer; plugin blocking does not block websites; network controls, audit logs, action recording, and team setup are Enterprise-only; action recording is off by default; Auto Review does not cover every side effect; model allowlist enforcement is not guaranteed; customer-hosted deployment is unavailable. Not established: independent isolation test, task reliability, every side effect, EDR coverage, residency commitment for a particular contract, incident response performance, or claimed customer savings and adoption scale.
FAQ
Are Bots isolated from one another?
Different users are isolated, but all Bots for one user share that user's computer.
Does blocking a plugin block its website?
No. The FAQ says a separate Enterprise network policy is needed to close the website route.
Is action recording enabled by default?
No. It is Enterprise-only and off by default.