대모델 도구 권한은 등급을 나눠야 한다
도구 권한은 동작의 리스크에 따라 등급을 나눠야지 단순한 온오프 스위치가 아니다.
- 동작 리스크에 따라 4등급으로(자동 실행 / 사용자 확인 / 관리자 승인 / 호출 금지)
- 같은 도구라도 파라미터가 다르면 리스크가 다르므로, 권한은 도구 이름에만 바인딩할 수 없고 파라미터와 컨텍스트도 봐야 한다
읽기·쓰기 유형에 따른 리스크 구간 구분
- 낮음: 읽기 전용 도구(재고 조회, 문서 읽기, 지식베이스 검색)
- 높음: 쓰기 조작(설정 변경, 알림 발송)
- 최고: 자금, 프라이버시, 외부 공개가 관련된 조작(주문 제출, 데이터 삭제)
4단계 권한 설계
| 등급 | 처리 방식 | 부제 |
|---|
| 1류 | 자동 실행 | 저위험 일반 조작 |
| 2류 | 실행 전 사용자에게 확인 요청 | 실행 전 확인 프롬프트 |
| 3류 | 관리자 승인 필요 | 고위험 민감 조작 |
| 4류 | 모델의 직접 호출 금지 | 모델에게 직접 조작 권한 없음 |
파라미터 단위 권한
| 도구 | 저위험 파라미터 | 고위험 파라미터 |
|---|
| 메시지 발송 | 자기 자신에게 발송 | 전사 그룹에 발송 |
| 고객 조회 | 단건 레코드 조회 | 일괄 내보내기 |
권한은 도구 이름에만 바인딩할 수 없고 파라미터와 컨텍스트도 봐야 한다.
정리
대모델 도구 권한은 읽기·쓰기 유형, 영향 범위, 파라미터 내용, 업무 리스크에 따라 등급을 나눠야 한다. 저위험 동작은 자동 실행하되, 고위험 동작은 반드시 확인이나 승인을 거쳐야 한다.
핵심 통찰
- 「보안 리스크가 있다」는 맞지만 정보량이 없는 답이다 — 어떤 문제에도 갖다 붙일 수 있는 답은 답을 안 한 것과 같다. 「날씨 조회 vs 데이터 삭제」라는 자릿수 차이로 추상적 리스크를 구체화하는 처리 방식은 배울 만하다.
- 권한의 입도는 시스템 구현의 편의가 아니라 동작의 리스크 분포에 맞춰야 한다 — 이진 스위치가 유행하는 이유는 구현하기 쉽기 때문이지만, 리스크는 연속 스펙트럼이다. 이진 스위치로 연속 스펙트럼을 자르면 필연적으로 너무 느슨하거나 너무 빡빡해진다.
- 파라미터 단위 권한이 이 문제의 분수령이다 — 대부분은 「도구별 등급화」까지만 답하는데, 「같은 메시지 발송 도구라도 자기에게 보내는 것과 전사 그룹에 보내는 것은 리스크가 완전히 다르다」는 지적이 권한 모델을
tool → permission에서 (tool, params, context) → permission으로 밀어 올린다.
- 「영향 범위」가 「읽기·쓰기 유형」보다 본질적인 리스크 차원이다 — 단건 조회와 일괄 내보내기는 둘 다 읽기 조작이지만 후자는 데이터 유출 사고다. 읽기·쓰기는 첫 번째 체에 불과하고, 범위(1건 vs 전량)가 자릿수를 결정한다.
- 4단계 설계의 본질은 「누가 최종 책임을 지는가」에 대한 네 가지 답이다 — 자동 실행(시스템이 책임) → 사용자 확인(사용자가 책임) → 관리자 승인(조직이 책임) → 호출 금지(어떤 책임 부담도 수용하지 않음). 이 관점으로 등급을 나누는 것이 「위험해 보이는 정도」로 나누는 것보다 훨씬 안정적이다.
- 효율과 안전은 취사선택이 아니라 계층화다 — 「일반적인 효율에도 영향을 주지 않고 고위험 동작도 막는다」가 성립하는 전제는 절대다수의 호출이 저위험 구간에 떨어진다는 것이다. 등급화 설계의 경제성은 바로 이 롱테일 분포에서 나온다.
- 4류 「모델의 직접 호출 금지」는 필요한 폴백 등급이다 — 어떤 동작은 아무리 확인을 많이 받아도 모델이 발기하게 하면 안 된다. 권한 체계를 설계할 때 「애초에 노출하지 않는」 등급을 남겨두는 것이, 모든 도구를 승인 플로우에 밀어 넣는 것보다 안전하다.
엔지니어링 실전 Tips
- 권한 판정을 도구 구현 안에 하드코딩하지 말고 독립된 정책 계층으로 추출할 것. 그렇지 않으면 파라미터 단위 규칙이 곳곳에 흩어져 감사가 불가능해진다.
- 「일괄」류 파라미터(limit, export, all, 넓은 시간 창)는 권한 민감 파라미터로 설정하고 임계값을 넘으면 자동으로 등급을 올릴 것.
- 사용자 확인 화면에는 도구 이름이 아니라 실행될 구체적 파라미터를 표시할 것. 그렇지 않으면 확인이 형식적이 되어 사용자가 「동의」를 누를 때 전사 그룹에 보내진다는 걸 모른다.
- 관리자 승인 등급에는 비동기 대기 메커니즘이 함께 필요하다. Agent가 타임아웃 실패가 아니라 작업을 서스펜드할 수 있어야 하며, 이것이 4단계 설계에서 공학량이 가장 큰 등급이다.
- 4류 「호출 금지」의 가장 간편한 구현은 애초에 그 도구를 모델의 도구 목록에 넣지 않는 것이지, 넣어 놓고 거부하는 것이 아니다. 후자는 모델의 반복 시도와 우회를 유발한다.
- 등급 판정 결론을 감사 로그에 남길 것(이번 호출이 어떤 권한 등급에 명중했고 판정 근거가 무엇인지). 그렇지 않으면 사후에 왜 통과시켰는지 복기할 수 없다.
- 등급 지정은 일회성 작업이 아니다. 파라미터 추가나 영향 범위 확대로 오래된 도구가 등급을 넘어갈 수 있으므로, 등급 지정을 변경 리뷰 프로세스에 포함할 것을 권장한다.