Grok Build · Authorization Pipeline

도구 요청에서 제한된 실행까지: 완전한 인가 체인

하나의 도구 호출은 먼저 구체적인 접근 의도로 파싱된 후, plan gate, hooks, 정책 규칙, 세션 인가, Auto 모드, 사용자 확인 단계를 거칩니다. 실행이 허가된 후에도 샌드박스가 OS 수준 기능을 계속 제한합니다.

학습 목표

실제 호출 체인을 따라 「누가 결정을 내렸는지」를 찾아내고, 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
6단계 실제 파이프라인
01 · PARSE

도구 입력 → AccessKind

ToolInput은 Read, Edit, Bash, Grep, MCPTool, WebFetch 또는 WebSearch로 매핑되며, 경로, 명령, 도메인, MCP 이름 등의 세부 정보를 포함합니다. 결정 입력은 ToolKind만으로는 알 수 없는 구체적인 정보를 담고 있습니다.

02 · PLAN

Plan 모드는 먼저 편집 게이트를 설정합니다

plan_mode_edit_gate는 권한 요청이 전송되기 전에 수정을 거부할 수 있습니다. 계획 파일에는 별도의 자동 승인 경로가 있습니다.

03 · HOOKS

PreToolUse는 명시적으로 차단할 수 있습니다

일치하는 hooks는 설정된 순서대로 실행됩니다. 명시적 deny는 즉시 중단시키고, 타임아웃, 충돌, 형식 오류는 현재 구현에서 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는 이번 요청만 허가합니다. 샌드박스가 실제로 활성화된 경우, 프로세스는 여전히 capability set과 서브프로세스 네트워크 정책의 제약을 받습니다. 완료 후 비차단 post_tool_use hooks가 실행될 수 있습니다.

Bash 명령은 스크립트 구조 이해가 필요합니다

bash_command_splitting

tree-sitter-bash는 안전하게 분해 가능한 스크립트를 개별 plain command로 분리하고, &&, ||, 세미콜론, 파이프를 인식합니다. 각 non-setup segment는 독립적으로 안전 명령, 정책 또는 인가 검사를 통과해야 하므로 ls && rm이 첫 번째 segment로 통과되는 것을 방지합니다.

복잡한 구문의 보수적 처리

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할 수 있습니다.

샌드박스 레이어: 기능 제약

「허가된 프로세스가 실제로 어떤 파일과 네트워크에 접근할 수 있는가」에 답합니다. 샌드박스가 활성화된 경우 권한 레이어의 Allow는 OS 기능을 확장하지 않습니다. 샌드박스가 적용되지 않은 경우 권한 팝업을 커널 수준 격리로 취급할 수 없습니다.

핵심 교정: 「샌드박스 내 모든 쓰기 작업은 자동 승인」은 일반적인 규칙이 아닙니다. 소스 코드의 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 결정, 세션 상태, 사용자 선택에 의존합니다. 권한 레이어는 결정을 담당하고, 샌드박스 레이어는 제약을 담당합니다. 두 레이어가 함께 도구 실행의 실제 보안 경계를 설명합니다.