MCP, 도구 사용(Tool Use), 그리고 아무도 파악하지 못한 새로운 공격 표면

에이전트(Agent)는 침해되지 않았습니다.

모델(Model)은 침해되지 않았습니다.

도구(Tool)도 침해되지 않았습니다.

모든 구성 요소는 설계된 대로 정확히 작동했습니다. 하지만 시스템은 아무도 승인하지 않은 동작을 실행했습니다.

이것은 전통적인 의미의 취약점(Vulnerability)이 아닙니다. 패치해야 할 구현 결함도 없었고, 취소해야 할 잘못 설정된 권한도 없었으며, 탐지해야 할 비정상적인 자격 증명(Credential) 활동도 없었습니다. 실패는 구성 요소 간의 권한 체인(Authority chain), 즉 사용자 요청을 세 개의 중간 계층을 거쳐 도구 실행으로 연결하는 위임 로직(Delegation logic)에서 발생했습니다. 그리고 현재 기업 아키텍처(Enterprise architecture)에는 이 체인을 관리하는 방법을 아는 규율이 존재하지 않습니다.

MCP — 모델 컨텍스트 프로토콜 (Model Context Protocol) — 은 이 문제를 구조적으로 만듭니다. 이는 기업이 현재 운영 중인 그 어떤 거버넌스(Governance) 모델보다 더 긴 위임 권한 체인(Delegated authority chains)을 도입합니다. 단순히 정도(Degree)의 차이가 아니라, 범주(Category)의 차이로 더 길어집니다.

프레임워크 #141 — 에이전트 권한 경계 (Agentic Authority Boundary)

에이전트 권한 경계(Agentic Authority Boundary)는 에이전트 시스템이 실행 권한을 위임할 수 있는 공식적인 한계를 정의하며, 이는 명시적인 범위(Scope), 신원(Identity), 소유권(Ownership), 그리고 취소 가능성(Revocability)에 의해 제한됩니다.

다음 네 가지 실패 상태는 경계가 붕괴되었음을 정의합니다:

실패 01 — 범위 확장 위임 (Scope Creep Delegation)
도구가 의도된 권한 범위를 벗어나 호출됨. 이를 방지할 선언된 범위 경계가 존재하지 않음.

실패 02 — 암묵적 신뢰 상속 (Implicit Trust Inheritance)
도구 서버(Tool server)가 오케스트레이터(Orchestrator)의 신원을 아무런 확인 없이 수용함. 도구는 정당한 호출과 상속된 자격 증명(Credentials) 하에서 작동하는 주입된(Injected) 호출을 구분할 수 없음.

실패 03 — 취소 불가능한 부여 (Non-Revocable Grant)
위임이 설정된 후 권한을 제한할 메커니즘이 존재하지 않음. 부여된 권한은 무언가가 재배포(Redeployed)될 때까지 지속됨.

실패 04 — 권한 체인의 불투명성 (Authority Chain Opacity)
실행 후 권한 이동을 재구성할 수 있게 해주는 증거 아티팩트(evidence artifact)가 존재하지 않음. 이는 로깅(logging)의 문제가 아니라 아키텍처(architecture)의 문제임. 실행 시점에 증거 기록이 생성되지 않는다면, 사고 발생 후의 어떤 로깅도 이를 재구성할 수 없음.

권한 체인의 불투명성(Authority Chain Opacity)은 포렌식 실패 상태(forensic-failure state)임. 나머지 세 가지 실패 상태는 경계가 어떻게 깨지는지를 설명함. 이 상태는 왜 아무도 그것이 깨졌는지 모르는지를 설명함.

대부분의 기업은 '누가 API 호출을 했는가?'라는 질문에는 답할 수 있음. 하지만 '그 뒤를 이은 도구 실행(tool execution)을 가능하게 한 권한 체인(authority chain)은 무엇인가?'라는 질문에 답할 수 있는 곳은 거의 없음.

MCP가 당신의 신뢰 모델(Trust Model)에 미치는 영향

전통적인 시스템은 경계(perimeter)에서 권한을 설정하고 이를 명시적으로 전달함. 사용자가 인증하면 자격 증명(credential)이 발급되고, 그 자격 증명이 요청과 함께 이동함. 권한 체인은 짧고, 동기적(synchronous)이며, 모든 홉(hop)에서 검사가 가능함.

에이전트 기반 시스템(Agentic systems)은 이 모델의 모든 부분을 깨뜨림:

속성	전통적인 실행 (Traditional Execution)	에이전트 기반 실행 (Agentic Execution)
신원 (Identity)	모든 홉에서 가시적임	간접적임 — 오케스트레이터(orchestrator)에 의해 상속됨
...

