Tool Safety Boundaries
이 문서는 CCAF Domain 2를 이해하기 위한 개념 설명용 노트다.
여기서는 도구 안전성을 단순한 권한 설정이 아니라, 어떤 capability를 어떤 조건 아래 노출할 것인가를 정하는 문제로 다룬다. 즉 tool safety를 단순한 분류 문제가 아니라, risk boundary와 exposure control 설계로 이해하는 데 초점을 둔다.
왜 safety boundary가 중요한가
도구는 에이전트에게 힘을 준다.
문제를 조회하고, 수정하고, 외부로 행동하게 만들 수 있다.
하지만 capability가 커질수록 risk surface도 커진다.
예를 들어:
- 읽기 전용 조회 도구
- 파일 수정 도구
- 결제/환불 같은 상태 변경 도구
- 이메일 발송, 외부 API 호출 같은 외부 행동 도구
는 위험 수준이 서로 다르다.
즉 안전한 도구 설계의 핵심은 모든 도구를 똑같이 취급하지 않는 것이다.
Capability는 편의의 문제가 아니라 위험 경계의 문제다.
safety boundary는 무엇을 정하는가
안전 경계는 단순히 “막을까 말까”만 정하는 것이 아니다.
실제로는 아래를 함께 정한다.
- 어떤 capability를 기본적으로 노출할지
- 어떤 도구는 어떤 조건에서만 보이게 할지
- 어떤 작업은 추가 승인이나 검증이 필요한지
- 어떤 위험 수준에는 어떤 통제 강도를 적용할지
즉 safety boundary는 실행 직전 차단 규칙만이 아니라,
capability exposure 전체를 설계하는 문제
다.
어떤 경계가 필요한가
가장 기본적인 구분은 아래처럼 볼 수 있다.
1. Read-only tools
정보를 조회하지만 상태를 바꾸지 않는다.
예:
- 검색
- 조회
- 파일 읽기
- 로그 확인
이들은 상대적으로 위험이 낮지만, 그래도 민감 정보 접근이라는 위험은 남는다.
2. Write / mutation tools
상태를 바꾸는 도구다.
예:
- 파일 수정
- DB 업데이트
- 설정 변경
이들은 잘못 쓰이면 즉시 손상이 생길 수 있다.
3. External action tools
시스템 밖으로 실제 행동을 일으킨다.
예:
- 이메일 발송
- 결제 실행
- 환불 처리
- 외부 서비스 호출
이들은 운영, 비용, 법적, 신뢰 측면에서 더 큰 리스크를 만든다.
즉 도구 경계는 기능 분류가 아니라,
부작용의 크기와 복구 비용 기준으로 나눌 필요가 있다.
least privilege는 왜 중요한가
모든 도구를 항상 다 열어두는 것은 편해 보인다.
하지만 그만큼 오용 가능성도 커진다.
least privilege의 핵심은:
- 필요한 도구만 주고
- 필요한 범위만 열고
- 불필요한 권한은 기본적으로 주지 않는 것
이다.
즉 좋은 도구 시스템은 “무엇까지 가능하게 할까”보다,
무엇을 기본적으로 불가능하게 둘까
를 더 중요하게 봐야 한다.
안전한 기본값은 무엇인가
보통 안전한 시스템은 기본적으로:
- 읽기 중심
- 제한적 capability exposure
- 외부 행동은 더 엄격한 통제
- 파괴적 작업은 명시적 승인 또는 별도 경로
를 가진다.
이건 모델을 못 믿어서가 아니라, 실수 비용이 비대칭적이기 때문이다.
읽기 실수는 보통 해석 문제로 끝날 수 있지만, 쓰기 실수나 외부 행동 실수는 실제 손해로 이어질 수 있다.
safety boundary는 selection 문제와 다르다
이 부분은 구분이 중요하다.
- Tool selection은 여러 도구 중 무엇을 더 명확하게 고르게 할 것인가의 문제다
- tool safety boundary는 어떤 capability를 아예 노출하지 않거나, 더 강한 조건 아래 노출할 것인가의 문제다
즉 둘 다 toolset을 다루지만,
- selection은 clarity 문제
- safety는 risk 문제
를 다룬다.
이 구분이 있어야 “헷갈리지 않게 도구를 잘 설명하는 것”과 “위험한 도구를 너무 쉽게 쓸 수 없게 만드는 것”을 섞지 않게 된다.
usability와 safety의 균형
너무 제한하면 시스템이 쓸모없어진다.
너무 열어두면 사고가 난다.
그래서 핵심은 단순 금지가 아니라, 위험 수준에 맞는 통제 강도를 적용하는 것이다.
예를 들면:
- 검색 도구는 넓게 허용
- 내부 고객 조회는 인증된 상황에서만 허용
- 환불/결제는 강한 검증과 승인 필요
- 외부 발송은 명시적 조건 충족 시에만 허용
이런 통제는 Hooks & Enforcement를 통해 런타임에서 자동 적용할 수도 있고, 위험 수준이 높으면 에스컬레이션으로 사람에게 넘기는 설계도 필요하다.
즉 모든 도구를 같은 세기로 통제하는 것이 아니라, 위험 비례적 통제가 중요하다.
흔한 오해
“도구를 많이 주면 에이전트가 더 유능해진다”
그렇지 않다. 위험한 capability exposure가 늘어날 수 있다.
“안전은 실행 직전에만 확인하면 된다”
아니다. 어떤 도구를 애초에 노출할지도 safety 설계의 일부다.
“read-only면 안전하다”
상대적으로 안전할 뿐이다. 민감 데이터 노출 위험은 여전히 있다.
한 문장 요약
Tool safety boundaries는 권한을 단순히 잠그는 작업이 아니라, 에이전트에게 어떤 capability를 어떤 조건과 위험 수준 아래 노출할지 설계하는 일이다.