LiteLLM의 감사 결과 3가지 MCP 게이트웨이 취약점이 드러났습니다: fail-open resolver, unpinned servers, opt-in least-privilege. Claude Code에서 버전 고정(version pinning)과 allowed_tools를 사용하여 이를 해결하십시오.

핵심 요약 (Key Takeaways)

• LiteLLM의 감사 결과 3가지 MCP 게이트웨이 취약점이 드러났습니다: fail-open resolver, unpinned servers, opt-in least-privilege.
• Claude Code에서 버전 고정(version pinning)과 allowed_tools를 사용하여 이를 해결하십시오.

'작동하는가?'가 놓치는 것을 찾아낸 감사

LLM 게이트웨이를 MCP 도구에 연결하는 대부분의 팀은 한 가지 질문을 던집니다: '작동하는가?' 널리 배포된 오픈 소스 LLM 프록시인 LiteLLM에 대한 운영 준비성(production-readiness) 감사는 그 질문만으로는 충분하지 않다는 것을 보여주었습니다. 진짜 테스트는 이것입니다: 권한 부여(authorization) 확인 중에 예상치 못한 예외(exception)가 발생했을 때, 게이트웨이가 호출을 거부합니까, 아니면 허용합니까?

이 단 한 줄의 동작 방식이 성숙한 플랫폼과 조용한 화요일에 터질 사고를 가르는 기준이 됩니다.

Willian Pinho가 수행한 이번 감사는 도구 액세스 거버넌스(tool-access governance), fail-close 동작, MCP 온보딩(onboarding), 관측 가능성(observability), 멀티-LLM 라우팅(multi-LLM routing), 비밀 정보(secrets), 그리고 운영 준비성(production-readiness)의 7가지 차원에서 LiteLLM을 평가했습니다. 결과는 녹색 4개, 황색 3개, 적색 0개였습니다. "주의 사항이 있는 운영 준비 완료 상태"라는 평가였습니다.

다음은 세 가지 황색 경고(yellow flags)이며, 여러분의 Claude Code 설정에서 이를 정확히 해결하는 방법입니다.

황색 경고 #1: Fail-Open 권한 부여 리졸버 (The Fail-Open Authorization Resolver)

LiteLLM의 모든 레벨별 권한 리졸버(permission resolver)는 fail-closed 방식으로 동작합니다. 즉, 예상치 못한 예외가 발생하면 로그를 남기고 빈 세트(empty set)를 반환하며, 이는 하위 단계에서 "액세스 권한 없음"으로 해결됩니다. 이는 올바른 태세입니다.

예외적인 부분은 최상위 래퍼(wrapper)인 get_allowed_mcp_servers()입니다. 이 함수는 예상치 못한 오류가 발생했을 때 빈 리스트 대신 모든 서버를 허용하는 서버 세트를 반환합니다. 피해 범위(blast radius)는 운영자가 이미 공개로 표시한 서버로 제한되지만, 권한 부여 리졸버에서의 fail-open은 프레임워크 내에서 가장 위험도가 높은 클래스입니다.

해결 방법: 해당 함수를 패치하여 예외 발생 시 빈 세트를 반환하도록 수정하십시오. 한 줄의 코드 변경과 회귀 테스트(regression test)만 있으면 됩니다.

황색 경고 #2: 고정되지 않은 제3자 MCP 서버 (Unpinned Third-Party MCP Servers)

LiteLLM의 큐레이션된 카탈로그는 npx -y @sentry/mcp-server와 같이 버전, 다이제스트(digest) 또는 체크섬(checksum) 고정 없이 유동적인 명령어를 사용하는 stdio 서버를 실행합니다. 이는 패키지 변조로 인한 공급망 사고(supply-chain incident)—즉, OWASP의 LLM03—로 이어질 수 있는 위험한 상태입니다.

Claude Code에서의 해결 방법: claude_code_mcp_config.json에 MCP 서버를 추가할 때, 항상 버전과 다이제스트(digest)를 고정(pin)하십시오. 예를 들어:

