#Agent 월권 경계 — 안전 샌드박스는 무엇을 가두는가

← 전체 목차 · 이전: 사용자가 중간에 목표를 바꾸면 이전 단계는 어떻게 폐기 판정하는가 · 다음: 전자상거래 Agent는 어떻게 가격을 약속해야 틀리지 않는가

"도구 호출 성공"은 실행 환경이 안전하다는 증명이 전혀 되지 못한다. 평범해 보이는 의존성 설치 명령 한 줄이 뒤에서는 로컬 키를 읽고, 프로젝트 밖 파일을 수정하고, 랜선을 타고 사내망에 침투하고 있을 수 있다.

그래서 샌드박스의 정의를 다시 세워야 한다. 샌드박스는 대규모 모델이 실수하는 것을 막기 위한 것이 아니다. 모델은 언젠가는 실수한다. 샌드박스의 진짜 목적은 백스톱이며, 실수한 뒤에 파괴할 수 있는 범위를 제한하는 것이다 — 손오공에게 원을 그려주는 것과 같다.

#개막의 사례: 설치 명령 한 줄이 할 수 있는 일

#샌드박스의 위치: 실수 방지가 아니라 백스톱

오해:  샌드박스 = 모델이 실수하지 않게 만든다
교정:  모델은 언젠가 실수한다 → 샌드박스는 「실수 여부」를 관리할 수 없다
정의:  샌드박스 = 백스톱
목표:  실수한 뒤 「파괴할 수 있는 범위」를 제한한다

#기본 경계 4종

#1. 파일 시스템 — 마운트만, 개방은 안 된다

원칙은 최소 마운트다. 디스크 전체를 열어주지 말고, 작업에 필요한 디렉터리만 그때그때 마운트한다.

#2. 네트워크 — 기본 차단, 화이트리스트로 허용

#3. 시스템 프로세스 — 반드시 제한할 4개 수치

1. CPU 점유율
2. 메모리 사용량
3. 최대 실행 시간 (타임아웃 상한)
4. 생성 가능한 자식 프로세스 수 (fork 상한)

목적은 명확하다 — 폭주해서 시스템 자원을 고갈시키는 것을 방지한다.

#4. 자격증명 — 작업 단위 임시 주입, 로그에 평문 없음

요구 1 (어떻게 줄 것인가): 작업 단위로 「임시 주입」
   → 환경에 장기 상주시키지 않고, 한 번 쓸 때 한 번 준다
요구 2 (어떻게 유출을 막을 것인가): 로그 마스킹
   → Agent가 실행 로그를 전부 출력하더라도
   → 이 자격증명들의 평문은 절대 보이지 않는다

두 조건이 동시에 성립해야 합격이다. 임시 주입만 하고 로그 마스킹을 하지 않으면 자격증명이 stdout으로 새어 나가고, 로그 마스킹만 하고 임시 주입을 하지 않으면 자격증명이 환경에 장기 상주하다가 읽혀 나간다.

#경계는 유형별로 갈라진다: 코드 Agent vs 브라우저 Agent

핵심 판단: 브라우저 Agent의 리스크는 코드 Agent 리스크의 부분집합이 아니라, 기본 권한 위에 "사람의 신분으로 행동하는" 리스크가 한 겹 더 얹힌 것이다.

#고위험 동작의 정의와 사람 확인 관문

판정 기준은 이 단계가 당신을 대신해 외부로 향하는, 되돌릴 수 없는 결과를 만들어내는가이다.

1. 구매 결제 클릭
2. 소셜 미디어에 콘텐츠 게시
3. 중요 메일 발송
4. 계정 비밀번호 변경

불허:  Agent가 독단으로 처리
필수:  확인 창을 띄운다
       ├─ 사용자가 직접 확인
       ├─ 「최종적으로 제출할 파라미터가 정확히 무엇인지」를 명확히 보여준다
       └─ 사용자가 승인해야만 통과

여기서 요점은 "확인 창이 있다"가 아니라 확인 창이 최종 파라미터를 반드시 노출해야 한다는 것이다. 그렇지 않으면 사용자가 누르는 것은 블랙박스다.

#일회용 환경과 상태 스냅샷 — 열람 후 소각

이 설계의 정수는 Agent의 산출물이 "이미 반영된 현장 변경"이 아니라 "검토 가능한 차이"의 형태로 샌드박스를 떠난다는 데 있다.

#핵심 통찰

