MCP 서버 연결 전 보안 체크리스트: 권한·토큰·도구 승인·프롬프트 인젝션

캘린더를 읽는 MCP 서버와 이메일 전송 도구가 같은 에이전트에 열려 있다고 가정해 봅시다. 일정에 숨은 악성 지시를 모델이 명령으로 오인하면 읽은 정보를 외부로 보내는 호출로 이어질 수 있습니다.

MCP(Model Context Protocol)는 LLM 애플리케이션과 데이터·도구를 연결하는 공개 프로토콜입니다. 최신 2026-07-28 사양은 호스트, 클라이언트, 서버가 어떤 메시지를 주고받는지 정의하지만, 구현체의 보안 정책을 대신 결정하지는 않습니다. 공식 사양도 임의의 데이터 접근과 코드 실행 경로가 생길 수 있으며, 동의와 접근제어는 구현자가 갖춰야 한다고 밝힙니다. MCP Specification 2026-07-28

특정 서버의 등급을 매기지 않고 연결·운영 시 확인할 항목을 다룹니다.

1. 서버를 신뢰하기 전에 도구부터 제한한다

서버가 읽을 데이터, 실행할 행동, 통신할 도메인과 사용할 신원을 먼저 적습니다. MCP 도구는 모델이 발견하고 호출하므로 애플리케이션은 노출된 도구와 실행 시점을 보여주고 사람이 거부할 수 있게 해야 합니다. MCP Tools의 User Interaction Model

search가 사내 전체 문서를 읽거나 run_query가 임의 SQL을 실행한다면 이름만 보고 조회 도구로 분류할 수 없습니다. 입력 스키마, 연결 계정, 대상 리소스와 네트워크 경로를 봐야 합니다.

배포 주체, 소스 저장소, 패키지 서명이나 해시, 업데이트 경로와 취약점 신고 창구를 확인합니다. 검토 전에는 테스트 계정과 격리된 데이터만 연결합니다.

클라이언트가 받아오는 도구 설명도 보안 정책으로 사용하면 안 됩니다. MCP 사양은 readOnlyHint, destructiveHint, idempotentHint 같은 annotation을 힌트로 정의하며, 신뢰된 서버에서 받은 것이 아니라면 클라이언트가 이를 신뢰하지 말아야 한다고 명시합니다. MCP Tools의 Tool 데이터 형식

서버가 delete_record를 읽기 전용으로 표시했더라도 실제 권한 검사는 정책 계층에서 이뤄져야 합니다. UI 배지와 프롬프트는 인증·인가가 아닙니다.

운영 주체와 배포 출처를 확인하고 사용할 도구만 허용 목록에 넣습니다. 첫 연결은 테스트 계정과 격리된 데이터로 수행합니다.

2. HTTP OAuth와 로컬 STDIO를 같은 방식으로 다루지 않는다

MCP 인증 사양은 HTTP 전송에서 제한된 서버에 접근하는 OAuth 흐름을 정의합니다. 인증 지원 자체는 선택 사항이며, HTTP 구현은 해당 사양을 따르도록 권고됩니다. STDIO 전송은 이 OAuth 흐름을 사용하지 않고 환경에서 자격 증명을 가져오도록 설명돼 있습니다. MCP Authorization의 Protocol Requirements

STDIO에서는 환경 변수로 받은 API 키가 하위 프로세스, 로그, 오류 메시지에 노출되지 않는지 살펴야 합니다. 로컬 실행이라는 이유로 비밀 저장과 파일 접근 범위를 생략할 수는 없습니다.

HTTP OAuth에서는 처음부터 넓은 스코프를 요청하지 않는 것이 기본선입니다. 최신 사양은 클라이언트가 현재 작업에 필요한 스코프만 요청하고, 추가 권한이 필요한 시점에 insufficient_scope 응답을 바탕으로 단계적으로 권한을 늘리는 방식을 권고합니다. MCP Authorization의 Scope Selection Strategy

스코프도 files:read, files:write, files:delete, messages:send처럼 작업 단위로 나눕니다. workspace:all 하나로 묶으면 조회 작업에도 삭제와 관리자 권한이 따라옵니다.

3. 토큰은 목적지와 수명을 함께 제한한다

MCP 클라이언트는 인증 요청과 토큰 요청에 resource 값을 포함해 토큰의 대상 MCP 서버를 지정해야 합니다. 서버 역시 들어온 토큰이 자신을 대상으로 발급됐는지 검증해야 합니다. MCP Authorization의 Resource Parameter와 Token Handling

MCP 서버가 외부 API를 호출할 때도 클라이언트에서 받은 토큰을 그대로 넘기면 안 됩니다. 공식 보안 고려사항은 하위 API용 별도 토큰을 사용하도록 하고 token passthrough를 금지합니다. MCP Authorization Security Considerations

HTTP 요청은 Authorization: Bearer 헤더를 사용하고 액세스 토큰을 URI 쿼리에 넣어서는 안 됩니다. MCP Authorization의 Access Token Usage

