Model Context Protocol (MCP)는 AI 어시스턴트를 데이터베이스, API, 코드 실행 환경, 이메일 시스템과 같은 외부 도구에 간단하게 연결할 수 있게 해줍니다. 이러한 연결성은 MCP를 유용하게 만드는 바로 그 요소인 동시에, 신중하게 보안을 강화해야 하는 이유이기도 합니다.

2024년 말 MCP가 출시된 이후, 보안 연구자들은 몇 가지 실제 공격 패턴을 기록해 왔습니다. 이러한 패턴을 이해하는 것이 방어의 첫 번째 단계입니다.

MCP 도구가 공격 표면이 되는 방식

에이전트가 MCP 서버에 연결되면, 서버의 도구 설명(tool descriptions)이 모델의 컨텍스트 윈도우(context window)로 직접 로드됩니다. 이는 사소한 세부 사항이 아닙니다. 즉, 도구 설명은 모델이 읽고 반응하는 '지침(instructions)'이지, 수동적인 메타데이터가 아니라는 의미입니다.

Invariant Labs의 연구원들은 2025년 초에 이른바 "도구 오염 (tool poisoning)"이라 불리는 현상을 통해 이를 입증했습니다. 악의적인 서버가 도구 설명 내부에 숨겨진 지시 사항을 삽입하는 방식입니다. 모델은 이를 읽고 실행하며, 명시적인 호출이 발생하기도 전에 파일을 유출하거나 자격 증명(credentials)을 탈취할 가능성이 있습니다. 이후 Trail of Bits는 이를 "라인 점핑 (line jumping)"으로 일반화했습니다. 즉, 서버가 호출당 승인 메커니즘(per-invocation approval mechanisms)이 적용되기도 전에 모델의 동작을 변경할 수 있다는 것입니다.

이해할 가치가 있는 두 가지 패턴이 더 있습니다:

토큰 패스스루 (Token passthrough): 많은 MCP 서버는 상위 API의 프록시(proxy) 역할을 하며 모델을 대신하여 OAuth 토큰을 관리합니다. 서버가 이러한 토큰을 수정 없이 하위 서비스로 전달할 때, 하위 서비스는 해당 토큰이 자신을 위해 의도된 것인지 확인할 수 없습니다. 이는 토큰이 허용되지 않은 권한을 부여하게 되는 혼동된 대리인(confused-deputy) 상황을 초래합니다. 현재 MCP 사양은 RFC 8707에 따라 서버가 토큰의 대상(audience)을 검증하도록 요구하고 있습니다.

Rug pulls (러그 풀): MCP는 도구 정의(tool definitions)의 불변성을 보장하지 않으며, 대부분의 클라이언트는 도구별 승인을 한 번만 수행하고 지속적인 재검증을 하지 않습니다. 서버는 처음에 무해해 보이는 도구를 제시한 다음, 나중에 이를 조용히 재정의할 수 있습니다. CVE-2025-54136은 이러한 취약점을 기록했습니다. 2025년 9월, 침해된 npm 패키지가 이 패턴을 악용하여 발견되기 전 약 2주 동안 사용자의 이메일을 공격자에게 비밀리에 BCC(숨은 참조)로 전송했습니다.

실제로 취해야 할 조치

위의 위험 요소들은 구체적인 실무 지침으로 전환되어야 합니다. 카테고리별 체크리스트는 다음과 같습니다:

도구 정의 (Tool definitions): 도구를 노출하기 전에 그 영향 범위(blast radius)를 충분히 고려하십시오. 에이전트에게 임의의 SQL 실행, 로우 셸 명령(raw shell commands), 또는 제한 없는 HTTP 클라이언트 접근 권한을 부여하는 것을 피하십시오. 이러한 기능들은 모델이 안전하게 작동하기에는 너무 광범위합니다. 읽기 전용 도구와 상태를 변경(mutate)하는 도구를 분리하고, 모든 부수 효과(side effects)를 문서화하십시오.

