Grok Build’s Enterprise Docs Say the Quiet Part Out Loud: Coding Agents Are Endpoint Software Now

Grok Build’s refreshed enterprise documentation is not the sort of launch that wins a hype cycle. Good. It is more important than that.

The page reads like xAI has accepted the thing every serious engineering org eventually learns about coding agents: once an agent can read a repo, run shell commands, call MCP tools, edit files, and hold authentication state, it is not merely a smarter autocomplete. It is endpoint software with a probabilistic operator attached. That means rollout policy, sandbox boundaries, credential precedence, audit behavior, and network egress matter at least as much as whether the model can one-shot a React component.

The refreshed docs, manually dated through the docs.x.ai sitemap at June 21, 2026 23:18 UTC, lay out the deployment surface in unusually concrete terms. Core Grok Build traffic requires cli-chat-proxy.grok.com for inference proxy and settings plus auth.x.ai for OAuth2/OIDC authentication. Enterprise identity requires the customer’s IdP domain, such as login.microsoftonline.com. Optional paths include api.x.ai for direct API-key use, code.grok.com for remote session sync and WebSocket relay, assets.grok.com for profile/UI assets, and installer/update hosts such as x.ai and storage.googleapis.com.

That host list is boring in exactly the right way. Security reviews do not fail because a demo looked insufficiently magical. They fail because nobody can answer which domains a binary needs, whether TLS inspection works, whether proxy idle timeouts break streaming, and whether a leftover API key can quietly bypass SSO. xAI’s docs now answer much of that: Grok Build uses TLS 1.2 or TLS 1.3 via rustls, does not expose an option to disable TLS, honors HTTPS_PROXY, HTTP_PROXY, and NO_PROXY, and uses SSE streaming with a default per-chunk idle timeout of 600 seconds. If your proxy kills idle connections after two minutes, your “model quality problem” may actually be a network appliance problem wearing a fake mustache.

The policy file is the product

The strongest signal in the docs is the managed configuration model. Grok loads configuration from five layers: /etc/grok/managed_config.toml, ~/.grok/managed_config.toml, ~/.grok/config.toml, ~/.grok/requirements.toml, and highest-priority /etc/grok/requirements.toml. The requirements file is explicitly described as a fail-closed pin mechanism. Values there cannot be overridden by user config, environment variables, remote settings, or lower-priority layers.

That is the enterprise feature hiding in plain sight. Not “the model writes better code.” Not “the agent has a nicer TUI.” The feature is that a security team can pin behavior at the system layer and expect the tool not to negotiate with a developer’s dotfiles. xAI recommends /etc/grok/requirements.toml for MDM, golden images, AMIs, onboarding scripts, and compliance-critical policies: disable telemetry, enforce sandbox profiles, restrict tools, pin feature flags, and turn off bypass modes.

This matters because coding agents create a new flavor of shadow infrastructure. A developer installs one binary, points it at a repo, gives it an auth path, and suddenly the tool has access to source code, secrets accidentally present in files, local cloud credentials, internal docs, package scripts, and whatever MCP servers happen to be configured. If rollout policy lives in “please don’t do that” guidance, it will lose to deadlines. Root-owned configuration is not glamorous, but it is how organizations make intent survive contact with humans.

xAI also reads a subset of Claude Code’s managed-settings.json for mixed environments, including permission rules, MCP server allowlists, selected telemetry/feedback flags, and marketplace restrictions. That compatibility is strategically smart. Most serious teams will not standardize on one coding agent overnight; they will evaluate Grok Build, Claude Code, Codex, Cursor, Qwen, and whatever arrives next quarter. Letting Grok understand part of an existing Claude policy lowers friction. Giving Grok’s own root-owned requirements.toml precedence is the equally important half. Similar policy vocabulary is useful; pretending different agents have identical enforcement semantics is how migration projects become incident reports.

Sandboxing and permissions are not the same control

The docs separate sandbox profiles from permission rules, which is the right mental model. Permissions decide what the agent may ask to do. Sandboxing limits what the process can do even when something gets approved or when a policy fails open.

