MCP 보안 모범 사례: 위험 요소와 안전 유지 방법

HostedMCP의 모든 MCP server 하단에는 다음과 같은 짧은 안내 문구가 있습니다: listed servers는 사용자가 부여한 권한으로 실행되므로, 설치 전 소스 코드를 검토하십시오. 이 문구를 명시한 이유는 가장 흔한 MCP 보안 문제가 정교한 취약점 공격이 아니기 때문입니다. 실제로는 사용자가 방금 발견한 server에 쓰기 권한이 전체 포함된 데이터베이스 URL을 그대로 붙여넣는 경우가 대부분입니다.

본 가이드는 두 가지 유형의 리스크를 모두 다룹니다. 과도한 권한을 가진 자격 증명과 같은 일반적인 리스크는 대부분의 보안 사고가 시작되는 지점입니다. 토큰 전달(token passthrough)이나 혼동된 대리자(confused deputy)와 같은 프로토콜 수준의 리스크는 server를 직접 구축하거나 호스팅할 때 중요합니다. 각 내용은 2026-07-28 개정된 공식 MCP 보안 베스트 프랙티스와 HostedMCP 카탈로그에서 확인된 사례를 바탕으로 작성되었습니다.

핵심 요약

• 대부분의 MCP 사고는 과도한 권한을 가진 자격 증명이나 검증되지 않은 server 사용과 같은 일반적인 실수에서 시작됩니다.
• 모델은 신뢰할 수 없는 텍스트를 읽기 때문에, 모델이 보유한 모든 tool은 웹 페이지, issue 또는 이메일에 의해 조종될 수 있습니다.
• 로컬 server는 사용자의 권한으로 실행됩니다. 원격 server는 OAuth 2.1을 준수해야 하며 절대로 토큰을 전달해서는 안 됩니다.
• 최소 권한 원칙 준수, 쓰기 작업에 대한 승인 절차, 버전 고정, agent당 server 개수 제한을 통해 대부분의 문제를 방지할 수 있습니다.

리스크	영향 대상	주요 방어책
콘텐츠를 통한 프롬프트 인젝션	agent가 웹 페이지, issue 또는 이메일을 읽는 모든 사용자	쓰기 전 승인 절차; 신뢰할 수 없는 입력값 근처에 되돌릴 수 없는 tool 배치 금지
로컬 server가 사용자 권한으로 실행됨	stdio server를 설치하는 모든 사용자	신뢰할 수 있는 게시자, 범위가 제한된 secret, 버전 고정
원격 server의 OAuth 실수	server 구축자 및 호스트	MCP 인증 사양 준수; 토큰 전달 금지
한 곳에 너무 많은 권한 집중	많은 server를 가진 agent	각 agent에게 작업에 필요한 server만 부여

MCP가 보안 환경을 변화시키는 이유

기존의 통합 방식은 개발자가 미리 정의한 방식에 따라 API를 호출하는 코드를 작성하는 것이었습니다. 반면 MCP를 사용하면 모델이 컨텍스트에 포함된 모든 정보를 바탕으로 런타임에 어떤 도구를 어떤 인자로 호출할지 직접 결정합니다. 이때 컨텍스트에는 팀원이 작성하지 않은 텍스트, 즉 모델이 가져온 웹 페이지, GitHub issue, 이메일, 또는 다른 도구의 실행 결과 등이 포함될 수 있습니다.

이것이 문제의 핵심입니다. 모델은 신뢰할 수 없는 입력을 읽고 판단을 내리는 의사 결정자입니다. 대부분의 MCP 리스크는 "신뢰할 수 없는 텍스트가 도구 호출을 유도함" 또는 "해당 상황에서 도구가 필요 이상의 권한을 가짐"과 같은 형태로 나타납니다.

리스크 1: 콘텐츠를 통한 프롬프트 인젝션

