공동 저자: ShalabhPradhan, Sarah_Young
1년 전, 우리는 MCP 구현의 보안 리스크 이해 및 완화라는 글을 게시했습니다.
핵심 아이디어는 여전히 유효합니다. 모델이 도구를 선택하고 호출할 수 있게 되는 순간, 그것은 단순히 묻고 답하는 상자가 아니라 '행동하는 소프트웨어'가 됩니다. 그리고 행동하는 소프트웨어에는 반드시 **신뢰 경계(trust boundary)**가 존재합니다. 도구 설명, 스키마, 출력값, 그리고 자격 증명은 모두 이 경계 안에 위치합니다.
그사이 바뀐 것은 바로 '규모'입니다. 모델 컨텍스트 프로토콜(MCP)은 유망한 아이디어에서 에이전트가 도구, 데이터, 시스템에 연결하는 표준 방식으로 자리 잡았습니다. 기업들은 실험을 멈추고 이를 실제 프로덕션 환경에 배포하기 시작했습니다. 이 포스트는 일종의 체크포인트입니다. 현재 주요 리스크는 무엇인지, 어떤 리스크가 변화했는지, 그리고 각 리스크에 대한 올바른 보안 대책은 무엇인지 짚어보겠습니다.
끊임없이 진화하는 사양
MCP는 여전히 빠르게 진화하고 있으며, 사양은 정기적으로 개정됩니다. 최신 릴리스 후보(release candidate)는 다음과 같은 방식으로 보안 기준을 높였습니다. 이제 요청(request)은 필요한 정보를 스스로 지니고 전달되므로, 게이트웨이는 숨겨진 세션을 신뢰하는 대신 모든 호출에 대해 검사하고 강제할 수 있습니다. 클라이언트와 서버 간의 ID 확인이 더욱 엄격해졌으며, 서버가 호스트의 샌드박스 내부에서 렌더링되는 대화형 UI를 제공할 수 있는 새로운 'MCP Apps' 기능도 추가되었습니다.
여기에는 하나의 일관된 테마가 있습니다. 프로토콜 자체가 당신을 위해 보안을 강제하지 않는다는 점입니다. 프로토콜은 클라이언트와 서버가 대화하는 방식을 정의할 뿐, 잠금 장치를 채우는 것은 여러분의 몫입니다. 따라서 "작년에 MCP를 검토했다"는 말은 이미 구식 정보로 간주하고, 각 릴리스가 나올 때마다 가정을 다시 점검해야 합니다.
아래의 리스크 목록이 중요한 이유가 바로 이것입니다.
2026년의 주요 리스크
이 중 일부는 작년에 경고했던 것과 동일합니다. 어떤 것들은 형태가 바뀌었고, 특히 권한 부여(authorization) 부분은 대폭 개편되었습니다. 아래의 각 항목은 리스크의 정의, 악용 시 발생할 수 있는 일, 그리고 가장 도움이 되는 제어 방안을 요약한 것입니다.
그림 1: MCP 보안 개요
1. 프롬프트 주입(Prompt Injection) 및 도구 중독(Tool Poisoning)
- 정의: 에이전트가 도구 설명, 파라미터 스키마, 도구가 반환하는 데이터 등 자신의 컨텍스트에 포함된 모든 것을 신뢰할 수 있는 것으로 간주하는 문제입니다. 이러한 요소에 명령을 심을 수 있는 사람이라면 누구나 에이전트를 조종할 수 있습니다. 도구 중독은 특히 위험한데, 사용자가 무심코 지나치기 쉬운 도구 설명이나 스키마 속에 악성 명령을 숨겨 모델이 이를 읽게 만드는 수법입니다.
- 발생 가능한 피해: 에이전트가 사용자의 명령 대신 공격자의 명령을 따르게 됩니다. 정상적인 도구 호출처럼 보이면서 몰래 데이터를 탈취하거나, 엉뚱한 도구를 호출하고, 누구도 승인하지 않은 동작을 수행할 수 있습니다.
- 제어 방안: 도구 설명과 출력값을 신뢰할 수 없는 입력값으로 취급하고, 서버를 승인하기 전에 전체 스키마를 검사하십시오. 도구 목록은 반드시 사람이 승인하는 프로세스를 거치도록 하고, 사용자에게는 친숙한 요약 대신 실제 도구 호출 전체를 보여주어야 합니다. 민감한 서버는 일반 목적의 서버와 격리하여, 중독된 도구가 높은 수준의 보호막을 뚫고 다른 곳에 접근하지 못하도록 하십시오.
2. 권한 부여 및 혼동된 대리인(Confused Deputy) 문제
- 정의: 이 영역은 가장 큰 확장이 있었던 부분입니다. 이제 MCP 서버는 OAuth 2.0 리소스 서버로 취급되며, 가이드는 OAuth 2.1, PKCE 및 특정 대상(audience)에 귀속된 토큰을 중심으로 강화되었습니다. 이 리스크는 권한이 없는 사용자를 대신하여 서버가 가진 광범위한 권한으로 행동하거나, 프록시를 속여 공격자에게 유효한 인증 코드를 넘겨주게 만드는 '혼동된 대리인' 문제를 타겟으로 합니다.
- 발생 가능한 피해: 공격자가 서버의 권한을 이용해 사용자가 원래 접근할 수 없는 데이터나 작업에 접근할 수 있으며, 때로는 사용자의 승인 없이도 가능합니다.
- 제어 방안: 최신 권한 부여 모델을 채택하십시오. OAuth 2.1과 PKCE, 클라이언트별 동의, 엄격한 리다이렉트 URI 매칭, 그리고 한 서버에서 생성된 토큰이 다른 서버에서 재사용되지 않도록 하는 대상 귀속 토큰(audience-bound tokens)을 사용해야 합니다. 모든 서버 앞에 ID 인식 게이트웨이를 두고, 유효한 대상 귀속 토큰이 없는 호출은 거부하십시오. Azure API Management는 Microsoft Entra 토큰을 검증하고 요청이 도구에 도달하기 전 발급자, 대상, 만료 여부를 확인할 수 있습니다.
그림 2: 혼동된 대리인 문제
3. 과도한 접근 권한 및 자격 증명 집약
- 정의: 단일 MCP 서버가 여러 시스템의 자격 증명을 동시에 보유하거나, 읽기 전용으로 충분한 상황에서 전체 사서함 접근 권한을 요구하는 등 필요 이상의 광범위한 범위를 요청하는 경우입니다.
- 발생 가능한 피해: 서버 하나가 침해당하거나 토큰 하나가 유출되면, 해당 서버와 연결된 모든 시스템이 뚫리는 결과로 이어집니다. 범위가 넓을수록 피해 범위(blast radius)도 넓어집니다.
- 제어 방안: 리소스별 최소 권한 원칙을 적용하십시오. 와일드카드 대신 세분화되고 좁은 범위의 OAuth 범위를 사용하고, 장기 유효 비밀번호 대신 단기 유효 토큰을 사용하십시오. Microsoft Entra Agent ID와 같이 거버넌스가 가능한 ID를 모든 에이전트에 부여하여, 정책을 일괄 적용하거나 한 번에 중단할 수 있도록 하십시오.
4. 공급망 리스크 및 러그 풀(Rug Pulls)
- 정의: MCP 서버는 단순히 서버 하나만이 아닙니다. 서버와 그 의존성, 그리고 서버가 실행되는 인프라가 모두 공격 통로가 될 수 있습니다. 오타를 이용한 타이포스쿼팅(typosquatted) 패키지, 침해된 라이브러리, 또는 동일한 URL 뒤에서 소유권이 변경되는 것 모두 신뢰했던 서버를 적대적으로 돌릴 수 있습니다. **러그 풀(Rug pull)**은 가장 명확한 사례로, 검토 중에는 정상적으로 동작하여 승인을 얻어낸 뒤, 에이전트와 워크플로우가 이미 의존하기 시작했을 때 악성으로 변하는 것을 말합니다.
- 발생 가능한 피해: 승인한 서버가 실제로 실행 중인 서버와 다를 수 있습니다. 평범한 도구 호출이 인자값을 유출하기 시작하거나, 응답을 조작하거나, 토큰을 탈취하는데도 겉보기에는 수천 건의 이전 요청과 아무런 차이가 없을 수 있습니다.
- 제어 방안: 승인은 일회성 이벤트가 되어서는 안 됩니다. 모든 서버를 디자인 타임 카탈로그에 등록하여 알려진 양호한 기준점(baseline)을 확보하십시오. 도구 정의를 고정(pin)하고 변경 사항에 대한 경고를 설정하여 러그 풀을 감지하는 트리와이어(tripwire)로 활용하십시오. 또한 모든 호출은 매번 ID와 정책을 재확인하는 게이트웨이를 거쳐야 합니다. Azure API Center를 통해 API와 MCP 서버를 인벤토리화할 수 있으며, Azure 제어 항목에 매핑된 OWASP MCP Top 10을 통해 현재 운영 중인 환경의 리스크를 대조해 볼 수 있습니다.
그림 3: 공급망 – 러그 풀
5. 섀도우(Shadow) MCP
- 정의: 에이전트 시대의 '섀도우 AI'입니다. 개발자가 데모를 위해 임시 서버를 띄우거나, 팀에서 아무 엔드포인트에나 에이전트를 연결하고 등록하지 않은 채 사용하는 경우입니다.
- 발생 가능한 피해: 보이지 않는 것은 거버넌스를 적용하거나 패치하거나 취소할 수 없습니다. 관리되지 않는 서버는 공급망 문제가 숨어들기에 최적의 장소입니다.
- 제어 방안: 가시성이 최우선입니다. 존재하는 모든 서버에 대한 디자인 타임 레지스트리를 구축하고, 모든 트래픽이 통과하는 런타임 게이트웨이를 마련하십시오. GSA AI 게이트웨이는 운영 중인 사실조차 몰랐던 미등록 섀도우 서버를 파악하는 데 도움이 됩니다.
6. 명령 주입(Command Injection) 및 샌드박스 탈출
- 정의: 많은 MCP 서버가 로컬에서 실행되며 표준 입출력(stdio)을 통해 통신하고, 하위 프로세스를 생성하거나 파일 시스템에 접근합니다. 서버가 검증되지 않은 입력값을 쉘 명령어나 파일 경로로 전달하면 명령 주입 또는 경로 탐색(path traversal) 문제가 발생하며, 이는 올해 보고된 MCP 취약점 중 가장 큰 비중을 차지했습니다.
- 발생 가능한 피해: 호스트에서 임의의 코드가 실행되거나, 서버가 접근해서는 안 되는 파일 및 자격 증명에 접근할 수 있습니다. 최악의 경우 사용자 승인 없이도 실행될 수 있습니다.
- 제어 방안: 로컬 서버를 컨테이너에 넣어 필요한 파일 시스템과 네트워크 접근만 허용하고, 기본적으로 외부로 나가는 이그레스(egress)를 차단하십시오. 모든 입출력값을 검증 및 정제하고, 원시 쉘 명령이나 정제되지 않은 경로를 절대 그대로 전달하지 마십시오. 이 클래스의 버그는 현장에서 계속 수정되고 있으므로 서버와 SDK를 항상 최신 상태로 패치하십시오.
마무리하며
프로토콜은 단순해졌지만, 신뢰 경계는 훨씬 더 복잡해졌습니다. 권한 부여 체계는 개선되었고, 새로운 릴리스 후보는 트래픽을 관리하는 더 깔끔한 방식을 제공합니다. 동시에 가장 영향력이 큰 실패 사례는 공급망, ID, 그리고 미등록 서버 쪽으로 이동했습니다. 리더들에게 주어진 과제는 MCP 도입을 '의도적'으로 만드는 것입니다. 어떤 서버가 존재하는지 파악하고, 도구 호출 시 ID와 정책을 요구하며, 변화를 모니터링하고, 사양이 바뀔 때마다 제어 장치를 재검토해야 합니다.
MCP를 운영하는 기업들을 위한 실질적인 단계는 플랫폼 및 보안 팀이 현재의 문서와 SDK를 검증하고, 프로덕션 환경에서 유효했던 경험을 커뮤니티에 다시 기여하는 것입니다. 권한 부여, 게이트웨이 강제, 샌드박스 기본 설정, 감사 이벤트, 스키마 변화 탐지에 대한 명확한 예시들이 모일 때, 개별 기업의 보안 강화가 생태계 전체의 안전 가이드라인으로 이어질 수 있습니다.
보안 관련 MCP RFC에 참여하거나 제안하여 이 프로토콜을 더욱 개선해 주시기를 권장합니다! 사양 저장소(specification repository)에 이슈를 남겨주세요. 구현에 관한 질문은 컨트리뷰터 디스코드의 관련 워킹 그룹(Working Group) 채널을 이용하는 것이 가장 빠른 답변을 얻는 방법입니다.
다음 파트에서는 이러한 제어 장치들을 실제로 심층 구현하는 방법과, 바로 업무에 적용할 수 있는 패턴 및 설정 가이드를 다루겠습니다.