MCP 서버 권한 설계는 단어 뜻만 알고 넘어가면 실제 판단에서 자주 흔들리는 주제입니다. 이 글은 개념보다 먼저 실무에서 어디를 봐야 하는지부터 정리합니다.
핵심은 AI 에이전트가 MCP 도구를 호출할 때 읽기와 쓰기, 승인과 감사 로그 기준을 나누는 것입니다. 그래서 단순 요약이 아니라 선택 기준, 실패 신호, 점검 순서를 함께 보겠습니다.
MCP 서버 권한 설계 판단 흐름
MCP 서버 권한 설계가 중요한 이유
MCP 서버 권한 설계는 AI 에이전트에게 도구를 많이 붙이는 작업이 아닙니다. 모델이 어떤 도구를 언제, 어떤 범위로, 누구의 승인 아래 호출할 수 있는지 정하는 운영 설계입니다.
핵심은 도구를 붙이기 전에 도구가 실패했을 때의 피해 범위를 먼저 나누는 것입니다.
읽기 도구도 안전하다고 단정하면 안 된다
read-only 도구는 데이터를 바꾸지 않기 때문에 안전해 보입니다. 하지만 고객 정보, 내부 문서, API 응답, 로그 파일을 읽을 수 있다면 그 자체가 민감한 권한입니다.
- 검색 범위가 너무 넓지 않은가
- 개인정보나 비밀 값이 그대로 반환되지 않는가
- 모델이 읽은 내용을 외부 응답에 그대로 노출할 수 있는가
- 도구 결과에 prompt injection 문장이 들어올 수 있는가
쓰기 도구는 위험도별로 나눈다
쓰기 도구라고 모두 같은 수준은 아닙니다. 로컬 임시 파일 생성, draft 수정, 이메일 전송, 결제 실행, 공개 publish는 위험도가 다릅니다. 도구 이름만 보고 허용하지 말고 결과의 되돌림 가능성을 함께 봐야 합니다.
- low risk: 임시 파일 생성, 로컬 미리보기
- medium risk: draft 수정, 내부 상태 업데이트
- high risk: 공개 발행, 외부 전송, 결제, 계정 설정 변경
- blocked by default: 비밀 값 조회, 권한 상승, 대량 삭제
도구 스키마는 권한 설계의 일부다
MCP 도구는 입력 스키마를 노출합니다. 이때 스키마가 너무 자유로우면 모델이 예상하지 못한 값을 넣기 쉽습니다. path, SQL, shell command처럼 위험한 입력은 특히 좁혀야 합니다.
{
"name": "update_draft",
"inputSchema": {
"type": "object",
"properties": {
"post_id": { "type": "integer" },
"content_package_id": { "type": "string" }
},
"required": ["post_id", "content_package_id"]
}
}자유로운 command 문자열보다 검증 가능한 식별자와 enum을 쓰는 편이 안전합니다.
승인 단계는 UX가 아니라 안전장치다
AI 에이전트가 실제 행동을 할 때는 사용자 승인 단계가 필요합니다. 특히 공개 발행, 외부 전송, 결제, 삭제처럼 되돌리기 어려운 작업은 자동 실행 대상으로 두면 안 됩니다.
승인 요청에는 도구 이름만 쓰면 부족합니다. 무엇을 바꾸는지, 대상은 무엇인지, 되돌릴 수 있는지, 실행 후 외부에 노출되는지를 함께 보여줘야 합니다.
감사 로그를 남겨야 나중에 고칠 수 있다
권한 설계는 한 번에 완벽하게 끝나지 않습니다. 어떤 도구가 자주 거부되는지, 어떤 입력에서 실패하는지, 승인된 작업이 실제로 문제를 만들었는지 로그로 남겨야 개선할 수 있습니다.
- user_id 또는 actor 식별자
- tool name과 tool_call_id
- 입력 요약과 민감정보 마스킹 여부
- 승인 여부와 승인 문구
- 실행 결과와 오류 유형
실무 체크리스트
- 도구를 read/write/high risk로 분류했다
- 도구별 입력 스키마를 좁혔다
- 민감 작업은 사용자 승인 없이는 실행되지 않는다
- 도구 결과를 신뢰하지 않고 후속 검증을 둔다
- 승인과 실행 결과를 audit log로 남긴다
검색 의도별로 읽는 법
- MCP를 처음 붙인다면 도구 목록과 위험도 분류부터 봅니다.
- 보안이 걱정된다면 읽기 도구의 민감정보 노출과 prompt injection 가능성을 먼저 점검합니다.
- 운영 자동화를 한다면 승인 단계와 audit log 기준을 먼저 설계합니다.
자주 묻는 질문
MCP 서버에 read-only 도구만 있으면 안전한가요?
아닙니다. 읽기 도구도 민감한 데이터를 반환하거나 prompt injection이 포함된 문서를 가져올 수 있습니다.
모든 write 도구에 매번 승인을 받아야 하나요?
위험도에 따라 다릅니다. 임시 파일 생성처럼 낮은 위험은 자동화할 수 있지만 공개 발행, 삭제, 외부 전송은 명시 승인이 필요합니다.
권한 설계는 클라이언트에서 하나요, 서버에서 하나요?
둘 다 필요합니다. 서버는 도구와 입력 범위를 좁히고, 클라이언트와 운영 정책은 승인과 표시 방식을 담당해야 합니다.
마지막 점검 체크리스트
- 도구별 최소 권한이 정의되어 있는가
- read-only 도구의 데이터 노출 범위를 제한했는가
- high risk 작업에 명시 승인 단계가 있는가
- 도구 입력이 자유 문자열로 과하게 열려 있지 않은가
- 나중에 문제를 추적할 audit log가 남는가
정리
MCP 서버 권한 설계를 제대로 보려면 하나의 정답을 외우기보다 글에서 정리한 기준을 실제 상황에 대입해야 합니다. 핵심은 AI 에이전트가 MCP 도구를 호출할 때 읽기와 쓰기, 승인과 감사 로그 기준을 나누는 것입니다.
관련 글로는 MCP란 무엇인가, MCP 보안은 왜 중요할까, AI 에이전트 로그 설계을 함께 보면 좋습니다. 외부 기준은 Model Context Protocol specification, MCP authorization specification, MCP tools specification을 확인했습니다.
