MCP 도구에는 작업 수준 권한 부여가 필요합니다

2026년 5월 17일, NVD는 WordPress 사이트에 AI와 MCP 기능을 노출하는 WordPress 플러그인 AI Engine 3.4.9에 대해 CVE-2026-8719를 공개했습니다.¹³

이 실패 방식은 모든 MCP 구축자를 불편하게 만들어야 합니다. Wordfence는 MCP OAuth bearer token 권한 부여 경로에서 WordPress 권한 확인이 누락되었다고 설명했습니다. 유효한 OAuth 토큰만 있으면 관리자 권한을 검증하지 않아도 관리자 수준의 MCP 도구에 접근할 수 있었습니다.² Wordfence는 이 문제를 8.8 High로 평가했고, 3.5.0을 패치된 릴리스로 표시했습니다.² 플러그인 변경 기록에는 3.5.0에서 관리자 권한을 요구하도록 해 MCP OAuth 권한 부여와 토큰 검증을 수정했다고 나와 있습니다.³

서버가 bearer token 보유를 모든 도구 사용 권한으로 취급할 때 MCP 권한 부여는 실패합니다. OAuth는 토큰이 권한 부여 흐름을 거쳐 도착했다는 사실을 증명할 수 있습니다. 하지만 MCP 서버는 여전히 그 주체가 해당 도구를, 해당 리소스에 대해, 그 정도의 영향 범위로 실행해도 되는지 판단해야 합니다.

요약

MCP의 HTTP 권한 부여 명세는 구축자에게 필요한 기반을 제공합니다. 보호 리소스 메타데이터, OAuth 2.1 흐름, bearer token 처리, 토큰 검증, 대상 확인, 그리고 범위나 권한이 부족할 때의 명시적인 403 Forbidden 응답이 여기에 포함됩니다.⁴ MCP 보안 튜토리얼은 권한 부여를 MCP 서버가 노출하는 민감한 리소스와 작업을 보호하는 계층으로 설명합니다.⁵ 그러나 이런 절차가 애플리케이션 수준의 권한 부여 판단을 대신하지는 않습니다. 서버는 토큰을 사용자, 역할, 테넌트, 도구, 리소스, 작업, 정책에 매핑해야 합니다.

CVE-2026-8719는 이 차이를 구체적인 실패로 보여줍니다. AI Engine은 5월 12일 버전 3.4.9에서 MCP 서버에 OAuth 2.1과 Dynamic Client Registration을 추가했습니다. 이후 5월 16일 버전 3.5.0에서 관리자 권한을 요구하도록 해 MCP OAuth 권한 부여와 토큰 검증을 패치했습니다.³ 이 교훈은 WordPress를 넘어섭니다. 데이터를 변경하거나, 콘텐츠를 게시하거나, 설정을 바꾸거나, 비공개 기록을 읽거나, 비용을 쓰거나, 특권 API를 호출할 수 있는 모든 MCP 서버에는 모델 아래와 클라이언트 아래에 작업 수준 권한 부여가 필요합니다.

도구 배포는 위험을 키웁니다. 2026년 5월에 나온 도구 복제 논문은 8,861개의 MCP 및 에이전트 기능 저장소에서 100,011개의 도구 항목을 측정했고, 유사도가 높은 구간에서 검증된 복제 비율이 높다는 사실을 발견했습니다.⁶ 재사용되는 템플릿은 좋은 패턴을 퍼뜨릴 수 있습니다. 동시에 누락된 확인도 퍼뜨릴 수 있습니다.

핵심 요점

MCP 서버 구축자에게: - 토큰을 검증한 뒤, 구체적인 작업을 권한 부여하세요. 두 단계를 별개의 관문으로 다루세요. - 유효하지 않거나 누락된 토큰에는 401을, 토큰은 유효하지만 범위나 권한이 부족한 경우에는 403을 반환하세요. - 낮은 권한의 토큰으로 모든 관리자, 쓰기, 게시, 삭제, 내보내기, 설정 도구를 테스트하세요.

