MCP 서버 연결과 권한 경계: 최소 권한 점검법

MCP 서버를 사내 AI 에이전트에 연결해도 접근 권한이 자동으로 제한되지는 않는다. MCP 프로젝트의 보안 정책은 서버가 실행 환경에서 허용된 자원에 접근하며, 서버 내부의 접근 제어와 입력 검증은 개발자가 구현해야 한다고 설명한다. 배포 전에는 서버가 실제로 얻는 파일·API 권한을 좁히고, 각 도구에 허용할 사용자, 대상 자료, 읽기·쓰기 동작을 따로 정해야 한다.

연결 승인 한 번을 이후의 모든 실행에 대한 승인으로 취급해서도 안 된다. 미국 국가안보국(NSA)의 MCP 보안 설계 보고서는 사용자 승인이 프로토콜 수준에서 강제되지 않으며, 이미 연결된 서버의 기능이나 데이터 접근이 재승인 없이 바뀔 수 있다고 지적한다. 따라서 연결할 서버를 신뢰할지, 특정 호출을 실행할지, 변경된 권한을 계속 허용할지는 각각 판단해야 한다.

프로토콜의 기능과 배포자의 통제를 구분한다

MCP는 AI 애플리케이션이 서버가 제공하는 도구와 자원을 발견하고 호출하는 방식을 정한다. 연결이 성립했다는 사실만으로 직원별 문서 접근권, 도구별 쓰기 권한, 실행 승인 정책이 만들어지지는 않는다. 이 정책은 호스트 애플리케이션, MCP 서버, 서버 뒤쪽의 업무 시스템에서 각자 집행해야 한다.

호스트는 사용자와 에이전트에 보여줄 도구를 제한하고 필요한 승인 절차를 실행한다. 서버는 호출을 받았을 때 사용자 신원, 대상 자원, 작업 종류와 인자를 다시 검사한다. 마지막으로 저장소나 업무용 API 계정에도 그 작업에 필요한 권한만 부여해야 한다. 에이전트가 도구를 선택했거나 사용자가 서버 연결에 동의했다는 이유로 뒤쪽 시스템의 권한 검사를 생략할 수는 없다.

특히 도구 목록을 숨기는 설정과 서버 프로세스의 실제 권한은 다르다. 검색 도구만 노출해도 서버가 사용하는 계정에 수정 권한이 남아 있다면, 서버 내부의 오류나 악의적인 동작까지 막는 경계로 볼 수 없다. 화면에 보이는 기능, 서버가 허용하는 작업, 실제 계정 권한이 같은 범위로 맞춰져야 한다.

연결 전: 서버 출처와 실행 환경을 확인한다

먼저 서버의 배포자와 소스 저장소, 설치할 패키지의 정확한 이름과 버전을 확인한다. 외부 목록에 등록됐다는 사실만으로 사내 사용을 승인하지 말고, 누가 유지·배포하는지와 업데이트 경로를 기록한다. 버전을 고정했다면 보안 수정이 나왔을 때 갱신할 절차도 함께 정해야 한다. 고정된 버전을 방치하면 새 릴리스를 자동으로 받지 않는 대신 필요한 수정도 놓칠 수 있다.

로컬 서버는 설치한 사용자의 실행 환경을 먼저 살펴야 한다. MCP 프로젝트의 로컬 서버 보안 안내에 따르면 stdio 서버는 일반 하위 프로세스로 실행되며, 별도 격리가 없으면 실행 계정이 읽을 수 있는 파일과 환경 변수에 접근할 수 있다. 설정 파일에 적은 허용 경로만으로 악의적이거나 침해된 프로세스의 접근을 강제 차단할 수는 없으므로, 운영체제 수준의 격리 범위를 함께 확인해야 한다.

문서 검색용 서버라면 필요한 프로젝트 디렉터리만 제공하고 가능하면 읽기 전용으로 마운트한다. 홈 디렉터리, 다른 프로젝트, 자격 증명 파일이 같은 실행 환경에 보이는지 확인한다. 컨테이너나 별도 계정으로 실행할 때도 이름만 확인하지 말고 실제 마운트 경로, 전달되는 환경 변수, 네트워크 접속 범위를 점검한다. 로컬 파일만 다루는 서버라면 외부 접속이 필요한 이유부터 확인하고, 필요하지 않은 접속은 실행 환경에서 차단한다.

원격 서버에는 같은 원칙을 API 계정에 적용한다. 예를 들어 사내 문서 모음 한 곳을 검색하는 서버라면 전체 저장소를 조회하거나 문서를 수정할 수 있는 계정을 연결할 이유가 없다. 서버별 자격 증명을 분리하고 접근할 자료 모음과 작업 종류를 해당 시스템에서 제한한다. 한 서버를 제거할 때 다른 연결의 자격 증명까지 교체해야 하는 구성이면 권한이 지나치게 묶여 있는지 살펴볼 필요가 있다.

실행 전: 도구의 동작, 대상, 승인을 분리한다

