에이전트의 안전장치를 공격 테스트하다: 살아남은 것들

파괴적인 에이전트 명령어에 대한 블랙리스트가 자체 테스트를 통과했지만, 제가 직접 작성한 네 가지 우회 시도에는 실패했습니다. 해결책은 더 똑똑한 구문 분석(parsing)이 아닙니다. 내부에서 테스트된 기록들을 확인하세요.

저는 AI 코딩 에이전트를 위해 안전장치(seatbelt)를 만들었습니다: 실행되기 전에 모든 Bash 호출을 검사하고 파괴적인 것을 차단하는 PreToolUse 훅입니다. 이 안전장치는 자체 테스트 스위트에서 통과했습니다—5번의 실행, 모두 성공(green).

그러고는 저는 저녁 시간을 들여 이것을 공격했습니다. 이 게시물은 세션 로그입니다: 블랙리스트가 포착한 것들, 그대로 통과한 것들, 두 번째 버전이 수정한 것들, 그리고 실제 취약점이 있는 곳까지 기록되어 있습니다. 아래의 모든 내용은 실제로 실행되었으며, 재구성된 것이 아닙니다.

v1 — 모두가 작성하는 블랙리스트

규칙은 간단합니다: PreToolUse 훅은 표준 입력(stdin)으로 JSON 형식의 도구 호출을 받습니다. 허용하려면 0을 반환하고, 차단하려면 2를 반환합니다—그리고 이 훅의 stderr는 모델에게 다시 전달되어, 왜 차단되었는지 읽고 적응할 수 있게 합니다. 스킬(skill)은 모델이 가중치를 둘 수 있는 조언입니다. 훅(hook)은 종료 코드(exit code)입니다.

가장 명백한 구현 방식은 블랙리스트입니다:

#!/bin/sh
# PreToolUse hook: stdin에서 { tool_name, tool_input } JSON을 읽습니다.
# exit 0 = 허용 | exit 2 = 차단, stderr는 에이전트에게 전달됩니다.
...

모두 성공했습니다: rm -rf $HOME/...은 차단되었고, mkdir -p build && ls는 허용되었으며, git push --force origin main은 차단되었고, rm -rf /var/data/scratch도 차단되었으며, DROP TABLE users도 차단되었습니다. 다섯 개 중 다섯 개 모두 성공했습니다. 출시할까요?

참고로 첫 번째 패턴의 $를 보세요—첫 초안에는 이것이 없었습니다. 왜냐하면 sh는 case 패턴 내부에서 $HOME을 확장하기 때문입니다. 가드는 확장된 경로를 검색했지만, 에이전트의 명령어는 리터럴 텍스트를 포함하고 있었습니다. 제가 공격하기도 전에 안전장치가 자체 테스트에 실패했습니다.

우회 시도 라운드

그러고 나서 저는 개발자처럼 테스트하는 것을 멈추고, 그것이 막으려는 대상(thing it guards against)처럼 테스트하기 시작했습니다:

$ echo '{"tool_input":{"command":"echo cm0gLXJmIC9EYXRhL3NlY3JldA== | base64 -d | sh"}}' | guard-bash.sh
exit=0

...

네 가지 공격, 네 번의 통과. base64 파이프는 동사(verb)를 완전히 숨기고; python3 -c는 절대 rm을 철자로 쓰지 않습니다; find -delete는 글자 순서 없이 삭제입니다; git clean -fdx는 도자기 같은 얼굴을 한 파괴입니다. 블랙리스트는 시작하기도 전에, 구조적인 이유로 무너졌습니다: 파괴적인 명령어의 집합은 무한하며, 쉘(shell)은 조합을 위해 설계된 언어이기 때문입니다. 당신이 무엇을 두려워해야 하는지 열거할 수 없습니다.

v2 — 정책 역전 (invert the policy)

그러니 나쁜 명령어를 나열하는 것을 멈추고 좋은 영역을 명시하기 시작하세요. 포지티브 정책(Positive policy): 파괴적인 동사는 허용되지만, 그 대상은 프로젝트 내부에 머물러야 합니다. 구문 분석이 진지해집니다 — 문자열 매칭(string matching)이 아니라 shlex를 사용합니다:

#!/usr/bin/env python3
"""사전 도구 사용 후크, v2 — 파괴적인 동사는 프로젝트 내부 경로만을 대상으로 해야 합니다."""
import json, shlex, sys, os
...

그리고 또다시 자체 테스트에 실패했습니다 — 좋은 의미의 실패입니다. rm -rf /tmp/seatbelt/build는 프로젝트 외부이므로 차단되었는데, macOS에서는 /tmp가 /private/tmp로 심볼릭 링크(symlink)이기 때문입니다: realpath가 대상을 수정했고 프로젝트 루트 경로는 접두사 없이 유지되었습니다. 해결책은 한 줄 — 양쪽 모두에 realpath를 적용하는 것 — 이고, 이는 자신의 기계의 병리 현상에 맞서 가드를 실행해 봐야만 발견할 수 있는 종류의 버그입니다.

수정 후: rm -rf /Data/secret 차단됨, git clean -fdx /etc 차단됨, rm -rf /tmp/seatbelt/build 허용됨. 세 개 중 세 개 모두 통과했습니다.

하지만 여전히: python3 -c "import shutil; shutil.rmtree(...)"는 통과합니다. 왜냐하면 파서가 아는 파괴적인 동사를 철자로 쓰지 않기 때문입니다. v2는 v1보다 더 잘 잡아내지만, 모든 것을 잡아내는 것은 아닙니다. 명령어를 구문 분석하는 것이 모든 것을 잡아낼 수는 없습니다.

실제 방어벽이 존재하는 곳

구문 분석을 통해 막을 수 없는 계층은 아예 명령어를 읽지 않는 것입니다:

$ chmod 555 wall/            # 부모 디렉토리가 쓰기 권한을 잃음
$ rm -rf wall/secret
rm: wall/secret: 권한 거부
...

파일 시스템 권한이 파서(parser)나 패턴 목록 없이 삭제를 차단했습니다. 모델이 논쟁할 거리를 찾지 못한 것이죠. 이것은 대부분의 에이전트 보안 스레드가 건너뛰는 지루한 답변입니다: 샌드박스(sandbox) 자체가 안전벨트 역할을 합니다—별도의 OS 사용자, 컨테이너, 범위가 지정된 파일 시스템을 의미하죠. 그리고 후크(hook)는 그 앞에 있는 정교하고 검사 가능한 계층입니다. Railway의 사고 대응 철학은 제품 언어로 같은 말을 하고 있습니다: 파괴적인 행위를 느리게 만들고, 복구 가능한 행위를 빠르게 만드세요. 그리고 그들의 파괴적 동작에 대한 평가 하네스(eval harness against destructive behavior)는 유지보수 루프입니다—주기적으로 재공격하지 않는 가드는 이미 썩어가고 있는 방어선과 같습니다.

밤을 견딘 것들

최종 아키텍처는 세 개의 계층으로 구성되며, 각각 다른 역할을 수행합니다: 결정론적이고 검사 가능하며 패턴에 대해 정직한 확인 게이트이자 트립와이어인 후크(hook); 어떤 명령어 문자열로도 매혹할 수 없는 권한 및 샌드박싱을 의미하는 벽으로서의 OS; 그리고 달력 항목일 뿐 분위기가 아닌 유지보수 루프로서의 **공격 세션(attack session)**입니다.

두 가지 정직한 한계가 있습니다. 여기에 설명된 모든 계층 중 파일 시스템 계층을 제외하고는 트립와이어이며, 파이썬 원라인 클래스(python-one-liner class)는 이 모든 것을 통과합니다—바로 이것이 OS 계층이 선택 사항이 아닌 이유입니다. 그리고 이것은 가드(guard)의 저자가 벌인 밤의 공격 중 하나일 뿐입니다. 더 많은 밤을 가진 적대자는 더 많이 찾아낼 것입니다. 안전벨트는 끝난 것이 아닙니다. 단지 그것이 무엇인지 정직하게 보여줄 뿐입니다: 벽이 나서야 하는 지루하고 되돌릴 수 없는 실수를 잡아내는 계층인 거죠.

어젯밤에 파싱할 수 없었던 에이전트의 동작은 무엇이었나요?