{
  "mcpServers": {
    "sentry": {
...

@latest 대신 @1.2.3을 사용하십시오. 더 나아가, 가능하다면 체크섬(checksum)이나 다이제스트(digest)를 사용하십시오. 버전이 지정된 릴리스를 제공하지 않는 서버는 모두 거부하십시오.

황색 경고 #3: 도구별 최소 권한 원칙(Per-Tool Least-Privilege)의 선택적 적용

게이트웨이에서의 권한 부여(Authorization)는 강력합니다. 호출자의 신원을 키(key), 팀(team), 최종 사용자(end-user), 에이전트(agent) 및 조직(org) 권한의 엄격한 교집합으로 강제하며, 모델은 권한 결정 과정에서 완전히 배제됩니다. 이는 프롬프트 인젝션을 통한 도구 호출(prompt-injection-to-tool-call)을 무력화합니다.

하지만 서버별 allowed_tools 허용 목록(allowlist)이 없다면, 서버에 접근 권한이 있는 호출자는 쓰기(write) 또는 외부 도구를 포함하여 해당 서버의 모든 도구를 호출할 수 있습니다. 이는 OWASP가 LLM06으로 추적하는 과도한 대리권 노출(excessive-agency exposure)에 해당합니다.

Claude Code에서의 해결 방법: 설정 파일의 각 MCP 서버 정의에 allowed_tools 필드를 추가하십시오. 예를 들어:

{
  "mcpServers": {
    "database": {
...

이를 통해 침해된 에이전트가 drop_table 또는 delete_all을 호출하는 것을 방지할 수 있습니다. 온보딩(onboarding) 시 이 허용 목록을 필수 사항으로 지정하고 CI에서 검증하도록 만드십시오.

LiteLLM이 잘한 점 (유지해야 할 사항을 알기 위해)

• ID 및 비밀 정보 (Identity and secrets): 양호 (Green). 인라인 비밀 정보(inline secrets) 없음. 실제 게이트웨이 호출 경로(call path)에서 JWT/OIDC가 강제됨. 최종 사용자 ID가 MCP 처리 및 비용 로그(spend logs)까지 전달됨. MCP 토큰의 경우, 게이트웨이는 대상(audience) 및 범위(scope) 바인딩을 포함하는 RFC 8693 OAuth 토큰 교환(token-exchange)을 지원함.
• 관측 가능성 (Observability): 양호 (Green). 전용 GenAI 시맨틱 컨벤션(semantic-convention) 매핑을 포함한 OpenTelemetry 사용. 표준 프로파게이터(propagator)를 통해 인바운드 W3C traceparent 헤더를 추출함.
• 라우팅 및 비용 (Routing and cost): 양호 (Green). 예산 제한(Budget caps)이 실제로 강제됨—예산 초과 시 단순히 경고를 보내고 지출을 계속하게 두는 대신 BudgetExceededError를 발생시킴.

Claude Code 사용자를 위한 교훈

구조화된 감사(audit)는 결정적인 증거(smoking gun)를 찾는 과정이 아닙니다. 성숙한 대상 시스템에서는 보통 그런 것이 존재하지 않습니다. 7가지 차원의 검사를 통해 드러난 것은 수준 높은 코드베이스 속에 숨어 있는 프로덕션 준비성(production-readiness)의 경계선들이었습니다. 즉, 노출 쪽으로 치우친 하나의 리졸버(resolver), 고정(pinning) 대신 떠다니는(floats) 공급망(supply chain), 그리고 누군가 선택하기를 기다리는 최소 권한 제어(least-privilege control)와 같은 것들입니다.

• LiteLLM audit article
• LiteLLM repo (pinned commit)
• OWASP Top 10 for LLM Applications (2025)
• RFC 8693 — OAuth 2.0 Token Exchange
• MCP specification (2025-06-18)

[ ext{devto} ext{mcp} ext{을 통해 7월 1일 업데이트됨}]

Sahajmeet Kaur가 작성한 별도의 프로덕션 게시물에서는 LiteLLM의 감사 결과와 유사한 세 가지 실제 MCP 거버넌스 실패 사례를 설명합니다. 지원 에이전트가 쓰기 활성화된(write-enabled) MCP 서버를 통해 47개의 중복 Jira 티켓을 생성했고, 계약직 직원의 Jira MCP 토큰이 퇴사 후에도 3주 동안 활성 상태로 남아 있었는데 이는 MCP 자격 증명이 표준 체크리스트에 포함되지 않았기 때문이었으며, 연구 에이전트가 웹 검색 도구(web-fetch tool)로부터 주입된 명령어(injected instructions)를 실행했다는 내용입니다 [Sahajmeet Kaur 작성]. 이 게시물은 MCP 프로토콜 자체에 의존하기보다는 중앙 게이트웨이를 통해 구현해야 하는 네 가지 제어 장벽—도구 수준의 RBAC, 단일 토큰 퇴사(single-token offboarding)가 적용된 중앙 집중식 자격 증명 관리, 호출별 감사 추적(per-invocation audit trails), 그리고 콘텐츠 가드레일(content guardrails)—을 옹호합니다.

원래 gentic.news에 게시됨