AI 코딩 에이전트 자동 승인은 어디까지 안전할까

AI 코딩 에이전트를 오래 사용하면 권한 요청 자체가 일이 됩니다. 파일을 읽고, 테스트를 실행하고, 같은 명령을 다시 실행할 때마다 승인을 누르다 보면 결국 모든 권한을 한꺼번에 열고 싶어집니다.

하지만 자동 승인과 전체 권한 우회는 같은 선택이 아닙니다. 작업 디렉터리 안의 수정과 검증은 자동화하되, 네트워크·비밀값·원격 저장소·배포 환경으로 넘어가는 순간에는 경계를 남기는 것이 현실적인 기본값입니다.

Codex와 Claude Code는 설정 이름은 달라도 샌드박스와 권한 규칙으로 자동 실행 범위를 좁힌다는 점은 같습니다. 제품 업데이트로 모드 이름과 설정 문법은 달라질 수 있지만, 작업 범위와 복구 가능성으로 권한을 나누는 기준은 그대로 적용할 수 있습니다.

판단 기준도 “이 명령은 안전한가?”보다 다음 세 질문이 낫습니다.

영향이 현재 작업 디렉터리 안에 머무는가?
Git이나 작업 사본으로 되돌릴 수 있는가?
외부 시스템이나 다른 사람에게 즉시 영향을 주는가?

세 질문에 모두 유리하면 자동 승인 후보입니다. 하나라도 불분명하면 매번 확인하거나 아예 차단하는 편이 낫습니다.

샌드박스와 승인은 다른 안전장치다

Codex 공식 문서는 로컬 보안을 두 층으로 설명합니다. 샌드박스는 에이전트가 기술적으로 접근할 수 있는 파일과 네트워크 범위를 정하고, 승인 정책은 그 경계를 넘기 전에 사용자에게 물을 시점을 정합니다.

예를 들어 workspace-write 샌드박스에서는 현재 작업 공간을 읽고 수정할 수 있지만 기본적으로 네트워크는 꺼져 있습니다. 에이전트가 작업 공간 밖을 수정하거나 네트워크가 필요한 명령을 요청하면 승인 흐름으로 넘어갑니다. 승인을 묻지 않게 설정해도 샌드박스가 그대로라면 에이전트는 그 경계 안에서만 움직입니다.

Claude Code 권한 설정도 읽기, 셸 명령, 파일 수정에 서로 다른 기본 권한을 적용하고 allow, ask, deny 규칙을 제공합니다. 규칙은 deny, ask, allow 순서로 평가되므로 명시적인 차단 규칙이 허용 규칙보다 우선합니다.

구분	정하는 것	잘못 설정했을 때 생기는 문제
샌드박스	접근 가능한 파일과 네트워크 범위	한 번의 승인으로 예상보다 넓은 영역에 접근할 수 있음
승인 정책	어떤 행동을 사용자에게 물을지	반복 승인 또는 지나친 자동 실행
허용·차단 규칙	특정 명령이나 도구의 예외	너무 넓은 패턴이 위험한 하위 명령까지 포함함

승인 창을 줄이고 싶다면 먼저 샌드박스를 좁게 잡아야 합니다. 넓은 시스템 권한을 준 뒤 명령어 이름만 보고 막는 방식보다, 작업 공간과 네트워크를 먼저 제한한 뒤 그 안에서 자율성을 주는 편이 경계가 분명합니다.

자동 승인은 복구 가능성으로 나눈다

명령어는 같은데 위험도는 상황에 따라 달라집니다. git은 상태를 읽기도 하고 원격 저장소에 push하기도 합니다. npm은 버전을 출력하기도 하고 외부 패키지의 설치 스크립트를 실행하기도 합니다. 도구 이름 전체를 허용하면 서로 다른 위험을 한 규칙에 묶게 됩니다.

작업을 결과 기준으로 나누면 범위를 정하기 쉽습니다.

