MCP 도구를 보안하는 것에 대한 대부분의 조언은 타당하지만 모호합니다: "서버를 검증하라", "응답을 스캔하라", "실패 시 차단(fail closed)하라" 등입니다. 좋은 직관이지만, 사양(spec)은 없습니다. MIT 라이선스의 오픈 저장소인 Microsoft의 Agent Governance Toolkit은 이러한 직관 중 하나를 실제로 준수할 수 있는 무언가로 바꾸어 놓았습니다.

사양(Spec)이란 무엇인가

읽어볼 가치가 있는 부분은 MCP Security Gateway 1.0입니다. 이는 에이전트(agent)와 MCP 도구 서버(tool servers) 사이에 위치하는 정책 강제 인터셉션 계층(policy-enforcing interception layer)을 설명합니다. 즉, 모든 도구 호출(tool call)과 모든 도구 응답(tool response)이 통과하는 게이트웨이입니다. 또한 이는 RFC-2119 준수 언어로 작성되었습니다. 즉, MUST, SHOULD, MAY가 핵심적인 역할을 하며, 이는 구현체가 단순히 느낌(vibe-check)으로 확인되는 것이 아니라 사양에 따라 측정될 수 있음을 의미합니다. 해당 저장소는 바로 그 측정 도구를 제공합니다: Python 구현체에 대한 127개의 테스트로 구성된 준수 스위트(conformance suite)입니다.

게이트웨이 패턴 자체는 새로운 것이 아닙니다. 새로운 점은 각 팀이 매번 새로 만드는 대신, 경계(boundary)를 테스트할 수 있을 만큼 정밀하게 명시했다는 것입니다.

구체적인 메커니즘

사양은 게이트웨이가 무엇을 하는지에 대해 구체적으로 명시하고 있으며, 이 부분이 유용합니다.

승인을 포함한 도구 호출 인터셉션(Tool-call interception). 호출은 엄격한 순서에 따라 평가됩니다: 차단 목록(deny-list), 허용 목록(allow-list), 승인 콜백(approval callback)을 호출하는 민감한 도구(sensitive-tool) 확인, 그리고 속도 제한(rate limits) 순입니다. 민감한 도구의 경우, 콜백이 APPROVED 이외의 값인 DENIED 또는 PENDING을 반환하면 호출이 차단됩니다.

응답 스캔(Response scanning). 도구 응답은 스캔되며 세 가지 작업 중 하나로 처리됩니다: BLOCK(차단), SANITIZE(나쁜 부분은 삭제하고 나머지는 통과), 또는 LOG(기록). 이는 지시문 태그 주입(instruction-tag injection, <SYSTEM> 또는 [INST]와 같은 마커), 명령형 주입(imperative injection, "이전 지시사항을 무시하십시오"), 자격 증명 유출(credential leaks), 사회보장번호(SSN) 및 카드 번호와 같은 개인정보(PII), 그리고 쿼리 매개변수(query parameters)를 통해 데이터를 몰래 유출하는 데이터 탈취(exfiltration) URL 등을 탐지합니다.

여섯 가지 명명된 위협에 대한 보안 스캐너. MCPThreatType 열거형(enum)은 정확히 여섯 개의 값을 가지며, 이름은 문서화와 같습니다:

• TOOL_POISONING: 도구 정의 내의 악성 명령어
• RUG_PULL: 등록 이후 도구 설명 또는 스키마가 변경된 경우
• CROSS_SERVER_ATTACK: 다른 서버에 있는 도구를 사용하려는 시도
• CONFUSED_DEPUTY: 권한을 상승시키거나 다른 에이전트의 역할을 수행하는 도구
• HIDDEN_INSTRUCTION: 눈에 보이지 않는 유니코드, 인코딩된 페이로드, 숨겨진 주석
• DESCRIPTION_INJECTION: 도구 설명에 삽입된 프롬프트 주입(prompt injection)

스키마 드리프트 감지. 드리프트 감지기(drift detector)는 각 도구의 스키마를 지문 인식(fingerprint)하고 로드할 때마다 비교합니다. 지문이 변경되면 CRITICAL 경고가 발생해야 하며, 이는 신뢰하던 도구가 나중에 출시되면서 악성으로 변하는 '러그 풀(rug-pull)' 사례에 대한 구체적인 통제 수단입니다.

항상 실패 시 폐쇄(Fail-closed). 명시된 설계 원칙은 게이트웨이, 스캐너, 속도 제한기(rate limiter), 인증 강제기(auth enforcer)를 포함한 모든 구성 요소가 오류 발생 시 반드시 거부해야 하며, 절대로 조용히 허용해서는 안 된다는 것입니다. 각 구성 요소의 실패 모드를 안전 기본값과 매핑하는 준수 테이블이 존재합니다. 충돌하는 스캐너는 응답을 차단할 뿐, 통과시키지 않습니다.

중요성

MCP 경계는 에이전트가 실제 권한을 가지고 제어하지 않는 코드를 만나는 지점입니다. 이곳은 통제 장치를 배치하기에 자연스러운 곳이며, 지금까지 '통제 장치를 여기에 배치해야 한다'는 것이 가이드라인의 끝이었습니다. 준수 테스트가 가능한 레퍼런스(reference)는 대화의 초점을

MCP 트래픽을 감사 가능하고(auditable), 오류 발생 시 차단되는(fail-closed) 단일 병목 지점(choke point)을 통해 라우팅하십시오. 에이전트 코드 곳곳에 흩어져 있는 도구별 체크가 아니라, 모든 도구 호출과 응답이 통과하는 단일 계층을 구축해야 합니다. 이 계층은 오류 발생 시 접근을 거부하고, 도구의 지문(fingerprint)을 식별하여 드리프트(drift)를 감지하며, 응답이 모델에 도달하기 전에 스캔합니다. 단일 경계(boundary)를 구축함으로써 얻는 이점은 "이것이 안전한가?"라는 질문에 답할 수 있는 장소가 단 한 곳이며, 문제가 발생했을 때 감사할 수 있는 곳도 단 한 곳이 된다는 점입니다.

좋은 소식은 그 경계를 처음부터 직접 설계할 필요가 없다는 것입니다. 이 사양(spec)은 이미 위협, 조치, 그리고 실패 의미론(failure semantics)을 열거하고 있습니다. 사양을 읽어본 후, 게이트웨이를 채택하거나 여러분의 자체 구현체를 동일한 기준에 맞추십시오.

이 사양은 자율 AI 에이전트 보안을 위한 개방형이자 벤더 중립적인 프레임워크인 *BRACE*의 근간이 되는 소스 중 하나입니다. BRACE의 에코시스템 가이드(ecosystem guide)는 이 사양이 구현하는 fail-closed MCP 게이트웨이 패턴을 다룹니다. BRACE는 각종 사고 사례와 연구를 검토하며, 매번 "이 상황을 방지하거나 억제할 수 있었던 구체적인 통제 수단(control)은 무엇인가?"라는 질문을 던지며 구축되었습니다._