MCP는 AI 에이전트에게 도구를 붙이는 표준 인터페이스로 자리 잡고 있습니다.
GitHub, 문서 검색, DB 조회, 브라우저 자동화, 내부 API 같은 기능을 에이전트가 호출할 수 있게 해줍니다.

편해지는 만큼 위험도 커집니다.
에이전트가 볼 수 있는 도구가 늘어나면, 잘못된 프롬프트 하나가 API 키, OAuth 토큰, 내부 파일, 고객 데이터로 이어질 수 있습니다.

이 글은 2026년 5월 28일 기준 Model Context Protocol 보안 가이드, GitHub MCP Server 문서, OWASP LLM Top 10을 바탕으로 MCP 서버를 붙일 때 먼저 확인할 체크리스트를 정리합니다.

MCP에서 키가 새는 흔한 경로

API 키 유출은 꼭 .env 파일을 커밋할 때만 생기지 않습니다.
MCP를 쓰면 새는 경로가 더 다양해집니다.

자주 보는 경로는 이렇습니다.

  1. 사용자가 대화창에 실제 키를 붙여 넣음
  2. MCP 서버 로그에 request header나 token이 남음
  3. 로컬 MCP 서버가 너무 넓은 파일 권한을 가짐
  4. 에이전트가 외부 문서나 이슈의 악성 지시를 그대로 따름
  5. OAuth scope가 너무 넓음
  6. tool 결과가 다시 다른 tool 입력으로 전달됨
  7. secret scanning 없이 변경사항을 커밋함

즉 MCP 보안은 “키를 숨긴다”만으로 부족합니다.
에이전트가 무엇을 볼 수 있고, 무엇을 호출할 수 있고, 그 결과가 어디에 남는가까지 봐야 합니다.

1. MCP 서버를 먼저 분류합니다

모든 MCP 서버를 같은 위험도로 보면 안 됩니다.

먼저 이렇게 나눕니다.

유형예시기본 원칙
읽기 전용 문서 서버공식 문서 검색비교적 낮은 권한으로 허용
저장소 접근 서버GitHub, GitLabrepo scope 최소화
운영 데이터 서버DB, 로그, CRM기본 차단, 필요 시 읽기 전용
실행형 서버shell, browser, deploy별도 승인과 감사 로그
내부 API 서버사내 API gateway서비스 계정과 scope 분리

OpenAI의 Docs MCP처럼 문서만 읽는 서버와, shell이나 운영 DB를 만지는 서버는 위험도가 다릅니다.
분류가 끝나야 permission도 정할 수 있습니다.

2. API 키를 에이전트 입력으로 넘기지 않습니다

가장 단순하지만 가장 중요한 규칙입니다.

API 키는 절대 프롬프트에 붙여 넣지 않는다.

에이전트가 키 값을 직접 볼 필요가 있는 경우는 거의 없습니다.
대부분은 환경 변수 이름, secret manager key 이름, placeholder만 알아도 충분합니다.

나쁜 요청은 이렇습니다.

이 키로 API 호출 테스트해줘: sk-live-...

더 나은 요청은 이렇습니다.

OPENAI_API_KEY 환경 변수가 설정돼 있다고 가정하고 API 호출 예제와 에러 처리 코드를 만들어줘. 실제 키 값은 출력하지 마.

3. OAuth scope와 token 권한을 최소화합니다

MCP 보안 가이드는 authorization, session, confused deputy 문제를 중요하게 다룹니다.
실무에서는 scope가 너무 넓은 token이 가장 먼저 문제가 됩니다.

예를 들어 GitHub 연결이라면 아래를 나눠 생각해야 합니다.

  • 모든 repo 접근이 필요한가
  • private repo 접근이 필요한가
  • 읽기만 필요한가, 쓰기도 필요한가
  • issue 작성과 code push가 같은 token으로 묶여 있는가
  • 조직 admin 권한이 섞여 있지 않은가

처음에는 읽기 전용으로 시작하고, 쓰기 권한은 작업 단위로 좁게 여는 편이 좋습니다.
특히 개인 access token 하나로 모든 MCP 서버를 돌리는 방식은 피해야 합니다.

4. 로컬 MCP 서버는 파일 접근 범위를 좁힙니다

로컬 MCP 서버는 편하지만 위험합니다.
에이전트가 로컬 파일, 환경 변수, shell 명령에 가까워질 수 있기 때문입니다.

