AI 에이전트가 외부 도구와 데이터에 접근할 때 핵심 위험은 권한 자체보다 판단과 실행의 속도에 있다. 사람이 직접 운영 환경을 배포하거나 데이터베이스를 조회할 때는 예상하지 못한 결과를 보고 멈출 가능성이 있지만, 에이전트는 잘못된 판단을 같은 속도로 반복할 수 있다. 한 번의 그럴듯하지만 부정확한 결정이 짧은 시간 안에 여러 번의 조회, 변경, 삭제 요청으로 이어질 수 있다는 뜻이다.
Cloudflare가 발표한 기능은 Cloudflare Gateway가 검사할 수 있는 네트워크 트래픽에서 MCP 요청의 프로토콜 신호를 식별하고, 어떤 사용자와 서버가 해당 트래픽을 만들었는지 파악하며, 관리되는 네트워크 경로에서 직접 연결을 통제하도록 돕는 데 초점이 있다. MCP Server Portal과 함께 사용하면 승인된 서버를 Portal 경유로만 이용하게 하고, 사용자가 승인 경로를 우회해 MCP 서버에 직접 접속하는 상황을 찾거나 차단하는 정책을 구성할 수 있다.
MCP 트래픽을 별도로 찾아야 하는 이유
Model Context Protocol은 AI 에이전트가 외부 SaaS, 사내 애플리케이션, API가 제공하는 도구를 발견하고 호출하는 공통 방식을 제공한다. 개발자는 Claude Code, Codex, Cursor, OpenCode, VS Code 같은 클라이언트나 다른 AI 실행 환경에 MCP 서버 주소를 추가할 수 있다. 연결 자체가 간단한 만큼, 조직의 승인 절차를 거치지 않은 서버가 개발 환경에 들어오는 이른바 섀도 MCP 문제도 생길 수 있다.
MCP 요청은 고정된 호스트 이름을 사용하지 않으며 URL 경로에 반드시 특정 문자열이 포함되는 것도 아니다. 따라서 목적지 도메인이나 경로만 보는 방식으로는 일반 HTTPS API 호출과 MCP 호출을 안정적으로 구분하기 어렵다. Cloudflare Gateway는 단순 URL 목록이 아니라 요청 헤더와 JSON-RPC 메시지처럼 프로토콜 수준에서 드러나는 신호를 조합해 검사 대상 트래픽을 식별한다.
다만 “MCP를 식별한다”는 표현을 모든 환경의 호출을 자동으로 발견한다는 의미로 받아들이면 안 된다. 네트워크 계층에서 관찰하려면 요청이 관리되는 경로를 지나야 하고, 암호화된 HTTPS 내부를 검사하려면 조직의 TLS 복호화 구성이 전제될 수 있다. 로컬 프로세스끼리 표준 입출력으로 통신하는 MCP 서버와 관리 네트워크 밖에서 발생한 요청은 Gateway가 볼 수 없는 범위다.
하나의 도구 호출에서 드러나는 정보
원격 MCP 도구 호출은 클라이언트 안에서는 “어떤 도구를 어떤 인자로 실행할지”에 대한 결정이며, 네트워크에서는 JSON-RPC 메시지를 담은 HTTP 요청이고, 서버에서는 실제 함수나 처리기를 실행하는 명령이 된다. 각 단계에서 확인할 수 있는 정보와 통제 가능한 범위가 다르다.
- 목적지와 경로: 요청이 어느 서버로 향하는지 보여준다. 다만 MCP가 고정된 도메인이나 경로를 요구하지 않으므로 이것만으로 판별하기는 어렵다.
- 인증 정보: 서버가 인증을 요구한다면 요청에는 호출자를 증명하는 자격 정보가 포함될 수 있다. 로그를 남길 때 인증 값 자체가 노출되지 않도록 별도 보호가 필요하다.
- 프로토콜 버전과 메서드: 관련 헤더와 JSON-RPC 본문은 사용 중인 MCP 버전, 호출 유형, 요청 식별자 등을 나타낼 수 있다.
- 도구 이름: 에이전트가 조회, 생성, 수정 등 어떤 기능을 실행하려는지 판단하는 단서다.
- 호출 인자: 검색어, 소스 코드, 고객 데이터, 티켓 생성 내용, 인프라 변경 지시처럼 가장 민감한 정보가 들어갈 수 있다.
- 응답 결과: 서버가 에이전트에게 돌려주는 결과에도 내부 문서나 사용자 데이터 같은 민감한 내용이 포함될 수 있다.
요청 검사는 위험한 작업이 실행되기 전에 차단할 수 있다는 점에서 중요하다. 응답 검사와 로깅은 도구가 에이전트에게 어떤 정보를 반환했는지 추적하는 데 도움이 된다. 두 가지는 목적이 다르므로, 호출 기록만 저장하는 정책이 실제 실행 전 통제를 대신할 수는 없다.
통제 지점은 세 곳이다
1. MCP 클라이언트 내부
클라이언트는 모델이 도구를 선택한 뒤 네트워크 요청을 만들기 전에 목적지, 도구 이름, 인자를 확인할 수 있다. 승인 목록에 없는 서버를 거부하거나, 민감한 작업은 사용자 확인을 요구하거나, 장치 밖으로 나가기 전에 인자에서 데이터를 제거하는 방식이 가능하다. 네트워크를 전혀 사용하지 않는 로컬 MCP 서버도 이 단계에서는 통제할 수 있다.
한계는 클라이언트마다 같은 제어를 구현해야 한다는 점이다. 조직에서 여러 편집기와 AI 도구를 허용한다면 특정 클라이언트의 기록만으로 전체 MCP 사용 현황을 파악하기 어렵다. 클라이언트 측 제어는 조직이 장치와 클라이언트를 함께 관리할 때 가장 효과적이다.
2. 장치의 네트워크 경계
보안 웹 게이트웨이는 클라이언트에서 나온 HTTP 요청을 사용자 및 장치 정보와 연결하고, 목적지와 프로토콜 헤더를 기준으로 정책을 적용할 수 있다. 특정 MCP 클라이언트 구현에 의존하지 않고 관리되는 경로의 원격 트래픽을 폭넓게 관찰할 수 있다는 것이 장점이다. 승인된 Portal을 거치지 않고 외부 서버로 직접 향하는 연결도 목적지에 도달하기 전에 차단할 수 있다.
TLS 복호화와 데이터 손실 방지 검사가 지원되고 적절히 구성된 환경이라면 JSON-RPC 메서드와 호출 인자에 민감한 정보가 들어가는지도 검사할 수 있다. 반대로 복호화 대상이 아닌 연결, 네트워크를 통과하지 않는 로컬 호출, 관리 범위 밖의 장치와 회선은 별도의 대책이 필요하다.
3. MCP 서버의 도구 실행 직전
서버는 호출자를 인증하고 MCP 메시지를 해석한 뒤 도구 이름을 실제 처리기와 연결하며, 입력값을 도구 스키마에 맞춰 검증한다. 따라서 특정 사용자에게 해당 도구를 실행할 권한이 있는지 판단하고, 호출 빈도를 제한하며, 인자를 검사하기에 가장 풍부한 실행 문맥을 가진다.
특히 데이터를 쓰거나 외부 동작을 일으키는 도구는 처리기를 실행하기 전에 권한과 입력을 확인해야 한다. 실행이 끝난 뒤 남기는 로그는 사고 원인을 조사하는 데는 유용하지만 이미 발생한 변경을 막을 수는 없다. 네트워크 정책이 있더라도 서버 자체의 세부 권한 검사와 입력 검증을 생략해서는 안 된다.
Cloudflare Gateway에서 확인할 실제 적용 범위
| 확인 항목 | 확인할 질문 | 판단 기준 |
|---|---|---|
| 네트워크 경로 | MCP 요청이 실제로 관리되는 Gateway 경로를 통과하는가? | 개발 장치, 원격 근무 환경, 자동화 실행기가 정책 범위에 포함되어야 한다. |
| TLS 검사 | HTTPS 내부의 프로토콜 신호와 JSON-RPC 내용을 검사할 수 있는가? | 조직의 인증서 배포, 예외 도메인, 개인정보 정책과 충돌하지 않는지 먼저 확인한다. |
| 사용자 식별 | 탐지된 요청을 사용자와 장치에 연결할 수 있는가? | 공용 자격 증명이나 공유 실행기 때문에 실제 호출 주체가 흐려지지 않아야 한다. |
| Portal 강제 | 승인 서버는 Portal 경유만 허용하고 직접 연결은 막을 수 있는가? | 허용 목록과 차단 정책을 적용했을 때 정상 개발 흐름이 유지되어야 한다. |
| 로컬 MCP | 표준 입출력으로 동작하는 로컬 서버를 별도로 관리하는가? | 네트워크 정책 밖의 호출은 클라이언트 또는 장치 정책으로 보완한다. |
| 서버 권한 | 도구별 읽기·쓰기 권한과 호출 제한이 서버에 구현되어 있는가? | Gateway를 통과했다는 이유만으로 서버가 요청을 신뢰하지 않아야 한다. |
| 데이터 처리 | 요청 인자와 응답 결과 중 무엇이 검사되고 기록되는가? | 소스 코드, 연구 자료, 고객 정보가 로그에 과도하게 남지 않도록 범위를 정한다. |
| 비용과 계정 조건 | 필요 기능이 현재 계약과 계정 유형에서 제공되는가? | 공식 제품 문서와 관리 화면에서 사용 가능 여부와 비용 조건을 확인한 뒤 판단한다. |
개인 사용자와 개발자가 적용할 때
개인 서버나 사이드 프로젝트에서는 먼저 연결한 MCP 서버가 어떤 도구를 제공하고, 그 도구가 사용하는 API 자격 증명에 어떤 권한이 부여됐는지 살펴봐야 한다. 읽기 전용 기능에 관리자 권한 토큰을 제공하지 말고, 가능하면 프로젝트별 자격 증명과 최소 권한을 사용한다. 테스트용 에이전트가 운영 데이터베이스나 실제 배포 계정에 바로 접근하지 않도록 환경도 분리하는 편이 안전하다.
학생과 연구자는 논문 원문, 미공개 연구 자료, 참가자 정보가 도구 호출 인자로 전송될 가능성을 확인해야 한다. MCP 서버가 외부 서비스에 연결된다면 데이터가 어느 서버로 전달되는지, 요청과 응답이 로그에 남는지, 삭제와 보존 조건은 무엇인지 공식 정책에서 확인해야 한다. 네트워크에서 MCP로 식별됐다는 사실만으로 데이터 처리 조건까지 검증되는 것은 아니다.
CI/CD와 개발 자동화를 관리하는 팀은 사람이 사용하는 편집기뿐 아니라 빌드 실행기, 배포 봇, 원격 개발 환경도 조사 대상에 포함해야 한다. 에이전트가 배포, 티켓 생성, 저장소 변경 같은 쓰기 작업을 수행한다면 도구별 권한, 승인 단계, 호출 제한, 롤백 방법을 함께 설계해야 한다. 동일 요청이 반복됐을 때 중복 배포나 중복 생성이 발생하지 않는지도 작은 테스트 환경에서 확인할 필요가 있다.
안전하게 시험하는 순서
- 현재 사용 중인 MCP 클라이언트, 원격 서버, 로컬 서버와 각 서버가 제공하는 도구를 목록으로 만든다.
- 읽기 작업과 상태를 변경하는 작업을 구분하고, 운영 환경에 영향을 주는 도구부터 위험도를 높게 잡는다.
- 관리 장치에서 테스트 요청을 보내 Gateway가 사용자, 장치, 목적지와 MCP 신호를 예상대로 표시하는지 확인한다.
- 승인된 Portal 경유 요청은 허용하고 같은 서버로 향하는 직접 연결은 차단되는지 검증한다.
- 로컬 표준 입출력 호출과 관리 네트워크 밖의 요청처럼 보이지 않는 영역을 확인하고 클라이언트·서버 정책으로 보완한다.
- 요청 인자와 응답 로그에 민감한 데이터가 불필요하게 저장되지 않는지 검토한다.
- 업무 전체를 옮기기 전에 낮은 권한의 샘플 도구로 실패, 차단, 재시도, 롤백 흐름을 시험한다.
도입 판단에서 놓치기 쉬운 점
이번 기능의 가치는 새로운 MCP 클라이언트를 제공하는 데 있지 않고, 이미 여러 클라이언트에서 발생하는 원격 MCP 연결을 네트워크 관점에서 발견하고 승인 경로를 강제하는 데 있다. 따라서 한 종류의 클라이언트만 사용하는 개인 환경과, 다양한 편집기·에이전트·관리 장치를 운영하는 조직의 효용은 다를 수 있다.
또한 네트워크 탐지, 클라이언트 통제, 서버 권한 검사는 서로 대체 관계가 아니다. 클라이언트는 실행 전 의도를 가장 먼저 볼 수 있고 로컬 호출을 다룰 수 있다. Gateway는 관리 경로에서 여러 클라이언트의 원격 연결을 공통 정책으로 관찰할 수 있다. 서버는 인증된 호출자와 입력 스키마를 바탕으로 실제 실행 직전의 세밀한 결정을 내릴 수 있다. 위험한 도구일수록 세 계층을 겹쳐 사용하는 구성이 적합하다.
가격, 지원 계정, 지역별 제공 범위, TLS 검사 조건과 세부 정책 문법은 제공된 발표 내용만으로 확정할 수 없다. 실제 적용 전에는 현재 사용 중인 Cloudflare One 계정에서 기능이 열려 있는지, 추가 계약이 필요한지, 기존 Gateway 및 데이터 손실 방지 설정과 어떻게 결합되는지를 공식 문서와 관리 화면에서 확인해야 한다.
출처와 검증
이 글은 Cloudflare가 공개한 MCP 트래픽 식별 방식, 세 가지 통제 지점, Gateway와 MCP Server Portal의 역할을 기준으로 재구성했다. 제품을 적용할 때는 계정별 기능 제공 범위와 최신 설정 방법을 원문 및 연결된 공식 문서에서 다시 확인하는 것이 좋다.
원문: Cloudflare Blog — How Cloudflare detects MCP traffic and helps secure it