MCP 보안: 20만 개의 취약한 인스턴스가 거버넌스된 모듈을 구매 기준으로 만드는 이유

공개

2026년 4월과 5월, OX Security는 명령어 주입과 원격 코드 실행을 가능하게 하는 모델 컨텍스트 프로토콜(MCP) STDIO 구성의 시스템적 아키텍처 결함을 공개했습니다. 이 권고는 MCP 공급망 전반의 10개 CVE — 약 20만 개의 취약한 인스턴스, 1억 5천만 다운로드에 영향 — 를 다룹니다. 취약점은 단일 패키지에 있지 않습니다. 대부분의 커뮤니티 MCP 서버가 함께 출시되는 기본 구성 패턴에 있습니다.

Cloud Security Alliance는 자사 연구 노트에 "MCP 보안 위기: AI 에이전트 인프라의 시스템적 설계 결함"이라는 제목을 붙였습니다. OWASP는 MCP Top 10 프로젝트를 출범하여 MCP 지원 시스템 수명 주기 전반에서 가장 중요한 보안 우려사항을 목록화했습니다. Aembit는 전송 위험과 공급망 위협을 다루는 가이드를 발행했습니다. TrueFoundry는 MCP 보안 위험과 모범 사례에 대한 엔터프라이즈 가이드를 발행했습니다.

이들 모두에 공통된 패턴: 취약점 표면은 커뮤니티 MCP 서버가 프로덕션 시스템이 요구하는 거버넌스 레이어 없이 구축되고 배포되기 때문에 존재합니다.

취약점이 실제로 무엇인가

MCP 서버는 전송을 통해 AI 에이전트 클라이언트와 통신합니다. STDIO 전송 — 로컬 개발과 많은 프로덕션 배포의 기본값 — 은 표준 입력과 출력을 통해 메시지를 전달합니다. OX Security 공개는 일반적인 STDIO 구성 패턴이 명령어 주입을 허용함을 식별했습니다: 조작된 입력이 MCP 서버를 실행하는 호스트에서 임의의 명령어를 실행할 수 있습니다.

이것은 이론적인 공격 경로가 아닙니다. MCP 서버는 에이전트 클라이언트와 동일한 머신에서 동일한 프로세스 권한으로 실행됩니다. STDIO를 통해 받은 입력을 기반으로 셸 명령어를 받아 실행하는 서버는 구조적으로 원격 코드 실행 표면입니다. 20만 인스턴스 추정치는 커뮤니티 MCP 채택의 규모를 반영합니다 — 레지스트리에 게시되고, 저장소에서 복제되고, 프로덕션용으로 결코 강화되지 않은 기본 구성으로 배포된 서버들입니다.

Backslash Security는 별도로 MCP 2026-07-28 릴리스 후보 자체가 도입한 세 가지 새로운 공격 표면 — 20일 후에 확정되는 바로 그 스펙 — 을 식별했습니다. 새로운 역량(서버 렌더링 UI, 장기 실행 작업, 헤더 기반 라우팅)은 보안 커뮤니티가 여전히 매핑 중인 새로운 진입점을 만듭니다.

왜 커뮤니티 서버가 노출인가

대부분의 커뮤니티 MCP 서버는 역량을 시연하기 위해 구축됩니다 — 에이전트를 도구에 연결하고, 결과를 반환합니다. 이들은 운영되도록 구축되지 않았습니다. 프로덕션 시스템이 요구하는 거버넌스 통제가 기본적으로 부재합니다:

• 감사 로깅 없음. 도구 호출이 요청, 응답, 지연, 결과와 함께 로깅되지 않습니다. 인시던트가 발생하면 재구성할 추적이 없습니다.
• 속도 제한 없음. 도구가 제한 없이 호출될 수 있습니다. 손상되거나 오작동하는 에이전트가 업스트림 API 할당량을 소진하거나 대규모로 의도치 않은 부작용을 유발할 수 있습니다.
• 타입화된 오류 계약 없음. 오류가 문자열이나 비구조화된 응답으로 반환됩니다. 에이전트는 일시적 실패와 영구적 실패를 구분할 수 없고, 운영자는 인시던트를 프로그래밍 방식으로 분류할 수 없습니다.
• 킬 스위치 없음. 운영자 런북도, 폴백 경로도, 오케스트레이션 백본을 건드리지 않고 모듈을 비활성화할 방법도 없습니다.
• 테스트 커버리지 없음. 오류 경로가 테스트되지 않았습니다. 개발 중에 결코 실행되지 않은 실패 모드가 바로 프로덕션에서 발생하는 것입니다.

이것들은 이색적인 보안 요구사항이 아닙니다. 어떤 프로덕션 API든 강제하는 것과 동일한 통제입니다. 문제는 MCP 서버가 프로덕션 통합이 아니라 개발 유틸리티인 것처럼 배포되고 있다는 점입니다.

거버넌스된 모듈은 어떤 모습인가

우리가 발행하는 MCP 모듈 코드 표준은 이러한 각 격차를 해결하는 거버넌스 레이어를 정의합니다. 이 표준은 보안 프레임워크가 아닙니다 — 보안을 강제 가능하게 만드는 코드 표준입니다. 통제는 구체적입니다:

감사 로깅. 모든 도구 호출은 타임스탬프, 에이전트 ID, 도구 이름, 입력 해시(원시 입력이 아닌 — PII 경계), 출력 상태, 지속 시간, 업스트림 시스템을 로깅합니다. 로그는 관측 가능성 파이프라인으로 전송되는 구조화된 JSON입니다. 인시던트가 발생하면 감사 추적이 요청 인수와 핸들에서 전체 워크플로 상태를 재구성합니다 — 세션 저장소 로그와의 상관관계 분석이 필요 없습니다.

속도 제한. 각 도구는 등록 호출에서 자체 속도 제한을 선언합니다. 백본은 에이전트별, 도구별, 윈도우별로 제한을 강제합니다. 제한에 도달하면 에이전트는 Retry-After 헤더가 있는 429 응답을 받습니다 — 충돌하거나 맹목적으로 재시도하지 않습니다. 속도 제한이 업스트림 API가 아닌 모듈 경계에서 강제되기 때문에 손상된 에이전트는 업스트림 할당량을 소진할 수 없습니다.

타입화된 오류 계약. 모듈은 날 문자열이 아닌 타입화된 예외 — MCPAuthError, MCPRateLimitError, MCPTimeoutError, MCPValidationError, MCPUpstreamError — 를 발생시킵니다. 백본은 이를 잡아 에이전트가 추론할 수 있는 구조화된 응답으로 변환합니다. 모든 오류가 코드를 지니기 때문에 운영자는 인시던트를 프로그래밍 방식으로 분류할 수 있습니다.

PII 경계 처리. 모듈은 어떤 입력 필드에 PII가 포함되는지 선언합니다. 백본은 로깅 전에 이 필드들을 해시(SHA-256)하고, 원시 PII를 감사 파이프라인에 보내지 않습니다. 도구 핸들러는 여전히 원시 값을 받습니다 — PII 처리는 비즈니스 로직 내부가 아니라 로깅 경계에서 강제됩니다.

테스트 커버리지. 모든 도구는 요청/응답 테스트와 오류 경로 커버리지를 가집니다. 통합 테스트는 샌드박스 환경에 대해 실행됩니다. 모의 테스트는 도구 등록, 인수 매핑, 응답 정규화, 오류 전파, 상태 전환을 검증합니다. 개발 중에 결코 실행되지 않은 실패 모드는 출시되지 않습니다.

38개 도구 증명 사례

이 통제들은 이상적인 목표가 아닙니다. 이들은 mcp_hospirfq_processor의 구조입니다 — 완전한 RFQ 수명 주기에 걸쳐 38개 도구를 등록하는 모듈: 요청 생성, 카탈로그 검색, 견적 생성, 가격 계층, 가용성 확보, 취소 정책, 번들 발견, 주문 인계.

모듈의 오류 핸들러는 모든 실패 모드에 대해 타입화된 오류 코드 — GRAPHQL_QUERY_FAILED, VALIDATION_FAILED, HOLD_NOT_FOUND, HOLD_ALREADY_EXPIRED, AVAILABILITY_INSUFFICIENT, PRICING_MODE_UNSUPPORTED — 를 정의합니다. 각 오류는 코드와 구조화된 세부사항을 지닙니다. handle_errors 데코레이터가 모든 도구 메서드를 래핑하므로 어떤 도구도 비구조화된 예외를 반환하지 않습니다. 상태 관리자는 유효한 상태 전환을 강제합니다 — 확보는 확인, 해제, 또는 만료될 수 있지만, 초기에서 완료로 건너뛸 수 없습니다.

이것이 실제로 거버넌스된 모듈의 모습입니다: 모든 도구에 스키마가 있고, 모든 오류에 코드가 있고, 모든 호출에 로그가 있고, 모든 상태 전환에 검증기가 있습니다. 거버넌스는 누군가 읽을 수도 있는 문서가 아니라 코드 안에 있습니다.

킬 스위치 아키텍처

거버넌스 레이어는 모듈을 넘어 오케스트레이션 백본까지 확장됩니다. 엔지니어링 브리프는 운영 자세를 명시합니다:

• 운영자 런북. 배포, 롤백, 인시던트 응답, 일반적 작업이 문서화됩니다. 모듈이 오작동하면 운영자는 Slack 스레드가 아니라 런북을 따릅니다.
• 폴백 경로. 백엔드를 사용할 수 없을 때 우아한 저하. 업스트림에 도달할 수 없는 모듈은 구조화된 오류를 반환하고, 에이전트는 폴백 도구로 라우팅하거나 사람에게 에스컬레이션합니다.
• 피처 플래그 롤아웃. 모듈은 환경별로 활성화됩니다. 모듈은 오케스트레이션 백본을 건드리지 않고 비활성화될 수 있습니다 — 킬 스위치는 코드 배포가 아니라 구성 변경입니다.
• 관측 가능성. 구조화된 로그, 메트릭, 트레이스가 모니터링 스택으로 전송됩니다. 에이전트의 동작은 엔드투엔드로 감사 가능합니다 — 기업이 재무 통제에 적용하는 것과 같은 자세입니다.

킬 스위치 아키텍처는 OX Security 공개가 20만 개의 커뮤니티 서버에서 누락된 것으로 드러낸 통제입니다. 취약점이 공개되면 운영자의 첫 질문은: 에이전트를 다운시키지 않고 이 모듈을 비활성화할 수 있는가? 거버넌스된 배포에서는 답이 예입니다. 커뮤니티 서버 배포에서는 답이 보통 아니오입니다 — 서버가 에이전트의 도구 목록에 연결되어 있어, 제거하려면 코드를 편집하고 재배포해야 합니다.

왜 지금 이것이 구매 기준인가

PwC 2026 글로벌 CEO 설문조사(CEO 4,454명)는 조직의 56%가 AI로부터 측정 가능한 재무적 이익을 보고하지 못한다는 사실을 발견했습니다. WRITER 엔터프라이즈 AI 채택 설문조사는 기업의 35%가 AI 에이전트가 배포되면 플러그를 뽑을 수 없음을 발견했습니다. 이 조합이 구매 기준입니다: 비활성화할 수 없는 시스템은 부채이고, 측정 가능한 이익을 내지 못하는 시스템은 비용입니다. 거버넌스 — 감사 로그, 속도 제한, 타입화된 오류, 킬 스위치 아키텍처 — 는 AI 에이전트를 안전하게 배포하고 안전하게 폐기할 수 있게 만드는 통제입니다.

Gartner는 2026년 말까지 불충분한 AI 위험 가드레일로 인한 "AI에 의한 죽음" 법적 청구가 2,000건을 초과할 것으로 예측합니다. EU AI법은 2026년 8월 2일 — 오늘로부터 25일 후 — 완전히 적용됩니다. 제50조 투명성 규칙은 AI 생성 콘텐츠 공개를 요구합니다. 위험 분류, 문서화, 기록 보관이 고위험 시스템에 의무화됩니다. 거버넌스된 모듈이 이미 함께 출시하는 감사 로그와 운영자 런북은 EU AI법이 요구할 규정 준수 증거입니다.

MCP 2026-07-28 스펙은 20일 후에 확정됩니다. 출시되면 "Model Context Protocol"에 대한 검색과 인용 볼륨이 급증할 것이며 — 보안 표면에 대한 정밀 조사도 마찬가지입니다. 거버넌스 기준을 충족하지 못하는 커뮤니티 서버가 표시될 것들입니다.

결정

팀이 MCP 기반 에이전트 배포를 평가할 때, 질문은 더 이상 "연결되는가?"가 아닙니다. 커뮤니티 서버는 연결됩니다. 질문은: 무언가 잘못되면 그것을 볼 수 있고, 멈출 수 있고, 무슨 일이 있었는지 증명할 수 있는가?

거버넌스된 모듈은 세 가지 모두에 예라고 답합니다. 커뮤니티 서버는 기본적으로 세 가지 모두에 아니오라고 답합니다. 20만 개의 취약한 인스턴스가 그 증거입니다.

---

NetSuite, BigCommerce, 세 개의 공급업체 카탈로그를 운영하는 유통업체는 이메일 또는 포털로 RFQ를 수신하고, 카탈로그 그래프에 대해 제품과 대체품을 해결하고, 고객 계층별로 가격을 책정하고, 만료와 함께 재고를 확보하고, 승인된 견적을 NetSuite에 다시 기록하는 에이전트를 얻습니다 — 모든 단계가 로깅되고, 모든 도구가 속도 제한되며, 모든 모듈이 구성으로 비활성화 가능합니다. 그 빌드는 4단계 메서드의 23단계이며 일반적으로 58주 내에 라이브됩니다.

범위 정의 빌드를 요청하세요. 1주 발견. 시스템 인벤토리, 워크플로 맵, 고정 범위를 받습니다 — 우리와 빌드할지 여부와 관계없이.