MCP Authentication은 단순히 “누가 들어왔는가"를 확인하는 단계가 아닙니다. 실무에서는 서버 신원, 사용자 신원, 에이전트 신원, 그리고 도구 권한을 분리해서 다뤄야 합니다. 이 경계를 분리하지 않으면, 하나의 토큰이나 하나의 세션이 너무 많은 권한을 갖게 됩니다.
개요 #
MCP는 도구 호출을 표준화하지만, 인증과 권한 모델은 배포 방식에 따라 달라집니다. 로컬 MCP 서버는 비교적 단순하지만, Remote MCP나 기업용 에이전트 환경에서는 인증 실패가 곧 데이터 노출로 이어질 수 있습니다.
이 글은 MCP Authentication, MCP Security, Tool Permission Model을 같이 보는 관점에서 정리합니다. 특히 OpenAI Remote MCP와 Cloudflare Remote MCP Security를 함께 보면 구조가 더 잘 보입니다.
왜 중요한가 #
MCP에서 인증을 대충 설계하면 다음 문제가 생깁니다.
- 서버 간 신뢰 경계가 무너집니다.
- 에이전트가 너무 많은 도구를 보게 됩니다.
- 사용자별 감사 로그를 복원하기 어려워집니다.
- 세션이 재사용되면서 권한이 과도하게 유지됩니다.
즉, Authentication은 단일 로그인 기능이 아니라 누가, 어떤 범위에서, 어떤 도구를, 얼마나 오래 사용할 수 있는지를 정의하는 정책 계층입니다.
인증/권한 설계 #
MCP Authentication은 보통 아래 4개를 분리해서 설계하는 편이 안정적입니다.
- 서버 인증: 이 MCP 서버가 진짜 운영 주체가 맞는지 확인합니다.
- 사용자 인증: 누가 이 요청을 보냈는지 확인합니다.
- 세션 식별: 현재 대화와 작업 컨텍스트를 식별합니다.
- 도구 권한: 어떤 tool만 호출할 수 있는지 제한합니다.
실무에서는 allowed_tools와 require_approval 같은 제어가 인증과 함께 묶여야 합니다. Tool Permission Model과 AI Access Control를 같이 적용하면 경계를 더 명확하게 만들 수 있습니다.
아키텍처 도식 #
아래 3개 도식은 인증 흐름, 선택 기준, 구조 분리를 한 번에 보게 해줍니다.
실무적으로는 다음 구조가 가장 다루기 쉽습니다.
- 인증 게이트웨이에서 사용자와 토큰을 먼저 검증합니다.
- MCP 서버는 토큰의 범위만 해석하고, 정책은 별도 레이어에서 적용합니다.
- 에이전트는 허용된 tool만 보며, 위험한 tool은 승인 단계를 거칩니다.
- 감사 로그는 사용자 ID, tenant ID, tool name, outcome을 함께 남깁니다.
체크리스트 #
- 서버별로 인증 방식이 문서화되어 있는가
- 사용자 인증과 에이전트 권한이 분리되어 있는가
- 세션 토큰의 TTL이 짧게 관리되는가
- tool allowlist가 명시되어 있는가
- 감사 로그에 사용자와 세션 정보가 남는가
- 실패 시 권한이 자동으로 축소되는가
- 재사용 가능한 토큰이 과도한 범위를 갖지 않는가
결론 #
MCP Authentication은 “로그인 기능"이 아니라 “신뢰 경계 설계"입니다. 서버 인증, 사용자 인증, 세션 관리, tool 권한을 분리하면 Remote MCP와 에이전트 자동화를 훨씬 안전하게 운영할 수 있습니다.
처음에는 단순한 allowlist로 시작하고, 이후에는 승인 정책과 감사 로그를 붙이는 방식이 가장 현실적입니다.