Cloudflare: MCP 탐지가 섀도 에이전트 트래픽을 보안 판단으로 전환하는 방식

Cloudflare는 MCP 트래픽 탐지를 명백한 서버 이름 너머로 확장해, 보안 팀이 이전에는 놓칠 수 있었던 문제를 드러냈다. 이제 Cloudflare의 작동 방식에 대한 질문은 알려진 도메인 목록이 아니라 프로토콜 증거에서 출발한다. Gateway는 관리되는 HTTP 트래픽에서 MCP 고유 경로와 JSON-RPC 메서드를 검사한 뒤, 승인된 Portal 트래픽과 직접 연결을 구분할 수 있다.

이 구분이 중요한 이유는 Model Context Protocol, 즉 MCP가 AI 에이전트가 외부 도구를 호출하고 비공개 데이터를 가져오도록 해주기 때문이다. 단일 연결로 소스 코드, 고객 기록, 클라우드 제어 환경 또는 메시징 시스템에 접근할 수 있다. 직원이 검토 없이 원격 서버를 구성하면, 그 결과 발생하는 섀도 MCP 활동은 작업을 수행할 수 있는 에이전트를 동반한 섀도 IT와 닮아 있다.

Cloudflare의 해법은 탐지와 집행 경로를 결합한다. Gateway가 네트워크 신호를 제공하고, MCP 서버 Portal은 승인된 서버를 하나의 엔드포인트 뒤에 중앙화한다. Access 정책은 ID 및 디바이스 조건을 관리하며, 데이터 유출 방지, 즉 DLP는 도구 요청과 응답을 검사할 수 있다. 해결되지 않은 문제는 조직이 이 모델을 신뢰할 수 있을 만큼 충분한 트래픽을 이러한 제어 수단으로 라우팅할 수 있는지다.

Cloudflare의 MCP 탐지가 프로토콜을 읽는 방식

Cloudflare의 중요한 변화는 목적지를 추정하는 방식에서 벗어나, 검사된 HTTP 트래픽 내부의 MCP 동작을 인식하는 방식으로 전환한 데 있다.

가장 단순한 탐지 방식은 대상 호스트명을 살펴보는 것이다. 관리자는 알려진 MCP 엔드포인트나 mcp를 포함하는 호스트명을 대상으로 Gateway 로그를 검색할 수 있다. 이 접근법은 mcp.example.com처럼 이름으로 용도를 드러내는 서비스를 포착한다.

두 번째 신호는 요청 URI에서 나온다. 원격 서버는 흔히 /mcp, /sse, /mcp/sse 같은 경로를 노출한다. 호스트명 자체가 일반적으로 보이더라도 Gateway는 기록된 요청에서 이러한 패턴을 검색할 수 있다.

두 방법 모두 초기 인벤토리 작성에는 유용하지만, 요청이 MCP를 포함한다는 사실을 증명하지는 못한다. 일반 애플리케이션도 같은 경로를 사용할 수 있다. MCP 서버 역시 평범한 호스트명과 눈에 띄지 않는 API 경로 뒤에 숨을 수 있다.

따라서 Cloudflare는 관리자에게 본문 검사를 권한다. MCP는 jsonrpc, method, params 같은 필드를 포함하는 구조화된 요청 형식인 JSON-RPC로 메시지를 인코딩한다. 표준 메서드 이름은 식별 가능한 프로토콜 수준의 증거를 만든다.

예로 initialize, tools/list, tools/call, resources/read, prompts/get이 있다. 도메인과 경로가 아무것도 드러내지 않더라도 DLP 프로필은 POST 본문에서 이러한 문자열을 검색할 수 있다. Cloudflare는 일반적인 여러 메서드와 프로토콜 버전 필드를 포괄하는 정규식 예시를 MCP architecture에 공개했다.

initialize 메서드는 MCP 클라이언트와 서버 간 관계를 시작하기 때문에 특히 유용하다. 클라이언트는 프로토콜 버전, 기능, 이름 및 버전을 선언한다. 서버는 자체 기능으로 응답하며 세션을 생성할 수 있다.

