#MCP 보안 권한 체크리스트
이 글은 교육용 보안 체크리스트입니다. 실제 고객 데이터, 실제 n8n/MCP 운영 사례, 침해 대응 결과, 보안 인증 상태를 주장하지 않습니다.
#바로 답변
MCP 보안 점검은 AI 앱이 외부 도구와 데이터에 접근하기 전에 “무엇을 읽고, 무엇을 실행하고, 누가 승인하고, 어떤 토큰을 쓰는지”를 확인하는 절차입니다. MCP는 AI 애플리케이션이 외부 시스템에 연결하는 공개 표준이므로, 편리함보다 권한 경계와 사용자 승인 흐름을 먼저 설계해야 합니다. 이 체크리스트는 보안 검토 출발점이며, 법무·보안 감사나 침투 테스트를 대체하지 않습니다.
#먼저 막아야 할 위험
| 위험 | 확인 질문 | 안전한 처리 |
|---|---|---|
| 과도한 도구 권한 | 서버가 읽기만 필요한데 쓰기·삭제 도구까지 노출하나요? | 최소 권한으로 줄이기 전에는 실제 계정에 연결하지 않습니다. |
| 불명확한 사용자 승인 | 도구 실행 전 사용자가 어떤 작업인지 이해하나요? | 승인 화면과 실행 로그를 설계합니다. |
| 토큰 전달 오해 | 클라이언트 토큰을 서버가 그대로 downstream API에 넘기나요? | 토큰 경계와 audience를 재설계합니다. |
| 로그 민감정보 | stdout, 서버 로그, 오류 메시지에 토큰·파일 경로·개인정보가 남나요? | 예시와 로그를 마스킹합니다. |
| 원격 서버 신뢰 | 서버 출처, 업데이트 경로, 권한 범위가 확인됐나요? | 출처와 권한 변경 이력을 검토합니다. |
#권한 설계 체크리스트
- 도구 목록을 “읽기, 쓰기, 삭제, 외부 전송”으로 분류합니다.
- 각 도구마다 필요한 입력값과 출력값을 적습니다.
- 기본값은 읽기 전용으로 두고, 쓰기 작업은 별도 승인 단계로 분리합니다.
- 삭제, 결제, 메일 발송, CRM 변경처럼 되돌리기 어려운 작업은 추가 확인을 둡니다.
- 도구 설명은 신뢰 가능한 서버에서 온 경우에도 검토 대상으로 둡니다.
- 사용자가 승인하지 않은 resource data를 다른 서버나 모델 호출로 보내지 않습니다.
- 테스트 계정과 샌드박스 데이터로 먼저 실행합니다.
#토큰과 비밀값 체크리스트
| 항목 | 안전한 기준 | 도입 전 확인할 질문 |
|---|---|---|
| 토큰 저장 | 환경변수 또는 비밀관리 시스템 사용 | 값 자체를 기록하지 않고 저장 위치만 문서화했나요? |
| 토큰 범위 | 필요한 API scope만 부여 | scope 목록과 이유가 있나요? |
| 토큰 audience | 서버와 downstream API 경계 확인 | 토큰이 원래 대상이 아닌 API로 전달되지 않나요? |
| 로그 | 토큰, 쿠키, raw OAuth 응답 미기록 | 마스킹 테스트나 코드 리뷰를 했나요? |
| 폐기 | 퇴사자, 벤더 변경, 서버 제거 시 revoke 절차 | 누가 언제 토큰을 폐기하나요? |
MCP 보안 문서는 token passthrough를 anti-pattern으로 설명합니다. 토큰을 그대로 중계하는 설계는 실제 도입 전에 authorization 경계, audience 검증, 감사 추적을 다시 설계해야 합니다.
#사용자 승인 플로우
MCP 도구는 일반 API 호출보다 사용자에게 더 불투명할 수 있습니다. 따라서 승인 화면이나 작업 로그는 다음 정보를 보여줘야 합니다.
| 사용자에게 보여줄 정보 | 예시 |
|---|---|
| 실행 도구 | `search_docs`, `create_ticket`, `send_email` |
| 접근 데이터 | 특정 폴더, 특정 DB table, 특정 SaaS workspace |
| 예상 결과 | 읽기, 문서 생성, 외부 발송, 레코드 수정 |
| 되돌리기 가능 여부 | 되돌릴 수 있음 / 수동 복구 필요 / 되돌리기 어려움 |
| 민감정보 포함 가능성 | 없음 / 사내 문서 포함 / 고객 데이터 포함 가능 |
#로그·stdout·오류 메시지 점검
MCP server와 client 로그에서는 다음을 피해야 합니다.
- 실제 API key, OAuth token, cookie, private URL, 고객 식별자 예시
- 실제 고객 워크스페이스 이름이나 private 파일 경로
- stdout으로 프로토콜 메시지가 아닌 디버그 로그를 섞는 예시
- “안전하다”, “보안 인증 완료”처럼 검증 없는 완료 주장
예시가 필요하면 `sk_test_xxx`, `customer_123` 같은 더미 값을 쓰고, 실제 형식과 혼동될 수 있는 값을 피합니다.
#소스와 확인일
| 출처 | 현재 용도 | 확인일 | 독자 확인 포인트 |
|---|---|---|---|
| https://modelcontextprotocol.io/docs/getting-started/intro | MCP가 AI 애플리케이션과 외부 시스템 연결 표준이라는 범위 설명 | 2026-05-20 | 공식 정의와 최신 문서 구조 확인 |
| https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices | 사용자 동의, 데이터 프라이버시, 도구 안전 원칙 확인 | 2026-05-20 | 실제 도입 전 보안 권고 재확인 |
| https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization | authorization/token boundary 검토 후보 | 2026-05-20 | token passthrough 관련 최신 문구 확인 |
| https://modelcontextprotocol.io/docs/develop/build-server | tools/resources/prompts 개념과 서버 구현 참고 | 2026-05-20 | 코드 예시는 별도 테스트 후 사용 |
#관련 글
| 경로 | 읽을 이유 |
|---|---|
| /ai-automation/ | AI automation 아이디어를 합성 데이터로 먼저 점검하는 방법 |
| /ai-automation/mcp-api/ | MCP와 API의 차이를 의사결정 관점에서 비교 |
#CTA
Security-aware automation consult는 “MCP 서버 권한표, 승인 플로우, 토큰/로그 노출 위험을 함께 점검한다”로 이해하면 됩니다. 보안 인증, 사고 방지, 규정 준수 완료, 고객 데이터 안전 보장을 약속하지 않습니다.
#FAQ
#MCP를 쓰면 자동화가 안전해지나요?
아니요. MCP는 연결 방식을 표준화하는 데 도움을 주지만, 권한 설계와 사용자 승인, 토큰 관리, 로그 마스킹은 별도로 구현하고 검토해야 합니다.
#모든 MCP 도구를 켜도 되나요?
아니요. 필요한 도구만 켜고, 쓰기·삭제·외부 전송 도구는 별도 승인과 로그 검토가 필요합니다.
#token passthrough는 왜 위험한가요?
서버가 토큰의 대상과 권한을 제대로 검증하지 않고 downstream API로 넘기면 보안 통제, 감사 추적, 신뢰 경계가 약해질 수 있습니다. 실제 도입 전 공식 authorization 문서 기준으로 설계를 재검토해야 합니다.
#이 체크리스트로 보안 감사가 끝나나요?
아니요. 이 페이지는 교육용 보안 점검표입니다. 실제 서비스에는 조직의 보안 정책, 법무 검토, 운영 로그, 샌드박스 테스트, 필요 시 외부 보안 검토가 필요합니다.