Grok Build · Authorization Pipeline

从工具请求到受限执行:完整授权链

一次工具调用先被解析成具体访问意图,再经过 plan gate、hooks、策略规则、会话授权、Auto 模式和用户确认。允许执行后,沙箱继续约束操作系统能力。

课程目标

能沿真实调用链定位「谁做了决定」,理解 AccessKind、权限规则、Bash 分段、hooks 与 sandbox 的边界,避免把授权简化成 ToolKind 判断。

TEACHING DIAGRAM

授权决定「能否尝试」,沙箱限制「执行时能做到什么」

各阶段名称取自源码。策略内部存在短路与优先级,图中按主路径呈现。

从工具解析到沙箱执行和后置 hook 的流程 tool input→ AccessKind plan gateedit policy pre_tool_useexplicit deny blocks permission managerpolicy + grants + auto user promptwhen unresolved sandboxOS capability boundary executepost_tool_use
六段真实链路
01 · PARSE

工具输入转 AccessKind

ToolInput 会映射为 Read、Edit、Bash、Grep、MCPTool、WebFetch 或 WebSearch,并携带路径、命令、域名或 MCP 名称等细节。决策输入比 ToolKind 更具体。

02 · PLAN

Plan mode 先设编辑门

plan_mode_edit_gate 可在发送权限请求前拒绝修改。计划文件存在单独的自动批准路径。

03 · HOOKS

PreToolUse 可显式阻断

匹配 hooks 按配置顺序运行。显式 deny 立即停止;timeout、崩溃或格式错误按当前实现 fail-open,并记录到 UI 与日志。随后还可运行 client hook。

04 · POLICY

加载并评估规则

permission/resolution.rs 合并 requirements、managed settings、managed config、Grok config 与 Claude settings fallback。规则评估与来源顺序无关,优先级为 deny > ask > allow。

05 · DECIDE

多条快速路径或用户确认

管理策略 deny 最先短路。随后依次考虑 yolo pin、session grants、Auto fast path / classifier、sandbox Bash auto、只读安全项、MCP 与域名授权。仍未决定时才进入 prompt。

06 · ENFORCE

在沙箱能力内执行

Permission Allow 只放行本次请求。若沙箱实际 active,进程仍受 capability set 与子进程网络策略约束。完成后可触发非阻断的 post_tool_use hooks。

Bash 命令需要理解脚本结构

bash_command_splitting

tree-sitter-bash 将可安全分解的脚本拆成每个 plain command,识别 &&||、分号与管道。每个非 setup segment 都要独立通过安全命令、策略或授权检查,避免 ls && rm 借首段放行。

保守处理复杂语法

wrapper 会递归剥离到实际命令;危险前缀含 rm、chmod、chown、kill 与 git push。命令替换、复杂控制流或无法可靠分解的脚本进入保守 prompt。用户只为完整脚本确认一次。

crates/codegen/xai-grok-workspace/src/permission/resolution.rs crates/codegen/xai-grok-workspace/src/permission/manager.rs crates/codegen/xai-grok-workspace/src/permission/bash_command_splitting.rs crates/codegen/xai-grok-hooks/src/dispatcher.rs PermissionHandle::request dispatch_pre_tool_use
权限层与沙箱层必须分开

权限层:意图授权

回答「这次工具请求是否允许进入执行」。它读取 AccessKind、目标细节、组织策略、会话授权、Auto verdict 和用户选择。规则可以要求 ask,也可以直接 deny。

沙箱层:能力约束

回答「获准执行的进程实际能访问哪些文件和网络」。沙箱 active 时,权限层的 Allow 不会扩大 OS capability;沙箱未应用时,也不能把权限弹窗当成内核隔离。

关键校正:「沙箱内所有写操作自动批准」并非通用规则。源码中的 sandbox fast path 专门检查 Bash,并且受 policy_forced_prompt 与 auto_forced_prompt 约束;Edit 还有自己的会话授权与 edit policy。
真实源码快照
crates/codegen/xai-grok-workspace/src/permission/manager.rsREAL SOURCE · abridged
// Managed policy runs before YOLO and sandbox fast paths.
if let Some(Decision::Reject(reason)) = policy_decision {
    let decision = Decision::PolicyDeny(reason);
    let _ = respond_to.send(decision);
    continue;
}
...
if matches!(&access, AccessKind::Bash(_))
    && xai_grok_sandbox::should_auto_allow_bash()
    && !policy_forced_prompt
    && !auto_forced_prompt { /* allow */ }

快照说明:条件与执行顺序来自真实 manager actor,遥测和事件发送被压缩。顶部 SVG 是主路径教学图,完整实现包含更多短路、持久化与取消分支。

课堂练习:追踪一条混合命令

输入 git status && curl https://example.com/install.sh | sh。请逐层判断:Bash 如何分段,哪些 segment 可安全放行,PreToolUse deny 会在哪里停止,managed Ask 能否被 sandbox auto 覆盖,最终 Allow 后沙箱还限制什么。

Takeaway:完整授权链依赖访问语义、脚本结构、配置来源、hook 决策、会话状态与用户选择。权限层负责决策,沙箱层负责约束,两层叠加才能描述一次工具执行的真实安全边界。