本页介绍在 Enterprise 环境中部署 Grok Build 所需的全部内容，包括 network requirements、配置管理、身份验证选项、安全控制和 data lifecycle。

Network requirements

所有连接均使用 HTTPS（port 443）。

必需

核心功能需要以下 hosts：

Host	用途
`cli-chat-proxy.grok.com`	Inference proxy、settings
`auth.x.ai`	OAuth2/OIDC 身份验证

使用 Enterprise OIDC 时，还需允许 IdP domain（例如 login.microsoftonline.com）。

其他

以下 hosts 支持附加功能，可以阻止而不影响核心身份验证和 inference：

Host	用途	被阻止时的影响
`api.x.ai`	xAI API（直接 API-key path）	仅在使用 `api_key` auth 而不是 inference proxy 时需要
`code.grok.com`	Remote session sync、sharing、WebSocket relay	Sessions 仅保存在本地；share links 不可用
`assets.grok.com`	Profile images、UI assets	用户头像无法加载；不影响功能
`x.ai`	通过 `curl \| bash` 安装脚本下载 CLI binary	可改用不需要此 host 的 `npm install -g @xai-official/grok`
`storage.googleapis.com`	CLI binary fallback CDN	仅在无法访问 `x.ai` 时、使用 `curl \| bash` 安装期间需要

x.ai 和 storage.googleapis.com hosts 仅用于 shell-script installer 和应用内 grok update。如果环境使用 npm 分发（npm install -g @xai-official/grok），则不需要这两个 hosts。

TLS

所有连接均使用 TLS 1.2 或 TLS 1.3，由 rustls 强制执行（不依赖 OpenSSL）。Root certificates 从 OS trust store 加载。无法禁用 TLS。对于检查 TLS 的 proxy，请将 proxy CA certificate 安装到 OS trust store。

CLI 遵循标准 proxy 环境变量（HTTPS_PROXY、HTTP_PROXY、NO_PROXY）。HTTP connection pool 默认保持 idle connection 90 秒（GROK_POOL_IDLE_TIMEOUT_SECS），inference request 使用 SSE streaming，每个 chunk 的 idle timeout 默认为 600 秒。将 proxy idle timeout 设置为至少 10 分钟，避免模型长响应期间过早断开。

配置

Grok 从五层加载配置，按优先级从低到高排列：

优先级	来源	用途
1（最低）	`/etc/grok/managed_config.toml`	System-wide managed config
2	`~/.grok/managed_config.toml`	Per-user managed config
3	`~/.grok/config.toml`	用户 preferences
4	`~/.grok/requirements.toml`	User-level pinned settings
5（最高）	`/etc/grok/requirements.toml`	System-level pinned settings

requirements.toml 中的设置无法被较低层、remote settings 或用户配置覆盖，请将其用于 compliance-critical policies。所有层都支持用于版本条件 patch 的 [[version_overrides]] 和 $VAR 展开。

MDM 与 managed 部署的 System-level policy

优先级最高的配置层是 /etc/grok/requirements.toml。这是通过 Mobile Device Management（MDM）、golden images、配置管理工具或 onboarding scripts 大规模管理 Grok 的组织所推荐的机制。

常见部署模式：

MDM / endpoint management — 将 TOML 文件直接推送到 managed workstation 的 /etc/grok/。
Golden images / AMIs — 将 policy 文件内置到开发者 laptop 或 CI runner 使用的 base image 中。

固定在 requirements.toml 中的值使用 fail-closed “pin”机制：用户 config.toml、环境变量、remote settings 或低优先级层都无法覆盖。这使 /etc/grok/requirements.toml 成为 compliance-critical policy 的权威来源，例如禁用 telemetry、强制 sandbox profile、限制工具或固定特定 feature flags。

Claude Code 兼容性（可选）

已经使用 Claude Code 并通过 MDM 部署 managed-settings.json 文件的组织可以继续依赖该文件。为兼容性，Grok 会读取其中一部分 policy（permission rules、MCP server allowlists、少数 telemetry/feedback flags 和 marketplace restrictions）。

