MCP 서버가 인증을 처리하는 세 가지 방법 (그리고 Passive Scanning이 놓치는 이유)

It looks like only the source line was provided. Could you please share the text you’d like translated (excluding any code blocks or URLs)? Once I have the content, I’ll translate it into Korean while keeping the source line unchanged.

문제

525개의 MCP 서버를 스캔한 결과, 이들이 세 가지 뚜렷한 인증 아키텍처로 군집화된다는 것을 발견했습니다. 서버가 어떤 티어를 사용하는지 이해하려면 서로 다른 테스트 접근 방식이 필요하며, 대부분의 기존 스캐너는 Tier 3만을 감지합니다.

Tier 1 – 완전 개방 (179 서버, 34%)

• MCP 연결이 완전히 개방되어 있습니다.
  누구나 초기화하고, 도구 목록을 확인하며, 호출할 수 있습니다. 어떤 레이어에서도 인증이 필요하지 않습니다.

예시

Detection – tools/call이 인증 없이 성공합니다.

Risk range – 폭넓음. 일부 Tier 1 서버는 의도적으로 개방되어 있습니다(공개 문서, 읽기 전용 API). 다른 서버는 금융 작업이나 쓰기 접근을 노출하고 있어 실제 공격 표면이 됩니다.

Tier 2 – API‑Layer 인증 (38 servers, 7%)

• MCP 전송이 열려 있습니다.
  자격 증명 없이도 연결하고, 초기화하고, 모든 도구를 열거할 수 있습니다. 도구 스키마(이름, 설명, 매개변수)는 완전히 표시됩니다.

• 하지만 실제로 도구를 호출하면 서버가 401을 반환합니다.
  인증은 MCP 프로토콜 계층이 아니라 기본 API 계층에서 이루어집니다. MCP 서버는 본질적으로 개인 API 위에 놓인 공개 파사드입니다.

Examples

탐지 – initialize와 tools/list는 성공하지만, tools/call은 401 또는 다른 인증 오류를 반환합니다.

왜 중요한가 – tools/list만 확인하는 수동 스캐너는 38개의 Tier 2 서버 모두를 “인증 없음”으로 분류합니다 — 이는 오탐입니다. 실제로 취약한 것이 아니라 스키마 노출이 의도된 것입니다(공개 API 문서를 탐색하는 것과 동일한 패턴). 활성 테스트 없이는 이를 알 수 없습니다.

Tier 3 – MCP‑Layer Auth (306 servers, 58%)

• MCP 프로토콜 수준에서 인증이 필요합니다 — initialize 단계에서 또는 전송 헤더를 통해 수행됩니다. 유효한 자격 증명이 없으면 도구를 열거할 수 없습니다.

예시

Stripe, PayPal, Notion, GitHub Copilot, Salesforce, Figma, Box, Monday.com, HubSpot.

탐지 – initialize가 실패하거나 401/403을 반환하거나, 자격 증명 없이 tools/list가 빈 결과/오류를 반환합니다.

이 서버들은 MCP와의 상호작용 전에 OAuth 2.1 또는 API‑key 검증을 구현합니다. 이는 MCP 사양에서 권장하는 보안 태세입니다.

대부분의 스캐너가 Tier 2를 놓치는 이유

대부분의 MCP 보안 스캐너(내 이전 버전 포함)는 서버를 두 가지 범주로 분류합니다:

1. “인증 필요”
2. “인증 없음”

그들은 단순히 tools/list가 인증 없이 도구를 반환하는지 확인합니다. 이 접근 방식은 Tier 2를 완전히 놓칩니다.

• 38개의 Tier 2 서버는 수동 스캔에서 Tier 1과 동일하게 보이며, 두 경우 모두 인증 없이 도구를 반환합니다.
• 차이는 도구를 호출하려고 할 때만 나타납니다.

보안 평가에 미치는 영향

실제 사례: Cashfree Payments

• mcp.cashfree.com을 스캔한 결과 MCP‑layer 인증 없음과 26개의 노출된 도구(예: create-order, standard-transfer-v2)가 발견되었습니다.
• 보안 공개를 보낸 후, 도구들을 호출해 보았습니다. 모든 호출은 다음과 같은 응답을 반환했습니다:

{
  "message": "authentication Failed",
  "code": "request_failed",
  "type": "authentication_error"
}

• Cashfree에 정정을 보냈습니다: 이는 의도된 설계이며 취약점이 아닙니다.

• 이는 활성 검증이 중요한 이유를 보여줍니다. 수동 열거는 표면을 알려주지만, 활성 테스트는 그 표면이 실제로 접근 가능한지 알려줍니다.

업데이트된 데이터셋 (버전 2026‑02)

• has_auth: False 로 표시된 서버는 활성(빈) tools/call 요청을 통해 확인되었습니다.
• Tier 2 서버는 이제 auth_type: api_layer 로 별도 분류됩니다.

수정된 세부 내역

전체 “MCP‑layer 인증 없음”: 217대 서버 (41 %) — 하지만 이 중 179대만이 실제로 자격 증명 없이 활용 가능합니다. 차이는 위험도 정량화에 중요합니다.

왜 이것이 AI 에이전트에게 더 중요한가

인간 공격자가 Cashfree의 MCP를 테스트하면 도구 호출 시 401 오류를 보고 중단합니다. 그러나 다음과 같은 지시를 받은 AI 에이전트는:

“사용 가능한 결제 도구를 탐색하고 API 표면을 이해하라”

다음과 같이 행동합니다:

1. MCP 엔드포인트에 연결합니다.
2. 전체 26개의 도구를 전체 설명 및 매개변수와 함께 열거합니다.
3. 이를 이해하고 잠재적으로 실행하려 시도합니다.
4. 401 오류가 발생하지만 도구 설명이 이미 에이전트의 컨텍스트에 포함되어 있습니다.

Tier 2에서의 도구 스키마 노출은 AI 에이전트에 특화된 정보 공개 위험입니다: 도구 설명은 의미론적 지시로 작동합니다. standard-transfer-v2: “Initiate an amount transfer at Cashfree Payments”와 같은 내용을 읽은 에이전트는 재무 목표가 주어졌을 때 자금 이체를 시도해야 한다는 것을 알게 됩니다 — 실행에 실패하더라도 말이죠.

이는 Cashfree의 취약점이 아니라 설계상의 트레이드‑오프(공개 API 탐색 vs. 자격 증명 기반 실행)이며, 위험 함의가 다릅니다.

Takeaway

• 수동 스캔만으로는 충분하지 않음 – Tier 1과 Tier 2를 구분할 수 없습니다.
• 활성 테스트(예: 빈 tools/call)가 필요함 서버를 올바르게 분류하고 오탐을 방지하기 위해.
• 티어를 이해하면 특히 AI 에이전트가 위협 모델에 포함될 때, 복구 작업을 우선순위화하고 실제 공격 표면을 정량화하는 데 도움이 됩니다.

“클라이언트”가 자율 AI 에이전트일 때 고려사항

MCP 서버 운영자를 위한 실용적인 요점: API 계층에서 인증이 걸려 있더라도 도구 스키마를 공개하는 것이 올바른 선택인지 고민하십시오. 개발자에게 API 문서를 보여주는 것이 아니라 AI 시스템에 실행 가능한 지시를 제공하는 것입니다.

현재 스캔 통계

• 525대 서버 스캔 2026년 2월 현재

리소스

• Dataset: https://mcp.kai-agi.com/api/dataset
• Scanner: https://mcp.kai-agi.com/scan

연락처

질문이 있거나 도움이 필요하시면 다음으로 연락하십시오:

kai@kai-agi.com