작업	기본 권장	이유
일반 파일 검색과 읽기	자동 허용	로컬 상태를 바꾸지 않음
`git status`, `git diff`, `git log`	자동 허용	저장소 상태를 읽기만 함
작업 공간 안의 코드 수정	조건부 자동 허용	Git으로 되돌릴 수 있지만 미커밋 변경 보호가 필요함
단위 테스트, 타입 검사, 린트	조건부 자동 허용	보통 로컬 검증이지만 프로젝트 스크립트에 부작용이 있을 수 있음
패키지 설치	매번 확인	네트워크, lockfile 변경, 설치 스크립트 실행이 함께 일어날 수 있음
`git commit`	사용자가 요청한 경우만	로컬에서 복구 가능하지만 이력이라는 결과물을 만듦
`git push`, PR 병합	매번 확인	원격 상태와 다른 사람의 작업 흐름에 영향을 줌
비밀값 읽기	원칙적으로 차단	한 번 노출되면 Git으로 되돌릴 수 없음
배포, 데이터 변경	매번 확인	외부 사용자와 운영 데이터에 직접 영향을 줌
삭제와 이력 재작성	매번 확인 또는 차단	복구 비용이 크고 범위를 오판하기 쉬움

여기서 “조건부 자동 허용”의 조건은 두 가지입니다. 저장소가 버전 관리 중이고, 에이전트가 작업을 시작하기 전에 기존 변경을 구분할 수 있어야 합니다. 사용자 변경과 에이전트 변경이 섞인 상태에서 자동 수정을 허용하면 되돌리는 과정에서 원래 작업까지 잃을 수 있습니다.

읽기와 로컬 검증은 비교적 넓게 허용할 수 있다

코드 검색, 파일 읽기, git diff와 같은 작업은 에이전트가 판단하기 위해 계속 반복합니다. 이 구간에 매번 승인을 요구하면 안전성이 크게 늘기보다 사용자가 승인 창을 습관적으로 누르게 될 가능성이 큽니다.

테스트와 린트도 대체로 자동화에 적합합니다. 다만 명령어 이름만 보고 안전하다고 단정하면 안 됩니다. 프로젝트의 test 스크립트가 Docker 컨테이너를 띄우거나, 외부 데이터베이스를 초기화하거나, 스냅샷 파일을 갱신할 수도 있습니다.

다음 조건을 만족할 때 로컬 검증을 자동 허용하기 좋습니다.

명령이 사용하는 환경 변수를 확인했습니다.
운영용 자격 증명이 로컬 셸에 들어 있지 않습니다.
테스트 데이터베이스와 운영 데이터베이스가 분리되어 있습니다.
스냅샷 갱신이나 코드 생성처럼 파일을 바꾸는 단계가 구분되어 있습니다.
실패해도 현재 작업 사본 밖에 영향을 주지 않습니다.

pnpm test라는 이름이 안전을 보장하는 것이 아닙니다. 그 명령이 실제로 무엇을 실행하는지 한 번 확인한 뒤 허용해야 합니다.

패키지 관리자는 하위 명령까지 좁혀야 한다

npm, pnpm, yarn, pip를 통째로 허용하면 승인 요청은 빠르게 줄어듭니다. 대신 설치, 게시, 전역 변경까지 같은 권한 범위에 들어올 수 있습니다.

패키지 설치에는 보통 세 가지 변화가 함께 따라옵니다.

레지스트리와 통신합니다.
lockfile과 의존성 디렉터리를 바꿉니다.
패키지가 제공하는 설치 스크립트를 실행할 수 있습니다.

따라서 pnpm test, pnpm lint, pnpm build처럼 이미 검토한 프로젝트 명령은 좁게 허용하고, pnpm add, npm install, pip install은 요청마다 확인하는 편이 낫습니다. npm * 같은 넓은 패턴은 npm publish까지 포함할 수 있으므로 승인 피로를 줄이는 대가가 너무 큽니다.

의존성 설치를 자주 반복해야 한다면 권한을 넓히기보다 환경을 분리할 수 있습니다. 개발 컨테이너나 일회용 작업 환경에서 설치 단계를 수행하면 호스트에 미치는 영향과 자격 증명 노출을 줄일 수 있습니다.

Git은 읽기, 로컬 이력, 원격 변경으로 나눈다

Git 전체를 하나의 허용 규칙으로 묶으면 읽기와 원격 변경이 같은 권한을 갖게 됩니다.

자동화하기 좋은 작업

git status
git diff
git log
git show