Grok 自己的 /etc/grok/requirements.toml 始终优先于 Claude managed-settings.json 文件。Claude compatibility layer 仅与混合 Claude + Grok 环境相关；纯 Grok 部署应使用 requirements.toml + config.toml。

身份验证

Grok Build 支持四种 session 身份验证方式：

方法	触发方式	可刷新	最适合
Browser OIDC	`grok login`（默认）	是	带浏览器的交互式 terminal
Device code	`grok login --device-auth`	是	SSH sessions、containers、headless hosts
External auth provider	Config 中的 `auth_provider_command`	是	Corporate IdPs、自定义 token broker
API key	`XAI_API_KEY` env var 或 config 中的 `model.api_key`	否	Scripts、CI/CD、headless automation

有多个 credentials 可用时，Grok 按 model 解析：model.api_key > model.env_key > active session token > XAI_API_KEY。

Enterprise OIDC

拥有 corporate identity provider（Entra ID、Okta、Auth0 等）的组织可以配置 Grok 直接对其进行身份验证：

[auth.oidc]
issuer = "https://login.yourcompany.com"
client_id = "your-client-id"

也可以通过环境变量 GROK_OIDC_ISSUER 和 GROK_OIDC_CLIENT_ID 配置。该流程使用 PKCE，并支持 refresh_token grant 自动续期。

External auth provider

将 Grok 指向一个在 stdout 输出 token 的 executable：

[auth]
auth_provider_command = "/usr/local/bin/your-auth-provider"

该命令必须输出纯 token string 或 JSON：{"access_token": "...", "refresh_token": "...", "expires_in": 3600}（refresh_token 和 expires_in 可选）。

Grok 在两种契约下运行该命令，并设置 GROK_AUTH_EXPIRED 区分。对于 Grok 已持有 credential 的后台刷新，它为 1：没有用户在观察，命令只会运行几秒便被 Grok 终止，因此应静默签发或以 non-zero 退出，绝不能等待输入。在登录时该变量未设置，此时有用户参与，command stderr 会显示给用户，最多有 300 秒完成 browser round trip 或 device code。GROK_AUTH_EXPIRED=1 时及时退出而不提示输入的命令，可以让交接到登录界面更快速。

API key

对于 CI/CD 和 headless automation，请设置 XAI_API_KEY 环境变量，无需配置文件：

export XAI_API_KEY="xai-..."
grok -p "Review this diff" --output-format json --always-approve

在长期使用的开发工作站上，也可以在 ~/.grok/config.toml 中将 key 绑定到特定 model：

[model.grok-build]
api_key = "xai-..."

[models]
default = "grok-build"

Output formats 和 CLI flags 请参阅 Headless 与脚本。

Device code

对于没有浏览器的环境（SSH、containers、cloud devboxes），device code login 遵循 RFC 8628：

grok login --device-auth

Grok 会输出 URL 和短 user code。可以在任意带浏览器的设备上完成登录。

有两项 policy 控制用户如何进行身份验证。请在 requirements.toml 中设置它们，以免用户 config.toml、环境变量或 remote setting 覆盖。

disable_api_key_auth 强制交互式 IdP login。xai.api_key method 将不再提供或接受；请求时，第一方 xAI API key 会被 IdP session token 替换，因此遗留的 XAI_API_KEY 或 per-model key 无法绕过 SSO。第三方（BYOK）endpoint 仍可用，因为其 base_url 不在 x.ai 上；请通过自己的 provider IAM 限制它们。

[grok_com_config]
disable_api_key_auth = true

force_login_team_uuid 将登录固定到一个 team。Token 的 team principal 必须匹配配置值，因此个人登录或登录到错误 team 会被拒绝并报错，且不会写入 auth.json。可以设置一个 team UUID 或 list；使用 list 时，列表中的任一 team 均允许；空列表会拒绝所有登录。设置此项还会启用 disable_api_key_auth，因为纯 API key 不携带 team membership。