인증 및 인가 (Authentication and authorization): MCP 서버에 연결하는 모든 클라이언트를 인증하십시오. 요청하는 사용자의 범위 내에서 도구 및 리소스별로 인가(authorization)를 강제하십시오. 한 서비스용으로 발급된 토큰을 다른 서비스로 절대 전달하지 마십시오. 모든 수신 토큰에 대해 대상(audience)을 검증하십시오.

허용 목록 및 입력 검증 (Allowlists and input validation): 각 도구가 사용할 수 있는 작업, 호스트, 경로 및 매개변수를 정의한 다음, 서버 측에서 해당 제약 조건을 강제하십시오. 모든 도구 인자(arguments)를 신뢰할 수 없는 입력으로 취급하십시오. 네트워크 기능이 활성화된 도구는 SSRF(Server-Side Request Forgery) 방지가 필요합니다.

변경 및 승인 게이트 (Mutation and approval gates): 쓰기, 삭제, 전송 또는 기타 방식으로 상태를 변경하는 도구가 실행되기 전에 명시적인 승인을 요구하십시오. 드라이 런(dry-run) 모드 및 하드 리밋(hard limits)과 같은 가드레일을 추가하십시오. 가능한 경우, 파괴적인 작업(destructive operations)을 되돌릴 수 있게 하거나 백업이 존재하도록 보장하십시오.

공급망 (Supply chain): 제3자 MCP 서버를 제3자 코드 의존성(dependencies)과 동일하게 취급하십시오. 실제로 그것이 바로 코드 의존성이기 때문입니다. 도구 정의를 고정(pin)하고 조용한 변경 사항을 모니터링하십시오. 자격 증명(credentials)과 비밀 정보(secrets)를 도구 정의 및 서버 응답에 포함하지 마십시오.

감사 및 로깅 (Auditing and logging): 호출자 신원(caller identity) 및 인자(arguments)와 함께 모든 도구 호출(tool invocation)을 기록하십시오. 인젝션 유도 동작(injection-driven behavior)처럼 보이는 호출을 포함하여, 비정상적인 패턴을 감지할 수 있는 모니터링 체계를 구축하십시오. 도구 정의(tool definitions)의 버전을 관리하고, 코드 리뷰와 동일한 엄격함으로 변경 사항을 검토하십시오.

실용적인 시작점

프로덕션 시스템에 MCP 도구(tooling)를 추가하고 있지만 아직 보안 제어 장치가 마련되지 않았다면, 가장 영향력이 큰 제약 사항부터 시작하십시오:

1. 도구 범위를 먼저 좁히십시오. 지나치게 광범위한 도구를 에이전트가 필요로 하는 작업만 수행할 수 있는 목적 특화형 도구로 교체하십시오.
2. 변이 게이트(mutation gate)를 추가하십시오. 상태를 변경하는 모든 도구는 실행 전 인간 참여(human-in-the-loop) 승인 단계를 거쳐야 합니다.
3. 토큰 대상(audience)을 검증하십시오. MCP 서버가 OAuth를 처리하는 경우, 다른 무엇보다 먼저 RFC 8707 대상 확인(audience checking)을 구현하십시오.

MCP의 설계는 강력한 기능을 빠르게 연결할 수 있도록 해줍니다. 하지만 동일한 설계 방식은 여러분이 연결하는 모든 서버의 보안 태세(security posture)가 에이전트의 신뢰 경계(trust boundary)의 일부가 된다는 것을 의미합니다. 정의 고정(pinning definitions), 권한 범위 제한(scoping permissions), 변이 제어(gating mutations), 호출 감사(auditing invocations)는 나중에 추가하는 강화 단계가 아니라, MCP를 프로덕션에서 운영하기 위한 기본 요건입니다.

이 가이드는 원래 agentpalisade.com에 게시되었습니다. Agent Palisade는 중소기업이 이미 사용 중인 도구 내에서 AI를 활용할 수 있도록 돕습니다 — 실용적인 자동화, 내부 어시스턴트, 그리고 AI 보안 검토를 지원합니다. 무료 30분 상담 예약하기.