보안 팀에게: - MCP 서버를 채팅 플러그인이 아니라 애플리케이션 엔드포인트처럼 검토하세요. - 각 도구 호출이 어떤 사용자, 역할, 테넌트, 리소스, 작업에 매핑되는지 물어보세요. - 로그에는 토큰 주체, 도구 이름, 리소스, 권한 부여 판정, 거부 사유가 드러나야 합니다.

에이전트 플랫폼 팀에게: - 마켓플레이스의 숫자가 독립적인 구현을 증명하지는 않습니다. - 복제된 도구는 취약한 권한 부여 로직을 그대로 베낄 수 있으므로 유사도와 출처 확인이 중요합니다. - 서버 템플릿을 보안에 민감한 기반 구조로 다루세요.

운영자에게: - 영향을 받는 WordPress 플러그인을 사용 중이라면 AI Engine을 3.5.0 이상으로 업그레이드하세요.²³ - 어떤 WordPress 역할이 어떤 도구에 접근할 수 있는지 알기 전까지 MCP 노출을 비활성화하세요. - 모든 새 MCP 연결은 읽기 전용 모드에서 시작하고, 거부 경로가 테스트로 입증된 뒤에만 권한을 넓히세요.

AI Engine에서 무엇이 깨졌나

AI Engine은 MCP를 URL, 로그인 흐름, 승인 단계를 통해 Claude Code, Claude, ChatGPT, OpenClaw 및 다른 클라이언트를 WordPress 사이트에 연결하는 방식으로 소개합니다.³ 버전 3.4.9는 브라우저 기반 클라이언트가 공유 bearer token 없이 연결할 수 있도록 MCP 서버에 Dynamic Client Registration이 포함된 OAuth 2.1을 추가했습니다.³

이 제품 방향은 타당합니다. 공유 정적 토큰은 사용자 대면 MCP 통합에 맞지 않습니다. OAuth 흐름은 복사해 붙여넣는 비밀값보다 클라이언트, 사용자, 서버를 더 깔끔하게 묶을 수 있습니다.

버그는 그보다 한 계층 아래에 있었습니다. NVD와 Wordfence에 따르면, 취약한 경로는 관리자 수준의 MCP 도구 접근을 허용하기 전에 관리자 권한을 확인하지 않았고, MCP 접근을 위해 유효한 OAuth 토큰이면 무엇이든 받아들였습니다.¹² 이 구분이 중요합니다.

WordPress 플러그인 페이지의 패치 설명은 올바른 표현을 사용합니다. MCP OAuth 권한 부여와 토큰 검증이 이제 관리자 권한을 요구하며, 비관리자 사용자의 권한 상승을 막는다는 내용입니다.³ 이 문장은 빠져 있던 계층을 정확히 지목합니다. 토큰은 권한 확인을 대신할 수 없습니다.

OAuth는 필요하지만 충분하지 않습니다

MCP의 권한 부여 명세는 HTTP 기반 전송을 위한 전송 수준 흐름을 다룹니다. 이 명세는 MCP 클라이언트가 리소스 소유자를 대신해 제한된 MCP 서버에 요청을 보낸다고 설명하며, OAuth 2.1, 보호 리소스 메타데이터, 권한 부여 서버 메타데이터, Dynamic Client Registration, bearer token 사용에 흐름의 기반을 둡니다.⁴

이 요소들은 실제 문제를 해결합니다.

MCP 명세는 confused-deputy와 token-passthrough 위험도 경고합니다. MCP 서버는 제시된 토큰이 MCP 서버를 대상으로 하는지 검증해야 하며, MCP 클라이언트에서 받은 토큰을 upstream API로 그대로 넘기면 안 됩니다.⁴ 이 지침은 서비스 사이의 경계를 보호합니다.

작업 수준 권한 부여는 MCP 서버 내부의 경계를 보호합니다.

