MCP 서버를 사내 시스템에 연결할 때 권한은 어떻게 통제합니까?

MCP 서버를 붙이는 것은 실행 권한을 주는 일입니다

MCP(Model Context Protocol)는 AI 애플리케이션이 외부 데이터와 기능에 접근하는 방식을 표준화한 공개 프로토콜입니다. 구조는 셋으로 나뉩니다. AI 애플리케이션(호스트), 그 안에서 연결을 맡는 클라이언트, 그리고 실제 기능을 내놓는 서버입니다. 서버가 내놓는 기능 가운데 도구(tool) 는 모델이 대화 맥락을 보고 스스로 골라 호출하도록 설계되어 있습니다.

그래서 MCP 사양(2026-07-28 개정판)은 도구를 임의 코드 실행에 준하는 것으로 신중하게 다루라고 적고 있습니다. 호스트는 도구를 호출하기 전에 사용자의 명시적 동의를 받아야 하고, 도구 호출을 거부할 수 있는 사람을 항상 중간에 두어야 한다는 것이 사양의 원칙이자 권고입니다. 다만 사양 스스로 밝히듯 프로토콜이 이 원칙을 강제하지는 못합니다. 통제는 연결하는 회사가 설계해야 합니다.

1. 직원의 요청
2. AI 모델의 도구 선택
3. 클라이언트 승인 화면
4. MCP 서버 권한 검사
5. 사내 시스템

통제 지점은 흐름의 뒤쪽 세 곳입니다. 모델이 무엇을 고르든 승인 화면과 서버, 사내 시스템이 각각 막을 수 있어야 합니다. 권한 판단을 모델에 맡기면 외부 문서에 숨은 지시 한 줄에 방어 전체가 흔들립니다.

MCP 서버는 크게 두 형태로 만납니다. 직원 PC에서 실행되는 로컬 서버와, 서비스 업체가 인터넷으로 제공하는 원격 서버입니다. 로컬 서버는 PC의 파일과 프로그램에 닿고, 원격 서버는 AI가 보낸 내용을 그 업체의 시스템으로 가져갑니다. 어느 쪽이든 어떤 데이터가 어디로 가는가와 무엇을 실행할 수 있는가를 함께 봐야 합니다.

도구를 위험도로 나눕니다

가장 먼저 할 일은 서버가 내놓는 도구 목록을 펼쳐 놓고 되돌릴 수 있는가와 영향 범위가 얼마나 넓은가로 분류하는 것입니다. OWASP는 LLM 애플리케이션 위험 목록에서 이 문제를 과도한 권한 위임(Excessive Agency)으로 부르고, 원인을 기능 과다·권한 과다·자율성 과다 셋으로 나눕니다. 분류는 세 원인을 각각 줄이는 출발점입니다.

예를 들어 고객 관리 시스템의 MCP 서버가 고객 조회, 상담 메모 추가, 고객 삭제 세 도구를 내놓는다면 조회는 자동 허용, 메모 추가는 실행 전 확인, 삭제는 AI에 아예 노출하지 않는 식으로 나눌 수 있습니다. 삭제·외부 발송·결제·권한 변경은 대부분 「되돌릴 수 없음」에 들어갑니다. 쓸 일이 없는 도구는 노출하지 않는 것이 가장 확실한 통제입니다. 범용 명령 실행이나 임의 주소 호출처럼 무엇이든 할 수 있는 도구보다 목적이 좁은 도구를 고르는 것도 같은 원리입니다.

주의할 점이 하나 있습니다. MCP 도구에는 「읽기 전용」 같은 설명(annotation)을 붙일 수 있지만, 사양은 신뢰할 수 있는 서버에서 온 것이 아니면 클라이언트가 이 설명을 믿지 말아야 한다고 규정합니다. 설명이 아니라 실제로 부여된 권한으로 판단해야 합니다.

토큰과 권한 범위를 서버 단위로 좁힙니다

MCP 서버가 사내 시스템에 접근할 때 쓰는 자격 증명이 실제 피해 범위를 정합니다. MCP 사양과 OWASP의 권고 가운데 실무에서 특히 중요한 것은 셋입니다.