MCP는 도구 서버(tool servers)가 호출되는 프로토콜을 표준화하지만, 권한(authority)이나 위임(delegation)의 의미론(semantics)은 전혀 표준화하지 않음. 프로토콜은 전송(transport)을 제어할 뿐임. 아무도 신뢰(trust)를 제어하지 않음.

도구 서버는 또한 새로운 섀도우 IT(shadow IT) 벡터이기도 함. 개발자에 의해 배포되고, 에이전트에 의해 호출되며, 네트워크 보안 팀에게는 보이지 않음. 이를 포착할 인벤토리(inventory)가 존재하기도 전에 노출이 누적됨.

Five Eyes는 위협 모델(Threat Model)을 정확히 파악했으나, 거기서 멈췄다

2026년 5월 Five Eyes의 에이전트형 AI (Agentic AI) 공동 지침은 프롬프트 인젝션 (Prompt Injection), 도구 오용 (Tool Abuse), 그리고 통제되지 않은 에이전트 실행 (Uncontrolled Agentic Execution)을 주요 위험 범주로 정확히 식별했습니다.

하지만 이 지침이 제공하지 못하는 것은 대응을 실행에 옮기기 위해 필요한 아키텍처 계층 (Architectural Layer)입니다.

기업 보안 프로그램은 이미 알려진 위험 범주에 대해 성숙한 규율 (Disciplines)을 갖추고 있습니다:

기존 규율	관리 대상
ID 거버넌스 (Identity Governance)	누가 행동할 수 있는가
...

Five Eyes 지침은 증상을 식별했습니다. 위 증상들을 치료할 규율은 위임 거버넌스 (Delegation Governance)입니다. 위협 모델 (Threat Model)은 존재하지만, 거버넌스 모델은 존재하지 않습니다.

이를 구체화한 CVE

CVE-2025-49596 (CVSS 9.4)은 Anthropic의 자체 MCP SDK에서 활성화되어 있었습니다. OX Security는 공식 구현체에서 체계적인 RCE (Remote Code Execution) 경로를 문서화했습니다.

전통적인 취약점은 구현상의 결함 (Implementation Flaws)을 노출합니다. 구현을 패치하면 취약점이 닫힙니다.

MCP 취약점은 권한 모델 (Authority-model)의 결함을 노출합니다. RCE 경로가 존재했던 이유는 도구 서버 (Tool Server)의 입력이 어디에서 왔는지, 그리고 어떤 권한을 가졌는지에 대한 SDK의 신뢰 가정 (Trust Assumptions)이 명세 (Specification) 수준에서 잘못되었기 때문입니다. 구현은 명세와 일치했습니다. 명세가 신뢰 모델 (Trust Model)에 대해 틀렸던 것입니다.

구현 패치는 격차 (Gap)의 현재 발현 형태를 닫을 뿐입니다. 격차 자체를 닫지는 못합니다. 잘못된 권한 가정 하에 작동하는 패치된 SDK는, 동일한 가정이 미래에 어떤 형태로든 다시 발현될 경우 여전히 공격 가능합니다.

아키텍처에 실제로 필요한 것

#141의 네 가지 실패 상태에 직접 매핑된 통제 수단:

범위 확장 위임 (Scope Creep Delegation) → 권한 선언 (Authority Declarations)
도구 서버는 등록 시점에 명시적인 권한 범위 (Authority Scope)를 선언해야 합니다. 이는 기능 목록 (Capability List)이 아니라 권한 경계 (Authority Boundary)여야 합니다. 선언된 범위를 벗어난 호출은 기본 허용 (Default-permit)이 아닌 명시적인 권한 상승 (Elevation)을 요구해야 합니다.

암묵적 신뢰 상속 (Implicit Trust Inheritance) → 신원 격리 (Identity Isolation)
오케스트레이터 (Orchestrator)의 자격 증명 (Credential)이 도구 실행 컨텍스트 (Tool execution context)로 전이되어서는 안 됩니다. 도구 서버 (Tool server)는 상위 신원 (Upstream identity)이 아닌, 호출 자체를 인증해야 합니다.

취소 불가능한 권한 부여 (Non-Revocable Grant) → 취소 가능한 위임 범위 (Revocable Delegation Scopes)
위임 권한 (Delegation grants)은 명시적인 만료 및 취소 경로를 포함해야 합니다. 재배포 없이는 취소할 수 없는 도구 서버 등록은 프로토콜 래퍼 (Protocol wrapper)가 씌워진 영구적 권한 부여와 다름없습니다.