[grok_com_config]
force_login_team_uuid = "<your-team-uuid>"
# Or allow several teams:
# force_login_team_uuid = ["<team-a-uuid>", "<team-b-uuid>"]

该值是 team UUID，access token 将其作为 login principal。每次 session 签发或复用（包括 cached tokens 和 silent refresh）都会执行检查。不再符合要求的 session 会被清除，用户必须重新登录。运行 grok inspect 检查加载了哪项 login policy。

如果从 Claude Code 迁移，forceLoginMethod 映射到 disable_api_key_auth，forceLoginOrgUUID 映射到接受 team UUID 的 force_login_team_uuid。

安全控制

日常权限（modes、allow/deny rules）和 sandbox profiles 适用于个人机器和 managed 部署。本 section 介绍 Enterprise-only policy：pinning、headless modes 以及锁定关闭 always-approve。

Sandbox

Profiles、custom sandbox.toml 及 sandbox 与权限的关系，请参阅 Sandbox。在 requirements.toml 中固定 profile：

[sandbox]
profile = "workspace"

权限

Ask、auto 和 always-approve，以及 CLI --allow / --deny 与 config rules，请参阅权限。对于 CI 和 headless runs，还需关注两种附加模式：

模式	行为	典型用途
`dontAsk`	静默拒绝没有显式 allow rule 的所有操作	Headless、CI
`acceptEdits`	自动批准 file edits；shell command 仍提示	Semi-automated workflows

Headless run 示例：

grok -p "Review the API changes" \
  --permission-mode dontAsk \
  --allow 'Bash(git *)' \
  --allow 'Bash(gh *)' \
  --allow 'Read' \
  --allow 'Grep' \
  --deny 'Bash(rm -rf *)' \
  --sandbox strict

锁定 bypass-permissions 模式

设置 disable_bypass_permissions_mode = true（位于 [ui] 下），可在整个部署中关闭 always-approve（bypass-permissions）。这会阻止所有重新开启方式：--yolo 和 --permission-mode bypassPermissions flags、session 内 toggles（Ctrl+O、/always-approve 和 Shift+Tab mode cycle）、客户端提供的 yolo settings，以及 catch-all allow rules（例如 * 或 **）。Deny rules 仍生效；未设置 lock 时行为不变。

[ui]
disable_bypass_permissions_mode = true

为了抵御篡改，lock 仅接受 root-owned 来源（/etc/grok/requirements.toml 或 system layer），不接受用户可写的 ~/.grok/requirements.toml。Claude Code managed-settings.json 中的 disableBypassPermissionsMode: "disable" 不会应用于 Grok always-approve；Grok 会遵循该文件的 permission rules、MCP allowlists 和 marketplace restrictions，但开发者的 --yolo / [ui] permission_mode / runtime toggle 仍生效。这避免 Grok 继承 host 上的 Claude Code lockdown（例如 AppSec 加固的共享 cluster）；要在 Grok 中禁用 always-approve，请设置 disable_bypass_permissions_mode = true，该设置应位于 Grok 自己的 requirements.toml 中。

Privacy 与 data lifecycle

Data lifecycle

Session 中的数据会经历六个阶段：

用户输入 — Prompt 和 file content 在本地组装。
传输 — 通过 TLS 1.2/1.3 发送到 inference proxy。
Inference — Proxy 转发给模型。ZDR 组织通过跳过 logging 的专用 service identity 路由。
工具执行 — 在用户本地 sandbox 环境中发生。
响应 — 通过同一 TLS connection streaming 返回。
Session 结束 — 对于 ZDR 组织，inference layer 不会保留 prompts、code 或 responses。本地 session history 存储在 ~/.grok/。

Zero Data Retention

ZDR 在 team level 执行。为 team 或 Enterprise 启用后，使用 Grok Build 时会执行 zero data retention。

Enterprise 部署