도구 호출은 더 강력한 운영 신호를 만든다. tools/call을 포함하는 요청은 에이전트가 단순히 엔드포인트 존재 여부를 확인하는 것이 아니라 기능을 호출하려 한다는 뜻이다. 인수는 해당 도구가 처리할 데이터 또는 작업도 드러낼 수 있다.

따라서 Cloudflare의 작동 모델은 계층적이다.

• 호스트명 패턴은 알려졌거나 명확히 이름이 붙은 MCP 서버를 식별한다.

• URI 패턴은 일반적인 원격 MCP 엔드포인트를 식별한다.

• JSON-RPC 메서드는 덜 명백한 엔드포인트의 MCP 동작을 식별한다.

• 사용자 및 디바이스 필드는 해당 동작을 사람 또는 관리되는 시스템과 연결한다.

• Gateway 작업은 요청이 허용, 차단 또는 다른 방식으로 처리되었는지를 보여준다.

Cloudflare가 문서화한 워크플로는 GraphQL Analytics API의 gatewayHttpRequestsAdaptiveGroups 데이터세트를 사용한다. 관리자는 호스트, URI, 사용자, 작업 및 일치한 DLP 프로필별로 결과를 그룹화할 수 있다. 회사의 detection tutorial에 따르면 이 데이터세트는 최대 30일간의 과거 쿼리를 지원한다.

이는 가장 광범위한 의미의 콘텐츠 인식형 위협 탐지는 아니다. tools/call 일치는 MCP 도구가 호출되었음을 뜻한다. 해당 도구가 신뢰할 수 있는지, 지침이 악의적인지, 또는 작업이 사용자의 의도에 부합하는지는 판단하지 않는다.

그럼에도 프로토콜 인식은 중요한 가시성 공백을 메운다. 보안 팀은 조사를 시작하기 전에 모든 MCP 공급업체나 엔드포인트를 알 필요가 없다. 프로토콜 자체의 특성을 검색할 수 있기 때문이다.

이것이 이 글의 핵심 긴장을 만든다. 탐지는 직접 MCP 트래픽을 드러낼 수 있지만, 신호만으로 어떤 연결을 계속 허용해야 하는지는 정해지지 않는다. 관리자가 합법적인 업무를 중단하지 않고 관리되지 않는 경로를 차단하려면, Cloudflare는 관리되는 대안을 제공해야 한다.

섀도 MCP는 보안 팀을 접근성과 도입 사이에 놓는다

즉각적인 부담은 유용한 에이전트 연결과 민감한 시스템에 대한 검토되지 않은 접근을 구분해야 하는 보안 팀에 돌아간다.

MCP는 AI 애플리케이션이 도구를 발견하고, 리소스를 읽고, 프롬프트를 가져오며, 작업을 호출하는 방식을 표준화한다. 이 프로토콜은 맞춤형 통합 작업을 줄이기 때문에 직원과 개발자가 중앙 배포 프로젝트 없이도 서버를 추가하기 쉬워진다.

그 속도는 익숙한 거버넌스 문제를 만든다. 사용자는 원격 서버 URL로 MCP 클라이언트를 구성하고 OAuth 또는 다른 자격 증명을 통해 접근 권한을 부여할 수 있다. 보안 팀은 승인된 소프트웨어 카탈로그 내에서 이 설정을 전혀 보지 못할 수 있다.

위험은 승인되지 않은 웹 애플리케이션 방문보다 크다. MCP 서버는 에이전트에 도구를 노출하며, 이러한 도구에는 의미 있는 권한이 수반될 수 있다. 통합 방식에 따라 도구는 문서를 검색하고, 리포지터리를 읽으며, 지원 기록을 열고, 인프라를 수정하거나 메시지를 보낼 수 있다.

합법적인 도구도 부적절한 데이터를 받을 수 있다. 직원이 에이전트에게 고객 문제 분석을 요청하면서 규제 대상 정보를 외부 서버로 자신도 모르게 전송할 수 있다. 손상되었거나 기만적인 서버는 이후 에이전트 동작을 조작하도록 설계된 지침을 반환할 수도 있다.

