MCP 보안: Model Context Protocol의 위험성과 거버넌스 방법 (2026)

Model Context Protocol (MCP)는 AI 에이전트 (AI agent)가 하나의 공통 인터페이스를 통해 도구, 파일, 앱에 연결될 수 있도록 하는 개방형 표준이며, 흔히 "AI를 위한 USB-C"라고 묘사됩니다. 이는 진정으로 유용하며, 2025년과 2026년을 거치며 AI 어시스턴트, IDE, 에이전트 프레임워크 전반에 걸쳐 채택되었습니다. 하지만 에이전트를 강력하게 만드는 바로 그 커넥터가 동시에 가장 큰 공격 표면 (attack surface)이기도 합니다. 기업 내 AI 에이전트를 관리하려는 최근의 움직임 — 코딩 에이전트를 모니터링하기 위한 도구를 출시하는 보안 벤더들과 Claude, ChatGPT, Copilot 내부에 도입되는 MCP 기반 거버넌스 계층 — 은 동일한 현상을 나타냅니다. 즉, 에이전트를 환경에 연결하는 것은 편의 설정이 아니라 보안 결정이라는 것입니다. 다음은 2026년 MCP 보안의 솔직한 현황과 이를 관리하는 방법입니다.

MCP가 단순한 기능이 아닌 보안 문제인 이유

MCP 자체는 단지 배관 (plumbing)일 뿐입니다. 즉, 모델이 도구를 발견하고, 설명을 읽고, 호출할 수 있는 표준화된 방식입니다. 위험은 프로토콜 자체가 아니라, 그 프로토콜을 통해 흐르는 내용에 있습니다.

에이전트가 MCP 서버에 연결되면, 해당 서버는 모델이 신뢰하는 두 가지를 제공합니다: 도구 설명 (tool descriptions) (각 도구가 무엇을 하는지, 어떻게 호출하는지를 모델에게 알려주는 텍스트)과 도구 출력 (tool outputs) (도구가 반환하는 모든 것)입니다. 모델은 이 두 가지를 모두 읽고 그에 따라 행동합니다. 따라서 여러분이 연결하는 모든 MCP 서버는 사실상 여러분의 에이전트 권한으로 실행되는 코드이자 지침입니다. 에이전트가 접근할 수 있는 모든 것 — 파일, 저장소, API, 이메일 등 — 에 대해 악의적인 서버가 에이전트를 통해 접근을 시도할 수 있습니다.

이는 AI 에이전트 보안 (AI agent security)을 전반적으로 어렵게 만드는 것과 동일한 변화가 특정 커넥터에 적용된 것입니다. 즉, 여러분의 MCP 설정 보안은 여러분이 연결하는 모든 서버의 보안과 같습니다.

2026년 MCP 특유의 위험 요소

이것들은 가설이 아닙니다. 보안 연구원들이 실제 MCP 클라이언트에서 이를 문서화했습니다.

• 도구 오염 (Tool poisoning). 악의적인 서버가 도구의 extit{설명 (description)} 내부에 명령을 숨깁니다. 이는 모델은 읽지만 사용자는 보통 읽지 않는 텍스트입니다. 무해해 보이는 add(a, b) 도구가 에이전트에게 비밀리에 개인 파일을 읽고 이를 외부로 유출하도록 지시할 수 있습니다. 사용자는 설명을 검토하지 않고 도구 호출을 승인하는 경향이 있기 때문에, 이는 가장 영향력이 큰 MCP 특유의 공격 중 하나입니다.
• 러그 풀 (Rug pulls, 무단 재정의). MCP 도구가 설치 및 승인된 extit{이후}에 스스로의 정의를 변경합니다. 사용자는 안전한 것을 검증했지만, 서버가 나중에 사용자에게 알리지 않고 악의적인 동작으로 교체해 버리는 것입니다.
• 도구 섀도잉 (Tool shadowing) 및 교차 서버 공격 (cross-server attacks). 여러 서버가 동일한 에이전트에 연결될 때, 침해된 서버가 신뢰할 수 있는 도구로 향하는 호출을 가로채거나 덮어쓸 수 있습니다. 이는 에이전트가 정당한 도구를 사용하고 있다고 생각하는 동안 공격자의 명령을 수행하게 되는 "혼란스러운 대리인 (confused deputy)" 문제입니다.
• 유출의 삼위일체 (The exfiltration trifecta). 진정으로 위험한 조합은 extit{개인 데이터}를 가지고 있고, extit{신뢰할 수 없는 콘텐츠}를 읽으며, 외부로 향하는 extit{유출 경로 (exfiltration path)}를 가진 에이전트입니다. MCP는 실수로 이 세 가지를 모두 연결하기 쉽게 만듭니다.
• 간접 프롬프트 인젝션 (prompt injection). 정직한 서버라 할지라도 에이전트가 읽게 되는 출력물(웹 페이지, 이슈, 문서 등)에 숨겨진 명령이 포함되어 있을 수 있습니다. 에이전트는 그 명령이 사용자로부터 온 것처럼 따를 수 있습니다.