• 서버 전용 토큰만 받습니다. 사양은 MCP 서버가 자신을 위해 발급되지 않은 토큰을 받아서는 안 된다고 규정합니다. 클라이언트가 가진 토큰을 그대로 하위 API에 넘기는 「토큰 전달(token passthrough)」은 명시적으로 금지된 방식입니다. 이렇게 하면 누가 호출했는지 기록이 흐려지고, 하위 시스템의 속도 제한이나 검증도 우회됩니다.
• 범위는 최소로 시작해 필요할 때 넓힙니다. 처음에는 조회 같은 낮은 위험의 범위만 주고, 변경 동작을 처음 시도할 때 추가 승인을 받는 단계적 방식이 권고됩니다. *·full-access 같은 포괄 범위는 흔한 실수로 꼽힙니다.
• 권한 판단은 하위 시스템이 합니다. 모델이 「이 사용자는 볼 수 있다」고 판단하게 두지 말고, 사내 시스템이 호출한 사용자의 권한으로 다시 검사해야 합니다. 가능하면 공용 서비스 계정이 아니라 요청한 직원의 권한으로 실행되게 합니다. OWASP도 확장 기능을 사용자 맥락에서 실행하고, 허용 여부는 모델이 아니라 하위 시스템에서 판단하라고 권합니다(LLM06).

외부 서비스의 API를 대신 호출해 주는 MCP 서버를 직접 운영한다면, 사양이 경고하는 「혼동된 대리인(confused deputy)」 문제도 확인해야 합니다. 이런 서버가 모든 클라이언트를 하나의 고정된 클라이언트 ID로 외부 서비스에 인증시키면서 클라이언트별 동의를 따로 받지 않으면, 공격자가 사용자의 브라우저에 남은 이전 동의 기록(쿠키)을 이용해 동의 화면을 건너뛰고 인가 코드를 가로챌 수 있습니다. 사양은 이런 서버가 클라이언트별로 동의를 받고 그 기록을 저장한 뒤에야 외부 인증으로 넘기도록 요구합니다.

로컬 MCP 서버는 설치가 곧 실행입니다

개발 도구나 데스크톱 AI 앱에 붙이는 로컬 MCP 서버는 직원 PC에서 그 앱과 같은 권한으로 실행됩니다. 사양은 설정 한 줄에 악성 시작 명령이 섞이거나 서버 자체에 악성 코드가 들어 있을 수 있다고 경고합니다. 그래서 클릭 한 번으로 로컬 서버를 설정하는 기능이 있는 클라이언트에는, 실행될 명령을 잘리지 않은 형태로 보여 주고 명시적 승인을 받도록 요구합니다.

회사 차원에서는 승인된 MCP 서버 목록을 두는 것이 현실적입니다. 출처와 버전을 고정하고, 가능하면 파일 시스템·네트워크 접근을 제한한 환경에서 실행하게 합니다. 직원이 인터넷에서 찾은 서버를 개인 판단으로 붙이는 것은 출처를 모르는 프로그램을 설치하는 것과 같습니다.

기록과 점검 항목

사양은 클라이언트가 도구 호출 전에 입력값을 사용자에게 보여 주고 감사 목적으로 도구 사용을 기록하도록 권고하며, 서버에는 입력 검증·접근 통제·호출 속도 제한을 요구합니다. 도구가 돌려준 결과도 검사 대상입니다. 사양은 도구 결과를 모델에 넘기기 전에 검증하도록 권하는데, 메일이나 웹페이지를 읽어 오는 도구라면 그 내용에 AI를 겨냥한 지시가 숨어 있을 수 있기 때문입니다.

기록은 사고가 난 뒤에야 쓸모가 드러납니다. 누가 어떤 요청으로 어떤 도구를 어떤 입력으로 실행했고 누가 승인했는지를 한 줄로 이어 볼 수 있게 남겨야 합니다. 빌드업웍스가 업무 자동화를 설계할 때도 위험하거나 비용이 큰 결정은 자동 실행하지 않고 사람 승인에서 멈추게 둡니다.

• 연결한 MCP 서버와 노출된 도구 목록이 문서로 관리되는가
• 도구마다 되돌릴 수 있는지와 영향 범위가 분류되어 있는가
• 되돌릴 수 없는 동작에 사람 승인 단계가 있는가
• 서버가 자기 전용 토큰만 받고 최소 범위로 동작하는가
• 사내 시스템이 호출한 사용자의 권한을 다시 검사하는가
• 도구 호출의 입력·결과·승인자가 기록되고 보관 기간이 정해져 있는가
• 로컬 MCP 서버는 승인 목록에 있는 것만 쓰는가

참고 자료

• Model Context Protocol 사양 — Security and Trust & Safety
• Model Context Protocol — Security Best Practices
• Model Context Protocol 사양 — Tools
• OWASP Top 10 for LLM Applications 2025 — LLM06 Excessive Agency