이 때문에 Cloudflare는 관리되지 않는 연결을 섀도 MCP라고 설명한다. 결정적인 문제는 알려지지 않은 모든 서버가 적대적인지 여부가 아니다. 조직이 서버, 운영자, 요청 권한 또는 그 안팎으로 흐르는 데이터를 검토하지 않았다는 점이다.

Gateway 로그는 이러한 미확인 활동을 인벤토리로 전환할 수 있다. 관리자는 사용자, 대상 호스트, 요청량, 정책 작업 및 탐지된 프로토콜 메서드를 식별할 수 있다. 이후 어떤 클라이언트가 트래픽을 만들었는지, 어떤 업무 목적을 수행하는지 조사할 수 있다.

인벤토리는 보다 신중한 집행도 지원한다. 팀은 초기 일치를 기록하고, 활성 대상지를 검토하며, 무엇이든 차단하기 전에 각 서버를 분류할 수 있다. 승인되지 않은 원격 도구로 향하는 직접 트래픽처럼 신뢰도가 높은 사례에는 더 엄격한 정책을 적용할 수 있다.

그러나 관리되는 네트워크 범위가 경계를 정한다. Gateway는 관련 HTTP 트래픽을 능동적으로 프록시해야 한다. 직원이 관리되지 않는 디바이스, 별도 네트워크 경로 또는 조직의 통제 밖에 있는 클라이언트를 사용하면 해당 요청은 같은 로그에 나타나지 않는다.

암호화된 트래픽에는 또 다른 조건이 추가된다. Gateway가 직접 MCP 연결의 HTTP 본문을 검사하려면 TLS 복호화가 필요하다. 그렇지 않으면 관리자는 대상 호스트명은 볼 수 있어도 JSON-RPC 메서드와 도구 인수는 놓칠 수 있다.

Cloudflare는 Portal 트래픽을 다르게 처리한다. Portal은 클라이언트 연결을 종료하고 업스트림 서버로 새 연결을 만든다. 이 아키텍처는 계정 전체 TLS 복호화 설정에 의존하지 않고도 Gateway가 라우팅된 Portal 트래픽을 검사하도록 한다.

직접 트래픽에는 이러한 자동 처리가 적용되지 않는다. Cloudflare의 Portal documentation에 따르면 WARP 관리 디바이스를 통해 직접 연결하는 에이전트는 본문 검사를 위해 일반적인 TLS 복호화 구성이 필요하다.

트래픽 검사를 면제해야 할 합법적인 이유도 있다. 개인정보 보호 요구 사항, 인증서 고정 애플리케이션 또는 운영상의 제약으로 인해 팀은 Do Not Inspect 정책을 만들 수 있다. 이러한 정책은 우선 적용되며, 일치하는 MCP 활동을 DLP 분석 범위 밖에 둘 수 있다.

이러한 한계가 탐지를 무용하게 만드는 것은 아니다. 오히려 결과 대시보드가 실제로 무엇을 의미하는지 규정한다. 보고서는 검사되고 관리되는 경로에서 가시화된 MCP 유사 활동을 보여준다. 회사 전체의 모든 에이전트 연결을 완전히 집계한 결과는 아니다.

이 구분은 사고 대응 방식을 좌우해야 한다. 탐지된 연결은 조사를 받아야 하지만, 빈 보고서가 섀도 MCP가 없다는 증거는 아니다. 보안 팀에는 네트워크 탐지와 함께 엔드포인트 범위, ID 데이터 및 클라이언트 구성 제어가 필요하다.

진짜 경쟁은 Portal 접근과 직접 연결 사이에서 벌어진다

Cloudflare의 보안 모델은 관리되는 경로에서 승인된 Portal 접근이 직접 서버 URL을 대체할 때에만 집행 가능해진다.

MCP 서버 Portal은 여러 승인 서버를 하나의 HTTP 엔드포인트 뒤에 통합한다. 사용자는 MCP 클라이언트에서 해당 엔드포인트를 구성하고, Cloudflare Access를 통해 인증하며, 정책이 허용하는 서버와 도구만 제공받는다.

Portal은 직접 연결이 개별 통합 전반에 분산하는 여러 작업을 수행한다. 사용자 식별, Access 규칙 평가, 업스트림 인증 관리, 승인된 도구 노출 및 요청 기록을 담당한다. 관리자는 모든 직원에게 개별 엔드포인트 목록을 유지하게 하지 않고도 서버를 구성할 수 있다.