1. "도구 호출 성공"은 도구에 관한 판단이지 환경에 관한 판단이 아니다 — 반환 코드는 이 단계에서 에러가 나지 않았다는 것만 알려줄 뿐, "이 단계가 무엇을 읽고 무엇을 쓰고 어디에 접속했는지"는 포함하지 않는다. 성공 회신을 안전 증명으로 여기는 것이 Agent 엔지니어링에서 가장 저지르기 쉬운 착오다.
2. 샌드박스의 KPI는 "모델이 덜 실수하는 것"이 아니라 "실수한 뒤의 폭발 반경"이다 — 모델은 언젠가 실수하므로, 프롬프트를 조이거나 정렬을 강화해 오류를 없애려는 모든 노선은 샌드박스를 대체할 수 없다. 하나는 확률을 낮추고 하나는 손실에 상한을 씌우는, 책임이 겹치지 않는 두 가지다.
3. 권한의 기본값이 시스템의 안전 하한선을 결정한다 — 네트워크는 "기본 차단, 필요하면 화이트리스트", 파일은 "기본 미지급, 작업 단위 마운트". 실제로 작동하는 것은 화이트리스트 자체가 아니라 기본 거부라는 방향이다. 기본 허용 후 하나씩 차단하는 방식으로는 영원히 다 막지 못한다.
4. 자격증명 보안은 "주입"과 "유출" 두 경로를 동시에 덮어야 한다 — 임시 주입만 하고 로그 마스킹을 하지 않으면 stdout으로 새고, 로그 마스킹만 하고 임시 주입을 하지 않으면 환경에 장기 상주하다가 읽혀 나간다. 하나만 하는 것은 안 한 것과 같다.
5. Agent의 리스크 경계는 지능 수준이 아니라 행동 매개체가 결정한다 — 코드 Agent는 시스템 하부에서 활동하므로 리스크 면이 파일·명령·패키지·네트워크다. 브라우저 Agent는 웹에서 "사람을 흉내" 내므로 로그인 상태, 클립보드, 다운로드물 같은 사람의 신분에 전속된 리스크 면이 추가된다. 매개체가 바뀌면 경계 세트를 갈아야지 재사용하면 안 된다.
6. 사람 확인의 가치는 전부 "파라미터 가시성"에 있다 — "계속하시겠습니까?"만 적힌 확인 창은 책임을 사용자에게 넘기면서 판단 근거는 주지 않는다. 최종 제출 파라미터를 보여주는 것은 본질적으로 되돌릴 수 없는 동작 앞에서 블랙박스를 여는 요구다.
7. 산출물은 기성사실이 아니라 차이(diff/산출물)의 형태로 샌드박스를 떠나야 한다 — "코드 비교 / 패키징 산출물" 설계는 "Agent가 무엇을 했는가"를 보이지 않는 현장 변경에서 한 줄씩 검토 가능한 대상으로 바꾼다. 이것이 일회용 환경의 진짜 지렛대이며 단순히 "돌리고 나서 지우기"가 아니다.
8. Agent 시나리오에서 제로 트러스트의 구체적 형태는 "관측 가능 + 회수 가능"이지 "선(先)검증 후 통과"가 아니다 — 안전 공간의 세 속성은 경계가 명확할 것, 언제든 볼 수 있을 것, 언제든 권한을 회수할 수 있을 것이다. 뒤의 두 개는 런타임 능력이며, 인가 시점의 심사만으로는 장시간 작업을 덮을 수 없어 중도 정지 수단이 반드시 있어야 한다.

#엔지니어링 실전 Tips

• 샌드박스에게 프롬프트의 책임을 지우지도, 프롬프트에게 샌드박스의 책임을 지우지도 말 것: 모델은 언젠가 실수한다는 것이 전제이므로 제약은 환경 계층에 있어야지 "키를 읽지 마"를 시스템 프롬프트에 쓰는 것으로 해결되지 않는다.
• 마운트 디렉터리는 프로젝트 단위가 아니라 작업 단위로: 같은 리포지토리라도 작업마다 가시 범위가 다를 수 있다. 리포지토리 전체를 한 번에 주는 것보다 훨씬 엄격하다.
• 화이트리스트는 도메인 입도까지: "출망 허용"만 쓰는 것은 안 쓴 것과 같다. api.github.com, npm.pkg.org 수준까지 내려가야 구속력이 생긴다.
• 자식 프로세스 수는 가장 놓치기 쉬운 쿼터: CPU·메모리·타임아웃은 기본 3종 세트지만, 폭주하는 fork 루프는 이 셋이 상한에 닿지 않은 채로 시스템을 마비시킬 수 있다.
• "로그 전체 출력"을 자격증명 마스킹의 인수 케이스로 쓸 것: 코드에 로그를 남기는지 심사하는 것이 아니라, 로그를 전부 출력해 평문이 있는지 직접 보는 방식이다.
• 확인 창은 "의도"가 아니라 "파라미터"를 심사할 것: 사고는 대개 파라미터 안의 금액, 수신자, 대상 계정에서 난다.
• "Agent가 실제 환경에 영구히 사는 것"을 명확한 레드라인으로: 임시 컨테이너를 다 돌리고 파기하지 않으면 당신의 모든 권한을 가진 장기 상주 프로세스와 같다. 파기 동작은 사람이 기억해서 청소하는 것이 아니라 작업 마무리 절차에 넣어야 한다.