MCP 서버는 10개의 도구를 노출할 수도 있고 100개의 도구를 노출할 수도 있습니다. 어떤 도구는 공개 메타데이터를 읽습니다. 어떤 도구는 비공개 기록을 읽습니다. 어떤 도구는 변경 초안을 만듭니다. 어떤 도구는 프로덕션 상태를 변경합니다. 어떤 도구는 사용자, 플러그인, 결제, 작업, 메시지, 기반 구조를 관리합니다. 서버가 세션을 받아들였다고 해서 유효한 토큰이 모든 도구에 자동으로 접근해서는 안 됩니다.

올바른 흐름은 다음과 같습니다.

1. 토큰 발급자, 서명, 만료, 대상, 전송 규칙을 검증합니다.
2. 토큰을 로컬 주체로 해석합니다. 사용자, 서비스 계정, 조직, 테넌트, 자동화가 될 수 있습니다.
3. 그 주체의 역할, 범위, 부여된 권한, 예산, 정책을 불러옵니다.
4. 요청된 MCP 도구를 작업 유형과 위험도에 따라 분류합니다.
5. 도구 이름만이 아니라 대상 리소스를 확인합니다.
6. 토큰은 유효하지만 작업이 권한을 초과하면 403을 반환합니다.
7. 나중에 검토할 수 있을 만큼 자세히 결정을 기록합니다.

OAuth는 요청을 판단 지점까지 데려옵니다. 권한 부여는 그 작업이 허용되는지 결정합니다.

도구 호출에는 권한 매트릭스가 필요합니다

에이전트 도구는 오래된 엔드포인트 습관을 더 위험하게 만듭니다. 일반적인 웹 경로는 대체로 그 주변에 좁은 UI 경로가 있습니다. 모델이 바라보는 도구는 계획기 안에 들어 있습니다. 에이전트는 재시도하고, 호출을 연결하고, 도구 설명을 살피고, 읽기 결과를 쓰기 작업과 결합하고, 신뢰할 수 없는 콘텐츠의 지시를 이후 단계로 가져갈 수 있습니다.

이 동작은 최소 권한 모델을 바꿉니다. 서버는 “이 사용자가 MCP에 접근할 수 있는가?”만 물어서는 안 됩니다. “이 사용자가 지금 이 도구를 통해 이 리소스에 대해 이 작업을 수행할 수 있는가?”를 물어야 합니다.

매트릭스를 사용하세요.

이 매트릭스는 에이전트 키에는 위험 예산이 필요합니다의 패턴과 맞닿아 있습니다. 자격 증명은 모든 용도에 쓰이는 bearer 문자열처럼 행동해서는 안 됩니다. 서버 측 제한, 활동 로그, 폐기, 보수적인 기본값을 갖춘 제한된 권한 객체처럼 행동해야 합니다.

또한 AI 에이전트 소유권은 신뢰의 기본 단위입니다의 소유권 관점과도 맞습니다. 특권이 있는 모든 도구 호출은 책임 있는 계정, 세션, 권한 묶음, 검토 경로, 중단 경로에 매핑되어야 합니다.

복제된 도구는 같은 누락 확인을 복사할 수 있습니다

AI Engine 버그는 모든 MCP 서버가 신중한 독립 구현에서 나왔더라도 중요했을 것입니다. 하지만 도구 생태계는 그렇게 깔끔해 보이지 않습니다.

Kim, Jiang, Hu, Jia, Gong은 2026년 5월 10일 agentic-AI 생태계의 도구 복제를 측정한 논문을 발표했습니다. 이 데이터셋은 87,564개의 추출 도구가 있는 7,508개의 MCP 저장소와 12,447개의 도구가 있는 1,353개의 에이전트 기능 저장소를 포함했습니다. 합치면 8,861개의 저장소와 100,011개의 도구 항목입니다.⁶ 저자들은 token-level Jaccard similarity와 ssdeep fuzzy structural similarity를 사용했고, 이후 유사도 구간별로 표본 쌍을 수동 검증했습니다.⁶

초록에 따르면, MCP 생태계에서 high-Jaccard 후보의 60%와 high-ssdeep 후보의 85%가 수동 검증 결과 복제본으로 확인되었습니다.⁶ 이 논문은 숨은 중복이 benchmark split을 오염시키고, 취약한 구현을 전파하고, 도구 사용 일반화 측정을 왜곡하며, 출처, 저작자 표시, 라이선스 문제를 일으킬 수 있다고 주장합니다.⁶

이 발견은 팀들이 MCP 마켓플레이스 성장을 읽는 방식을 바꿉니다. 도구가 많다고 해서 독립적인 보안 검토가 더 많다는 뜻은 아닙니다. 반복되는 서버 골격은 생태계에 일관성을 줄 수 있습니다. 같은 반복은 같은 약한 인증 패턴을 여러 패키지에 복사할 수도 있습니다.

따라서 보안 검토에는 출처가 포함되어야 합니다.

에이전트 기능에는 패키지 관리자가 필요합니다는 에이전트 기능에 패키지식 배포, 출처, 정책이 필요하다고 주장했습니다. MCP 서버에도 같은 규율이 필요하며, 여기에 실행 시점의 권한 부여 테스트가 더해져야 합니다.

MCP 권한 부여를 위한 최소 테스트 묶음

비공개 데이터나 변경 가능한 데이터를 다루는 모든 MCP 서버는 권한 부여 테스트 묶음을 함께 제공해야 합니다. 정상 경로를 확인하는 단위 테스트만으로는 충분하지 않습니다. 위험한 동작은 거부 경로에 있습니다.

다음 사례부터 시작하세요.

정확한 상태 코드는 제품 정책을 따를 수 있지만, 구분은 유지되어야 합니다. 유효하지 않은 자격 증명은 주체 해석 전에 실패해야 하고, 유효한 자격 증명이지만 권한이 부족한 경우에는 권한 부여 관문에서 실패해야 합니다. MCP 명세는 누락되었거나 유효하지 않은 권한 부여에는 401을, 유효하지 않은 범위나 권한 부족에는 403을 명시합니다.⁴

WordPress에서는 같은 규칙이 더 선명해집니다. 관리자 작업을 수행하는 MCP 도구는 대시보드, REST API, 내부 PHP 경로가 확인하는 것과 같은 WordPress 권한을 확인해야 합니다. 모델 대상 프로토콜을 통해 호출이 들어왔다는 이유만으로 낮은 권한의 역할이 관리자 동작으로 가는 새 경로를 얻어서는 안 됩니다.

마켓플레이스 검토가 요구해야 하는 것

MCP 마켓플레이스와 플러그인 디렉터리는 권한 부여 메타데이터를 패키지 데이터의 핵심 정보로 다뤄야 합니다. 서버를 활성화할지 결정하는 사용자에게는 도구 개수 이상의 정보가 필요합니다.

최소 공개 메타데이터는 다음과 같습니다.

이 필드들이 취약한 도구를 없애지는 못합니다. 하지만 검토 표면을 실제로 드러냅니다. 운영자는 선언된 권한을 실제 코드와 비교할 수 있고, 마켓플레이스는 결함이 나타났을 때 유사한 구현을 묶을 수 있습니다.

이것이 MCP 권한 부여 명세와 도구 복제 논문 사이에 빠진 다리입니다. 명세는 구현자에게 프로토콜 수준 흐름을 수행하는 방법을 알려줍니다. 생태계에는 패키지 수준의 출처와 작업 수준 권한 부여 증거가 필요합니다. 그래야 반복되는 구현이 같은 누락 확인을 반복하지 않습니다.

대신 무엇을 만들어야 하나

MCP 권한 부여를 파이프라인으로 만드세요.

