NSA MCP 보안 지침, GitHub·WhatsApp 유출 사례를 경고

AI 요약

• 무슨 일: NSA AISC가 2026년 5월 20일 MCP 보안 설계 지침을 공개했습니다.
  • 문서는 MCP가 AI 자동화의 사실상 표준으로 확산됐지만 보안 모델은 그 속도를 따라가지 못했다고 봅니다.
• 위험 사례: GitHub MCP 권한 범위, WhatsApp MCP 데이터 노출, MCP Inspector RCE가 실제 사례로 들어갔습니다.
  • NSA는 tool parameter injection, tool name collision, downstream output poisoning도 MCP 배포의 운영 위험으로 묶었습니다.
• 실무 조치: MCP 서버는 이제 endpoint가 아니라 권한, 로그, 샌드박스, DLP가 필요한 agent runtime입니다.
• 주의점: 공식 MCP 문서의 권고만으로 끝내지 말고 사내 registry, egress proxy, SIEM 연동까지 설계해야 합니다.

미국 NSA의 Artificial Intelligence Security Center가 2026년 5월 20일 MCP 보안 설계 지침을 공개했습니다. 제목은 Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation입니다. 17쪽짜리 Cybersecurity Information Sheet이며, 문서 번호는 U/OO/6030316-26, PP-26-1834, 버전은 1.0입니다.

이 문서가 뉴스인 이유는 NSA가 MCP를 단순한 개발자 편의 기능이 아니라 AI 인프라 보안 대상으로 다뤘기 때문입니다. NSA는 MCP가 AI-driven service 사이의 통신을 가능하게 하는 사실상 표준이 됐고, 비즈니스, 금융, 법무, 소프트웨어 개발 배포에 들어갔다고 설명합니다. 예시 제품으로 AutoGen Studio, Harvey AI, Agentverse, Copilot을 직접 언급했습니다.

MCP는 Anthropic이 2024년 11월 공개한 뒤 Claude Desktop, IDE, agent framework, SaaS connector, 내부 자동화 도구로 빠르게 퍼졌습니다. 개발팀 입장에서는 API와 데이터베이스, GitHub, Slack, 브라우저, 파일 시스템을 agent에게 연결하는 쉬운 방식입니다. NSA 문서는 바로 그 쉬운 연결 방식이 보안 경계도 함께 이동시켰다고 봅니다.

NSA의 핵심 판단은 짧습니다. MCP의 확산은 보안 모델 개발보다 빨랐습니다. 문서는 MCP가 초기 웹 프로토콜처럼 유연하고 덜 규정된 설계로 나왔고, 구현자에게 자유를 주는 동시에 안전한 사용에 모호성을 만들었다고 적습니다. 개발팀이 "MCP 서버 하나 붙인다"라고 부르는 작업이 실제로는 identity, authorization, tool execution, context sharing, audit logging을 한꺼번에 열어 주는 배포라는 뜻입니다.

클라이언트가 서버를 부르는 구조가 뒤집혔습니다

전통적인 웹 서비스에서는 클라이언트가 서버에 데이터를 요청하고, 서버는 비교적 정해진 API surface를 제공합니다. NSA는 MCP에서 이 익숙한 패턴이 뒤집힌다고 설명합니다. MCP는 서버가 연결된 클라이언트의 data와 action을 질의하거나 실행하는 흐름을 만들 수 있습니다. 에이전트가 사용자의 의도를 해석하고, MCP client library가 protocol message로 바꾸고, MCP server가 도구와 capability를 골라 작업을 수행하는 구조입니다.

이 구조는 여행 계획 예시처럼 편리합니다. 사용자가 "해외 출장 일정 잡아줘"라고 쓰면 agent는 위치, 시간, 공항, 비자 요건, 항공편, 일정표를 여러 도구에서 가져올 수 있습니다. 그러나 같은 구조가 전자의무기록, private repository, 회계 시스템, 고객지원 로그를 다룰 때는 다른 문제가 됩니다. 하나의 tool result가 다음 tool call의 입력이 되고, 이전 context가 다음 agent 판단에 섞이며, approval UI는 사용자가 실제 action 범위를 이해하기 전에 Allow 버튼 하나로 압축될 수 있습니다.

NSA는 MCP 환경에서 traditional cybersecurity principle이 여전히 필요하다고 말합니다. authentication, authorization, input validation은 기본입니다. 그러나 문서는 agentic AI system이 dynamic tool invocation, implicit trust relationship, context sharing을 만들기 때문에 기존 방어 전략만으로는 부족하다고 봅니다. 서버 endpoint 하나를 패치하는 방식이 아니라 agent lifecycle 전체를 봐야 한다는 진단입니다.

NSA가 열거한 첫 번째 위험은 권한입니다

문서의 access control 항목은 MCP adoption의 가장 흔한 문제를 짚습니다. NSA는 session과 identity의 연결이 protocol 자체에 정의돼 있지 않고, 구현자 재량으로 남아 있다고 설명합니다. 일부 MCP 구성요소는 authentication 없이 data를 처리하고, authentication이 있어도 CRUD 같은 role-based enforcement가 부족할 수 있습니다.

이 지적은 GitHub MCP 같은 개발 도구에서 곧바로 현실 문제가 됩니다. NSA가 든 실제 사례는 GitHub 기반 MCP tool입니다. 사용자가 GitHub MCP server에 권한을 주면, tool이 private repository와 public repository 양쪽에 repository-level read/write access를 넓게 얻을 수 있습니다. 권한이 특정 repository나 operation 단위로 좁혀지지 않으면, compromised tool이 private content를 읽고 public repository에 쓰는 경로가 생깁니다.

개발팀이 여기서 확인할 항목은 OAuth consent 화면의 존재 여부가 아닙니다. 중요한 질문은 세 가지입니다. 첫째, MCP client가 user identity와 server identity를 분리해서 기록하는가. 둘째, 도구별 권한이 read, write, delete, publish 수준으로 잘리는가. 셋째, 이미 trust된 MCP server가 capability를 바꿀 때 다시 승인 절차가 발생하는가. NSA는 승인 이후 capability나 data access가 바뀌어도 사용자가 모르는 경우를 별도 위험으로 분류했습니다.

토큰과 세션은 "권장"만으로 부족합니다

NSA 문서는 MCP 구현이 OAuth-style bearer token이나 session ID에 의존하지만, protocol-level token lifecycle management는 충분히 지정돼 있지 않다고 봅니다. refresh, revocation, reuse control, expiration, rotation이 구현별 best practice로 남으면 message replay나 unauthorized session reuse가 가능합니다. session hijacking이 일어나면 공격자는 정상 client처럼 MCP server와 상호작용할 수 있습니다.

MCP 공식 Security Best Practices 문서도 token passthrough를 anti-pattern으로 분류합니다. MCP server가 client에서 받은 token을 downstream API에 그대로 넘기면, token audience와 audit trail이 깨집니다. 공식 문서는 MCP server가 자신을 대상으로 발급되지 않은 token을 받아서는 안 된다고 적습니다. NSA의 지침은 이 공식 권고가 production 환경에서는 token lifecycle, replay protection, idempotency까지 이어져야 한다고 읽힙니다.

idempotency도 작게 보이지만 agent 환경에서는 중요합니다. MCP가 JSON-RPC와 message queue 위에서 동작할 때, 같은 operation이 재전송되거나 resume될 수 있습니다. 결제, repository write, ticket status 변경, 고객 데이터 export 같은 action에서 idempotency가 없으면 network retry가 실제 변경을 두 번 만들 수 있습니다. 사용자에게는 한 번 승인한 작업으로 보이지만, backend에는 두 번 실행된 mutation이 남습니다.

실제 사례는 이미 나왔습니다

NSA 문서의 중간부는 real-world MCP security issue를 모았습니다. 첫 사례는 tool parameter injection입니다. open source MCP agent에서 malformed MCP message의 unsanitized tool parameter가 실행되어 민감한 MCP server data가 노출됐다는 내용입니다. 문제는 tool interface가 정상 경로처럼 보였고, contextual validation과 logging이 부족했다는 점입니다.

두 번째는 tool invocation path confusion입니다. 일부 MCP orchestrator는 public registry나 local module에서 tool name을 자동으로 resolve합니다. 이름 충돌이나 configuration manipulation이 있으면 공격자-controlled code가 로드될 수 있습니다. NSA는 MCP client가 unique tool identifier나 strict resolution policy를 지정하지 못하는 경우 malicious data나 external server response가 정상 기능을 덮어쓸 수 있다고 정리했습니다.

