MCP 보안 체크리스트: tool poisoning·prompt injection·권한 경계

5월 25, 2026 댓글 없음

MCP 서버를 붙일 때는 도구 이름만 보지 말고 도구 설명, 권한, 네트워크 경계, 승인 로그부터 확인하는 편이 안전해요. 서버를 하나 연결하는 순간 모델은 그 서버의 tool description을 읽고, 사용자는 그 설명을 정상 설정값처럼 믿기 쉬워서 여기서 보안 사고의 입구가 생깁니다.

MCP를 이미 쓰고 있거나 곧 도입한다면, 새 서버를 붙이기 전에 출처와 권한부터 정리해 두세요. 이 글은 공격 기법을 과장하기보다 개발자, 자동 처리 운영자, 사내 AI 도구 담당자가 바로 적용할 방어 기준만 남긴 체크리스트예요.

MCP에서 가장 먼저 봐야 할 위험

MCP는 모델이 외부 도구, 데이터, 파일, API를 더 쉽게 다루게 해주는 표준 인터페이스예요. 편리한 만큼 보안 운영에서는 모델에 새 실행 경로를 붙이는 일로 보고, tool poisoning, prompt injection, 권한 경계 세 가지를 먼저 점검하면 돼요.

도구 설명 오염: MCP 서버가 제공하는 tool description 안에 모델을 속일 지시가 들어가는 경우
권한 과다: 파일, 셸, 브라우저, API 토큰 같은 민감 권한이 한 번에 열리는 경우
경계 혼동: 여러 MCP 서버가 서로 격리되어 있다고 믿지만 모델이 중간 전달자가 되어 경계가 무너지는 경우

특히 tool poisoning은 사용자가 어떤 도구를 직접 호출하기 전에도 영향을 줄 여지가 있어요. MCP 클라이언트가 서버에 연결하면서 tools/list로 도구 목록과 설명을 받아 모델 컨텍스트에 넣기 때문이에요. 악의적인 설명이 섞이면 모델이 그 내용을 일반 지시처럼 취급할 수 있어요.

Tool poisoning이 위험한 이유

Tool poisoning은 MCP 도구의 이름, 설명, 예시, 매개변수 설명에 숨은 지시를 넣어 모델 행동을 바꾸는 공격이에요. 겉으로는 평범한 “파일 검색 도구”나 “문서 요약 도구”처럼 보여도 설명 안에는 “다른 명령을 실행할 때도 이 규칙을 따르라” 같은 문장이 숨어 있을 수 있어요.

Trail of Bits는 이 문제를 “line jumping”이라고 설명했습니다. 도구가 실제로 호출되기도 전에 도구 설명이 모델 컨텍스트에 들어가므로, 공격자가 보안 체크포인트 앞줄로 끼어드는 셈이에요. Invariant Labs도 MCP tool poisoning을 별도 보안 이슈로 다루며, 도구 설명 자체를 신뢰 경계 밖의 입력으로 봐야 한다는 대목을 강조했습니다.

실무에서는 아래 상황이 특히 위험해요. 하나라도 해당하면 운영 계정보다 격리된 테스트 환경에서 먼저 검증하는 편이 좋아요.

검증되지 않은 공개 MCP 서버를 개발 환경에 바로 연결하는 경우
셸 실행, 파일 읽기, 네트워크 요청 권한을 한 클라이언트에 몰아주는 경우
자동 승인 모드로 명령 실행을 켜두는 경우
여러 MCP 서버를 동시에 연결하면서 서버별 데이터 접근 범위를 나누지 않는 경우
도구 설명 변경 이력을 기록하지 않는 경우

Prompt injection과 MCP 연결

OWASP는 prompt injection을 LLM 앱의 핵심 위험 중 하나로 봐요. 사용자가 보는 문서, 웹페이지, 이메일, 도구 응답 안에 숨은 지시가 모델의 원래 지시를 덮어쓸 수 있기 때문이에요. MCP에서는 모델이 읽는 입력이 사용자 질문뿐 아니라 도구 설명, 도구 응답, 외부 API 결과, 파일 내용까지 넓어집니다.

모델이 외부 텍스트를 읽을 때는 “명령”으로 실행하지 않도록, 클라이언트와 서버 양쪽에서 “데이터” 취급 규칙을 분명히 두어야 해요.

이 원칙은 클라이언트, 서버, 운영 정책에 함께 반영해야 해요. “모델이 알아서 구분하겠지”에 맡기기보다, 실행 전에 경계와 검증 단계를 명확히 두고 사람이 승인 로그를 확인할 수 있게 만드는 쪽이 안전해요.

