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