하네스가 승인을 맡고 샌드박스가 실행을 막는다
에이전트 하네스는 모델 호출과 도구 라우팅, 승인 판단을 맡는 제어 평면이고, 샌드박스는 파일·명령·네트워크 접근을 OS 수준에서 막는 실행 평면입니다. 이 구분이 코드에 없으면 승인 로직과 격리 로직이 뒤섞여, 권한 하나를 바꿀 때마다 실행 환경까지 손대야 합니다. 개인용 에이전트 하네스 설계 사례인 SemaClaw는 내부 도구(메모리 조회, 작업공간 관리)는 사전 승인 상태로 두고 외부 도구(결제, 발신, 외부 API)만 호출마다 사용자 확인을 받는 2단계 정책으로 이 분리를 구현합니다.
승인 피로, 안전장치가 조용히 무력화되는 지점
사람이 매번 검토하도록 설계해도 그 검토는 오래가지 못합니다. 확인창이 반복되면 사용자는 내용을 읽지 않고 허용 버튼을 누르는 쪽으로 기운다는 패턴이 현장에서 되풀이 관찰되며, 이 지점에서는 승인창이 떠 있어도 실질적인 사람 개입은 0에 가까워집니다. 세션마다 다시 묻는 대신 '항상 허용' 규칙을 디스크에 저장해 재부팅 후에도 유지하는 방식은 피로를 줄이지만, 규칙을 만든 당시의 맥락이 사라진 뒤에도 그대로 살아남는 대가를 치릅니다.
스키마 게이팅, 도구를 아예 안 보여주는 방어
런타임 권한 검사보다 강한 방어는 애초에 도구를 스키마에서 빼는 것입니다. 호출 가능한 도구 목록에 없는 기능은 우회를 시도할 대상 자체가 없으므로, 계산기라고 선언한 도구가 실제로는 네트워크 접근 권한을 가져오는 식의 선언-동작 불일치를 배포 전에 걸러내는 편이 승인 대화상자를 하나 더 넣는 것보다 견고합니다.
설계에서 운영까지: 하네스 권한·샌드박스 게이팅 체크리스트
목표 수치는 설계 전에 못박아 둡니다. 세션당 사람 확인 요청 건수를 샌드박스 자동 승인 도입 전 대비 80% 이상 줄이는 것을 1차 목표로 삼고(참고 사례에서는 84% 감소), 도구 스키마당 요구 권한 항목은 실제 사용 항목과 일치율 100%를 기준으로 둡니다. '항상 허용' 규칙의 최대 유효기간(예: 30일)도 이 시점에 정합니다.
실패는 네 갈래로 반복됩니다. 첫째, 도구 스키마가 필요 권한보다 넓게 선언돼 계산기 도구가 네트워크 접근까지 가져가는 선언-동작 불일치. 둘째, 확인창이 세션당 두 자릿수로 반복돼 내용을 읽지 않고 허용을 누르는 승인 피로. 셋째, '항상 허용' 규칙이 프로젝트 성격이 바뀐 뒤에도 남아 예전 권한이 새 작업에 그대로 적용되는 만료 누락. 넷째, 내부·외부 도구를 같은 승인 레벨로 묶어 조회성 호출까지 매번 승인을 요구하다 정작 위험한 외부 호출의 피로를 키우는 계층 미분리입니다.
복구는 승인 요청 자체를 줄이는 방향으로 설계합니다. 도구 선언 시점에 정책 엔진이 capability 선언과 실제 import·호출을 대조해 불일치를 배포 전에 차단하고, 승인 피로가 임계치(세션당 확인 10회 초과 등)를 넘으면 해당 세션을 자동으로 더 엄격한 샌드박스 격리 레벨로 전환해 사람 승인 없이도 안전 여백을 확보합니다. '항상 허용' 규칙은 만료 없는 저장을 금지하고 갱신 주기를 강제합니다.
운영 체크리스트는 기본값 거부(default-deny) 스키마에서 출발합니다. 내부 도구는 사전 승인, 외부 도구는 호출마다 확인이라는 2단계 승인 레벨을 코드로 고정하고, 샌드박스 격리 수준은 격리 없음부터 gVisor·마이크로VM·WASM까지 위험도에 맞춘 선택 기준표로 문서화합니다. 배포 전 테스트에는 계산기 도구에 네트워크 권한을 몰래 얹는 선언-동작 불일치 케이스를 반드시 포함합니다. 감사 로그에는 도구명, 요청 파라미터, 승인 주체(사람·자동 정책), 격리 레벨, 승인까지 걸린 지연을 필드로 남겨 사고 후 재구성이 가능하게 합니다.
지속 개선은 주간 단위로 승인 로그를 모아 '항상 허용' 규칙 중 30일 넘게 갱신되지 않은 항목을 자동 만료시키고, 선언-동작 불일치가 재발한 도구는 다음 릴리스에서 스키마 자체를 축소합니다. 승인 프롬프트 감소율이 정체된다면 자동화가 아니라 사람 개입 총량만 옮겨간 것일 수 있으므로, 세션당 확인 횟수와 격리 레벨 상향 빈도를 함께 추적합니다.
한눈에 보는 적용 포인트
승인 피로는 검토를 늘려서가 아니라 검토 자체를 줄여서 해결됩니다. 도구 스키마를 기본값 거부로 좁히고, 내부·외부 도구를 2단계 승인으로 분리하며, 격리 수준 선택 기준과 '항상 허용' 규칙의 만료 정책을 감사 로그와 함께 문서화하면 승인창을 하나 더 띄우는 것보다 견고한 하네스가 됩니다.