도입 전 15분 체크리스트

새 MCP 서버를 붙이기 전에는 아래 항목부터 보면 돼요. 표에서 하나라도 “아니오”가 나오면 운영 환경이 아니라 격리된 테스트 환경에서 먼저 검증하는 편이 안전해요.

점검 항목	확인 질문	권장 조치
출처	서버 코드와 배포자를 신뢰할 수 있나요?	공식 저장소, 커밋 이력, 릴리스 노트 확인
도구 설명	tool description에 숨은 지시나 과도한 행동 유도가 있나요?	도구 설명을 리뷰하고 변경 이력 저장
권한	필요 이상의 파일, 셸, 네트워크 권한을 주고 있나요?	읽기 전용, 디렉터리 제한, 명령 allowlist부터 시작
승인	위험 작업 전에 사람이 의미 있는 검토를 할 수 있나요?	자동 실행 금지, diff·명령·대상 URL을 승인 화면에 표시
격리	서버별 토큰과 데이터 범위가 분리되어 있나요?	서버별 계정·토큰·스코프 분리
로그	누가 어떤 도구를 어떤 입력으로 호출했는지 남나요?	요청 ID, 도구명, 승인자, 결과 요약 기록

권한 경계 잡는 법

MCP 서버를 안전하게 연결하는 쉬운 기준은 최소 권한을 기본값으로 두고 필요한 권한만 단계적으로 여는 것입니다. 처음부터 전체 홈 디렉터리, 셸, 네트워크를 전부 허용하면 사고 뒤 원인을 좁히기 어려워요.

파일 접근: 프로젝트 루트 안의 필요한 하위 디렉터리만 허용해요.
셸 실행: 기본 차단 뒤 빌드·테스트처럼 반복되는 명령만 allowlist로 엽니다.
네트워크: 내부망, 메타데이터 IP, 관리자 URL 접근을 차단해요.
토큰: MCP 서버별 전용 토큰을 쓰고 다른 서비스와 공유하지 않아요.
쓰기 작업: 파일 수정, 배포, 외부 API 변경은 별도 승인 단계로 분리해요.

mcp_policy:
 filesystem:
 allow_read:
 - ./docs
 - ./src
 allow_write:
 - ./tmp/mcp-output
 deny:
 - ~/.ssh
 - ~/.env
 - ~/.config
 shell:
 default: deny
 allow:
 - npm test
 - python -m pytest
 network:
 block_private_ip: true
 block_cloud_metadata: true
 require_https: true

이 예시는 특정 제품 설정 파일이 아니라 운영 기준을 표현한 겁니다. 실제 클라이언트가 지원하는 정책 문법에 맞게 옮기면 돼요.

OAuth와 토큰에서 자주 터지는 문제

MCP 보안 모범 사례 문서는 OAuth 프록시, consent cookie, token audience 같은 주제를 중요하게 다뤄요. 핵심은 이 토큰이 누구를 위해 발급됐고 어떤 서버가 받아도 되는지 명확히 검증해야 한다는 대목이에요.

MCP 서버가 다른 API 앞단의 프록시처럼 동작할 때 confused deputy 문제가 생길 수도 있어요. 사용자는 정상 흐름으로 승인했다고 생각하지만 정적 client ID, 동적 client registration, consent cookie 조합 때문에 공격자가 승인 코드를 가로채거나 동의 화면을 우회하는 흐름이 생길 수도 있어요.

MCP 서버는 자신을 대상으로 발급된 토큰만 받아야 합니다.
토큰의 audience, scope, issuer, 만료 시간을 검증해야 해요.
서버별 토큰을 공유하지 말고 사용자·환경·권한별로 분리해요.
consent 상태는 사용자 승인 후에만 저장하고 콜백에서 state 값을 반드시 비교해요.
운영 로그에는 토큰 원문을 저장하지 않고 해시나 요약 식별자만 남깁니다.

SSRF와 네트워크 경계도 같이 봅니다

MCP 클라이언트나 서버가 URL을 가져오는 기능을 갖고 있다면 SSRF 위험도 함께 봐야 해요. 악의적인 서버가 OAuth metadata나 redirect URL을 이용해 내부망, 클라우드 메타데이터 주소, 관리자 페이지로 요청을 보내게 만들 수 있기 때문이에요.

169.254.169.254 같은 클라우드 메타데이터 IP 접근
사설 IP 대역, loopback, link-local 주소 접근
HTTP 기반 OAuth URL 사용
검증 없는 redirect chain 자동 추적
내부 관리자 페이지나 쿠버네티스 API 서버 접근