권한은 서버 단위의 ‘사용 가능’ 한 항목으로 끝내지 않는다. 도구마다 누가 호출할 수 있는지, 어느 자료를 대상으로 하는지, 읽기·생성·수정·삭제 중 무엇을 수행하는지 적는다. 같은 업무 시스템에 붙은 문서 검색과 문서 수정도 별도 권한으로 취급한다. 검색만 필요한 에이전트에는 쓰기 도구를 노출하지 않고, 서버의 실제 계정에서도 쓰기 권한을 없애야 범위가 일치한다.

조건부 예로, 사내 지식 검색 에이전트에는 특정 문서 모음의 조회만 허용할 수 있다. 이때 검색 결과에 기밀 문서가 섞일 수 있다면 ‘읽기 전용’이라는 이유만으로 안전하다고 판단하기 어렵다. 사용자의 원래 문서 접근권을 서버가 요청마다 확인하고, 결과가 모델의 대화 문맥이나 다른 도구로 전달되는 범위도 정해야 한다. 자료 분류와 사용자 권한이 다른 경우에는 동일한 검색 도구라도 결과 범위가 달라져야 한다.

승인 화면은 서버 이름보다 실행될 작업을 보여줘야 한다. 사용자가 어떤 도구가 어느 자료를 읽거나 바꾸는지, 결과가 외부 서비스로 전달되는지를 이해할 수 있어야 한다. 반복되는 조회를 사전 승인할 경우에는 대상 자료와 허용 기간을 좁혀 정하고, 쓰기 작업이나 승인 범위 밖의 전송에는 새 승인을 요구하는 방식이 적절하다. 승인 여부는 모델의 해석이 아니라 애플리케이션이 집행하는 정책으로 남겨야 한다.

승인을 받았더라도 도구 인자는 서버에서 검증해야 한다. 파일 경로가 허용 디렉터리 밖을 가리키는지, 자료 식별자가 다른 사용자의 자원인지, 요청 크기와 형식이 예상 범위인지 확인한다. 임의 URL이나 명령 문자열을 받는 도구에는 허용 대상을 더 좁게 정의해야 한다. 검색 결과나 다른 도구의 출력에 담긴 지시문은 권한 부여의 근거가 아니라 외부에서 들어온 데이터로 취급한다.

운영 중: 토큰 수명과 변경 이력을 관리한다

서버별 자격 증명에는 필요한 접근 범위와 유효 기간을 정하고 회수 방법을 마련한다. 넓은 권한의 개인 토큰을 여러 서버가 공유하면 어느 서버에서 노출됐는지에 따라 다른 연결까지 영향을 받는다. 토큰을 설정 파일이나 호출 로그에 평문으로 남기지 않도록 하고, 서버를 제거하거나 권한을 축소할 때 기존 자격 증명도 회수한다. 새 토큰을 발급하는 절차만 있고 이전 토큰을 끊는 절차가 없다면 권한 축소가 끝난 것이 아니다.

도구 이름과 설명, 서버 버전, 접근할 자료 범위가 바뀌면 최초 연결 승인을 그대로 적용할지 다시 판단한다. 새로운 쓰기 도구가 추가되거나 일반 자료만 읽던 서버가 민감 자료에 접근하게 되는 변경은 재승인 대상으로 삼는 것이 타당하다. 자동 업데이트를 허용하는 환경이라면 변경된 도구와 권한을 검토하기 전까지 새 기능이 활성화되지 않도록 배포 절차를 설계한다.

호출 기록에는 나중에 작업을 재구성할 수 있는 정보가 필요하다. 사용자와 에이전트 식별자, 서버와 도구, 호출 시각, 대상 자원, 승인 여부와 결과를 연결해 남긴다. 인자와 결과를 보관할 때는 조사에 필요한 범위를 정하되 토큰이나 불필요한 민감 원문은 제외한다. 거부된 호출과 예상 밖의 외부 접속 시도도 함께 관찰하면 권한 정책이 실제 요청에 어떻게 적용되는지 파악할 수 있다.

배포 판단을 위한 단계별 점검표

연결 전: 배포자·패키지·버전을 확인하고, 서버가 실행될 계정의 파일·환경 변수·네트워크 접근을 조사한다. 로컬 서버에는 필요한 경로만 제공하고 원격 서버에는 범위가 제한된 별도 API 계정을 사용한다. 설정에 적힌 제한이 실제 실행 환경에서도 강제되는지 확인한다.
실행 전: 각 도구에 허용할 사용자, 자료, 읽기·쓰기 동작을 정의한다. 사용자에게 표시되는 승인 내용과 서버의 인자 검사가 같은 범위를 집행하는지 확인하고, 허용 범위 밖의 경로·자료 식별자·전송 대상이 거부되는지 살핀다.
운영 중: 토큰 만료와 회수 방법, 도구 또는 데이터 접근 변경 시 재승인 조건, 호출 기록의 필드를 정한다. 새 버전이 권한을 넓히거나 서버 사용을 중단할 때 연결과 자격 증명을 처리할 담당자를 지정한다.

배포 승인에 필요한 답은 구체적이어야 한다. 어느 사용자와 에이전트가 어떤 도구로 어느 자료에 무슨 동작을 할 수 있는지 설명할 수 있어야 하며, 그 범위가 서버 설정뿐 아니라 실제 계정 권한, 실행 승인, 호출 기록에도 반영돼야 한다.

함께 읽기: