MCP 거버넌스: 플러그인 중심의 세상에서 AI 에이전트를 보호하는 방법

AI 에이전트 배포의 역사에는 전과 후를 나누는 경계선이 존재하며, Model Context Protocol (MCP)이 바로 그 경계선입니다.

2026년 4월 20일, CIS는 Astrix 및 Cequence와 공동 저술한 MCP 보안 컴패니언 가이드(MCP Security Companion Guide)를 발표했습니다. 이는 CIS Controls v8.1을 MCP 환경으로 확장한 일련의 통제 항목입니다. 이 가이드를 촉발한 발견은 다음과 같습니다: MCP는 대부분의 기업 거버넌스 프레임워크가 아직 다루지 못하는 방식으로 에이전트의 ID, 액세스 제어(access control), 로깅(logging) 및 애플리케이션 보안 표면을 공식적으로 확장한다는 점입니다. 나흘 전, The Register는 보안 연구원들이 공식 MCP 구현에서 설계 결함을 기록했다고 보도했습니다. 그들의 분석에 따르면, 이 결함은 최대 200,000대의 서버를 위험에 빠뜨릴 수 있으며, 10개의 높음(high) 및 심각(critical) 등급의 CVE가 접수되었습니다. 만약 6개월 전까지 MCP 거버넌스가 당신의 관심사가 아니었다면, 이제는 반드시 고려해야 할 사항입니다.

**MCP 거버넌스 (MCP governance)**는 외부 도구 및 서비스에 연결하기 위해 Model Context Protocol을 사용하는 AI 에이전트에 대한 정책을 정의하고 집행하는 관행입니다. MCP는 표준화된 프로토콜을 통해 에이전트를 파일 시스템, 데이터베이스, API 및 통신 플랫폼에 연결함으로써 에이전트의 기능 표면(capability surface)을 극적으로 확장하기 때문에, 그에 비례하여 공격 표면(attack surface)과 거버넌스 요구 사항도 확장됩니다. MCP 거버넌스는 세 가지 계층에서 작동합니다: 도구 허용 목록(allowlisting) 및 범위 지정(scoping) (어떤 도구를 어떤 조건에서 호출할 수 있는지), 도구 결과 검사 (tool result inspection) (응답이 에이전트 컨텍스트에 들어가기 전에 스캔), 그리고 시퀀스 수준의 정책 평가 (세션 내 도구 간 패턴 추적)입니다. MCP가 속한 거버넌스 평면 (governance plane)에 대한 더 넓은 정의는 에이전트 거버넌스란 무엇인가 →를 참조하십시오.

MCP 이전에는 에이전트가 강력했지만 제한적이었습니다. 에이전트가 세상에서 할 수 있는 일은 개발자가 명시적으로 연결한 도구(tools)에 의해 제한되었습니다. 만약 그 도구들이 위험하다면 위험할 수는 있지만, 어쨌든 제한적이었습니다. MCP 이후에는 MCP 서버에 연결함으로써 에이전트의 역량을 동적으로 확장할 수 있습니다. 이 서버들 중 일부는 개발자가 선택한 것이지만, 일부는 다른 사용자, 다른 시스템, 또는 에이전트 생태계 자체에 의해 추가되었을 수도 있습니다. 이러한 동적 확장성(dynamic extensibility)이 MCP를 가치 있게 만드는 요소이며, 동시에 거버넌스(governance)를 선택이 아닌 필수 사항으로 만드는 요소입니다.

MCP가 실제로 변화시키는 것

핵심적인 변화는 다음과 같습니다. MCP 이전에는 에이전트의 역량이 개발자가 명시적으로 구성한 도구에 의해 배포 시점에 결정되었습니다. MCP 이후에는 MCP 서버에 연결함으로써 에이전트의 역량을 동적으로 확장할 수 있습니다. 이 서버들 중 일부는 개발자가 선택한 것이지만, 일부는 다른 사용자, 다른 시스템, 또는 에이전트 생태계 자체에 의해 추가되었을 수도 있습니다.

MCP 도입 속도는 대부분의 보안 팀이 예상했던 것보다 빠르게 진행되고 있습니다. Claude Code는 MCP 클라이언트(client)를 탑재하여 출시되었습니다. 개발자 도구들은 MCP 통합(integrations) 기능을 출시하고 있습니다. 엔터프라이즈 플랫폼들은 내부 시스템을 위한 MCP 서버(servers)를 구축하고 있습니다. 정교한 배포 환경에서 운영되는 대부분의 프로덕션 에이전트들은 향후 12~18개월 이내에 — 이미 그렇지 않더라도 — MCP를 통해 상당한 규모의 도구 생태계에 접근할 수 있게 될 것입니다.

거버넌스 측면에서의 함의를 명확히 말씀드리자면 다음과 같습니다. 에이전트가 명시적으로 구성된 5개의 도구를 가지고 있을 때는, 그 5개의 도구로 무엇을 할 수 있을지 추론할 수 있었습니다. 하지만 에이전트가 MCP를 통해 수십 개의 도구에 접근할 수 있게 되면 — 일부는 사용자가 설치한 것이고, 일부는 타인에 의해 추가되었으며, 일부는 마지막으로 검토했을 때와 역량이 달라졌을 수도 있습니다 — 추론의 문제는 근본적으로 달라집니다. CIS 가이드는 "비인간 아이덴티티 (Non-Human Identities, NHIs)"라는 개념을 도입합니다. 각 MCP 연결은 고유한 접근 범위(access scope)를 가진 비인간 아이덴티티이며, 대부분의 조직은 이들을 위한 레지스트리(registry)나 이들이 할 수 있는 일을 규제하는 정책을 갖추고 있지 않습니다.

MCP는 어떻게 AI 에이전트의 공격 표면(Attack Surface)을 확장하는가?

에이전트가 접근할 수 있는 모든 도구는 잠재적인 공격 표면(Attack Surface)입니다. 이는 도구 자체가 악의적이기 때문이 아니라, 어떤 도구든 의도하지 않은 결과를 초래하는 방식으로 호출될 수 있으며, LLM이 생성할 수 있는 호출(Invocation)의 범위가 매우 넓기 때문입니다.

도구 결과(Tool results)를 통한 프롬프트 인젝션 (Prompt injection). 이것은 보안 팀이 밤잠을 설치게 만들 만한 문제입니다. 2026년 3월, Oasis Security 연구원들은 "Claudy Day"라고 명명된 완전한 공격 파이프라인을 시연했습니다. 이 공격은 보이지 않는 프롬프트 인젝션과 데이터 유출(Data exfiltration)을 체인 형태로 연결하여, 별도의 수정이 없는 기본 claude.ai 세션에서도 대화 기록을 훔칠 수 있음을 보여주었습니다. 특별한 설정도, 권한 상승도 필요하지 않았습니다. 인젝션은 Claude의 ?q= URL 프리필(Pre-fill) 파라미터 내부에 보이지 않는 HTML 태그로 삽입되었습니다. 이는 채팅창의 사용자에게는 보이지 않지만, 사용자가 전송(Send)을 누르면 모델로 전체 내용이 전송됩니다. claude.com의 오픈 리다이렉트(Open redirect)를 악용한 Google Ads 캠페인을 통해 전달되었으며, 이후 Claude는 Files API를 통해 대화 기록을 공격자가 제어하는 Anthropic 계정으로 유출하도록 지시받았습니다. 이것은 단순한 침해 사고가 아니라, 에이전트의 컨텍스트(Context)로 들어오는 콘텐츠를 검사하지 않을 때 어떤 일이 가능한지를 보여주는 시연이었습니다. 도구 호출 결과(Tool call results)를 통해 에이전트에 프롬프트 인젝션이 유입되는 방식에 대한 더 심층적인 기술적 분석은 포스트 43에서 전체 메커니즘을 다룹니다.

승인되지 않은 도구 호출 (Unauthorized tool invocation). "이메일 전송" MCP 도구에 접근 권한이 있는 에이전트는 이메일을 보낼 수 있습니다. 문제는 다음과 같습니다: 어떤 조건 하에서 이메일 전송이 허용되어야 하는가? 만약 에이전트의 정당한 범위가 제품 질문에 답변하는 것이고, 좁은 범위의 알림 목적으로만 이메일 도구에 접근할 수 있다면, 다른 맥락에서 해당 도구를 호출하는 것을 무엇이 막을 수 있을까요? 도구가 언제 호출될 수 있는지를 정의하는 명시적인 정책(Policy)이 없다면, 그 답은 "모델의 판단"이 됩니다. 그것은 정책이 아닙니다. 그것은 단지 희망 사항일 뿐입니다.

도구 호출 시퀀스(tool call sequences)를 통한 데이터 유출 (Data exfiltration). 데이터베이스 쿼리 도구와 통신 도구에 접근 권한이 있는 에이전트는 민감한 데이터를 검색하여 외부로 전송할 수 있습니다. 이는 단 한 번의 극적인 행동이 아니라, 개별적으로는 경고를 발생시키지 않을 법한 그럴듯해 보이는 일련의 작업 시퀀스를 통해 이루어집니다. 이에 대응하려면 단순히 개별 호출(invocation)뿐만 아니라, 세션 내에서의 도구 호출 시퀀스와 도구 간 패턴(cross-tool patterns)에 대한 가시성이 필요합니다. 이것이 바로 CIS 가이드에서 말하는 "프로토콜 계층 전반에 걸친 감사 가능한 상호작용 (auditable interactions across the protocol layer)"입니다.

제한 없는 도구 사용으로 인한 비용 폭증. 일부 MCP 도구는 호출 비용이 비쌉니다. 코드 실행 환경, 대규모 데이터 검색, 요청당 과금이 발생하는 외부 API 호출 등 — 예상보다 공격적으로 이러한 도구들을 호출하거나, 비용이 많이 드는 도구가 포함된 루프에 빠진 에이전트는 비용을 빠르게 발생시킬 수 있습니다. 도구 호출 수준에서의 예산 집행 (budget enforcement at the tool call level) 없이는 사후에나 이를 알게 될 것입니다.

기존 에이전트 거버넌스가 MCP를 완전히 다루지 못하는 이유

LLM 호출에 대한 정책, 입출력 스캐닝, 세션 수준의 예산 가드레일(guardrails)과 같은 거버넌스 인프라를 갖추고 있다면 기초는 마련된 셈입니다. 하지만 MCP는 그 기초가 커버하지 못할 수도 있는 거버넌스 요구사항을 도입합니다.

동적인 도구 가용성 (Dynamic tool availability). 정적인 거버넌스 정책은 알려진 고정된 도구 세트를 가정합니다. MCP의 핵심은 도구 세트가 확장 가능하다는 점입니다. 여러분의 거버넌스 계층은 정책이 작성될 당시 범위에 없었던 도구들에 대한 호출도 처리할 수 있어야 합니다. 즉, 단순히 이름 기반의 허용 목록(allowlists)이 아니라, 도구 카테고리 전반에 걸쳐 일반화될 수 있는 정책이 필요함을 의미합니다.

도구 결과 신뢰 (Tool result trust). 기존의 스캐닝 방식은 사용자의 입력을 평가할 수도 있습니다. 하지만 MCP 도구 결과는 사용자가 아닌 서버로부터 전달되므로, 그 자체로 별도의 신뢰 평가를 거쳐야 합니다. 도구 자체가 정당하고 서버가 신뢰할 수 있는 상태라 하더라도, 도구 결과에는 악성 콘텐츠가 포함될 수 있습니다. '공격 표면으로서의 콘텐츠 (content-as-attack-surface)' 문제는 단순히 사용자 입력 계층이 아닌, 도구 결과 계층에서의 거버넌스를 요구합니다. 저장소 파일 내에 임베딩된 지침이 에이전트에 의해 공개되지 않은 채 검색되고 실행된 GitHub 코딩 에이전트의 프롬프트 인젝션 (prompt injection) 사례는 이를 보여주는 날카로운 예시입니다: GitHub AI Agent Prompt Injection: What No CVE Disclosure Looks Like.

교차 도구 시퀀스 분석 (Cross-tool sequence analysis). 개별적인 도구 호출은 무해할 수 있습니다. 하지만 도구 호출의 시퀀스(sequence)는 그렇지 않을 수 있습니다. 각 도구 호출을 개별적으로만 평가하는 거버넌스 계층은 패턴 수준의 위험을 놓치게 됩니다. 이를 위해서는 세션 수준의 분석 — 어떤 도구가, 어떤 순서로, 어떤 페이로드 (payload)와 함께 호출되었는지 추적하는 것 — 이 필요하며, 개별 이벤트가 아닌 시퀀스에 정책을 적용해야 합니다.

EU AI Act 부속서 III (시행 마감일: 2026년 8월 2일)에 따라, 고위험 AI 시스템의 배포자는 최소 6개월 동안 자동화된 로그를 보관하고 인간 감독 (human oversight) 메커니즘을 구현해야 합니다. 이 마감일을 연기하려던 2025년 11월 유럽 위원회의 제안은 법제화되지 않았으며 (Digital Omnibus 삼자 회담은 2026년 4월 28일에 결렬되었습니다), 2026년 8월이 여전히 유효한 시행일로 남아 있습니다. MCP 도구 호출 시퀀스는 바로 이러한 감사 추적 (audit trail) 요구 사항이 포착하도록 설계된 대상이며, 대부분의 기존 거버넌스 스택은 해당 수준에서 이를 기록하지 않습니다.

MCP 거버넌스의 실제 모습

실질적으로 말하자면, MCP 거버넌스는 세 가지 계층에서 작동합니다:

도구 허용 목록(Allowlisting) 및 스코핑(Scoping). 에이전트가 어떤 조건 하에, 어떤 매개변수 제약(parameter constraints)을 가지고 어떤 MCP 도구를 호출할 수 있는지 명시적으로 정의합니다. 이는 도구 접근에 대한 RBAC(Role-Based Access Control, 역할 기반 액세스 제어)입니다. 단순히 "에이전트가 이 도구에 접근할 수 있는가"를 넘어 "어떤 상황에서 접근할 수 있는가"를 다룹니다. 예를 들어, 에이전트가 파일을 읽을 수는 있지만 쓸 수는 없게 하거나, 지정된 테이블 집합 내에서만 데이터베이스를 쿼리하게 하거나, 특정 승인 조건이 충족될 때만 이메일 도구를 호출하도록 설정할 수 있습니다. Waxell의 MCP Gateway는 이를 인프라 수준에서 실행합니다. 테넌트당 하나의 URL이 모든 상위 MCP 설정을 대체하며, 도구 핑거프린팅(tool fingerprinting)을 통해 각 도구를 5가지 상태(Pending, Drift, Trusted, Blocked, Removed)로 추적합니다. 이를 통해 도구 정의가 변경될 경우 에이전트가 호출하기 전에 이를 포착할 수 있습니다. 직접 구축하는 에이전트의 경우, Waxell Observe를 통해 에이전트를 재빌드할 필요 없이 실행 전 50개 이상의 정책 카테고리를 강제할 수 있습니다.

도구 결과 검사(Tool result inspection). 에이전트의 컨텍스트(context)에 추가되는 모든 도구 호출 응답은 처리되기 전에 검사 단계를 거쳐야 합니다. 인젝션(injection) 패턴을 스캔하고, 컨텍스트에 유입되어서는 안 되는 PII(개인정보, Personally Identifiable Information)가 있는지 확인합니다. 응답이 예상된 스키마(schema)를 준수하는지 검증하며, 이상 징후가 발견되면 검토를 위해 플래그를 표시합니다. MCP Gateway는 이를 네트워크 계층에서 처리합니다. 해당 게이트웨이의 프롬프트 인젝션 스캐너(prompt injection scanner)는 핑거프린팅 시점(에이전트 호출 전)에 도구 설명을 검사하며, PII 레드액션(redaction, 비식별화)은 민감한 데이터가 모델에 도달하지 않도록 전송 과정에서 제거합니다. API 키, 토큰, 자격 증명과 같은 비밀 정보(Secrets)는 게이트웨이에서 차단되어 외부로 유출되지 않습니다.

시퀀스 수준의 정책 평가 (Sequence-level policy evaluation). 세션 내의 도구 호출 (tool call) 시퀀스를 추적하고, 이를 세션 수준의 정책에 따라 평가합니다. 예를 들어, 하나의 세션 내에서 3개 이상의 서로 다른 외부 엔드포인트가 호출되면 검토 대상으로 표시하라는 정책을 세울 수 있습니다. 또는, 데이터베이스 읽기 작업이 발생한 후 N회 이내의 턴(turn) 안에 외부 호출이 발생하면 승인을 요구할 수도 있습니다. 이는 호출 수준 (call-level)의 결정이 아닌, 세션 수준 (session-level)의 거버넌스 결정입니다.

직접 구축하지 않은 MCP 서버들 — 마켓플레이스 서버, 벤더 제공 통합 서비스, 제3자 데이터 커넥터 등 — 을 관리하는 팀의 경우, MCP Gateway를 통해 이 모든 것 앞에 단일화된 관리 엔드포인트를 배치할 수 있습니다. 이 게이트웨이는 160개 이상의 업스트림 커넥터를 지원하며, 모든 tools/call은 업스트림에 도달하기 전에 신원이 확인(identity-resolved)되고 정책 검사(policy-checked)를 거칩니다. 20만 개의 서버를 위험에 빠뜨린 MCP STDIO 설계 결함은 왜 외부 MCP 서버의 거버넌스가 서버 자체의 제어 기능 구현에 의존해서는 안 되는지를 보여주는 명확한 사례입니다.

왜 지금이 MCP 거버넌스를 구축할 적기인가?

MCP는 아직 초기 단계이기에 거버넌스 도구를 포함한 주변 툴링 생태계가 여전히 구축되고 있는 중입니다. CIS MCP 보안 가이드가 발행된 이유는 기업들이 MCP를 배포하면서 감사 추적 (audit trails), SSO 통합 인증 (SSO-integrated auth), 게이트웨이 동작, 그리고 설정 이식성 (configuration portability)과 같은 예측 가능한 문제들에 직면하고 있기 때문입니다. 이 가이드가 존재한다는 것은 그만큼의 수요가 있었다는 뜻이며, 그 수요는 실제 운영 환경의 배포 과정에서 발생하는 실제적인 거버넌스 공백을 반영합니다.