이 명령들은 저장소를 이해하고 변경을 검토하는 데 필요하며 기본적으로 상태를 읽습니다.

사용자가 요청했을 때만 실행할 작업

git add <구체적인 파일>
git commit

로컬 커밋은 되돌릴 수 있지만, 사용자가 의도하지 않은 파일이 포함되면 검토 단위가 망가집니다. 특히 git add .는 비밀 파일이나 관련 없는 변경을 함께 스테이징할 수 있습니다. 커밋을 맡기더라도 파일 목록과 diff를 먼저 확인하는 절차가 필요합니다.

자동 승인하지 않을 작업

git push
git reset --hard
git clean -fd
git rebase

push는 원격 상태를 바꿉니다. reset --hard와 clean은 로컬 변경을 잃게 할 수 있고, rebase는 공유 이력과 충돌할 수 있습니다. 명령 자체가 항상 나쁜 것은 아니지만 자동 승인 기본값으로 두기에는 복구 조건이 복잡합니다.

네트워크 권한은 목적지까지 좁힌다

네트워크 접근은 파일 쓰기와 다른 위험을 가집니다. 에이전트가 로컬 파일을 수정하면 diff로 확인할 수 있지만, 외부로 전송된 데이터는 같은 방식으로 회수할 수 없습니다.

Codex의 네트워크 정책은 workspace-write에서 명령의 네트워크 접근을 기본적으로 끄고, 네트워크를 켠 경우에도 도메인 정책으로 목적지를 제한할 수 있게 합니다. 네트워크 기능을 켜는 설정과 허용할 목적지를 정하는 설정은 별개입니다.

실무에서는 다음처럼 나누는 편이 안전합니다.

공식 패키지 레지스트리와 문서 사이트: 필요한 작업에 한해 허용
프로젝트 API의 개발 환경: 정확한 호스트만 허용
localhost: 필요한 포트와 프로세스를 확인한 뒤 허용
사설망 전체와 임의의 외부 호스트: 기본 차단
운영 API와 클라우드 관리 엔드포인트: 매번 확인

도메인 전체를 *로 허용하면 네트워크 승인을 없앨 수는 있지만, 프롬프트 인젝션이나 잘못된 명령이 데이터를 외부로 보낼 수 있는 범위도 함께 넓어집니다.

비밀값은 읽기 권한부터 분리한다

.env, SSH 키, 클라우드 자격 증명, 패키지 레지스트리 토큰은 “수정하지 않으니 안전한 파일”이 아닙니다. 읽기만 해도 위험이 생깁니다.

에이전트가 테스트를 실행하려면 비밀값이 필요하다고 생각하기 쉽지만, 실제로 필요한 것은 대개 운영 자격 증명이 아니라 제한된 개발용 값입니다.

운영 토큰을 로컬 셸에서 제거합니다.
테스트 전용 계정과 최소 권한 키를 사용합니다.
비밀 파일 경로는 명시적으로 읽기 차단합니다.
로그와 오류 메시지에 토큰이 출력되지 않는지 확인합니다.
클라우드 작업에는 작업 단계에 필요한 비밀만 짧게 주입합니다.

비밀값을 읽은 뒤 “출력하지 마”라고 지시하는 것은 접근 통제가 아닙니다. 읽지 못하게 만드는 것이 먼저입니다.

Claude Code는 allow, ask, deny를 함께 쓴다

Claude Code의 프로젝트 설정에서는 이미 검토한 명령을 허용하고, 외부 부작용이 있는 작업은 묻거나 차단할 수 있습니다. 다음은 권한 범위를 보수적으로 잡은 예시입니다.

{
  "permissions": {
    "allow": [
      "Bash(pnpm test)",
      "Bash(pnpm lint)",
      "Bash(pnpm build)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git log)"
    ],
    "ask": ["Bash(pnpm add *)", "Bash(npm install *)", "Bash(git commit *)"],
    "deny": ["Bash(git push *)", "Read(./.env*)", "Read(~/.ssh/**)"]
  }
}