Access 정책은 ID 그룹, 위치 및 디바이스 상태를 활용할 수 있다. 재무 Portal은 재무 직원에게 선택된 읽기 전용 도구를 노출할 수 있다. 엔지니어링 Portal은 관리되는 회사 디바이스에서만 추가 작업을 허용할 수 있다.

관리자는 개별 도구나 프롬프트를 숨길 수도 있다. 이는 서버를 승인한다고 해서 그 서버가 게시하는 모든 기능을 승인할 필요는 없기 때문에 중요하다. 리포지터리 접근 권한을 가진 서버는 검색 및 읽기 작업을 노출하되, 쓰기 작업은 사용할 수 없도록 유지할 수 있다.

Cloudflare의 Portal 설계는 인증되지 않은 업스트림 서버와 OAuth로 보호되는 서버를 지원한다. 사용자는 업스트림 서비스에 별도로 인증할 수 있으며, 일부 시스템 간 워크플로는 Access 서비스 토큰을 사용할 수 있다. Portal은 이후 도구 호출을 프록시할 때 적절한 자격 증명을 연결한다.

Gateway 라우팅이 활성화되면 실시간 호출은 Portal에서 Gateway를 거쳐 업스트림 서버에 도달한다. Gateway는 요청을 기록하고 HTTP 및 DLP 정책을 적용할 수 있다. 송신 제어는 이러한 요청에 예측 가능한 소스 주소를 제공할 수도 있다.

이로써 실용적인 허용 및 차단 패턴이 만들어진다. 보안 팀은 직원에게 승인된 Portal 엔드포인트를 제공한 다음, 업스트림 MCP 서버로의 직접 연결을 중단하는 Gateway 규칙을 만든다. Portal 경로는 계속 사용할 수 있지만 관리되지 않는 대안은 제한된다.

정책은 올바른 대상을 겨냥해야 한다. Cloudflare는 Portal 트래픽용 DLP 규칙이 Portal 도메인만이 아니라 업스트림 MCP 서버 호스트명과 일치해야 한다고 설명한다. Portal은 클라이언트가 접하는 진입점이지만, Gateway는 실제 서버를 향해 재생성된 요청을 평가한다.

이 구조는 단순한 디렉터리보다 애플리케이션 게이트웨이에 가깝습니다. ID, 도구 선택, 로깅, 데이터 제어가 만나는 관문을 제공합니다. 이 관문이 검색을 거버넌스로 전환합니다.

그러나 직접 URL은 여전히 핵심적인 약점입니다. Cloudflare는 Portal에서 서버를 숨긴다고 해도 사용자가 원래 주소로 연결하는 것을 막지는 못한다고 경고합니다. 업스트림 서버가 공개적으로 계속 접근 가능하다면 Portal 정책만으로는 우회를 차단할 수 없습니다.

따라서 조직에는 Portal 인터페이스 밖의 강제 제어 수단이 필요합니다. 호스트 이름을 통제할 수 있는 경우 Access로 서버를 보호하거나, 알려진 이그레스 주소로 인바운드 트래픽을 제한하거나, Gateway를 통해 직접 목적지를 차단할 수 있습니다. 타사 서비스에는 해당 배포 모델이 지원하는 제어 수단이 필요합니다.

선택지는 Cloudflare 대 다른 보안 벤더가 아닙니다. 핵심 경쟁 구도는 거버넌스가 적용된 Portal 액세스와 사용자가 직접 구성한 연결 간의 대결입니다. 모든 주요 기능은 이 경쟁을 뒷받침합니다.

Portal 로그는 승인된 활동을 식별합니다. Gateway 검색은 승인된 경로 밖의 트래픽을 찾습니다. Access는 누가 Portal을 사용할 수 있는지 결정합니다. DLP는 관리 경로를 통과하는 데이터를 평가합니다. 네트워크 정책은 직접 경로를 차단하려 시도합니다.

이 모델은 강제가 시작된 후에도 개발자에게 사용할 수 있는 목적지를 제공합니다. MCP를 전면 금지하면 실험은 공식 채널 밖으로 밀려날 것입니다. 선별된 Portal은 보안 팀이 추가 서버를 검토하는 동안 팀이 승인된 도구를 계속 사용할 수 있게 합니다.

결과는 운영 규율에 달려 있습니다. 누군가는 승인 서버 카탈로그를 소유하고, 도구 권한을 검토하며, Access 정책을 유지하고, 새로 탐지된 목적지에 대응해야 합니다. 중앙화는 흩어진 제어를 줄이지만, 그러한 결정을 없애지는 않습니다.

프로토콜 휴리스틱은 범위를 제공할 뿐, 확실성을 제공하지는 않는다

Cloudflare는 강력한 MCP 지표를 식별할 수 있지만, 그러한 지표가 연결이 안전한지, 악의적인지, 또는 적절히 관리되는지를 증명하지는 않습니다.

탐지 패턴은 휴리스틱입니다. "method":"tools/call"을 포함한 본문은 MCP와 매우 유사하지만, 다른 JSON-RPC 애플리케이션도 같은 메서드 이름을 사용할 수 있습니다. 사용자 정의 MCP 구현은 제한적으로 작성된 정규 표현식 범위를 벗어나는 형식을 만들 수도 있습니다.

공백 허용 범위는 이 문제를 잘 보여 줍니다. 예시 표현식은 JSON 필드 주변에서 제한된 양의 공백을 허용합니다. 각 패턴이 하나의 필드를 대상으로 한다면 필드 순서가 바뀌어도 탐지되어야 하지만, 대체 직렬화 방식과 이스케이프 처리는 매칭을 복잡하게 만들 수 있습니다.

암호화되었거나 지원되지 않는 트래픽은 더 큰 공백을 만듭니다. Gateway가 복호화하지 않는 한 DLP는 직접 HTTPS 본문을 검사할 수 없습니다. 표준 입력과 출력을 통해 통신하는 로컬 MCP 서버는 HTTP 게이트웨이를 전혀 통과하지 않습니다.

Streamable HTTP는 Cloudflare의 현재 설계에서 가장 중요한 원격 전송 방식입니다. MCP transport specification은 JSON-RPC 메시지와 선택적 세션 식별자를 전달하는 HTTP 요청을 정의합니다. 이러한 규칙적인 구조는 Gateway가 프로토콜을 인식하는 데 도움이 됩니다.

Cloudflare의 라우팅된 Portal 경로는 Streamable HTTP를 지원합니다. 업스트림 서버가 이전의 Server-Sent Events 전송 방식만 지원한다면 해당 서버에서는 Gateway 라우팅이 실패합니다. 라우팅이 활성화되어 있으면 Portal은 Streamable HTTP를 시도하지만, 업스트림 서비스가 이를 지원해야 합니다.

백그라운드 동기화도 또 다른 예외입니다. Portal은 주기적으로 업스트림 서버에서 도구와 프롬프트를 가져오지만, Cloudflare에 따르면 이러한 동기화 요청은 Gateway를 통과하지 않습니다. 문서화된 라우팅 검사는 실시간 사용자 도구 호출에만 적용됩니다.

DLP 적용 범위에도 제품별 한계가 있습니다. Cloudflare는 AI 프롬프트 프로필이 서로 다른 API 경로와 형식을 예상하기 때문에 MCP Portal 트래픽에는 적용되지 않는다고 설명합니다. 관리자는 표준 DLP 프로필을 사용해야 합니다.

검사하지 않음(Do Not Inspect) 규칙은 Portal 트래픽에도 계속 적용됩니다. Portal 라우팅은 자동 복호화를 허용하지만, 명시적 예외는 페이로드 검사를 방지합니다. 따라서 광범위한 예외는 승인된 업스트림 서버에서 DLP 보호를 제거할 수 있습니다.

ID 정책에도 주의할 점이 있습니다. Cloudflare는 독립 MFA, 목적 정당화, 임시 인증이 Portal을 통해 승인된 서버에는 강제되지 않는다고 문서화합니다. 이메일, 그룹, 국가, 디바이스 상태 선택기는 계속 적용됩니다.