공식 보안 문서는 안전한 토큰 저장과 수명이 짧은 액세스 토큰을 권고하며, 공개 클라이언트의 refresh token 회전을 요구합니다. MCP Authorization Security Considerations의 Token Theft

토큰은 전용 비밀 저장소에 보관하고 저장소, 프롬프트, URL과 일반 로그에는 넣지 않습니다.

4. 승인은 도구 이름이 아니라 실제 호출을 보여줘야 한다

“이 도구를 허용하시겠습니까?”만으로는 판단하기 어렵습니다. 같은 send_email도 본인에게 초안을 보내는 호출과 외부 주소 수백 개에 파일을 전송하는 호출의 위험이 다릅니다.

MCP 도구 사양은 민감한 작업에서 사용자 확인을 요청하고, 호출 전에 입력값을 보여줘 악의적이거나 실수로 발생하는 데이터 유출을 막도록 권고합니다. 클라이언트는 도구 결과를 LLM에 넘기기 전에 검증하고, 타임아웃과 감사 로그도 구현해야 합니다. MCP Tools의 Security Considerations

호출 종류	기본 처리	승인 화면에 표시할 항목
제한된 공개 정보 조회	정책 통과 시 자동	도구, 조회 범위
사내·개인 데이터 조회	호출별 검토	데이터 종류, 계정, 조회 조건
파일·DB 생성과 수정	실행 전 승인	대상, 변경 전후 값, 복구 방법
삭제·결제·배포·외부 전송	강한 승인 또는 차단	수신자, 금액, 대상, 영향, 되돌리기 가능 여부
권한·토큰·보안 설정 변경	별도 관리자 승인	변경 권한, 적용 범위, 만료 시점

승인은 도구 이름, 정규화한 인자, 대상 리소스와 호출 ID를 묶어야 합니다. 승인 뒤 인자가 달라지면 다시 검토해야 합니다.

5. 프롬프트 인젝션은 입력과 출력 양쪽에서 들어온다

프롬프트 인젝션은 사용자 외의 제3자가 문서, 웹페이지, 이메일 등에 지시를 숨겨 모델의 행동을 바꾸려는 공격입니다. OpenAI는 공격 목표로 비공개 데이터 유출과 의도하지 않은 하위 도구 호출을 들고 있습니다. OpenAI, Safety in building agents

공격은 외부 문서의 악성 지시 → MCP 조회 결과 → 모델의 도구 선택 → 쓰기·전송 호출로 이어질 수 있습니다.

특정 문구만 지우는 필터로는 부족합니다. OpenAI 공식 지침은 신뢰할 수 없는 데이터를 developer message에 직접 넣지 않고, 노드 사이의 흐름을 enum이나 고정 스키마로 제한하며, MCP 도구 승인을 유지하라고 권고합니다. 이 조합도 모든 공격을 제거하지는 않습니다. OpenAI, Safety in building agents

MCP 서버도 출력을 정제해야 하고 클라이언트도 결과를 검증해야 합니다. 서버에는 입력 검증, 접근제어, rate limit, 출력 정제가 요구되며, 클라이언트에는 결과 검증과 호출 기록이 권고됩니다. MCP Tools의 Security Considerations

실무에서는 방어를 겹칩니다.

외부 콘텐츠를 신뢰하지 않는 데이터로 분리한다.
자유 형식 결과를 다음 도구 인자로 바로 전달하지 않는다.
허용 필드만 구조화하고 값·길이·대상을 검증한다.
읽기와 외부 전송을 같은 무승인 경로에 두지 않는다.
네트워크 목적지와 데이터 반출 크기를 제한한다.
연속 권한 상승과 새로운 목적지를 탐지한다.

운영 전 마지막 확인

아래 항목에 답할 수 없다면 운영 계정 연결을 미루는 편이 낫습니다.

출처·버전·노출 도구를 기록했다.
계정과 스코프를 최소 범위로 제한했다.
resource와 audience를 검증하고 token passthrough를 금지했다.
민감 호출은 인자와 대상을 보여준 뒤 승인받는다.
입력·출력 검증, 타임아웃, rate limit과 네트워크 제한이 있다.
요청·도구·승인·결과를 연결할 감사 ID와 사고 절차가 있다.

적용 한계

이 체크리스트는 서버 코드와 배포 환경을 감사한 결과가 아니므로 특정 서버의 신뢰성을 판정하지 않습니다.

사용자 승인을 켠 것만으로 프롬프트 인젝션이나 데이터 유출이 사라지지는 않습니다. 대상과 인자가 없거나 요청이 너무 잦으면 승인이 형식화될 수 있습니다.

이 글은 2026-07-28 사양을 기준으로 합니다. SDK와 호스트가 이전 버전을 구현할 수 있으므로 프로토콜 버전, OAuth 기능, 승인 UI와 로그 범위를 배포 전에 다시 확인해야 합니다.

처음에는 읽기 전용 테스트 폴더 하나만 연결하세요. 어떤 데이터가 읽혔고 어떤 인자로 도구가 호출됐으며 사용자가 어디서 멈출 수 있었는지 재구성할 수 있을 때 다음 권한을 열 근거가 생깁니다.