MCP를 안전하게 거버넌스하는 방법

MCP를 피할 필요는 없습니다. 무엇을 연결할지 거버넌스(governance)하고, 단 하나의 악성 서버가 재앙이 되지 않도록 이를 격리(box it in)해야 합니다. 이 원칙들은 새로운 커넥터에 적용되는 오래된 보안의 지혜입니다.

• 신뢰할 수 있는 서버를 검증(Vet)하고 고정(Pin)하세요. 공식적이거나 충분히 검토된 MCP 서버를 우선적으로 사용하십시오. 실제 권한을 가진 에이전트(Agent)에 임의의 제3자 서버를 연결하지 마십시오. 또한 설치 후 변경되는 도구 정의(Tool definitions)를 주의 깊게 살펴야 합니다.
• 서버별 최소 권한 원칙(Least privilege per server)을 적용하세요. 각 서버에는 작업에 필요한 최소한의 권한만 부여해야 하며, 이때 **범위가 제한되고 취소 가능한 자격 증명(Scoped, revocable credentials)**을 사용하십시오. 절대로 사용자의 기본 계정이나 운영(Production) 키를 사용해서는 안 됩니다. 서버가 읽기 권한만 필요하다면 쓰기 권한을 허용하지 마십시오.
• 폭발 반경(Blast radius)을 제한하세요. 하나의 침해된 서버가 다른 서버를 가로챌 수 있으므로, 신뢰할 수 없는 여러 서버를 동일한 에이전트에 연결하는 것을 피하십시오. 민감한 작업은 공개 웹(Open web)을 읽는 요소로부터 격리하십시오.
• 영향력이 큰 작업에는 인간 참여(Human in the loop)를 적용하세요. 돈을 송금하거나, 데이터를 삭제하거나, 공개적으로 게시하거나, 액세스 권한을 변경하는 등 되돌릴 수 없는 작업 전에는 반드시 명시적인 확인을 거쳐야 합니다. 에이전트가 초안을 작성하게 하고, 최종 승인은 사용자가 하십시오.
• 도구 설명(Tool descriptions)과 출력값(Outputs)을 신뢰할 수 없는 것으로 취급하세요. 두 가지 모두 주입된 지침(Injected instructions)을 포함할 수 있습니다. 에이전트가 AI 코드 리뷰 도구나 외부 콘텐츠를 입력받는 모든 도구를 사용할 때도 동일한 주의가 필요합니다.
• 도구 호출(Tool calls)을 기록하고 감사(Audit)하세요. 에이전트가 어떤 서버와 도구를 사용했는지 기록을 남겨, 이상 징후를 포착하고 빠르게 권한을 취소할 수 있도록 하십시오.
• 프롬프트와 도구 인자(Tool arguments)에 비밀 정보를 포함하지 마세요. 프롬프트나 도구 호출에 붙여넣은 비밀번호와 API 키는 서버 상의 텍스트가 됩니다. 대신 범위가 제한된 토큰(Scoped tokens)과 비밀 관리자(Secret managers)를 사용하십시오.

솔직한 결론

MCP 보안은 단 하나의 사고방식 전환으로 귀결됩니다. MCP 서버는 설치하고 잊어버리는 플러그인이 아닙니다. 자율성과 접근 권한을 가진 새로운 참여자이며, 여러분은 이를 완전히 신뢰할 수 없는 대상처럼 취급해야 합니다. 프로토콜 자체는 개방적이고 유용하지만, 위험은 검증되지 않은 서버에 광범위하고 지속적인 신뢰를 부여하는 데서 발생합니다. 의도적으로 연결하고, 모든 서버의 범위를 엄격히 제한하며, 되돌릴 수 없는 모든 작업에는 인간의 승인 단계(human gate)를 유지하십시오. 또한 모든 도구 설명(tool description)과 출력값이 에이전트를 하이재킹(hijack)하려 할 수 있다고 가정하십시오. 현재 AI 에이전트 — 특히 MCP에 크게 의존하는 AI 코딩 에이전트 — 를 중심으로 거버넌스(governance)를 구축하고 있는 팀들은 정확히 이 지점으로 수렴하고 있습니다: 덜 연결하고, 좁게 신뢰하며, 검증하십시오.

FAQ

MCP 보안이란 무엇인가요?