Grok Build’s documented sandbox profiles include off, workspace, devbox, read-only, and strict. In strict, filesystem reads are limited to the current working directory and system paths, writes are restricted to the current working directory, /tmp, and ~/.grok/, and child-process network access is blocked. Always write-protected directories include ~/.ssh, ~/.gnupg, ~/.grok/auth, ~/.aws, ~/.config/gcloud, and ~/.azure.

That is the right default direction. A coding agent does not need casual write access to SSH keys or cloud credential stores. It also should not be able to turn every package script into an exfiltration path without the environment noticing. xAI says child network blocking in read-only and strict uses a Linux seccomp BPF filter. The caveat is material: macOS child-network blocking is not currently enforced. Many developer fleets are Mac-heavy, so teams should not read “strict” and assume identical guarantees across local laptops, Linux CI, and cloud devboxes.

Permission modes add another layer. dontAsk silently denies anything without explicit allow rules. acceptEdits auto-approves file edits but still prompts for shell commands. Policy checks run in order: PreToolUse hooks, policy rules where deny beats ask beats allow, built-in fast paths, then prompt policy. The always-safe list includes read-only operations such as reading files, listing directories, grep, web search, todo writes, and selected commands like git status, git diff, cargo check, and kubectl get/logs/describe. Dangerous commands including rm, chmod, chown, chgrp, chattr, kill, pkill, killall, and git push always prompt in ask mode even if whitelisted.

The subtle point: “read-only” is not synonymous with “safe.” kubectl logs can expose secrets. git diff can contain credentials someone accidentally pasted into a config file. Repo files can contain proprietary data, customer samples, or prompts designed to manipulate the agent. Prompt injection is not only a web-browsing problem. It is any untrusted text inside the agent’s context asking for authority it should not have.

SSO that API keys cannot bypass

The authentication section is another place where xAI seems to understand the actual enterprise failure mode. Grok supports browser OIDC via grok login, device-code login via grok login --device-auth, external token providers through auth_provider_command, and API-key auth through XAI_API_KEY or model config. Credential precedence is documented as model.api_key over model.env_key over active session token over XAI_API_KEY.

That precedence list is useful, but the control is better: disable_api_key_auth = true forces interactive IdP login for first-party xAI paths and prevents stale API keys from bypassing SSO. force_login_team_uuid pins login to one or more team UUIDs; setting it also disables API-key auth because bare API keys do not carry team membership.

This is not bureaucracy. This is how you stop “we use SSO” from becoming a poster on the wall while production usage actually runs through copied keys in shell profiles, CI variables, and forgotten onboarding docs. Developers will use the fastest path that works. If the fastest path violates policy, the binary needs to refuse it.

For teams evaluating Grok Build, the immediate action is not another model bake-off. Start with the policy file. Decide whether API-key auth is allowed. Pin team login if you need it. Pick sandbox profiles by environment. Disable bypass/always-approve modes from root-owned configuration if your risk model requires it. Define MCP allowlists. Test on Linux and macOS separately. Run an adversarial repo with fake secrets and prompt-injection strings before pointing the agent at crown-jewel code.

The competitive story here is bigger than Grok. Coding-agent comparison is moving beyond benchmarks. SWE-bench scores and demo videos still matter, but the next serious axis is operational control: identity, sandboxing, permission precedence, data retention, auditability, and policy portability. xAI’s enterprise docs suggest Grok Build wants to compete there. That is a healthier race than another leaderboard screenshot.

LGTM’s take: the maturation moment for coding agents will look boring. It will be root-owned config, fail-closed policy, blocked child networking, SSO that keys cannot bypass, and a security team saying “fine, pilot it.” If Grok Build becomes enterprise-relevant, it will be because of controls like these as much as any model improvement.

Sources: xAI Grok Build Enterprise docs, xAI Grok Build overview, xAI modes and commands docs, xAI headless scripting docs, xAI pricing