이러한 제약은 Portal이 실제 정책 경로보다 더 엄격해 보일 수 있기 때문에 중요합니다. 관리자는 서버 수준 요구 사항을 할당하고 사용자가 Portal 승인 과정에서 이를 마주할 것이라고 가정할 수 있습니다. Cloudflare의 문서에 따르면 여러 단계적 추가 인증 제어는 그렇게 작동하지 않습니다.

보안 팀은 프로토콜 탐지와 의미론적 보안을 분리해서도 봐야 합니다. 요청은 승인된 Portal을 통과하고 DLP 규칙과 일치하지 않으면서도 안전하지 않은 작업을 유발할 수 있습니다. DLP는 사용자의 의도에 프로젝트 삭제가 부합하는지를 판단하는 것이 아니라 정의된 데이터 패턴을 찾습니다.

도구 인젝션은 관련된 문제를 제기합니다. 업스트림 서버는 에이전트의 다음 결정을 좌우하는 콘텐츠를 반환할 수 있습니다. 네트워크 검사는 민감한 문자열을 기록하거나 차단할 수 있지만, 그 외에는 유효한 콘텐츠에 포함된 조작적 지시를 반드시 인식하지는 않습니다.

반대 방향도 마찬가지입니다. 섀도 MCP 연결이 자동으로 사고를 의미하지는 않습니다. 개발자가 무해한 공개 데이터 소스를 테스트하고 있을 수 있습니다. 이 연결은 여전히 거버넌스 밖에 있지만, 비즈니스 및 보안 영향은 맥락이 필요합니다.

따라서 오탐과 미탐은 운영 모델에 포함되어야 합니다. 팀은 호스트 이름과 URI 일치를 단서로 취급한 뒤, 본문 신호, 사용자 귀속 정보, 클라이언트 데이터, 서버 검토를 사용해 결론에 도달해야 합니다. 영향이 큰 차단 규칙은 일반적인 경로 일치 이상의 근거에 의존해야 합니다.

단계적 롤아웃은 중단을 줄일 수 있습니다. 관리자는 로깅부터 시작해 예상되는 Portal 트래픽을 확립하고, 일반적인 직접 목적지를 식별할 수 있습니다. 이후 새 서버를 위한 승인 프로세스를 마련하면서 신뢰도가 높은 섀도 연결을 차단할 수 있습니다.

가장 강력한 방식은 네트워크와 엔드포인트 제어를 결합합니다. Gateway는 관리되는 경로를 통과하는 원격 트래픽을 확인합니다. 엔드포인트 관리는 사용자가 설치하는 클라이언트와 구성을 제어할 수 있습니다. Access와 업스트림 제한은 승인된 경로가 생긴 후 우회를 더 어렵게 만듭니다.

Cloudflare는 그러한 아키텍처를 위한 구성 요소를 제공했습니다. 이를 설계할 필요성까지 없앤 것은 아닙니다.

세 가지 신호가 Cloudflare의 MCP 모델이 유지되는지 보여 줄 것이다

다음 시험대는 기업이 MCP 가시성을 일관된 라우팅, 의미 있는 차단, 측정 가능한 도구 거버넌스로 전환할 수 있는지 여부입니다.

첫 번째 신호는 탐지된 트래픽 중 승인된 Portal 도메인을 통과하는 비중입니다. 초기 Gateway 검색에서는 알려진 서비스, 실험, 오탐이 섞여 드러날 가능성이 큽니다. 승인된 대안이 제공된 뒤 직접 MCP 활동이 감소하면 이 모델은 신뢰를 얻습니다.

보안 팀은 이를 단순한 차단 건수가 아니라 라우팅 결과로 측정해야 합니다. 차단된 요청 수가 늘어나는 것은 정책이 작동함을 보여 줄 수 있지만, 사용자가 계속 승인된 경로를 우회하려 한다는 신호일 수도 있습니다. 성공적인 전환은 정당한 활동이 Portal을 통해 계속 이뤄지는 것을 의미합니다.

