MCP 보안은 도구 승인 이후부터 시작됩니다 | Focused Labs

프로덕션 환경을 위해 MCP 서버를 한 번 승인하는 것은 MCP 보안의 첫 단계일 뿐입니다. 진짜 위험은 그 이후, 모델이 상호작용하는 접점(surface)이 느리지만 근본적으로 변할 때 발생합니다.

읽기 전용(read-only) 고객 조회 도구가 데이터 내보내기(export) 도구로 변합니다. 데이터베이스 헬퍼(database helper)에 필수적인 raw-SQL 파라미터가 추가됩니다. 로컬 파일 검색 도구가 외부 API를 호출하기 시작합니다. 동일한 서버, 동일한 연결, 그리고 최초 승인 화면에서 받았던 동일한 녹색 체크 표시가 유지됩니다.

이 에이전트(agent)는 지난 화요일에 부여된 승인을 기억하지 못합니다. 런타임(runtime) 시점에 에이전트가 보는 것은 현재의 도구 설명(tool description), 현재의 스키마(schema), 현재의 반환 형태(return shape), 그리고 현재의 어포던스(affordance, 즉 도구가 모델에게 허용하는 행위)뿐입니다. 그러면 에이전트는 그에 따라 행동합니다.

이것이 바로 MCP가 직면하게 될 런타임 보안 문제입니다.

도구 메타데이터는 런타임 권한입니다

MCP 도구 명세(spec)는 도구가 모델에 의해 제어된다는 점을 명시적으로 언급합니다. 즉, 언어 모델(language model)이 컨텍스트와 프롬프트(prompt)를 기반으로 도구를 자동으로 발견하고 사용할 수 있다는 의미입니다. 공식 MCP 서버 도구 명세(official MCP server tools specification)에 따르면, 도구 목록이 변경되었을 때 클라이언트에 알리는 서버를 위해 tools/list 및 tools/call과 더불어 notifications/tools/list_changed가 존재합니다.

이 작은 프로토콜 구조가 중요합니다. 도구 정의(tool definition)는 더 이상 팀이 API 옆에 작성해 두는 문서가 아닙니다. 그것은 API가 지원하는 행동의 세계에 대해 모델에게 가르치기 위해 생명력을 불어넣은 API의 문서(documentation)입니다.

설명(description)은 모델에게 도구의 의도(intent)를 알려줍니다. 입력 스키마(input schema)는 모델에게 질문을 하기 위해 도구를 어떻게 사용하는지 알려줍니다. 어노테이션(annotations)은 호스트(host)와 사용자 인터페이스(user interface)에 도구가 어떻게 동작하는지 알려줍니다. 마지막으로, tools/call로부터의 응답은 에이전트(agent)의 다음 단계를 위한 증거(evidence)가 됩니다. LangChain과 같은 프레임워크를 사용하면, 예를 들어 팀은 MultiServerMCPClient.get_tools()를 사용하여 클라이언트를 위한 모든 MCP 도구를 가져온 다음, 현재 LangChain용 MCP 가이드current LangChain MCP guide에서 설명된 대로 이를 create_agent()에 전달할 수 있습니다. 이는 유용한데, 도구 표면(tool surface)이 변경되면 이제 에이전트의 실행 가능한 동작(executable behavior)의 변경으로 직접 매핑되기 때문입니다.

저는 MCP가 서로 다른 것들을 통합하는 작업을 유사하게 만들어 주기 때문에 좋아합니다. Focused가 최근 기사에서 주장했듯이, MCP는 통합 작업을 런타임 작업으로 만듭니다 MCP turns integration into runtime work. 그리고 맞습니다, 통합 작업의 형태가 공유된다고 해서 해당 런타임 작업의 안전성이 자동으로 보장되는 것은 아닙니다. 하지만 그것은 보안을 강화할 가치가 있게 만듭니다.

승인은 스냅샷입니다

허가 시점(admission-time)의 제어는 허가 시점에 특정 서버에 연결하는 것이 안전할지 여부에 대한 좁은 질문에 답합니다. 허가 시점 제어에는 서버 자체에 대한 정보(예: 서버의 신원)뿐만 아니라 다양한 신뢰 루트(trust roots), 서명 정보, 서버를 위한 레지스트리(registry), 서버를 위한 스코프(scopes), 그리고 서버를 위해 인간 관리자가 내린 다양한 인간의 동의 결정이 포함됩니다. 이러한 허가 시점의 보안 결정을 내리는 것은 좋습니다.

더 최신의 질문은 이것입니다: 호출 시점에, 호출을 수행하기 위해 실행 중인 도구가, 허가 시점 보안이 이미 한참 전에 지나간 상태에서, 호출이 이루어지는 서버에 대해 팀이 승인했던 역량 표면(capability surface) 내에 여전히 머물러 있는가 하는 점입니다.

이 문제는 최근 승인 시점 보안 이후의 런타임 도구 드리프트 탐지 (runtime tool drift detection after admission-time security)에 관한 MCP 커뮤니티 토론(2026년 5월)에서 제기되었습니다. 승인 시점(admission-time) 보안 검사는 서버의 신원, 서버가 올바른 신뢰 경계(trust boundary) 내에 있는지 등을 확인합니다. 하지만 일단 연결이 이루어진 후에는, 해당 서버에 연결된 도구가 읽기 전용(read-only)에서 완전한 변경 가능(mutate) 도구로 바뀌거나, 새로운 개인정보(PII) 데이터 클래스를 추가하는 등의 변화가 발생할 수 있으며, 서버의 신원은 나중에 변경될 때까지 바뀌지 않습니다.

OWASP는 이러한 유형의 공격을 MCP 서버를 승인한 후 서버가 도구 정의(tool definitions)를 변경할 수 있는 '러그 풀(rug pull)'이라고 부릅니다. OWASP MCP 보안 치트 시트 (OWASP MCP Security Cheat Sheet)는 이 문제를 식별하고 도구 오염(tool poisoning), 도구 섀도잉(tool shadowing), 혼동된 대리인(confused deputy), 과도한 권한의 토큰(over-scoped tokens), 재전송 공격(replay attacks), 그리고 샌드박스 탈출(sandbox escapes)을 포함한 더 넓은 MCP 공격 표면(attack surface)을 나열합니다. 이 치트 시트는 도구 정의를 해싱(hashing)하거나 고정(pinning)하고, 도구 설명, 함수 및 저장 프로시저 레지스트리(description, parameter names, parameter types, return schemas 포함)의 변경 사항에 대해 경고를 보낼 것을 제안합니다. 이것이 이 범주의 문제에 대한 합리적인 MCP 보안 모범 사례의 기초입니다. 전체 도구 정의를 보안 민감 자료로 취급하십시오.

승인은 스냅샷입니다. 런타임 보안은 실제로 실행된 도구를 검사합니다.

런타임은 역량 매니페스트(capability manifest)를 보유해야 합니다

승인된 역량 매니페스트(capability manifest)는 도구 호출 전의 런타임 거버넌스 (runtime governance before the tool call)를 위한 유용한 프리미티브(primitive)입니다. 이 프리미티브는 단순히 서버를 환경에 배포하기 전에 승인받아야 하는 서류 작업이 아닙니다. 이는 런타임(Runtime)이 어떠한 도구 호출을 실행하기 전에 실제 서버/도구 인터페이스(surface)와 비교할 수 있는 아티팩트(artifact)입니다.

역량 매니페스트에 무엇을 포함할지에 대한 실질적인 세부 사항은 추후 결정될 수 있지만, 현재로서는 서버 도구에 대한 단순하고 승인된 역량 매니페스트가 필요합니다. 이것은 단순한 종이 문서가 아니라, 런타임이 도구를 실행하기 전에 대조하여 확인할 수 있는 아티팩트입니다. 이를 이해하는 간단한 방법은 드리프트(drift, 차이)가 발생할 수 있는 지점들에 대응하는 필드 목록으로 보는 것입니다. 설명(description) 필드는 모델을 유도하고, 입력(input) 및 출력(output) 스키마(schema) 필드는 새로운 경로를 열며, 효과(effects) 필드는 조회(lookup)의 성격을 변화시키고, 민감한 데이터를 위한 데이터 클래스(data classes)는 메타데이터 호출을 개인 데이터 호출로 변경합니다. 이 모든 필드는 반드시 사람이 승인해야 합니다. 하지만 새로운 선택적 설명(optional description) 필드에 대한 승인이 CISO(정보보호최고책임자)에게 보고서를 제출해야 할 정도의 일일 필요는 없습니다. 반면, 새로운 필수 입력 파라미터(input parameter), 외부 목적지(external destination), 민감한 데이터 클래스, 또는 선언된 효과(declared effect)에 대한 승인은 해당 도구의 인터페이스가 승인된 인터페이스와 일치(reconciled)될 때까지 해당 도구를 격리(quarantine)해야 합니다.

관리 대상 도구들의 런타임 인터페이스(runtime surface)는 실행 전, 즉 새로운 도구 정의가 관리되는 도구 세트에 추가되는 시점만큼이나 이른 시점에 서버의 매니페스트와 비교됩니다. 새로운 인터페이스가 승인된 매니페스트와 동일해 보입니까, 아니면 별도로 분류되어야 할 다른 형태입니까?

분류하십시오. 도구의 이름에 대한 미미한 변경 사항은 조직의 CISO(최고 정보 보안 책임자)나 보안 팀의 관심을 거의 끌지 못할 것입니다. 그러나 새로운 선택적 문자열 필드(optional string field)는 승인 팀의 검토를 필요로 할 수 있습니다. 예를 들어, 새로운 필수 파라미터(required parameter), 외부 목적지(external destination), 민감한 데이터 클래스(sensitive data class), 또는 현재 메타데이터를 읽기 전용으로 조회하여 로그나 대시보드에 결과를 출력하는 역할만 수행하던 도구의 선언된 효과(declared effects)가 증가하는 경우에는, 해당 도구의 표면(surface)이 사람에 의해 조정(reconcile)될 때까지 도구를 격리(quarantine)해야 합니다.

이 지점이 바로 도구 호출 전의 런타임 거버넌스 (runtime governance before the tool call)가 단순한 정책 그 이상인 이유입니다. 런타임은 호출을 허용하거나, 호출을 거부하거나, 사람에게 입력을 요청하거나, 또는 서버가 배포된 승인된 표면과 일치하도록 적절한 구성으로 복구되는 동안 도구를 격리 모드(isolated mode)에 둘 것입니다.

배포 전 도구 기능에 대한 감사(Auditing)는 여전히 유효합니다. 과도한 권한을 가진 도구 기능에 대한 MCP 서버 감사 (Auditing MCP Servers for Over-Privileged Tool Capabilities) (논문 “mcp-sec-audit”)에서 저자들은 MCP 서버 기능의 코드와 메타데이터를 감사하기 위한 프로토콜 인식 툴킷(protocol-aware toolkit)을 설명합니다. 이 논문은 감사를 위한 정적 규칙(static rules)뿐만 아니라 Docker 및 eBPF를 사용한 동적 샌드박싱(dynamic sandboxing)에 대한 설명도 함께 제공합니다. 드리프트(drift)에 대한 런타임 탐지와 대조적으로, 이러한 종류의 감사는 서버가 실제로 사용될 환경에 진입하기 전에 수행되도록 설계되었습니다. 그 후 서버의 보고 내용이 오래되어 유효하지 않게 되면 런타임 드리프트 탐지가 역할을 이어받습니다.

변경 사항을 나열하는 것만으로는 충분하지 않습니다

현재 MCP 구현에는 이미 notifications/tools/list_changed라는 신호(signal)가 존재합니다. 이 신호는 서버가 명세서의 도구 기능 섹션에 사용 가능한 도구가 있음을 클라이언트에게 알릴 수 있게 해주므로 유용합니다. 우리는 이 신호를 있는 그대로, 즉 보안 제어(security control)가 아닌 신호로서 사용할 것입니다.

지연된 MCP 도구 로딩 (lazy MCP tool loading)과 관련해서도 유사한 아이디어가 이미 제기된 바 있습니다. 승인된 모든 개별 도구의 설명을 컨텍스트 윈도우 (context window)에 로드하는 것은 모델의 집중력을 해친다는 주장이 이미 있었습니다. 하지만 승인은 되었으나 사용되지 않는 도구들의 설명으로 컨텍스트 윈도우를 채우는 것은 훨씬 더 나쁜 결과를 초래할 것입니다. 왜냐하면 각 도구가 단순히 자리만 차지하는 것이 아니라, 프롬프트(prompt)를 통해 권한을 행사할 수 있는 상태가 되기 때문입니다. 대신 모델과 관련된 가장 작은 도구 집합만 로드하고, 각 도구의 호출을 현재의 증거(evidence)에 결합해야 합니다.

신뢰의 느낌보다는 호출당 영수증이 낫습니다

(승인 대화 상자의 스크린샷 한 장이 아무리 멋지다 하더라도) 보안 팀의 사고 대응 (incident response) 과정에서 그 스크린샷 하나만으로 사고를 디버깅하는 것은 불가능할 것입니다. 그들에게는 실제 호출 기록이 필요합니다.

저는 또한 호출당 서명된 기록 (per-call signed records)을 검토했습니다. GitHub의 논의는 강력하게 그 방향을 가리키고 있습니다: 입력(input), 결과(outcome), 효과(effects), 권한 부여 결정(authorization decision), 위험 결정(risk determination), 그리고 해당 호출에 대해 내려진 결정까지 거슬러 올라가는 해시 체인(hash chain)이 필요합니다. 드리프트 탐지기 (drift detector)는 재계산 가능한 증거를 생성합니다: 승인된 표면 해시 (approved surface hash), 현재 표면 해시 (current surface hash), 분류된 차이 (classified delta), 정책 결정 (policy decision), 그리고 관찰된 효과 (observed effect)입니다.

런타임 (runtime)은 결정, 호출, 그리고 효과에 대한 영수증을 남겨야 합니다.

Focused는 이러한 이유로 이 개념을 부작용 원장 (side-effect ledger)이라는 용어로 부릅니다. "로그 (Log)"는 우리가 여기서 필요로 하는 것을 설명하기에 너무 약한 단어입니다. 로그는 단순히 무언가가 발생했다는 사실을 보고할 뿐입니다. 반면, 영수증 (receipt)은 내려진 결정, 작업 키 (operation keys), 도구 버전 (tool versions) 등에 대한 기록과 그 결정의 결과(effects), 그리고 잘못된 결정으로 인해 발생한 피해를 어떻게 되돌릴 수 있는지에 대한 기록을 포함합니다.

이는 다음 논점으로 바로 이어집니다. 이미 확인했듯이, MCP 경계를 가로지르는 추적 증거 (trace evidence across the MCP boundary)가 필요합니다. tools/call에서 멈춰버리는 에이전트 추적 (agent trace)은 프로덕션 팀이 조사하는 데 필요한 핵심 정보를 숨기기 때문입니다. 이 정보는 MCP 호출 (MCP call), 다운스트림 API 스팬 (downstream API span), 정책 결정 (policy decision), 그리고 반환된 데이터 클래스 (returned data class)입니다. 이 모든 정보는 동일한 조사 경로 (investigation path)에 포함되어야 합니다.