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