두 번째 신호는 도구 및 데이터 수준의 정책 품질입니다. 승인된 모든 서버의 모든 기능을 노출하는 Portal은 접근을 중앙화하지만, 큰 제약을 적용하지는 않습니다. 더 강력한 배포 환경은 도구를 선별하고, ID 조건을 사용하며, 요청과 응답 모두에 DLP 프로필을 적용할 것입니다.

Cloudflare의 Gateway는 아웃바운드 콘텐츠가 표준 DLP 프로필과 일치할 때 도구 요청을 차단할 수 있습니다. 또한 업스트림 서버가 일치하는 민감 데이터를 반환할 경우 응답을 차단할 수 있습니다. MCP 클라이언트는 보호된 콘텐츠 대신 오류를 받습니다.

이러한 제어는 조직이 실제 워크플로에 맞게 조정할 때 더 가치가 높아집니다. 자격 증명, 금융 정보, 고객 식별자, 독점 문서는 서로 다른 위험을 수반합니다. 모든 것을 차단하는 정책은 사용자를 좌절시키고, 전혀 발동하지 않는 정책은 거의 보호를 제공하지 않습니다.

보안 팀은 차단된 도구 메서드, 일치한 데이터 범주, 영향을 받은 서버, 사용자 결과를 추적해야 합니다. 또한 에이전트가 차단된 요청을 반복적으로 재시도하는지 검토해야 합니다. 반복 시도는 부적절한 클라이언트 동작이나 더 안전한 승인 설계가 필요한 워크플로를 드러낼 수 있습니다.

세 번째 신호는 Cloudflare와 MCP 생태계가 알려진 적용 범위 공백을 얼마나 빠르게 해소하는지입니다. Streamable HTTP의 채택은 Gateway 라우팅을 사용할 수 없는 업스트림 서버 수를 줄여야 합니다. 더 나은 엔드포인트 제어는 로컬 및 관리되지 않는 구성에 대한 가시성을 개선할 수 있습니다.

프로토콜 변경도 중요합니다. 현재 JSON-RPC 메서드를 중심으로 구축된 탐지 패턴은 사양이 발전함에 따라 함께 진화해야 합니다. 안정적인 헤더 또는 다른 표준화된 전송 신호는 분류를 더 쉽게 만들 수 있지만, 보안 팀은 모든 클라이언트가 새 필드를 즉시 채택한다고 가정해서는 안 됩니다.

경쟁사의 움직임도 핵심 경쟁 구도를 바꾸지 않으면서 또 다른 단서를 제공할 것입니다. 보안 웹 게이트웨이와 엔드포인트 벤더는 자체 MCP 분류, 서버 인벤토리 또는 에이전트 제어를 추가할 가능성이 큽니다. 이러한 압력은 탐지 방법을 개선하고 네트워크 전용 접근 방식이 부족한 지점을 드러낼 수 있습니다.

Cloudflare의 강점은 아키텍처 통합에 있습니다. Portal, Access, Gateway, DLP, 이그레스, 애플리케이션 제어가 하나의 정책 경로에 참여할 수 있습니다. 과제는 고객이 의미 있는 우회 경로를 남기지 않고 이러한 구성 요소를 설정할 수 있음을 증명하는 것입니다.

따라서 Cloudflare가 이를 어떻게 수행하는지에 대한 이야기는 단일 탐지기보다 피드백 루프에 가깝습니다. 직접 MCP 트래픽을 찾아 조사하고, 필요한 서버를 승인하며, Portal을 통해 라우팅하고, 관리되지 않는 경로를 차단합니다. 이후 사용자가 새 도구를 채택함에 따라 이 과정을 반복합니다.

이 모델을 고려하는 조직은 한 가지 실용적인 질문에서 시작해야 합니다. 보안 팀은 오늘날 실제로 어떤 관리형 네트워크 경로와 에이전트 클라이언트를 관찰할 수 있는가?

그다음 MCP 신호를 목록화하고, 이를 승인된 Portal 트래픽과 비교하며, 강제가 충분한 신뢰도를 갖는 지점을 선택할 수 있습니다. 목표는 모든 MCP 연결을 위험하다고 분류하는 것이 아닙니다. 에이전트가 조직이 인증, 검사, 감사할 수 있는 경로를 통해 민감한 도구에 도달하도록 보장하는 것입니다.