MCP 서버 연결 전 점검할 보안 기준, 도구 권한과 인증을 나누는 법

AI를 활용하여 생성한 이미지입니다.

MCP 서버를 연결하면 AI 클라이언트가 파일을 읽거나 외부 API를 호출하거나 로컬 명령을 실행할 수 있어요. 편리하지만 “서버가 연결됐다”는 사실만으로 안전하다고 볼 수는 없습니다. 도구 목록, 실행 권한, 사용자 인증, 입력 검증을 각각 따로 확인해야 사고 범위를 줄일 수 있어요.[1]

MCP에서 권한이 새는 지점

MCP의 도구는 이름과 설명, 입력 스키마를 클라이언트에 노출하고 호출 결과를 돌려줍니다. 이 구조에서는 도구 설명이 곧 사용자의 승인으로 바뀌지 않아요. 파일 삭제나 네트워크 요청처럼 영향이 큰 동작은 사용자가 확인할 수 있는 승인 단계와 서버 쪽 검증을 함께 둬야 합니다.[3]

도구 권한을 작게 시작하기

처음부터 “파일 시스템 전체”나 “셸 명령 전체”를 열지 마세요. 읽기 전용 목록 조회부터 시작하고, 작업 폴더를 하나로 제한한 뒤 필요한 동작을 하나씩 추가하는 방식이 낫습니다. 예를 들어 문서 검색 서버라면 read_document와 search_document만 먼저 노출하고, 삭제·이동·외부 전송 도구는 별도 승인 대상으로 둡니다.

권한을 줄이는 기준은 도구 이름이 아니라 실제 부작용이에요. export_report라는 이름이어도 결과를 외부 URL로 전송한다면 네트워크 권한이 필요합니다. 반대로 단순 계산 도구라면 파일이나 네트워크 접근 없이 실행할 수 있어요.

인증과 권한을 섞지 않기

인증은 “누구인가”를 확인하고, 권한은 “무엇을 할 수 있는가”를 정합니다. MCP의 인증 흐름을 붙였더라도 모든 사용자가 같은 도구와 같은 범위를 얻도록 만들면 최소 권한 원칙이 사라집니다.[2]

원격 서버라면 토큰을 URL 쿼리에 넣지 말고, TLS로 전송 구간을 보호하며, 토큰 만료와 폐기 방법을 준비하세요. 로컬 서버도 예외는 아니에요. 다른 프로세스가 같은 포트에 접근할 수 있고, 로그나 환경 변수에 비밀 값이 남을 수 있으므로 바인딩 주소와 로그 정책을 확인해야 합니다.

입력 스키마는 방어선이 아니에요

JSON Schema가 문자열과 숫자 형식을 제한해도, 그 값이 안전한 경로인지 또는 허용된 도메인인지까지 자동으로 보장하지는 않습니다. 서버는 경로가 작업 폴더 안에 있는지, URL이 허용 목록에 있는지, 명령 인자가 예상 범위인지 다시 검사해야 해요. 도구 문서에 적힌 설명만 믿고 실행하면 안 되는 이유입니다.[1][3]

승인 화면과 로그를 설계하는 법

1. AI가 요청한 도구 이름과 입력값을 사용자에게 보여줍니다.
2. 읽기와 쓰기, 로컬과 외부 전송을 서로 다른 위험 등급으로 표시합니다.
3. 파괴적 작업은 승인 전 미리보기나 변경 목록을 제공합니다.
4. 실행 뒤에는 사용자, 시각, 도구, 결과 상태를 남깁니다.

로그에는 API 키와 원문 문서가 그대로 들어가지 않도록 마스킹 규칙을 두세요. 실패 로그도 중요하지만, 실패한 입력을 그대로 재시도하는 자동 루프는 별도 제한이 필요합니다.

연결 전 체크리스트

• 업무에 필요한 도구만 등록하기
• 작업 폴더와 허용 도메인을 제한하기
• 인증 토큰의 만료·폐기 경로 확인하기
• 스키마 검증 뒤 서버 측 경로·URL 검증 추가하기
• 삭제·전송 도구에 승인과 감사 로그 붙이기

도구 호출이 실패했을 때 재시도·멱등성·병렬 실행을 함께 설계하려면 AI 에이전트 도구 호출의 멱등성과 재시도 기준도 연결해서 읽어 보세요.

로컬 서버라도 위험 경계는 필요해요

같은 컴퓨터에서 실행하는 MCP 서버는 인터넷에 공개되지 않았다는 이유로 자동으로 안전해지지 않습니다. 악성 문서나 웹 페이지가 도구 입력으로 흘러들 수 있고, 같은 사용자 권한으로 실행되는 서버는 그 권한만큼 파일과 환경 변수에 접근할 수 있어요. 서버가 어느 주소에 바인딩되는지, 다른 사용자가 포트에 접근할 수 있는지, 시작 시 어떤 환경 변수를 읽는지 확인하세요.[1]

특히 외부에서 받은 MCP 서버 설정을 그대로 복사하지 마세요. 실행 파일 위치, 작업 폴더, 네트워크 목적지, 토큰 저장 위치를 먼저 읽고 필요 없는 권한을 지운 뒤 시작하는 것이 좋습니다. 신뢰할 수 없는 서버는 도구 목록을 읽는 단계와 실제 호출 단계를 분리해 검토하세요.

도구 설명을 신뢰하는 방법

도구 설명은 사용자가 무엇을 승인하는지 이해하는 데 도움을 주지만, 서버가 실제로 하는 일을 증명하지는 않습니다. 설명과 입력 스키마가 실제 구현과 맞는지 확인하고, 예상하지 못한 필드가 들어오면 거부하도록 서버를 설계하세요. 이름이 비슷한 도구가 여러 개라면 공급자와 버전을 화면에 함께 표시하면 잘못된 서버를 승인할 가능성을 줄일 수 있습니다.[3]

최소 권한을 유지하는 운영 습관

• 개발 중에는 테스트 폴더와 테스트 토큰만 사용하기
• 운영 계정의 비밀 키를 로컬 실험 서버에 재사용하지 않기
• 읽기 전용 도구와 변경 도구를 서로 다른 서버로 나누기
• 도구 목록과 권한 변경을 버전 관리하고 변경 이유 남기기

Sources

• [1] Model Context Protocol, Security Best Practices
• [2] Model Context Protocol, Authorization
• [3] Model Context Protocol, Tools