enterprise.md +35 −0
137 137
138Grok prints a URL and a short user code. Complete login on any device with a browser.138Grok prints a URL and a short user code. Complete login on any device with a browser.
139 139
140### Restricting login methods
141
142Two policies control how users authenticate. Set them in `requirements.toml` so a user `config.toml`, an environment variable, or a remote setting cannot override them.
143
144`disable_api_key_auth` forces interactive IdP login. The `xai.api_key` method is no longer offered or accepted, and at request time a first-party xAI API key is replaced with the IdP session token, so a leftover `XAI_API_KEY` or per-model key cannot skip SSO. Third-party (BYOK) endpoints keep working, since their `base_url` is not on `x.ai`; restrict those through your own provider IAM.
145
146```text
147[grok_com_config]
148disable_api_key_auth = true
149```
150
151`force_login_team_uuid` pins login to a team. The token's team principal must match the configured value, so a personal login or a login to the wrong team is rejected with an error and nothing is written to `auth.json`. You can set a single team UUID or a list, in which case any team in the list is allowed; an empty list rejects every login. Setting this also turns on `disable_api_key_auth`, because a bare API key does not carry team membership.
152
153```text
154[grok_com_config]
155force_login_team_uuid = "<your-team-uuid>"
156# Or allow several teams:
157# force_login_team_uuid = ["<team-a-uuid>", "<team-b-uuid>"]
158```
159
160The value is the team's UUID, which the access token carries as its login principal. Enforcement applies every time a session is issued or reused, including cached tokens and silent refreshes. A session that no longer complies is cleared, so the user has to log in again. Run `grok inspect` to check which login policy loaded.
161
162If you are migrating from Claude Code, `forceLoginMethod` maps to `disable_api_key_auth`, and `forceLoginOrgUUID` maps to `force_login_team_uuid`, which takes team UUIDs.
163
140## Security controls164## Security controls
141 165
142### Sandbox166### Sandbox
218 242
219Permissions control what the model is allowed to request. The sandbox controls what the process can do even if a command is approved. For untrusted code, combine `dontAsk` + narrow allow rules + `--sandbox strict`.243Permissions control what the model is allowed to request. The sandbox controls what the process can do even if a command is approved. For untrusted code, combine `dontAsk` + narrow allow rules + `--sandbox strict`.
220 244
245**Locking bypass-permissions mode**
246
247Set `disable_bypass_permissions_mode = true` under `[ui]` to turn always-approve (bypass-permissions) off across the deployment. This blocks every way to switch it back on: the `--yolo` and `--permission-mode bypassPermissions` flags, the in-session toggles (Ctrl+O, `/always-approve`, and the Shift+Tab mode cycle), client-supplied yolo settings, and catch-all `allow` rules such as `*` or `**`. Deny rules still apply, and behavior is unchanged when no lock is set.
248
249```text
250[ui]
251disable_bypass_permissions_mode = true
252```
253
254To resist tampering, the lock is honored only from root-owned sources (`/etc/grok/requirements.toml` or the system layer), not from the user-writable `~/.grok/requirements.toml`. Claude Code's `managed-settings.json` `disableBypassPermissionsMode: "disable"` is **not** applied to grok's always-approve — grok honors that file's permission rules, MCP allowlists, and marketplace restrictions, but a developer's `--yolo` / `[ui] permission_mode` / runtime toggle still take effect. This keeps grok from inheriting a host's Claude Code lockdown (e.g. shared clusters hardened by AppSec); to disable always-approve in grok, set `disable_bypass_permissions_mode = true` in grok's own `requirements.toml`.
255
221## Privacy & data lifecycle256## Privacy & data lifecycle
222 257
223### Data lifecycle258### Data lifecycle