세 번째는 WhatsApp MCP 확장 사례입니다. NSA 문서는 trusted third-party MCP agent와 malicious MCP server가 같은 client에 연결됐을 때, 악성 tool description이 client behavior를 조작해 WhatsApp message data를 노출할 수 있었다고 설명합니다. 더 위험한 부분은 malicious server가 설치 시점에는 benign instruction을 내보이고, 두 번째 사용 이후 instruction을 바꾸는 방식으로 시도를 숨겼다는 점입니다.

네 번째는 downstream automation poisoning입니다. 한 agent의 output이 다른 agent의 input이 되는 multi-agent workflow에서 tool metadata, hidden instruction, prompt injection이 이어질 수 있습니다. NSA는 이 문제를 isolated vulnerability가 아니라 systemic class로 봅니다. agent pipeline에서 "이전 단계 출력은 신뢰할 수 있다"는 가정이 깨지면, control-flow hijacking이나 data exfiltration이 여러 단계 뒤에서 발생할 수 있습니다.

마지막으로 MCP Inspector의 CVE-2025-49596 원격 코드 실행 사례가 들어갑니다. MCP server를 테스트하는 개발 도구가 crafted message를 통해 RCE를 허용했고, 0.14.1에서 수정됐다는 내용입니다. 이 사례는 agent runtime뿐 아니라 inspector, debugger, registry, local launcher 같은 개발 보조 도구도 attack surface라는 점을 보여줍니다.

보안 경계는 tool 단위로 다시 그려야 합니다

NSA 권고의 첫 축은 supported MCP project를 고르는 일입니다. 문서는 MCP project documentation이 일부 인기 server가 더 이상 actively maintained되지 않는다고 지적한다고 말합니다. file system, development tool, browser automation, productivity service와 연결되는 archived server는 작은 demo라 해도 production에 들어가면 supply chain risk가 됩니다.

두 번째 축은 boundary design입니다. NSA는 agent, plugin, model, end user를 서로 다른 trust zone으로 다뤄야 한다고 권고합니다. user-facing plugin에서 온 data를 privileged backend model이 그대로 믿어서는 안 됩니다. 공개 도구는 공개 data set을 다루는 zone에 묶고, health record, financial information, controlled unclassified information 같은 민감 data와 연결되는 tool은 별도 zone으로 분리해야 합니다.

이 지점에서 MCP의 장점인 dynamic tool discovery는 위험도 됩니다. agent가 runtime에 새 tool을 찾아 붙일 수 있다면, origin verification과 authorization check가 같이 있어야 합니다. 사내 MCP registry를 만들고, registry에 등록되지 않은 server는 개발 환경에서도 경고하거나 차단하는 방식이 현실적입니다. NSA는 private data를 처리할 때 local MCP server instance를 선호하라고 권고했습니다.

프롬프트 필터보다 parameter validation이 먼저입니다

MCP 보안 논의는 자주 prompt injection으로 수렴합니다. NSA 문서는 prompt injection도 다루지만, 더 넓게 parameter validation을 요구합니다. 모든 tool invocation과 model execution request는 well-defined schema, expected range, intended context에 맞춰 검증돼야 합니다. malformed input, missing field, excessive size는 injection뿐 아니라 DoS에도 쓰일 수 있습니다.

예를 들어 수학 interpreter agent가 있습니다. 사용자가 보낸 수식 자체는 안전해 보일 수 있습니다. 그러나 context parameter가 file I/O behavior를 바꾸도록 조작되면, tool은 계산기처럼 보이면서 로컬 파일에 접근할 수 있습니다. NSA가 말하는 validation은 "입력 문자열에 나쁜 단어가 있는가"보다 "이 tool이 지금 이 context와 permission에서 실행돼도 되는가"에 가깝습니다.

parameter forwarding도 제한해야 합니다. 한 component에 들어온 user-supplied input이 다른 component parameter로 자동 전달되면, downstream tool은 그 값을 system instruction이나 execution option으로 오해할 수 있습니다. agent chain에서 이 자동 forwarding은 편리하지만, incident response 때는 어느 단계에서 의미가 바뀌었는지 찾기 어렵습니다.

