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

5월 25, 2026 댓글 없음

요약부터 말하면, MCP 보안은 “어떤 도구를 붙였는가”보다 도구 설명, 권한, 네트워크 경계, 승인 로그를 어떻게 통제하느냐가 핵심입니다. MCP 서버를 하나 붙이는 순간 모델은 그 서버의 도구 설명을 읽고, 사용자는 그 설명이 안전하다고 믿기 쉽습니다. 문제는 바로 이 지점에서 시작됩니다.

이 글은 MCP를 이미 쓰고 있거나 곧 도입하려는 개발자, 자동화 운영자, 사내 AI 도구 담당자를 위한 실전 체크리스트입니다. 공격 기법을 과장하지 않고, 지금 바로 적용할 수 있는 방어 기준만 정리했습니다.

MCP에서 가장 먼저 봐야 할 위험은 무엇인가요?

MCP는 모델이 외부 도구, 데이터, 파일, API를 더 쉽게 다루게 해주는 표준 인터페이스입니다. 편리하지만, 보안 관점에서는 모델에게 “새로운 손과 발”을 붙이는 일에 가깝습니다. 그래서 위험은 크게 세 가지로 나뉩니다.

도구 설명 오염: 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 결과, 파일 내용까지 확장되기 때문입니다.

즉, MCP 보안의 기본 원칙은 단순합니다.

모델이 읽는 모든 외부 텍스트는 “명령”이 아니라 “데이터”로 취급해야 합니다.

이 원칙을 클라이언트, 서버, 운영 정책에 모두 반영해야 합니다. “모델이 알아서 구분하겠지”는 보안 정책이 아닙니다. 모델에게는 더 명확한 경계와 실행 전 검증이 필요합니다.

도입 전 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을 이용해 내부망, 클라우드 메타데이터 주소, 관리자 페이지로 요청을 보내게 만들 수 있기 때문입니다.

서버 환경에서 MCP 클라이언트를 운영한다면 최소한 아래는 막아야 합니다.

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

좋은 기본값은 “외부 HTTPS allowlist만 허용”입니다. 편의성은 조금 줄지만, MCP가 내부망 프록시로 변하는 최악의 사고를 막을 수 있습니다.

운영팀용 MCP 배포 기준

개인 개발 환경이 아니라 팀 단위로 MCP를 쓴다면, 설치 자체보다 운영 기준이 더 중요합니다. 아래 기준을 문서로 남기고, 새 서버를 추가할 때마다 같은 양식으로 검토하세요.

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

실전 방어 규칙 10가지

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

사고가 의심될 때는 무엇부터 해야 하나요?

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

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

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

MCP를 쓰지 말자는 이야기가 아닙니다. 오히려 MCP는 AI 도구 생태계에서 계속 중요해질 가능성이 높습니다. 다만 MCP 서버를 “편한 플러그인” 정도로 보면 위험합니다. 모델에게 외부 도구를 연결하는 순간, 그 도구 설명과 권한은 보안 설계의 일부가 됩니다.

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

FAQ

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

아닙니다. 서버 수가 적으면 경계가 단순해질 뿐, 도구 설명 오염이나 과도한 권한 문제는 그대로 남습니다. 하나만 쓰더라도 출처와 권한 검토는 필요합니다.

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

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

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

충분하지 않습니다. 사람 검토는 필요하지만, 도구 설명 변경 diff, 권한 제한, 실행 전 정책 검증, 로그가 함께 있어야 합니다. 사람이 놓치는 순간을 시스템이 막아야 합니다.