GitHub server를 연결하여 이슈에 댓글을 달거나 이슈를 닫을 수 있는 권한을 부여했다고 가정해 보겠습니다. 그리고 에이전트에게 새로운 이슈를 분류(triage)하도록 요청합니다. 이때 어떤 이슈의 긴 로그 사이에, 어시스턴트에게 모든 오픈 이슈를 중복 이슈로 처리하여 닫으라고 지시하는 문장이 숨겨져 있다고 가정해 봅시다. 데이터에 포함된 지시 사항을 따르는 모델은 정확히 그 명령을 수행할 수 있습니다.

Model Context Protocol 자체에는 이를 방지하는 기능이 없습니다. 모델의 추론 과정은 프로토콜이 검증할 수 있는 영역이 아니기 때문입니다. 이를 보완하기 위해서는 계층적인 방어 체계가 필요합니다. 우수한 호스트는 데이터를 변경하는 도구를 실행하기 전에 사용자에게 승인을 요청하고 전달될 인자(arguments)를 보여줍니다. 우수한 server는 쓰기나 삭제를 수행하는 도구에 별도로 표시를 하여, 호스트가 이를 다르게 처리할 수 있도록 합니다. 또한 작업에 필요한 최소한의 권한만 에이전트에게 부여할 수 있습니다. 예를 들어 이슈 분류 작업에는 읽기와 라벨 지정 권한만 필요하며, 이슈를 닫거나 삭제하는 권한은 필요하지 않습니다.

주의

신뢰할 수 없는 콘텐츠를 읽는 에이전트는 사람이 확인하기 전에는 되돌릴 수 없는 작업을 수행하는 도구를 보유해서는 안 됩니다. 이것은 저희가 스스로 준수하는 규칙입니다.

리스크 2: 로컬 서버가 사용자의 권한으로 실행됨

로컬 서버는 사용자의 AI 앱에 의해 시작되며, 사용자의 권한을 가진 컴퓨터 상의 프로그램입니다. 로컬 서버는 사용자가 읽을 수 있는 파일을 읽을 수 있고, 사용자가 접근할 수 있는 네트워크에 도달할 수 있습니다. MCP 보안 모범 사례에서는 이를 별도의 리스크로 다룹니다. 악의적이거나 침해된 로컬 서버는 클라이언트의 권한으로 임의의 명령을 실행할 수 있으므로, 원클릭 설치 흐름에서는 반드시 명시적인 동의를 얻고 실행될 정확한 명령을 보여주어야 합니다.

로컬 서버는 특히 개발자 도구 분야에서 우리 카탈로그의 큰 비중을 차지하며, 그중 상당수는 secret이 필요합니다. 2026년 11월 11일 기준으로 11,660개의 서버가 환경 변수를 선언했으며, 그중 12,757개의 변수가 API key, token, password와 같이 클라이언트의 설정 파일에 저장되는 secret으로 표시되었습니다.

우리 enrichment model이 README를 읽어 분석한 결과, 카탈로그 내 서버들의 인증 방식은 다음과 같습니다 (측정값 November 14, 2026):

인증	Servers	공유
없음	18,603	46%
API key 또는 OAuth	10,519	26%
API key 또는 token	9,247	23%
OAuth	2,389	6%

이에 대응하는 방법은 대부분 일관되게 적용되는 상식적인 수준입니다.

제품의 벤더나 other 작업물을 확인할 수 있는 퍼블리셔의 서버를 우선적으로 선택하십시오. 서버 페이지에서 퍼블리셔를 확인할 수 있으며, 공식 서버는 별도로 표시됩니다.

소스가 공개되어 있고 활발히 관리되는지 확인하십시오. 연결된 repository가 없거나 마지막 수정이 1년 전인 패키지는 위험 부담이 큽니다. 각 HostedMCP 페이지에는 마지막 commit 및 release 날짜가 표시됩니다.

설치하기 전에 도구 목록을 읽어보십시오. 만약 "weather" 서버에 shell 명령을 실행하는 도구가 있다면 중단하십시오.

secret의 범위를 제한하십시오. 데이터베이스 서버에는 read-only 사용자를 부여하십시오. GitHub 서버에는 특정 repository에 대한 fine-grained token을 부여하십시오. filesystem 서버는 특정 프로젝트 폴더를 가리키도록 설정하고, 절대로 홈 디렉토리를 지정하지 마십시오.

팁

중요한 항목은 버전을 고정하십시오. npx -y some-server@latest는 실행될 때마다 가장 최근에 게시된 버전을 실행하지만, npx -y some-server@1.4.2는 사용자가 확인한 버전을 실행합니다.

프록시를 실행하는 경우 알아두어야 할 로컬 리스크가 명세에 하나 더 있습니다. 웹 페이지가 로컬 MCP 프록시에 도달할 수 있는 설정에서, 해당 페이지의 cross-site scripting 버그는 프록시의 stdio 서버를 통해 명령 실행으로 에스컬레이션될 수 있습니다. localhost에서 MCP gateway 또는 프록시를 실행한다면, 이를 공격 표면을 가진 다른 로컬 서비스와 동일하게 취급하십시오.

리스크 3: 원격 서버 및 OAuth

원격 서버는 사용자의 로컬 머신에 직접적인 영향을 주지는 않지만, 여러 사용자의 토큰을 보유하고 사용자를 대신하여 다른 서비스와 통신하므로 다른 종류의 문제들을 야기합니다. MCP 보안 모범 사례에서는 다음과 같은 문제들을 명시하고 있습니다.

공격 유형	발생 가능한 문제	방어 방법
Token passthrough	서버가 자신에게 발급되지 않은 토큰을 수락하거나, 사용자의 토큰을 상위 서비스로 전달함	해당 서버를 위해 발급된 토큰만 수락하고, 절대 전달하지 않음
Confused deputy	정적 클라이언트 ID를 사용하는 프록시가 실제 동의 없이 악의적인 클라이언트에게 코드를 부여함	프록시에서 클라이언트별 동의 절차 수행
Server-side request forgery	OAuth discovery가 클라이언트를 클라우드 메타데이터와 같은 내부 URL로 유도함	클라이언트가 discovery URL을 검증함
Mix-up attack	악의적인 인증 서버가 정상적인 서버의 토큰 엔드포인트로 코드를 전송함	iss 검증 (RFC 9207), 2026-07-28 추가됨
Authorization URL abuse	서버가 javascript: URL 또는 쉘 메타문자를 반환함	클라이언트가 URL을 열기 전에 검증함
Localhost redirect impersonation	다른 로컬 프로세스가 localhost로 전송된 코드를 가로챔	데스크톱 클라이언트에서 리다이렉트 처리를 주의 깊게 수행함
Over-broad scopes	유출된 토큰이 필요한 작업보다 훨씬 더 많은 권한을 가짐	가장 좁은 범위의 scope를 요청함

첫 번째 행의 규칙은 명확합니다. MCP server는 해당 MCP server를 위해 명시적으로 발급되지 않은 토큰을 수락해서는 안 됩니다.

2026-07-28 개정판에서는 OAuth Dynamic Client Registration 대신 Client ID Metadata Documents를 사용하도록 권장하며, stateless 설계가 프로토콜 세션을 대체함에 따라 기존의 세션 하이재킹 우려는 이제 서버가 발급하는 상태 핸들(state handles)의 하이재킹 문제로 다루어집니다. 서버가 상태를 유지해야 한다면, 해당 핸들을 추측할 수 없게 만들고 사용자와 결합하십시오.

리스크 4: 한 곳에 너무 많은 권한 집중

가장 간과하기 쉬운 리스크는 집중화입니다. GitHub MCP server, Slack MCP server, 데이터베이스 MCP server, 브라우저 MCP server를 모두 가진 단일 에이전트는 하나의 컨텍스트 안에서 코드를 읽고, 메시지를 확인하며, 고객 정보를 조회하고, 모든 웹사이트를 방문할 수 있습니다. 이 경우 주입된 단일 명령어가 데이터를 외부로 유출하는 방법까지 포함하여 매우 광범위한 작업을 수행할 수 있게 됩니다.

권한을 분리하면 도움이 됩니다. 에이전트에게 모든 서버를 제공하는 대신 현재 작업에 필요한 서버만 부여하십시오. 민감한 데이터를 읽는 서버와 외부로 데이터를 게시할 수 있는 서버를 분리하거나, 최소한 외부로 데이터를 보내는 서버는 승인 절차를 거치도록 설정하십시오.

서버 설치 사용자를 위한 체크리스트

서버를 추가하기 전, 몇 분만 투자하여 다음 사항을 확인하면 대부분의 문제를 방지할 수 있습니다.

1. 게시자를 확인합니다. 벤더 공식 버전인지, 혹은 신원을 확인할 수 있는 관리자인지 확인하십시오.
2. 코드가 공개되어 있는지, 최근까지 유지보수되고 있는지 확인합니다.
3. 모든 도구의 이름과 설명을 읽어봅니다. 서버의 목적과 맞지 않는 도구가 있다면 주의가 필요합니다.
4. 권한을 최소한으로 부여합니다. 읽기 전용 사용자, 단일 저장소 토큰, 단일 폴더 등으로 제한하십시오.
5. 쓰기 및 삭제 작업은 반드시 승인을 거치도록 설정하며, 신뢰할 수 있을 때까지 영구 승인을 하지 마십시오.
6. 의존성이 있는 서버는 버전을 고정하고, 신중하게 업데이트합니다.
7. 더 이상 사용하지 않는 서버는 삭제합니다. 설치된 모든 서버는 공격 표면(attack surface)이자 컨텍스트 창(context window)을 차지합니다.

HostedMCP의 모든 서버 페이지에는 게시자, 마지막 커밋, 필요한 환경 변수 및 전체 도구 목록이 표시되어 있어, 처음 네 가지 항목을 1분 안에 확인할 수 있습니다.

서버 개발자를 위한 체크리스트

서버를 직접 유지 관리한다면 그만큼 더 큰 책임이 따릅니다.

1. 작업 단위의 이름을 사용하여, 목적을 달성하는 데 필요한 최소한의 도구 세트만 노출합니다.
2. 쓰기 또는 삭제 작업을 수행하는 도구에는 destructive hint를 표시하여, 호스트가 사전에 사용자에게 확인을 요청할 수 있도록 합니다.
3. 모든 인자는 공격자가 보낸 것이라고 가정하고 검증합니다. 실제로 그럴 수 있기 때문입니다.
4. 로그는 반드시 stderr로 기록하며, stdout에는 절대 기록하지 않습니다. 또한 비밀 정보(secrets)를 로그에 남기지 않습니다.
5. 원격 서버의 경우 MCP authorization spec을 준수합니다: OAuth 2.1을 사용하고, 해당 서버를 위해 발급된 토큰만 허용하며, 토큰 전달(passthrough)을 금지하고, 스코프(scope)를 최소화합니다.
6. 상태 핸들(state handles)은 비밀 정보처럼 취급합니다: 무작위로 생성하고, 사용자에 종속시키며, 유효 기간을 짧게 유지합니다.
7. 서버에 필요한 모든 권한과 환경 변수를 문서화하되, 값은 반드시 placeholder로만 작성합니다.

MCP server 구축 가이드에서는 현재 SDK를 사용한 기초적인 방법을 설명하며, MCP vs API에서는 데이터를 적게 반환하는 것이 왜 보안 측면에서 유리한지 설명합니다.

팀 내 MCP 운영

업무에서 MCP를 사용하는 인원이 늘어나면 임시로 설치하는 방식으로는 확장이 어렵습니다. 다음의 습관을 통해 효율적으로 관리할 수 있습니다.