권한 체인의 불투명성 (Authority Chain Opacity) → 증거 수준의 실행 기록 (Evidence-Grade Execution Records)
모든 도구 호출은 다음 사항을 캡처하는 기록을 생성해야 합니다: 위임 체인 (Delegation chain), 호출 시점에 활성화된 권한 범위 (Authority scope), 각 계층의 신원 컨텍스트 (Identity context), 그리고 생성된 출력값 (Output). 이 기록은 사후에 재구성되는 것이 아니라, 실행 시점에 생성되어야 합니다.

인간 개입 (Human-in-the-loop) 게이트도 여기에 해당하지만, 배치가 중요합니다. 승인 요구 사항을 주관적으로 "민감한 (Sensitive)" 작업이 아니라, 권한 상승 (Authority elevation) 이벤트에 매핑하십시오. 선언된 경계를 넘어 권한 범위를 상승시키는 작업에는 인간의 승인이 필요합니다. "민감함"은 통제 가능한 모델이 아닙니다. 권한 범위 (Authority scope)가 통제 가능한 모델입니다.

실제 노출 지도 (The Real Exposure Map)

노출 계층 (Exposure Tier)	도구 소유 모델 (Tool Ownership Model)	권한 경계 조건 (Authority Boundary Condition)
낮음 (Low)	퍼스트 파티 (First-party) 도구만 사용	경계가 조직적임 — 기존 통제 수단을 통해 감사 가능
...

외부 MCP 서버를 사용하는 Copilot Studio, Bedrock Agents, n8n, 그리고 LangChain 기반 워크플로우는 중간(Medium)과 극심함(Extreme) 사이에 위치합니다. 극심한(Extreme) 단계에 있는 조직들은 종종 이를 인지하지 못합니다. 동적인 도구 발견 (Dynamic tool discovery)은 종종 경고 신호가 아닌 기능(Feature)으로 제공되기 때문입니다.

실제 노출 정도를 드러내는 질문은 다음과 같습니다: 당신의 에이전트 시스템 (Agentic systems)이 오늘 호출할 수 있는 모든 도구의 인벤토리를 생성할 수 있습니까? 여기에는 각 도구에 부여된 권한 범위와 해당 권한 부여가 취소 가능한지 여부도 포함되어야 합니다.

20년 전에는 그에 상응하는 질문이 다음과 같았습니다: 귀하의 환경에 있는 모든 권한 있는 계정(privileged account)의 인벤토리를 생성할 수 있습니까? 그 질문이 ID 거버넌스(identity governance)라는 전문 분야를 구축했습니다. 지금의 질문은 동일한 방식으로 위임 거버넌스(delegation governance)의 필요성을 구축하고 있습니다. 대부분의 조직은 이에 답할 수 없습니다. 그것이 바로 노출(exposure)입니다.

아키텍트의 판결 (Architect's Verdict)

MCP는 엔터프라이즈 아키텍처에 기존 거버넌스 패턴이 존재하지 않는 신뢰 위임 모델(trust delegation model)을 도입합니다. 프로토콜 자체가 문제는 아닙니다. 프로토콜이 가능하게 하는 것을 관리하는 데 필요한 규율(discipline)의 부재가 문제입니다.

기존의 모든 보안 통제(security control)는 실행 경계(execution boundary)가 네트워크 또는 ID 계층에서 가시적인 시스템을 위해 설계되었습니다. MCP는 실행 경계를 암시적이고(implicit), 동적이며(dynamic), 중간 시스템 체인을 통해 신뢰가 상속(trust-inherited)되도록 만듭니다. ID 거버넌스는 누가 인증(authenticated)했는지를 알려줍니다. API 거버넌스는 무엇이 호출(called)되었는지를 알려줍니다. 하지만 그 어느 것도 사용자 요청이 모델을 거쳐, 오케스트레이터(orchestrator)를 거쳐, 운영 시스템(production systems)에 대해 실행되는 도구로 권한이 어떻게 이동했는지는 알려주지 않습니다.

위임 거버넌스(Delegation governance)는 누락된 규율입니다. CVE-2025-49596은 이를 구축해야 하는 이유가 아니라, 그 부재에 이름이 붙기도 전부터 이미 부재가 악용되고 있었다는 증거입니다. 공격 표면(attack surface)은 실재합니다. 인벤토리는 존재하지 않습니다. 권한 체인(authority chains)은 작동하고 있습니다. 아무도 그것을 매핑(mapping)하고 있지 않습니다.

_원문 게시처: rack2cloud.com