도구는 권한이다
이 장에서 배우는 것 도구를 붙이기 전에 확인해야 할 네 가지, 그리고 조직에서 권한을 어떻게 나누는지.
관점을 바꿔야 합니다
지금까지 도구를 "할 수 있는 일이 늘어나는 것"으로 봤습니다. 보안 관점에서는 같은 일이 이렇게 보입니다.
도구를 붙이는 것은 에이전트에게 권한을 주는 일입니다.
파일삭제 도구를 붙였다면, 에이전트는 파일을 지울 수 있는 권한을 가진 것입니다.
그 권한이 언제 쓰일지는 모델의 판단에 달려 있습니다.
붙이기 전 네 가지 질문
1. 이 서버가 닿는 범위는 어디까지인가
대개 붙일 때 발급하는 토큰의 권한이 그 답입니다. 토큰을 만들 때 권한을 좁게 주면 서버가 할 수 있는 일도 좁아집니다.
최소 권한 원칙: 지금 필요한 것만 주고, 나중에 필요하면 넓힙니다. 넓게 주고 좁히는 건 잘 안 일어납니다.
2. 되돌릴 수 없는 동작이 있는가
이게 가장 중요한 구분입니다.
| 성격 | 예 | 대응 |
|---|---|---|
| 읽기 | 조회, 검색, 계산 | 대체로 안전 |
| 되돌릴 수 있는 쓰기 | 임시 파일 생성, 초안 저장 | 로그만 남기면 됨 |
| 되돌릴 수 없음 | 메일 발송, 결제, 삭제, 대외 게시, db_update·db_delete | 사람 승인 |
"보낸 메일은 취소할 수 없습니다." 이 한 줄이 승인 지점을 정하는 기준입니다.
3. 그 동작에 사람 승인을 끼울 수 있는가
도구 사용에서 본 대로, 실행은 시스템이 합니다. 모델은 요청만 합니다. 그래서 그 사이에 승인을 넣을 수 있습니다.
graph TD
A["모델: 메일발송 호출 요청"] --> B{"되돌릴 수 없는 동작?"}
B -->|"아니오"| C["바로 실행"]
B -->|"예"| D["사람에게 확인 요청"]
D -->|"승인"| C
D -->|"거부"| E["실행 안 함"]승인 지점이 없는 시스템이라면 되돌릴 수 없는 도구는 붙이지 않는 게 맞습니다.
4. 자격증명은 어디에 두는가
그리고 키가 노출됐을 때 무엇을 해야 하는지를 미리 정해두세요. 대개 "새로 발급하고 옛것을 폐기"인데, 그 절차를 아는 사람이 있어야 합니다.
조직에서 권한 나누기
한 워크스페이스의 모든 사람이 같은 도구를 쓸 필요는 없습니다.
| 구분 기준 | 예 |
|---|---|
| 팀별 | 영업팀은 CRM 도구, 개발팀은 저장소 도구 |
| 역할별 | 관리자만 쓰기 도구, 나머지는 읽기만 |
| 환경별 | 운영 시스템 도구는 특정 워크스페이스에만 |
Connect에서 워크스페이스별로 도구를 켜고 끄고, 멤버 역할을 나누는 이유가 이것입니다.
권한은 사람이 아니라 묶음에 주세요. 개인마다 손대기 시작하면 나중에 아무도 현재 상태를 설명하지 못합니다.
주의할 시나리오
남이 만든 MCP 서버를 붙일 때
편리하지만 그 서버가 무엇을 하는지 확인해야 합니다. 공식 제공자가 만든 것인지, 어떤 권한을 요구하는지 봅니다. 특히 사내 데이터에 닿는 서버라면 더 그렇습니다.
그리고 한 가지가 더 있습니다. 도구 목록은 우리가 적는 게 아니라 서버가 알려줍니다. 연결할 때 "이 서버에는 이런 도구들이 있고 각각은 이런 일을 합니다"를 서버가 보내주고, 모델은 그 설명을 읽고 무엇을 부를지 정합니다. 즉 도구 설명은 모델에게 가는 지시문입니다 (읽은 것이 명령이 될 때와 같은 성질입니다).
여기서 나오는 결론이 불편합니다.
서버 쪽이 도구 설명을 바꾸면, 우리 쪽은 아무것도 안 바꿔도 동작이 바뀝니다.
처음 붙일 때 검토한 그 서버가 다음 달 같은 주소에서 다른 도구를 알려줄 수 있습니다. 우리 설정에는 주소 한 줄뿐이라 화면상 달라진 것이 없습니다.
붙이기 전에 이 다섯 개를 적어두세요.
네 번째가 대개 비어 있습니다. 최소한 붙인 시점의 도구 목록(이름과 설명)을 적어두고 분기 점검 때 지금 것과 대조하세요 — 도구 권한 점검해보기의 1단계 표가 그 자리입니다.
조직 차원에서는 붙일 수 있는 서버를 목록으로 정해두는 것이 가장 단순한 통제입니다. 필요할 때마다 각자 새 서버를 붙이기 시작하면, 무엇이 붙어 있는지 아는 사람이 없어집니다.
에이전트가 도구를 조합할 때
각 도구는 안전한데 조합이 위험한 경우가 있습니다.
그래서 승인은 개별 도구가 아니라 "되돌릴 수 없는 동작"에 걸어야 합니다. 메일발송에 승인이 걸려 있으면 이 조합도 막힙니다.
자주 하는 오해
"읽기 도구는 다 안전한가?"
읽는 대상에 따라 다릅니다. 인사 정보나 고객 개인정보를 읽는 도구는 읽기라도 민감합니다. "되돌릴 수 있는가"와 "봐도 되는가"는 다른 질문입니다.
"보안 때문에 도구를 안 붙이는 게 낫나?"
그러면 환각이 늘고 답의 근거가 없어집니다. 읽기 도구부터 붙이고 쓰기는 승인과 함께 붙이는 순서가 실무적입니다. 아무것도 안 붙이는 것이 안전한 선택은 아닙니다.
확인
1. 승인 지점을 정하는 한 줄 기준은 무엇입니까?
답
"되돌릴 수 있는가"입니다. 보낸 메일, 실행된 결제, 삭제된 데이터는 취소할 수 없으므로 그 앞에 사람을 세웁니다.
2. 각 도구는 안전한데 조합이 위험할 수 있는 예를 들어보세요.
답
파일읽기 + 메일발송이면 사내 문서를 읽어 외부로 보내는 경로가 생깁니다.
그래서 승인은 개별 도구가 아니라 "되돌릴 수 없는 동작"에 걸어야 합니다.
3. 최소 권한 원칙을 도구에 적용하면?
답
토큰을 만들 때 지금 필요한 권한만 주는 것입니다. 넓게 주고 나중에 좁히는 건 실제로 잘 일어나지 않으므로, 좁게 시작해서 필요할 때 넓힙니다.
이제 우리 워크스페이스에 실제로 적용해봅니다. 30분짜리 점검입니다 → 도구 권한 점검해보기