좋은 기본값은 “외부 HTTPS allowlist만 허용”입니다. 편의성은 조금 줄지만 MCP가 내부망 프록시로 변하는 최악의 사고를 막는 데 도움이 돼요.

운영팀용 MCP 배포 기준

운영 환경에서는 도구를 붙였다는 사실만으로 충분하지 않아요. 누가 승인했고, 어떤 권한을 열었고, 언제 설명이 바뀌었는지 남겨야 나중에 사고 범위를 좁힐 수 있어요.

서버 등록: 서버 이름, 저장소, 배포자, 버전, 담당자를 기록해요.
권한 명세: 파일, 네트워크, 셸, 외부 API 권한을 표로 남깁니다.
도구 설명 스냅샷: 최초 연결 시 tool description을 저장하고 변경 시 diff를 봐요.
승인 정책: 읽기 작업, 쓰기 작업, 배포 작업의 승인 단계를 분리해요.
로그 정책: 도구 호출, 승인, 실패, 차단 이벤트를 한 곳에 남깁니다.
퇴출 기준: 설명 변경, 권한 증가, 의심스러운 네트워크 요청이 보이면 즉시 비활성화해요.

실전 방어 규칙 10가지

아래 규칙은 제품별 설정 문법이 아니라 운영 기준이에요. 사용하는 MCP 클라이언트와 배포 환경에 맞게 정책, 승인 화면, 로그 항목으로 옮기면 돼요.

검증되지 않은 MCP 서버는 운영 계정에 연결하지 않는 편이 안전해요.
도구 설명은 신뢰 입력이 아니라 외부 데이터로 취급해요.
위험 명령 자동 실행을 기본값으로 켜두지 않아요.
파일 쓰기 권한은 별도 디렉터리에만 줍니다.
서버별 전용 토큰과 최소 scope를 사용해요.
OAuth state, redirect URI, token audience를 검증해요.
내부망과 클라우드 메타데이터 주소 접근을 차단해요.
도구 목록과 설명 변경을 로그로 남깁니다.
모델 응답보다 실행 전 정책 엔진을 더 신뢰해요.
사고가 의심되면 토큰 폐기, 서버 비활성화, 로그 보존부터 처리해요.

사고가 의심될 때 첫 조치

의심스러운 MCP 동작을 발견했다면 “한 번 더 실행해 보기”보다 중지가 먼저예요. 셸 실행, 파일 접근, 외부 API 쓰기 권한이 연결되어 있다면 작은 이상 징후도 크게 봐야 해요.

MCP 클라이언트에서 해당 서버를 비활성화해요.
관련 토큰과 application password를 폐기하거나 재발급해요.
최근 tool description 변경 내역과 도구 호출 로그를 보존해요.
파일 변경, 외부 API 변경, 배포 로그를 확인해요.
동일 서버를 쓰는 다른 개발자나 자동 처리 환경이 있는지 찾습니다.
재활성화 전에는 권한을 줄이고 격리 환경에서 재검증해요.

결론: MCP는 막을 기술이 아니라 다룰 기술입니다

MCP는 막을 기술이라기보다 다룰 기술이에요. AI 도구 생태계에서 계속 중요해질 여지가 있지만, MCP 서버를 “편한 플러그인” 정도로 보면 도구 설명과 권한이 곧 보안 설계의 일부라는 점을 놓치기 쉬워요.

현실적인 시작점은 간단해요. 새 MCP 서버를 붙일 때마다 출처, 도구 설명, 권한, 승인, 네트워크, 로그 여섯 가지만 확인해두면 돼요. 이 기본선을 지키면 tool poisoning이나 prompt injection이 발생해도 피해 범위가 훨씬 작아집니다.

FAQ

MCP 서버를 하나만 쓰면 안전한가요?

서버를 하나만 쓰면 경계는 단순해지지만, 도구 설명 오염이나 과도한 권한 문제까지 사라지지는 않아요. 단일 서버 구성에서도 출처와 권한 검토를 빼지 말고 같은 체크리스트로 확인하는 편이 안전해요.

자동 승인 모드는 무조건 끄는 게 좋나요?

운영 환경이나 민감 데이터가 있는 환경에서는 기본적으로 끄는 편이 안전해요. 자동화가 꼭 필요하다면 읽기 전용 작업부터 시작하고 쓰기·배포·외부 API 변경은 별도 정책으로 분리하면 돼요.

도구 설명을 사람이 매번 읽으면 충분한가요?

사람 검토만으로는 부족해요. 도구 설명 변경 diff, 권한 제한, 실행 전 정책 검증, 로그가 함께 있어야 사람이 놓치는 순간을 시스템이 막아줍니다.