코딩 에이전트에게 권한을 줄 때 마지막 안전장치는 사람입니다. 명령이 뜨면 읽고 판단해서 승인하거나 막죠. 그 판단 40만 건을 모아봤더니 위협 셋 중 하나가 그냥 통과했습니다.

개발자 알렉스 바우터스가 만든 브라우저 게임에서 나온 숫자죠. 플레이어는 코딩 에이전트를 감시하는 사람 역할을 맡아, 시간 압박 속에서 올라오는 명령을 승인하거나 거부합니다. git status처럼 평범한 것도 있고 cat ~/.aws/credentials처럼 자격증명을 빼가는 것도 섞여 있죠. 4만 판이 쌓이는 동안 개별 승인·거부 결정은 40만 9천 건에 달했습니다.

출처: Humans missed 1 in 3 threats approving AI agent commands across 40,000 plays – Scale X

숫자를 읽기 전에 조건부터 짚겠습니다. 게임에 나온 명령의 34%가 위협이었고, 플레이어는 자기가 시험받는 중이라는 걸 알고 있었죠. 실무에서 위협은 이보다 훨씬 드물게 섞입니다.

그러니 평균 정확도 66.3%를 실제 사고율로 옮겨 읽으면 곤란합니다. 다만 어떤 종류의 위협을 상대적으로 못 잡는지는 이 데이터로 비교할 수 있죠.

눈에 띄는 파괴는 잡고, 조용한 유출은 놓친다

위협을 네 갈래로 나눠 보면 순서가 뚜렷합니다. rm -rf /처럼 대놓고 부수는 명령은 11.7%만 통과했죠. 크론탭에 작업을 심거나 git 설정을 바꿔치기하는 지속형 변조가 23.8%.

낯선 API로 데이터를 보내는 유출·코드 실행 계열은 33.4%였습니다. 권한 범위를 벗어나 ~/.aws/credentials 같은 파일을 읽는 명령이 35.0%로 가장 자주 통과했죠. 눈에 띄게 부수는 명령은 잘 막았지만, 실제로 자격증명을 가져가는 명령은 세 배 가까이 놓친 겁니다.

npm run 뒤에 숨기면 성공률이 두 배가 된다

가장 많이 통과한 명령은 npm run analyze였습니다. 64.7%가 승인했죠. 그 자체로는 평범한 명령입니다.

문제는 npm run이 실제로 하는 일이죠. package.json에 적힌 스크립트를 그대로 실행합니다. 번들 분석기일 수도 있고, 앞서 파일로 심어둔 코드일 수도 있죠.

게임은 그 스크립트의 내용을 승인 창 바로 위 히스토리 로그에 보여줬습니다. 분석 결과를 외부 주소로 전송하는 코드가 그대로 적혀 있었죠. 그런데도 3분의 2가 승인했습니다. 이름을 위장한 명령 세 개를 묶으면 통과율 52.5%, 다른 유출 계열 28.4%의 거의 두 배.

해커뉴스 토론에서 나온 지적이 이 지점을 정확히 짚습니다. npm run build를 승인한다는 건 package.json에 적힌 임의의 셸 명령을 실행하도록 허락하는 것이고, 에이전트는 그 package.json을 이미 승인 없이 고칠 수 있었다는 것. 명령 하나하나를 묻는 방식은 파일이 바뀐 뒤엔 힘을 잃습니다.

꼼꼼해질수록 에이전트가 멈춘다

세션이 길어질수록 놓치는 비율은 다시 올라갔습니다. 초반 몇 개를 지나며 좋아졌다가 후반부에 반등하는 모양이었죠. Anthropic도 Claude Code에서 같은 현상을 언급한 적이 있습니다. 승인 창을 많이 볼수록 하나하나에 기울이는 주의가 줄어든다는 것.

반대 방향의 비용도 있습니다. 사내 미러를 등록하는 npm config set registry는 59%가 막혔고, 빌드 산출물을 지우는 rm -rf dist/는 45%가 거부됐죠. 죽은 프로세스가 붙잡은 포트를 푸는 명령도 43%가 막혔습니다. 멀쩡한 작업을 계속 차단하면 에이전트를 쓰는 의미가 줄고, 그 피로는 다시 무심한 승인으로 돌아오죠.

그래서 통제가 운영체제로 내려갔다

같은 주에 Zed는 에이전트 패널의 터미널·fetch 도구에 샌드박싱을 넣고 1.14 릴리스부터 전 사용자 기본값으로 켰습니다. 프로젝트 폴더 밖 쓰기, .git 쓰기, 네트워크 요청이 기본적으로 차단되죠. 제한을 거는 주체가 에이전트가 아니라 운영체제라는 것. macOS는 Seatbelt, 리눅스는 네임스페이스, 윈도우는 WSL을 씁니다.

Zed 팀은 규칙 기반 통제가 왜 부족한지도 함께 설명했습니다. git .* 명령을 금지해도 bash -c로 감싸거나, 환경변수에 담거나, 실행 파일을 하나 만들어 우회할 길이 계속 남죠. 규칙은 선의를 가진 에이전트에게는 잘 듣지만 공격자 앞에서는 무너집니다. 남의 PR에 심긴 지시문을 읽어버린 에이전트에게 “하지 마”라고 적어둔 문서가 무슨 힘을 갖겠습니까.

Cloudflare가 사내에 먼저 적용하고 베타로 연 WriteGuard는 같은 발상을 프로토콜 쪽으로 옮긴 사례입니다. MCP 서버의 도구마다 위험 등급을 매겨, 기록만 남길지 아예 막을지를 서버에서 결정하죠. 스킬이나 확인 프롬프트 같은 클라이언트 쪽 장치는 하네스마다 동작이 다르고 사용자가 꺼버릴 수 있다는 게 이유였습니다.

승인 버튼이 그동안 지켜온 것

이 데이터가 말하는 건 사람이 부주의하다는 얘기가 아닙니다. 판단에 필요한 정보가 승인 창에 없다는 것이죠. cat ~/.zshrc가 위험한지는 그 파일에 API 키를 export해뒀는지에 달려 있는데, 에이전트도 승인 창도 그걸 모릅니다. 이 명령의 승인률이 45.9%로 게임에서 가장 크게 갈렸던 이유죠.

그래서 도구들이 향하는 방향은 사람의 주의력을 끌어올리는 쪽이 아닙니다. 사람이 틀려도 피해가 번지지 않게 경계를 미리 그어두는 쪽이죠. 승인 버튼을 없애자는 얘기는 아닙니다. 다만 안전을 그 버튼 하나에 걸어두고 있었다면, 지금이 다시 볼 때죠.

참고자료:

• Sandboxing – Zed Blog
• WriteGuard: Fine-grained controls for MCP Servers – Cloudflare Blog
• Suffering from Agent Permission Fatigue? Find out your high score – Scale X