샌드박스와 egress proxy는 선택 기능이 아닙니다

NSA는 MCP를 통해 실행되는 tool action을 high-risk action으로 다루라고 권고합니다. shell command, database query, external API call 모두 strict resource boundary 안에서 실행돼야 합니다. 문서는 Windows AppContainers, seccomp, AppArmor, SELinux 같은 OS-level isolation을 예로 듭니다. agent process도 least privilege를 따라야 하며, 필요 없는 file system, model file, internal network 접근은 runtime에서 차단해야 합니다.

outbound control도 들어갑니다. NSA는 외부 entity로 나가는 연결에 filtering outgoing proxy나 enterprise DLP를 쓰라고 권고했습니다. Squid, tinyproxy 같은 proxy 이름도 예시로 나옵니다. 이유는 MCP server가 외부 URL, API, registry, OAuth discovery endpoint와 상호작용할 때 data exfiltration과 SSRF가 같은 경로로 발생할 수 있기 때문입니다.

MCP 공식 security 문서도 SSRF를 별도 attack vector로 설명합니다. 악성 MCP server가 OAuth metadata discovery 과정에서 internal IP, cloud metadata endpoint, localhost service로 향하는 URL을 넣으면 MCP client가 proxy처럼 동작할 수 있습니다. production MCP client는 private IP range, link-local address, redirect chain, DNS rebinding을 검증해야 합니다. 이 검증을 손으로 만든 URL parser에 맡기는 것은 위험합니다.

메시지 서명과 로그는 사후 대응의 조건입니다

NSA는 MCP가 transport layer encryption, 예를 들어 TLS에 의존하지만 protocol 자체는 message integrity를 검증하지 못한다고 지적합니다. sensitive data나 security-critical decision을 처리한다면 JSON payload 안에서 cryptographic signature를 적용하고, expiration timestamp와 replay protection metadata를 붙이는 방식을 검토해야 합니다. 지연되거나 중복된 message가 unintended re-execution으로 이어지는 distributed system 위험을 줄이기 위한 조치입니다.

로그 항목도 구체적입니다. 모든 tool과 model invocation은 exact parameter, involved identity, 가능한 경우 result나 output의 cryptographic hash를 포함해 기록해야 합니다. 이 telemetry는 SIEM, threat detection pipeline, compliance dashboard와 연결돼야 합니다. NSA가 말한 suspicious pattern은 unexpected tool invocation, anomalous message flow, authorization failure, RBAC violation입니다.

많은 agent 제품은 사용자 경험을 위해 로그를 요약하거나 숨깁니다. 그러나 MCP incident에서는 "agent가 무엇을 읽었고, 어떤 tool을 어떤 parameter로 호출했고, 결과가 어느 downstream step으로 넘어갔는가"가 forensic backbone입니다. 로그가 prompt와 final answer만 남기면, tool call 사이의 permission escalation이나 data leak을 재구성하기 어렵습니다.

사내 네트워크에서 MCP 서버를 찾아야 합니다

NSA 권고 중 가장 운영적인 항목은 local network scan입니다. 조직은 unauthenticated MCP server, outdated MCP server, unauthorized deployment, unregulated internet connectivity를 정기적으로 찾아야 합니다. 문서는 MCP Scanner, Ramparts, CyberMCP, Proximity 같은 scanning tool을 예로 듭니다.

이 조항은 개발팀 문화와 충돌할 수 있습니다. MCP 서버는 로컬 실험으로 시작하기 쉽습니다. IDE agent에 filesystem server를 붙이고, browser automation server를 띄우고, 사내 API wrapper를 몇 줄로 만들어 demo를 합니다. 그러나 그 server가 localhost에 계속 떠 있거나, container port가 열려 있거나, shared development host에서 다른 process가 접근할 수 있으면 보안팀이 모르는 agent integration이 됩니다.

따라서 production readiness checklist에는 MCP inventory가 들어가야 합니다. 최소 항목은 server name, version, owner, repository, capability list, data classification입니다. outbound domain, credential storage, patch history, approval workflow, logging destination도 같은 registry에 넣어야 합니다. NSA 문서는 versioning과 patch history를 포함한 registry가 vulnerability triage를 빠르게 한다고 설명합니다.

개발팀의 첫 대응은 "MCP 금지"가 아닙니다

