권한과 sandbox로 신뢰 범위 정하기

권한은 켜고 끄는 스위치가 아니라 신뢰를 조절하는 다이얼이야

모든 AI CLI는 "매번 물어봐"와 "알아서 해" 사이에서 어디까지 허용할지 정하게 해. Claude Code는 allow / ask / deny 규칙을 쓰고, Codex는 승인 정책과 sandbox를 나눠 다루며, Gemini는 sandbox와 도구 제외 목록을 사용해. 용어는 달라도 묻는 질문은 하나야. 이 작업에서 에이전트를 어디까지 믿을 건가?

너무 자주 묻게 하면 사용자가 병목이 되고, 너무 많이 열어주면 확률적으로 움직이는 시스템에 위험한 권한을 맡기게 돼. 하나의 정답을 영구 설정으로 고집하지 마. 막 clone한 낯선 저장소에서는 엄격하게, 이미 격리된 컨테이너나 CI 실행기에서는 더 넓게 허용하는 식으로 작업마다 맞춰야 해.

신뢰 수준은 세션 중에도 바뀔 수 있어. 처음에는 읽기만 허용했다가 구조를 파악한 뒤 편집을 열고, 인증 코드로 들어가면 다시 좁히는 식이지. /permissions나 /approvals 같은 명령이 있는 이유도 바로 그 조절을 빠르게 하려는 거야.

직접 확인할 항목: npm install, read-only / workspace-write / danger-full-access, rm -rf, untrusted / on-request / never.

Code

같은 권한 개념을 표현하는 세 가지 방식·bash

# Claude Code — rule-based, deny → ask → allow
# .claude/settings.json
{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(git diff *)", "Read"],
    "ask":   ["Bash(git push *)"],
    "deny":  ["Bash(rm -rf *)", "Read(./.env)"]
  }
}

# Codex CLI — approval mode + sandbox mode
codex --ask-for-approval on-request --sandbox workspace-write

# Gemini CLI — sandbox container + tool exclusion
gemini --sandbox -e "WriteFile,RunShellCommand"

상황에 따라 권한을 좁히고 넓히기·bash

# 1. Brand-new repo, you don't trust the code yet
codex --sandbox read-only "explain what this project does"

# 2. Familiar repo, normal coding
codex                                    # default: workspace-write + on-request

# 3. Inside a Docker container, fully isolated
codex --sandbox danger-full-access --ask-for-approval never \
      "fix all eslint errors and rebuild"

# Same CLI, three trust levels — one per situation

Exercise

평소 쓰는 머신에서 가장 자주 쓰는 CLI에 허용 규칙 3개와 거부 규칙 2개를 추가해. 허용 규칙에는 매번 다시 승인하던 명령을, 거부 규칙에는 절대 실행시키고 싶지 않은 명령을 넣어. 세션을 돌린 뒤 승인 요청이 얼마나 줄었는지 세어봐. 그 차이가 실제 생산성 이득이야.

권한은 켜고 끄는 스위치가 아니라 신뢰를 조절하는 다이얼이야

Code

External links

Exercise

Progress

댓글 0