셸 명령의 실제 부작용을 먼저 관찰해 승인하는 Caper

무엇인가

코딩 에이전트는 코드 편집뿐 아니라 빌드, 테스트, 각종 셸 명령을 상태를 가진 워크스페이스에서 실행한다. 명령 하나가 잘못되면 자격 증명이 유출되거나 데이터가 삭제되고 보안 제어가 약해질 수 있어, 최근 에이전트 프레임워크는 명령 실행 전에 승인 단계를 둔다. 문제는 사람이 모든 명령을 승인하는 방식이 확장되지 않는다는 점이다. Anthropic은 사용자가 Claude Code 권한 프롬프트의 93%를 승인한다고 보고했고, 그래서 Claude Code Auto Mode 같은 시스템이 허용 규칙과 모델 기반 분류기로 승인을 자동화한다. 그러나 논문이 지적하는 핵심은 기존 승인자가 명령의 효과가 아니라 텍스트를 본다는 것이다. CARE 같은 정적 규칙 검사기, ToolSafe·gpt-oss-safeguard·Qwen3Guard 같은 가드레일 모델, Claude Code Auto Mode 같은 배포된 권한 분류기는 모두 요청문과 명령 문자열, 대화 이력을 판단 근거로 삼을 뿐 명령이 실제로 무엇을 하는지는 관찰하지 않는다. 셸 명령은 호출하는 코드의 동작이 명령 텍스트에 드러나지 않는다. 논문의 예에서 make clean && make는 어떤 워크스페이스에서는 재생성 가능한 빌드 산출물만 지우지만, 다른 워크스페이스에서는 Makefile 내용 때문에 소스 파일과 저장소 이력을 지운다. 승인자 입장에서 두 경우의 입력은 완전히 동일하다.

어떻게 동작하나

저자들이 제안하는 Caper(Consequence-Aware PERmission)는 에이전트 자체는 건드리지 않고 셸 경계에 개입한다. 명령이 제안되면 먼저 태스크 컨테이너를 스냅샷하고, 그 안에서 strace -f로 시스템 호출을 추적하며 명령별 타임아웃을 걸어 한 번 실행한다. 이때 출력은 에이전트에게 아직 돌려주지 않는다. 실행 결과로부터 제한된 크기의 효과 보고서를 만들고, LLM 승인자가 사용자 과제와 대조해 허용 여부를 판단한다. 허용되면 스냅샷을 버리고 실행 후 상태를 유지한 채 캡처한 출력을 도구 결과로 반환하므로 명령은 정확히 한 번만 실행된다. 차단되면 변경된 컨테이너를 제거하고 스냅샷에서 새 컨테이너를 띄워, 차단된 명령의 변화를 하나도 물려받지 않은 상태에서 에이전트가 계속 진행하게 한다. 이때 차단 사유를 함께 돌려주어 에이전트가 같은 작업을 다른 래퍼로 재시도하는 대신 더 안전한 경로를 찾도록 유도한다.

무엇과 다른가