NSA 문서는 MCP를 금지하자는 문서가 아닙니다. 결론에서 MCP가 agentic AI의 orchestration과 automation에 promising foundation이라고 말합니다. 다만 current security posture가 uneven하고, protocol guarantee보다 implementation discipline에 크게 의존한다고 봅니다. 이 표현은 개발팀에게 꽤 직접적입니다. MCP를 쓰려면 agent runtime을 web API 수준으로 통제해야 한다는 뜻입니다.

첫 번째 대응은 사내 MCP registry입니다. 누가 만든 server인지, 어느 version인지, 어떤 tool을 제공하는지, 어떤 data zone에 붙는지 추적해야 합니다. registry 밖 server는 default deny로 두고, 개발 환경에서도 warning과 approval을 요구해야 합니다. npx some-mcp-server를 바로 실행하는 one-click flow는 정확한 command와 argument, file system access, network access를 사용자에게 보여줘야 합니다.

두 번째 대응은 tool permission model입니다. read_repo, write_repo, create_issue, publish_release가 같은 GitHub access로 묶이면 agent의 실패가 곧 배포 사고가 됩니다. sensitive action은 별도 approval과 idempotency key를 요구해야 합니다. capability 변경은 silent update가 아니라 재승인 event가 돼야 합니다.

세 번째 대응은 output pipeline filter입니다. tool output은 다음 agent에게 넘기기 전에 untrusted input으로 다시 검사해야 합니다. hidden instruction, oversized content, unexpected URL, code block, serialized command, tool metadata mutation을 검사하는 계층이 필요합니다. NSA는 MCP-aware security proxy가 아직 성숙 중이라고 적었으므로, 현재는 egress proxy, DLP, schema validation, custom policy engine을 조합해야 합니다.

네 번째 대응은 incident drill입니다. MCP 사고는 API key 유출처럼 단일 secret rotation으로 끝나지 않을 수 있습니다. agent memory, cached tool result, downstream ticket, public repository write, chat message, audit log가 모두 영향을 받을 수 있습니다. runbook에는 server disable, token revoke, tool registry quarantine, affected context purge, downstream output invalidation이 들어가야 합니다.

MCP의 다음 단계는 보안 제품보다 운영 규율입니다

NSA 문서가 공개되자 일부 보안 벤더는 agent firewall, MCP proxy, detection layer의 근거로 이 지침을 인용했습니다. PipeLab은 2026년 5월 22일 글에서 NSA가 filtering outgoing proxy, DLP, sandboxing, message integrity, output filtering, local MCP scan을 언급했다는 점을 정리했습니다. 이런 제품군은 필요할 수 있습니다. 그러나 지침의 핵심은 특정 제품 도입보다 MCP를 운영 inventory와 trust boundary 안으로 끌어들이는 일입니다.

MCP가 널리 쓰이는 이유는 분명합니다. agent가 file, repo, issue tracker, browser, database, SaaS API를 같은 방식으로 호출할 수 있습니다. 이 표준화는 개발 속도를 올립니다. 동시에 권한과 context를 한 곳에 모으고, tool output을 다음 action으로 자동 연결합니다. NSA가 경고한 부분은 바로 이 연결성입니다.

AI 개발팀은 이제 MCP 서버를 "플러그인"보다 "작은 원격 실행 환경"으로 봐야 합니다. 누가 실행하는가, 어떤 권한을 갖는가, 어떤 network로 나가는가, 어떤 data를 읽는가, 어떤 log가 남는가, 어떤 update가 승인 없이 들어오는가를 배포 단위로 기록해야 합니다. agent가 점점 더 많은 일을 맡을수록, MCP 보안은 모델 안전성 논의가 아니라 software supply chain과 runtime security의 문제로 이동합니다.

NSA MCP 지침의 실무 메시지는 명확합니다. 에이전트에 도구를 연결하는 순간, tool call은 권한 있는 action이 됩니다. MCP를 production에 넣는 팀은 prompt filter만 붙이고 끝낼 수 없습니다. registry, sandbox, schema, signature, egress, DLP, SIEM, scanner가 같은 설계 문서 안에 들어가야 합니다. 이 기준을 갖추지 못한 MCP 배포는 편리한 자동화가 아니라 추적하기 어려운 권한 위임입니다.

출처