- MCP는 LLM과 도구를 연결하는 표준 프로토콜이지만, 기본적으로 보안이 적용되어 있지 않음
- 명령어 삽입, 도구 중독, 정의 변조 등 다양한 보안 취약점이 존재함
- MCP는 인증, 암호화, 무결성 검증 기능이 없어 신뢰하기 어려운 구조임
- ScanMCP 같은 도구로 가시성과 통제를 확보하는 것이 현재로선 최선의 대응임
MCP란 무엇이며 왜 중요한가
- MCP는 Model Context Protocol의 약자로, Claude, GPT, Cursor와 같은 LLM들이 도구 및 데이터와 통합되는 방식의 새로운 표준임
- "AI 에이전트를 위한 USB-C"로 불릴 만큼 표준화된 연결 방식을 제공함
- MCP를 통해 AI 에이전트는 다음과 같은 기능을 수행함
- 표준화된 API로 도구와 연결
- 세션 상태를 유지
- 명령 실행 (과도하게 자유롭게 실행될 수 있음)
- 워크플로 간 컨텍스트 공유
- 하지만 기본적으로 보안이 적용되어 있지 않음
- 사용자 모르게 시스템에 접근할 수 있는 사이드 채널을 열어주는 위험이 있음
MCP에서 발생하는 주요 보안 취약점들
-
명령어 삽입 취약점 (Equixly 리서치)
- 2025년 현재도 명령어 삽입을 통한 원격 코드 실행(RCE) 이 발생하고 있음
- Equixly의 조사에 따르면 전체 MCP 서버 구현 중 43% 이상이 안전하지 않은 쉘 호출을 사용함
- 공격자는 도구 입력값에 쉘 명령어를 포함시켜 신뢰된 에이전트를 통해 원격 코드를 실행할 수 있음
-
도구 중독 (Tool Poisoning, Invariant Labs)
- 공격자가 악의적인 명령을 도구 설명 안에 숨겨두는 방식
- 사용자 눈에는 보이지 않지만 AI는 이를 그대로 인식하고 실행함
- 단순한 수학 연산처럼 보이는 도구가 실제로는 사용자 시스템에서 SSH 키나 민감한 설정 파일을 읽을 수 있음
-
조용한 도구 재정의 (Rug Pull)
- 도구가 설치 후 스스로 정의를 변경할 수 있음
- Day 1에는 정상적이던 도구가 Day 7에는 공격자의 API 키 수집 도구로 바뀔 수 있음
- 이는 공급망 보안 문제의 새로운 형태로 LLM 내부에서 발생함
-
교차 서버 도구 그림자화
- 여러 MCP 서버가 하나의 에이전트에 연결되어 있을 때, 악성 서버가 신뢰된 서버의 호출을 가로채거나 오버라이드 가능
- 결과적으로 다음과 같은 문제가 발생할 수 있음
- 사용자에게 보낸 척하면서 공격자에게 이메일 발송
- 숨겨진 로직을 도구에 주입
- 인코딩된 데이터 유출
MCP가 아직 안전하지 않은 이유
- MCP는 다음을 우선시함
- 하지만 다음이 부족함
- ❌ 인증 표준 없음
- ❌ 컨텍스트 암호화 없음
- ❌ 도구 무결성 확인 불가
- 사용자는 에이전트가 실제로 어떤 설명을 기반으로 도구를 사용하는지 알 수 없음
개발자와 플랫폼 운영자가 할 수 있는 보안 대응
-
개발자
- 입력값 검증 필수
- MCP 서버와 도구의 버전을 고정 (pinning)
- 도구 설명에서 민감 정보 제거
-
플랫폼 운영자
- 전체 도구 메타데이터를 사용자에게 표시
- 서버 업데이트 시 무결성 해시 사용
- 세션 보안 강제 적용
-
사용자
- 신뢰할 수 없는 MCP 서버에 연결 금지
- 세션 로그를 운영환경처럼 감시
- 의심스러운 도구 업데이트 모니터링
ScanMCP.com의 아이디어 제안
- ScanMCP는 다음을 수행하는 스캐너 및 대시보드로 제안됨
- 연결된 MCP 도구를 감사
- RCE, 도구 중독, 세션 누수 등 리스크 탐지
- 사용자가 보는 정보 vs. 에이전트가 인식하는 정보를 비교해 시각화
- 다음과 같은 사용자에게 유용할 수 있음
- 에이전트 플랫폼 보안팀
- AI 인프라 스타트업
- 신뢰 기반 도구를 만들고자 하는 독립 개발자
마무리 생각
MCP는 강력한 프로토콜이지만, API 보안 성숙도는 부족한 상태에서 너무 빠르게 도입되고 있음
Secure-by-default 방식이 도입되기 전까지는 ScanMCP.com과 같은 도구가 가시성과 통제력을 확보하는 최선의 방법임
- 결론: MCP의 "S"는 Security가 아님. 하지만 그래야만 함