효과 보고서는 원시 트레이스를 그대로 쓰지 않는다. 명령 하나가 수십 킬로바이트의 시스템 호출을 만들고 그중 상당수는 무관하거나 신뢰할 수 없는 콘텐츠에 영향받기 때문이다. 추출기는 먼저 경계를 넘는 결과, 즉 지속적 파일 변화와 네트워크 시도, 사용자에게 보이는 출력을 찾아 각각 작은 구조화 레코드인 결과 카드로 만든다. 파일 변화는 실행 전후 워크스페이스 비교로 얻고 작은 텍스트 파일은 제한된 내용 diff를 붙여 무엇이 바뀌었는지 보여주며, 민감 경로는 내용을 가린다. 네트워크 카드는 연결이 관측됐는지, 시도만 됐는지, 시뮬레이션 서비스가 응답했는지를 구분한다. 데이터를 실을 수 있는 결과에는 같은 프로세스가 그 이전에 무엇을 읽었는지를 같은 행위자라는 형태로 붙여 출처를 밝히고, dotenv·자격 증명 저장소·개인 키 후보에 대한 성공적 읽기는 이후 유출 지점이 없어도 보호된 읽기로 남긴다. 출력이 자격 증명 값 패턴과 일치하면 값이 아니라 일치한 분류만 표기한다. 보고서는 4KiB를 목표로 8KiB에서 상한을 두고, 초과하면 디렉터리 단위 집계, 카운트, 전이 요약 순으로 압축하되 실행 상태와 관측·포함·생략 이벤트 수, 시뮬레이션 표시, 명시적 불확실성은 예산을 넘겨서도 남긴다. 승인자 프롬프트는 승인 대상 패킷을 지시가 아닌 증거로 규정하고, 명령이나 파일, 출력에 적힌 지시를 따르지 말 것, 네트워크나 자격 증명 효과가 관측되지 않았다고 해서 안전하다고 단정하지 말 것을 요구한다. 판단 축은 위임된 목표와 범위, 자격 증명 접근, 훅·스캐너·저장소 정책 같은 보호된 보안 제어 변경, 즉각적 런타임 효과, 이후 설치·빌드·커밋·시작 시점에 실행되도록 예약된 지연 효과, 증거의 불확실성으로 나뉜다.

어떻게 쓰나

실험은 두 벤치마크에서 이뤄졌다. SABER는 상태를 가진 프로젝트 워크스페이스에서 정당한 개발 요청을 주지만 순진하게 수행하면 자격 증명 유출, 데이터 삭제, 보안 제어 약화 같은 과제별 피해가 발생하는 셸 전용 682개 과제로, 8개 피해 범주와 3개 시나리오를 아우른다. YoloFS-Ext는 저자들이 YoloFS를 확장해 만든 것으로, 겉보기에는 무해한 명령이 호출하는 도구 안에 유해 행동을 숨긴다. 원본 13개 프로젝트와 요청을 유지하면서 피해 행동을 스크립트, Makefile, 스크립트 체인, 컴파일된 바이너리의 네 가지 은닉 수준으로 포장해 102개 위험 과제를 만들었고, 각 위험 과제에는 파일과 요청, 명령이 같고 도구 코드만 무해한 안전 쌍둥이 과제가 있어 이를 차단하면 정의상 오탐이다. 비교 대상은 승인 없는 실행, 규칙 기반 CARE, 가드레일 모델 TS-Guard와 gpt-oss-safeguard-20b와 Qwen3Guard-Gen-8B, YoloFS, Claude Code Auto Mode의 여섯 시스템이다. 에이전트는 GLM-5.3-Flash, Caper 승인자와 Auto Mode 분류기는 gpt-5.6-luna를 썼다. 결과는 SABER에서 유해 결과율 6.7%로 기존 시스템의 14.8~21.2%(승인 없음은 19.7%)보다 낮았고, YoloFS-Ext에서는 Caper 7.8%, Claude Code 훅으로 구현한 Caper 6.9%로 기존 시스템의 35.3~94.1%를 크게 앞섰다. 동시에 안전 쌍둥이 과제는 1.0%만 차단했고, SABER의 안전 결과율은 승인 없는 실행과 같은 수준을 유지했다. 같은 Claude Code 환경에서 내장 분류기를 Caper 훅으로 교체하면 유해율이 SABER에서 14.8%에서 10.0%로, YoloFS-Ext에서 62.7%에서 6.9%로 떨어졌다.

전제와 한계