MCP 보안은 Model Context Protocol (MCP) — 2024년 말 Anthropic이 도입한 개방형 표준이자 종종 'AI를 위한 USB-C'로 묘사되는 — 을 통해 AI 모델과 에이전트를 외부 도구 및 데이터에 안전하게 연결하는 관행을 의미합니다. MCP 자체는 단순한 커넥터(connector)일 뿐입니다. 보안 문제는 무엇을 연결하느냐와 그것을 얼마나 신뢰하느냐에 달려 있습니다. 에이전트가 연결하는 각 MCP 서버는 에이전트의 권한으로 실행되는 코드와 명령어로 구성되므로, 악의적이거나 침해된 서버는 사용자의 데이터를 읽거나, 다른 도구를 호출하거나, 사용자를 대신하여 행동을 취할 수 있습니다. MCP 보안이란 서버를 검증하고, 권한 범위를 엄격히 제한하며, 도구 설명과 출력을 신뢰할 수 없는 입력값으로 취급하는 것을 의미합니다.

MCP에서 도구 포이즈닝(tool poisoning)이란 무엇인가요?

도구 포이즈닝(tool poisoning)은 악의적인 MCP 서버가 도구의 설명(description)이나 메타데이터 내부에 명령어를 숨기는 행위를 말합니다. 이는 모델은 읽지만 사용자는 보통 읽지 않는 텍스트입니다. 모델은 이러한 숨겨진 명령어를 명령(command)으로 처리하므로, 겉보기에는 무해한 '두 숫자를 더하는' 함수처럼 보이는 도구가 에이전트에게 비밀 파일을 읽어 어딘가로 전송하라고 몰래 지시할 수 있습니다. 보안 연구원들은 이를 가장 영향력 있는 MCP 특화 위험 중 하나로 기록했는데, 이는 사용자들이 기저에 깔린 설명을 검사하지 않고 도구 호출을 승인하는 경향이 있기 때문입니다.

MCP 러그 풀(rug pull)이란 무엇인가요?

러그 풀(rug pull), 또는 '조용한 재정의(silent redefinition)'라고도 불리는 이 공격은 사용자가 이미 설치하고 신뢰한 MCP 도구가 스스로의 정의(definition)를 변경할 때 발생합니다. 사용자는 안전해 보이는 도구를 승인하지만, 이후 서버가 사용자에게 알리지 않고 몰래 악성 지침(instructions)으로 교체해 버립니다. 이와 관련된 공격으로 '도구 섀도잉(tool shadowing)'이 있는데, 이는 악성 서버가 신뢰할 수 있는 도구로 향하는 호출을 가로채거나 덮어쓰는 방식입니다. 두 공격 모두 한 번 부여된 신뢰는 거의 재검토되지 않는다는 사실을 악용하며, 이것이 바로 도구 정의의 변경 사항을 모니터링하는 것이 중요한 이유입니다.

MCP는 사용하기에 안전한가요?

신뢰할 수 있는 서버에만 연결하고 그들의 액세스 권한(access)을 엄격하게 제한한다면, MCP는 일상적인 용도로 사용하기에 대체로 안전합니다. 하지만 광범위한 권한을 가진 임의의 제3자 서버를 연결해 두고 방치하는 것은 안전하지 않습니다. 이 프로토콜은 개방형 커넥터(open connector)이므로, 안전성은 전적으로 연결된 서버와 부여된 액세스 권한에 달려 있습니다. 공식적이거나 검증된 서버를 사용하고, 메인 계정 대신 각 서버에 별도의 취소 가능한 자격 증명(revocable credentials)을 부여하며, 영향력이 큰 작업에는 반드시 사람의 개입(human in the loop)을 유지하고, 도구를 승인하기 전에 해당 도구가 무엇을 할 수 있는지 검토하십시오.

MCP 서버를 어떻게 보안 처리하나요?

최소 권한 원칙(least privilege)을 적용하십시오. 관리자 키나 기본 계정 대신, 범위가 지정된 취소 가능한 토큰(scoped, revocable tokens)을 사용하여 각 MCP 서버에 작업에 필요한 최소한의 액세스 권한만 부여하십시오. 신뢰할 수 있는 서버를 검증하고 고정(pin)하며, 공식 서버를 우선적으로 사용하고, 설치 후 변경되는 도구 정의를 주시하십시오. 도구 설명(tool descriptions)과 도구 출력(tool outputs)은 주입된 지침(injected instructions)이 포함될 수 있는 신뢰할 수 없는 콘텐츠로 취급하십시오. 하나의 탈취된 서버가 다른 서버를 가로챌 수 있으므로, 여러 개의 신뢰할 수 없는 서버를 동일한 에이전트(agent)에 연결하는 것을 피하십시오. 감사(audit) 및 권한 취소가 가능하도록 도구 호출을 로그(log)로 남기고, 프롬프트(prompt)와 도구 인자(tool arguments)에 비밀 정보(secrets)를 포함하지 마십시오.

원문은 alexi.sh에 게시되었습니다.