습관	도움이 되는 이유
저장소에 승인 및 고정된 서버 목록 관리	모두가 검토된 동일한 버전을 사용함
에이전트별 별도 식별 정보 부여	감사 로그를 통해 에이전트의 동작을 확인 가능하며, 권한 회수 시 다른 사용자의 접속을 차단하지 않음
SaaS 제품용 호스팅 서버 사용	노트북에 API key를 저장할 필요가 없으며, 제품의 관리자 제어 기능에 따라 액세스 권한이 관리됨
도구 호출 로그 기록	예상치 못한 결과 발생 시, 어떤 콘텐츠가 모델의 동작을 유도했는지 로그로 확인 가능
의존성 라이브러리처럼 업데이트 검토	사용자의 권한으로 실행되는 새로운 코드를 실행 전에 미리 검토함

승인된 목록을 유지하십시오. 팀에서 사용할 서버를 선정하고 버전을 고정하며, 각자의 홈 디렉터리가 아닌 저장소를 통해 설정을 공유하십시오. Claude Code의 프로젝트 범위 .mcp.json 및 VS Code의 워크스페이스 .vscode/mcp.json이 바로 이 용도로 존재하며, 클라이언트 가이드에서 각 도구의 프로젝트 설정 위치를 확인할 수 있습니다.

에이전트에게 별도의 식별 정보를 부여하십시오. 개인 자격 증명과 분리된 에이전트용 서비스 계정이나 bot token을 사용하면, 감사 로그에서 에이전트가 수행한 동작을 명확히 파악할 수 있고 다른 사용자의 접속을 차단하지 않고도 권한을 회수할 수 있습니다.

SaaS의 경우 호스팅 서버 사용을 권장합니다. 벤더가 자사 제품을 위한 MCP server를 직접 운영하면, 노트북에 API key를 배포할 필요가 없으며 액세스 권한은 제품의 다른 기능과 동일하게 OAuth 승인 및 관리자 제어에 따라 관리됩니다. 원격 서버 목록을 통해 어떤 벤더가 서비스를 제공하는지 빠르게 확인할 수 있습니다.

도구 호출을 기록하십시오. 대부분의 호스트는 어떤 도구가 어떤 인자와 함께 실행되었는지 기록할 수 있습니다. 이러한 로그를 다른 감사 로그와 함께 보관하고, 예상치 못한 상황이 발생하면 확인하십시오. 대개 어떤 콘텐츠가 모델의 동작을 유도했는지 정확히 보여줍니다.

업데이트를 의존성 라이브러리처럼 검토하십시오. 서버 업데이트는 사용자의 권한으로 실행되는 새로운 코드입니다. 라이브러리를 검토할 때와 마찬가지로, 운영 시스템에 쓰기 권한이 있는 서버의 경우 changelog를 반드시 확인하십시오.

HostedMCP의 검사 범위 및 제한 사항

HostedMCP는 디렉토리 서비스이며 보안 감사 기관이 아니므로, 그 경계를 명확히 밝혀둡니다. 저희는 모든 리스팅에 대해 저장소, 패키지 및 README를 읽고, 발행자, 마지막 커밋, 릴리스 및 선언된 환경 변수를 기록하며, 전체 도구 목록을 표시합니다. 대량 발행자의 리스팅은 플래그를 지정하며, 포크 및 미러는 원본으로 병합합니다.

저희는 서버를 실행하거나 코드를 감사하지 않습니다. HostedMCP에 리스팅되어 있다는 것은 저희가 해당 항목을 찾아 정확하게 설명했다는 의미일 뿐, 귀하의 환경에서 안전하다는 것을 보장하지 않습니다. 안전 여부에 대한 판단은 귀하의 몫이며, 위의 체크리스트는 저희가 검토할 때 사용하는 기준입니다.

이 모든 과정이 처음이라면, MCP란 무엇인가와 MCP server란 무엇인가를 먼저 살펴보는 것이 좋습니다. 또한 원격 서버 목록을 이용하면 귀하의 로컬 머신에 전혀 영향을 주지 않고 서버를 테스트할 수 있는 가장 쉬운 방법을 확인할 수 있습니다.