실제 패턴은 프로젝트 명령에 맞게 좁혀야 합니다. 인자가 필요 없다면 예시처럼 정확한 명령부터 허용하고, 반복해서 필요한 인자가 확인됐을 때만 와일드카드를 추가합니다. Claude Code 공식 문서가 설명하듯 와일드카드는 공백을 포함한 여러 인자와 일치할 수 있으므로 /permissions에서 출처와 적용 범위를 확인해야 합니다.

bypassPermissions 또는 --dangerously-skip-permissions는 승인 창만 줄이는 설정이 아닙니다. 보호 경로 쓰기를 포함한 권한 확인을 건너뜁니다. Claude Code 권한 모드 문서는 이 모드를 컨테이너나 VM처럼 호스트와 격리된 환경에서만 사용하라고 안내합니다.

Codex는 좁은 샌드박스 안에서 자율성을 준다

Codex의 보수적인 로컬 설정은 작업 공간 쓰기, 요청 시 승인, 명령 네트워크 차단으로 잡을 수 있습니다. 각 설정이 만드는 경계는 샌드박스 문서에서 확인할 수 있습니다.

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

반복해서 사용하는 명령은 prefix rule로 세분화할 수 있습니다. 예를 들어 git status와 git diff는 허용하고 git push는 계속 묻게 만들 수 있습니다. 규칙이 여러 개 일치하면 더 제한적인 결정이 우선합니다.

전체 승인 요청을 끄는 approval_policy = "never"도 샌드박스와 함께 사용할 수 있습니다. 이 경우 Codex는 승인 없이 샌드박스 안에서 할 수 있는 만큼만 수행하고, 경계를 넘는 작업은 진행하지 못합니다. 반면 danger-full-access나 --dangerously-bypass-approvals-and-sandbox는 승인과 샌드박스를 함께 우회하므로 전혀 다른 위험 수준입니다.

전체 권한 우회가 가능한 조건

전체 우회가 필요한 자동화도 있습니다. 장시간 벤치마크, 대규모 코드 변환, 반복적인 테스트 수정처럼 중간 승인이 작업을 사실상 멈추게 하는 경우입니다.

그래도 개인 노트북에서 바로 전체 권한을 주는 것이 기본값이 되어서는 안 됩니다. 최소한 다음 조건을 모두 만족하는 환경이 필요합니다.

작업이 끝나면 폐기할 수 있는 컨테이너나 VM입니다.
호스트 홈 디렉터리와 다른 저장소가 마운트되지 않았습니다.
운영용 SSH 키, 클라우드 자격 증명과 브라우저 세션이 없습니다.
네트워크가 꺼져 있거나 필요한 목적지만 허용되어 있습니다.
저장소는 별도 브랜치나 worktree에 있고 원격 push 권한이 없습니다.
결과는 diff와 테스트를 통해 사람이 검토합니다.

격리 환경이 없다면 전체 우회보다 dontAsk처럼 미리 허용한 작업만 비대화형으로 실행하고 나머지는 거부하는 방식이 낫습니다. 자동화가 멈추는 것이 호스트나 운영 환경을 잘못 바꾸는 것보다 복구 비용이 낮습니다.

권한 요청이 뜨면 명령어 이름만 보지 말고 범위, 비밀값, 외부 효과와 복구 방법을 확인합니다. 같은 승인이 반복되더라도 곧바로 “항상 허용”을 누르기보다 git 전체가 아닌 git diff, 패키지 관리자 전체가 아닌 pnpm test, 네트워크 전체가 아닌 필요한 도메인으로 규칙을 좁힙니다.

결론

AI 코딩 에이전트의 자동 승인 범위는 명령어의 익숙함이 아니라 영향 범위와 복구 가능성으로 정해야 합니다.

파일 읽기, 코드 검색, 로컬 diff와 검증은 좁은 샌드박스 안에서 자동화할 수 있습니다. 패키지 설치는 네트워크와 설치 스크립트 때문에 한 단계 더 확인해야 합니다. 비밀값, 원격 저장소, 배포와 운영 데이터는 별도 경계로 남겨야 합니다.

승인 피로를 줄이는 가장 좋은 방법은 모든 권한을 없애는 것이 아닙니다. 에이전트가 자유롭게 움직여도 되는 작은 구역을 먼저 만드는 것입니다.

AI 코딩 에이전트, 어디까지 자동 승인해도 될까