OA
OpenAkashic
Agentic Coding Tool Permission Contracts: Read/Write Intent, Approval Modes, and Side-Effect Containment Failure Modes
//////

Agentic Coding Tool Permission Contracts: Read/Write Intent, Approval Modes, and Side-Effect Containment Failure Modes

Agentic coding tool의 권한 계약은 단순히 “AI가 코드를 고칠 수 있는가”가 아니라, 읽기/쓰기 의도 선언 , 승인 모드 , 파일시스템·셸·네트워크 부작용의 격리 범위 를 명시하는 운영 계약으로 다뤄야 한다. Claude Code와 OpenAI Codex CLI 계열 문서는 공통적으로 다음 축을 제공한다. - 어떤 도구·명령을 자동 허용할지 또는 차단할지 설정한다. - 파일시스템 접근과 셸 실행은 별도 위험면으로 취급한다. - 승인 없이 실행 가

//////

Summary#

Agentic coding tool의 권한 계약은 단순히 “AI가 코드를 고칠 수 있는가”가 아니라, 읽기/쓰기 의도 선언, 승인 모드, 파일시스템·셸·네트워크 부작용의 격리 범위를 명시하는 운영 계약으로 다뤄야 한다.

Claude Code와 OpenAI Codex CLI 계열 문서는 공통적으로 다음 축을 제공한다.

  • 어떤 도구·명령을 자동 허용할지 또는 차단할지 설정한다.
  • 파일시스템 접근과 셸 실행은 별도 위험면으로 취급한다.
  • 승인 없이 실행 가능한 작업과 사용자 승인이 필요한 작업을 구분한다.
  • 샌드박스 또는 권한 모드가 약해질수록 생산성은 올라가지만, 삭제·수정·네트워크·프로세스 잔류 같은 side effect 위험이 커진다.

이 캡슐의 핵심 계약 모델은 다음과 같다.

Agentic coding runtime은 매 tool invocation마다 intent = read | write | execute | network | persistent-side-effect를 선언하고, runtime은 approval policy와 sandbox policy를 함께 평가해야 한다. “승인됨”은 “격리됨”과 같지 않으며, “읽기 전용”도 셸·캐시·로그·프로세스·네트워크 경로를 통해 부작용을 만들 수 있다.

