Safety Is a Stack, Not a Switch

For Grok Build, the safety question is not simply whether a user clicked “allow.” It has two parts: whether the requested operation is authorized, and what the agent process can reach after that operation is authorized. This chapter separates those questions through Grok Build's permission evaluator and its OS-level sandbox. The result is a practical way to judge autonomy: identify which layer makes a decision, what that layer can actually enforce, and where platform or configuration limits remain.

That separation matters for ordinary development, not only hostile code. A developer may want a model to run tests and edit a repository automatically, but not to read credentials, use a broad shell escape, or write outside the intended workspace. Conversely, a restrictive profile can block a legitimate build if it cannot access a compiler cache or a required network path. Safety is therefore a design of boundaries and trade-offs, not a single setting with a “safe” label.

Permission decides whether a request may run

Grok Build's permission system merges rules from several places: native Grok configuration, managed or enterprise settings, project configuration, and Claude-compatible settings. Project-tier rules are gated by folder trust so that an unfamiliar checkout cannot silently supply its own approvals. The effective policy is evaluated by severity rather than by the order in which files happened to be loaded: a matching deny wins over ask, and ask wins over allow.

That precedence is the first reason a permission rule is more than a convenience prompt. An allow rule can make routine work easier, but it cannot override a deny rule from a stronger or simply more restrictive source. An ask rule can force confirmation for an operation that would otherwise be automatically accepted. A managed requirement can also pin always-approve off and remove untrusted catch-all grants. The system is designed so that adding a convenient local rule does not automatically defeat a higher-level restriction.

The evaluator also treats different operations as different access kinds. A file read, an edit, a grep search, a shell command, an MCP tool, a web fetch, and a message to a child agent do not all share one matcher. A Read rule can govern grep because grep reads file contents; otherwise a model could bypass a read restriction by switching tools. Path patterns are normalized before matching, and native file checks can follow a symlink to the target when evaluating deny or ask conditions. A rule that appears to protect one path is therefore not evaluated only against the spelling the model supplied.

Shell commands require more analysis because one input string can contain several operations. Grok Build splits chained commands and evaluates the segments rather than trusting only the first command. An allow for git can authorize git status && git diff, but it does not authorize an unrelated command after the chain. A deny or ask condition on one segment affects the whole request.