확인할 항목은 이렇습니다.

  1. 프로젝트 폴더 밖 파일을 읽을 수 있는가
  2. .env, .ssh, cloud credential 폴더를 읽을 수 있는가
  3. shell 명령을 실행할 수 있는가
  4. 네트워크 요청을 보낼 수 있는가
  5. 로그에 tool 입력과 출력이 원문으로 남는가

권장 방식은 작업 폴더 단위 allowlist입니다.
에이전트가 홈 디렉터리 전체를 볼 수 있게 두지 말고, 필요한 repo 안에서만 동작하게 해야 합니다.

5. tool 출력에 secret이 섞이지 않게 합니다

MCP 서버는 결과를 에이전트에게 돌려줍니다.
이 결과에 secret이 섞이면, 대화 기록, 디버그 로그, PR 코멘트, 생성된 문서로 퍼질 수 있습니다.

특히 아래 출력은 마스킹이 필요합니다.

  • HTTP request/response header
  • Authorization header
  • cookie
  • database connection string
  • webhook secret
  • signed URL
  • cloud provider credential
  • 내부 IP와 host name

서버 쪽에서 secret을 마스킹하고, 에이전트 프롬프트에도 규칙을 넣습니다.

토큰, 쿠키, Authorization 헤더, 연결 문자열은 원문으로 출력하지 말고 앞뒤 4자만 남겨줘.

6. MCP 서버 설치 출처를 확인합니다

MCP 서버도 소프트웨어 공급망입니다.
GitHub에 올라온 서버라고 해서 곧바로 안전한 것은 아닙니다.

설치 전에 확인할 항목은 이렇습니다.

  1. 공식 벤더가 운영하는 서버인가
  2. 최근 release와 security advisory가 있는가
  3. 설치 스크립트가 무엇을 실행하는가
  4. package lockfile이 있는가
  5. 어떤 환경 변수를 요구하는가
  6. token을 어디에 저장하는가
  7. 로그 기본값이 무엇인가

처음 보는 MCP 서버는 실제 계정 대신 테스트 계정, 테스트 repo, 낮은 권한 token으로 먼저 붙이는 편이 좋습니다.

7. 커밋 전 secret scanning을 습관화합니다

GitHub Docs에 따르면 GitHub MCP Server는 Copilot agent mode, Copilot CLI, Claude Code, Cursor, Windsurf 같은 MCP 호환 도구에서 secret scanning을 실행할 수 있습니다.
이 결과는 현재 세션에 보이는 pre-commit 점검 성격이므로, GitHub Security 탭의 영구 alert를 대체하지는 않습니다.

실무에서는 에이전트에게 이렇게 요청할 수 있습니다.

현재 변경사항에서 노출된 secret, API key, token, credential이 있는지 커밋 전에 검사해줘.

그리고 사람이 확인할 것은 따로 있습니다.

  1. 실제 secret이 발견되면 파일 수정만 하지 말고 키를 폐기합니다.
  2. .env.example에는 placeholder만 둡니다.
  3. 테스트 fixture에 실제 token처럼 보이는 값이 들어가지 않게 합니다.
  4. PR 템플릿에 secret scanning 확인 항목을 넣습니다.

바로 쓰는 체크리스트

MCP 서버를 새로 붙이기 전에 아래를 확인합니다.

  1. 이 MCP 서버는 읽기 전용인가, 쓰기 권한이 있는가
  2. 어떤 계정과 token으로 동작하는가
  3. OAuth scope가 작업에 필요한 최소 범위인가
  4. 로컬 파일 접근 범위가 repo 안으로 제한되는가
  5. .env, .ssh, cloud credential 폴더 접근이 막혀 있는가
  6. tool 입력과 출력 로그에 secret이 남지 않는가
  7. 외부 문서나 issue 내용을 tool 실행 지시로 그대로 믿지 않는가
  8. 커밋 전 secret scanning을 실행하는가
  9. 키 유출 시 폐기와 재발급 절차가 정해져 있는가

한 줄 결론

MCP 서버는 AI 에이전트의 능력을 키우지만, 동시에 trust boundary를 넓힙니다.
API 키 유출을 막으려면 “키를 숨긴다”에서 끝내지 말고, 권한, 파일 범위, 로그, tool 출력, 커밋 전 스캔을 같이 관리해야 합니다.

같이 보면 좋은 글

출처