1. 프로토콜 관문: 보호 리소스 메타데이터, OAuth 흐름, 토큰 위치, 토큰 유효성, 만료, 발급자, 대상을 검증합니다.
2. 주체 관문: 토큰을 사용자, 서비스 계정, 역할, 테넌트, 작업 공간에 매핑합니다.
3. 도구 관문: 모든 도구를 읽기, 초안 작성, 쓰기, 삭제, 게시, 내보내기, 관리, 실행, 지출로 분류합니다.
4. 리소스 관문: 정확한 대상 객체나 테넌트 경계를 권한 부여합니다.
5. 예산 관문: 실행 전에 호출률, 크기, 지출, 대상, 시간 제한을 적용합니다.
6. 승인 관문: 고위험 작업에는 사람 또는 정책 승인을 요구합니다.
7. 감사 관문: 허용, 거부, 검토 필요 판정을 운영자가 확인할 수 있는 위치에 기록합니다.

이 관문들은 모델 밖에 있어야 합니다. 도구 설명은 에이전트에게 관리자 작업을 피하라고 말할 수 있습니다. 프롬프트는 조심하라고 요청할 수 있습니다. 하지만 어느 쪽도 경계를 책임져서는 안 됩니다. 에이전트가 정중하게, 자신 있게, 반복해서 요청하더라도 서버는 권한이 없는 작업을 거부해야 합니다.

당신의 에이전트 샌드박스는 제안일 뿐입니다는 같은 지점을 다른 각도에서 말합니다. 유효한 권한도 조합되면 안전하지 않은 동작이 될 수 있습니다. 에이전트는 사람이 머릿속으로 시뮬레이션할 수 있는 속도보다 더 빠르게 작업을 조합하기 때문에, MCP 도구에는 작업 경계에서의 권한 부여가 필요합니다.

FAQ

MCP에는 OAuth가 필수인가요?

아닙니다. MCP 권한 부여는 선택 사항이며, HTTP 권한 부여 명세는 구현이 HTTP 기반 전송에서 권한 부여를 지원할 때 적용됩니다. 같은 명세는 STDIO 전송이 HTTP OAuth 흐름을 따르기보다 환경에서 자격 증명을 가져와야 한다고 말합니다.⁴

OAuth가 MCP 권한 부여 문제를 해결하나요?

OAuth는 문제의 일부만 해결합니다. OAuth는 권한 부여 흐름을 수립하고, 토큰을 발급하고, 보호된 MCP 서버가 bearer token을 검증하게 할 수 있습니다. 하지만 MCP 서버는 여전히 토큰 주체가 대상 리소스에 대해 특정 도구 작업을 수행해도 되는지 판단해야 합니다.

CVE-2026-8719는 무엇을 입증했나요?

CVE-2026-8719는 유효한 토큰 경로에도 로컬 권한 강제가 빠질 수 있음을 입증했습니다. NVD와 Wordfence는 AI Engine 3.4.9가 관리자 수준 MCP 도구에 접근할 수 있게 하기 전에 관리자 권한을 검증하지 않았고, MCP 접근을 위해 유효한 OAuth 토큰이면 무엇이든 받아들였다고 설명합니다.¹²

MCP 구축자는 무엇을 먼저 테스트해야 하나요?

거부 경로를 먼저 테스트하세요. 낮은 권한 토큰으로 관리자 도구 호출, 읽기 전용 토큰으로 쓰기 도구 호출, 유효한 토큰으로 다른 테넌트의 리소스 접근, 만료된 토큰, 대상이 틀린 토큰, 승인 없는 파괴적 도구 호출이 우선입니다. 정상 경로의 OAuth가 통과했다고 해서 작업 수준 권한 부여가 입증되지는 않습니다.

도구 복제가 MCP 보안에서 왜 중요한가요?

도구 복제가 중요한 이유는 반복되는 구현이 같은 취약한 middleware, 인증 지름길, 누락 확인을 반복할 수 있기 때문입니다. 2026년 5월 도구 복제 논문은 유사도가 높은 MCP 후보에서 검증된 복제 비율이 높다는 점을 발견했고, 숨은 중복이 취약한 구현을 전파할 수 있다고 경고했습니다.⁶

참고 문헌