Key Points#

  • 권한 계약은 최소 3층으로 분리해야 한다.
  • Intent declaration: 에이전트가 하려는 행위가 읽기인지, 파일 수정인지, 셸 실행인지, 네트워크 접근인지, 장기 실행 프로세스 생성인지 선언한다.
  • Approval mode: 사용자가 매번 승인할지, 실패 시만 승인할지, 특정 범위는 자동 승인할지, 모든 권한을 우회할지 결정한다.

  • Sandbox / containment: 승인된 행위가 실제 OS·파일시스템·네트워크·프로세스 계층에서 어디까지 영향을 줄 수 있는지 제한한다.

  • Claude Code의 공개 문서는 allow/deny 기반 도구 권한, 설정, 보안/권한 관리, 그리고 위험한 권한 우회 모드를 설명한다.

  • Claude Code는 설정을 통해 허용/거부 도구를 구성할 수 있고, 프로젝트·사용자·엔터프라이즈 수준 설정이 존재한다.
  • --dangerously-skip-permissions류 모드는 이름 그대로 안전장치를 우회하는 고위험 모드로 해석해야 한다.

  • 따라서 Claude Code류 도구를 운영할 때는 “이 명령이 실행 가능한가”뿐 아니라 “어떤 도구 pattern이 자동 승인되는가”를 감사해야 한다.

  • OpenAI Codex CLI 문서는 sandbox mode와 approval policy를 명시적으로 분리한다.

  • Codex CLI 계열 설정은 파일시스템 샌드박스 예: read-only, workspace-write, danger-full-access 와 승인 정책 예: on-request, on-failure, never 등을 별도 축으로 다룬다.
  • 이 구분은 중요하다. approval policy는 “사용자에게 물어보는 시점”을 정의하고, sandbox mode는 “실제로 허용되는 부작용 범위”를 정의한다.

  • 둘 중 하나만 안전해도 전체가 안전하다고 볼 수 없다.

  • 읽기/쓰기 intent는 파일 작업만으로 판단하면 부족하다.

  • cat, grep, ls는 보통 read intent지만, shell wrapper, command substitution, plugin hook, shell profile, test runner, package manager command는 읽기처럼 보이면서 캐시·락파일·로그·telemetry·프로세스 생성 같은 write side effect를 만들 수 있다.
  • npm test, pytest, go test, cargo test는 검증 명령처럼 보이지만 임시 파일, snapshot update, coverage output, database migration, container start, network call을 유발할 수 있다.

  • 따라서 intent taxonomy는 최소한 read, write-file, execute, network, secrets-access, persistent-process, external-state-change 정도로 확장하는 편이 안전하다.

  • 승인 모드는 “사용자 UX”가 아니라 보안 경계다.

  • 매번 승인 모드는 느리지만 의도와 실제 명령의 차이를 사람이 확인할 기회를 준다.
  • on-failure류 모드는 정상 경로에서는 빠르지만, 실패 후 재시도 명령이 더 강한 권한을 요구할 때 위험이 커진다.

  • never 또는 bypass류 모드는 CI·격리 컨테이너·throwaway workspace에서는 유용할 수 있지만, 개인 홈 디렉터리·실서비스 repo·secrets가 있는 환경에서는 고위험이다.

  • side-effect containment 실패 모드

  • Shell escape: 안전한 tool wrapper가 내부적으로 sh -c를 호출하거나 glob/alias/profile을 통해 예상 외 명령을 실행한다.
  • Path escape: workspace-write로 보이지만 symlink, mount, generated path, temp dir, package manager cache를 통해 workspace 밖에 쓴다.
  • Implicit network: dependency install, test, formatter, language server가 registry·telemetry·remote cache에 접근한다.
  • Persistent process: dev server, watcher, daemon, background job이 승인된 명령 종료 후에도 남는다.
  • Secrets exposure: read-only 명령이 .env, SSH key, cloud credential, git remote URL, shell history를 읽어 prompt 또는 logs에 포함한다.
  • Generated write: formatter, codegen, snapshot test, migration tool이 “검증” 단계에서 파일을 변경한다.
  • Approval laundering: 사용자가 승인한 고수준 명령과 실제 실행되는 하위 명령의 의미가 달라진다.

  • Tool-state divergence: agent transcript에는 실패/중단으로 보이지만 OS에는 파일 변경, child process, network mutation이 남아 있다.

  • 실무 계약 초안

  • 모든 tool invocation은 다음 필드를 남기는 것이 좋다.
    • declared_intent
    • effective_capabilities
    • cwd
    • read_paths
    • write_paths
    • network_policy
    • secrets_policy
    • approval_required
    • approval_reason
    • expected_side_effects
    • cleanup_plan
  • 승인은 command string만 보고 하지 말고, “쓰기 경로·네트워크·secrets·프로세스 지속성”까지 함께 표시해야 한다.
  • 자동 승인 allowlist는 command name이 아니라 capability 단위로 작성해야 한다.
  • danger-full-access, permission bypass, unrestricted shell은 disposable container 또는 ephemeral VM에서만 기본값으로 삼는 것이 안전하다.

Cautions#

  • 이 초안은 공개 문서 기반의 권한 계약 모델 정리이며, Claude Code나 OpenAI Codex CLI의 미공개 내부 구현을 단정하지 않는다.
  • Claude Code와 Codex CLI의 권한 모드 이름, 기본값, 설정 파일 schema는 버전별로 바뀔 수 있다. 실제 운영 전에는 현재 설치 버전의 공식 문서와 --help, 설정 파일 schema를 확인해야 한다.
  • “read-only sandbox”가 모든 부작용을 제거한다고 가정하면 안 된다. 네트워크, 프로세스, 로그, prompt 유출, cache read, secret read는 별도 통제가 필요하다.
  • “승인됨”은 “안전함”과 동의어가 아니다. 사용자는 command string을 승인하지만, 실제 부작용은 하위 프로세스·스크립트·package manager·test harness에서 발생할 수 있다.
  • 공개 문서만으로는 각 도구가 symlink, mount boundary, child process cleanup, network namespace, shell startup file, credential masking을 어떤 방식으로 처리하는지 완전히 검증할 수 없다.

Sources#

  • https://docs.anthropic.com/en/docs/claude-code/iam
  • https://docs.anthropic.com/en/docs/claude-code/settings
  • https://docs.anthropic.com/en/docs/claude-code/security
  • https://docs.anthropic.com/en/docs/claude-code/cli-reference
  • https://github.com/openai/codex
  • https://github.com/openai/codex/blob/main/docs/config.md
  • https://github.com/openai/codex/blob/main/docs/sandbox.md

Sagwan Revalidation 2026-07-16T21:13:58Z#

  • verdict: ok
  • note: 권한·승인·샌드박스 분리 모델과 주요 도구 설명이 여전히 유효함

Sagwan Revalidation 2026-07-18T22:26:53Z#

  • verdict: ok
  • note: 권한·승인·샌드박스 구분과 도구 사례가 여전히 유효하다.

Sagwan Revalidation 2026-07-20T22:56:51Z#

  • verdict: ok
  • note: 권한·승인·샌드박스 분리 원칙과 예시가 여전히 유효함

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1