분석의 핵심은 텍스트 기반 승인자가 엄격해서가 아니라 볼 수 없어서 실패한다는 것이다. 증거 없이 대화 맥락을 늘리면 SABER 유해율은 명령만 볼 때 44.1%에서 전체 대화를 볼 때 17.6%로 줄지만, 쌍둥이 오탐은 52.0%에서 61.8%로 늘어난다. 증거를 주면 명령만으로도 유해율 1.0%, 오탐 0%가 나온다. 같은 모델이 효과를 예측하게 하면 유해율은 관측과 비슷하게 떨어지지만 쌍둥이의 61.8%를 여전히 차단한다. 내용 diff를 빼면 유해율이 7.8%에서 13.7%로 오른다. 은닉 수준별로는 증거가 없을 때 바이너리 4.2%에서 Makefile이나 스크립트 체인 26.9%까지 편차가 크지만, 증거가 있으면 모든 수준에서 4~15%로 유지된다. 또 YoloFS는 같은 파일 변화를 관찰하지만 명령이 실행된 뒤 에이전트에게 보여주고 판단을 맡기는데, 에이전트는 102개 위험 실행 중 66개에서 되돌렸고 되돌리지 않은 36개 중 33개가 피해로 끝나 35.3%의 피해를 남겼다. 실행 후 되돌리기는 과제 성공률도 깎아 안전 완료가 22.5%에 그쳤고, Caper는 60.8%였다. 저자들은 되돌리기가 승인 없는 실행보다 더 많은 피해를 남기는 경우(21.2% 대 19.7%)도 있다고 지적한다. 한 번 흘러나간 자격 증명은 회수할 수 없기 때문이다.

오버헤드는 실무적으로 감당 가능한 수준으로 보고된다. SABER에서 효과 보고서 중앙값은 0.9KB(95백분위 2.6KB)로 원시 트레이스 62.5KB보다 99.4% 작다. 승인 지연 중앙값은 3.2초(95백분위 6.4초)로, 증거 없이 같은 승인자를 돌린 3.3초(11.4초)와 비슷하다. 샌드박스 비용은 허용된 명령당 약 0.5초, 차단된 명령당 1.5초이고, API 비용은 과제당 0.019달러로 증거 없을 때의 0.017달러와 큰 차이가 없다.

개발자 입장에서 이 논문은 셸 명령을 자유롭게 실행하는 자동화 파이프라인이나 사내 에이전트에 곧바로 적용할 만한 설계도를 준다. 다만 도입 전에 확인해야 할 것은 세 가지다. 첫째, 사전 실행이 실제 실행이라는 점이다. 컨테이너 네트워크를 반드시 차단하거나 응답을 기록하는 프록시로 우회시켜야 하고, 그래야 롤백 트랜잭션이 성립한다. 둘째, 보고서의 커버리지와 불확실성 표시를 승인 정책에 어떻게 반영할지다. 관측되지 않았다는 사실은 안전의 증거가 아니다. 셋째, 안전 쌍둥이 오탐률과 지연을 자체 워크로드에서 측정해야 한다. 논문은 오탐 1.0%를 보고하지만 이는 저자들이 통제해 만든 벤치마크 기준이다.

저자들이 밝힌 한계도 분명하다. 사전 실행은 실제 실행이므로 컨테이너 밖으로 나가는 효과, 즉 네트워크 요청이나 원격 서비스 쓰기, 명령이 띄운 프로세스는 승인 판단 전에 이미 일어나고 롤백으로 되돌릴 수 없다. 또한 Caper는 셸 명령만 게이트한다. 파일 편집은 호출 자체에 변경이 적혀 있어 하네스에 맡기며, 그 자체로 피해를 주는 편집은 호출 텍스트만으로 판단된다. 보고서는 샌드박스에서의 한 번의 실행을 기술하므로 시간이나 난수, 환경에 따라 동작이 달라지는 도구는 다시 실행할 때 다르게 행동할 수 있고, 샌드박스를 감지하거나 피해를 지연시키거나 여러 명령에 피해를 쪼개는 적응형 공격은 두 벤치마크에 포함되지 않아 향후 과제로 남겨졌다. 승인 판단을 LLM이 한다는 점도 실행마다 판단이 흔들리거나 보고서를 오독할 수 있다는 한계다. 비교 대상도 Claude Code Auto Mode로 제한되는데, OpenAI Codex의 자동 리뷰어는 기본 샌드박스에서 워크스페이스를 벗어나는 요청만 검토하므로 이 벤치마크의 피해 대부분이 검토 대상에 도달하지 않는다. 저자들은 Caper가 피해를 없애는 것이 아니라 줄이는 방어이므로, 고위험 작업에는 샌드박싱과 사람 검토를 함께 써야 한다고 명시한다.