MCP 서버에 읽기 권한만 연결할 때와 실제 변경 권한을 열어 줄 때의 위험은 크게 다릅니다. 검색이나 상태 조회는 잘못된 호출이 발생해도 대체로 데이터가 바뀌지 않지만, 이슈 종료, 댓글 작성, 이메일 발송, 배포 실행, 레코드 삭제 같은 도구는 한 번의 잘못된 판단을 시스템 상태 변경으로 이어지게 합니다. 에이전트는 같은 작업을 사람이 따라가기 어려운 속도로 반복할 수 있으므로, 사용자에게 권한이 있다는 사실만으로 안전한 운영이 보장되지는 않습니다.
Cloudflare가 공개한 WriteGuard는 이런 쓰기 작업을 MCP 클라이언트의 프롬프트나 사용자 주의에만 맡기지 않고, MCP 서버 포털 쪽에서 통제하기 위한 정책·귀속·감사 계층입니다. 발표 시점에는 비공개 베타로 제공되며, 향후 몇 달에 걸쳐 서버 소유자가 Cloudflare MCP server portal에서 도구별 정책을 구성할 수 있도록 할 계획입니다. 모든 계정에서 바로 사용할 수 있는 일반 공개 기능으로 이해해서는 안 되며, 실제 이용 가능 여부와 신청 조건은 공식 안내를 확인해야 합니다.
MCP 쓰기 권한에서 문제가 되는 지점
Cloudflare는 범위가 지나치게 넓은 정리 작업을 실행한 백그라운드 에이전트가 수많은 티켓을 닫는 가상 사례로 문제를 설명합니다. 같은 시간에 사용자가 직접 정상적으로 닫은 티켓도 있다면 사후 복구는 더 어려워집니다. 변경 기록에는 사용자와 에이전트의 작업이 같은 사용자 자격 증명으로 남을 수 있고, 네트워크 로그만으로는 여러 에이전트 세션 가운데 어느 세션이 문제를 일으켰는지 구별하기 어렵기 때문입니다.
티켓 상태 변경은 비교적 복구 가능한 사례일 수 있지만, 쓰기 도구의 대상에 따라 피해 범위는 훨씬 커질 수 있습니다. 계약 내용 수정, 고객 지원 답변 발송, 데이터베이스 테이블 삭제, 운영 배포 실행처럼 외부 사용자나 프로덕션 환경에 영향을 주는 작업도 MCP 도구로 노출될 수 있습니다. 따라서 “이 에이전트를 신뢰하는가”보다 “어떤 도구가 어떤 조건에서 실행되고, 실행 주체와 세션을 나중에 식별할 수 있는가”를 먼저 물어야 합니다.
WriteGuard가 제공하는 세 가지 통제
WriteGuard는 각 도구의 설정과 요청 맥락을 함께 보고 호출을 처리합니다. Cloudflare가 설명한 동작은 크게 세 가지입니다.
- 그대로 통과: 정책상 허용되는 호출은 기존 MCP 도구로 전달합니다.
- 귀속 정보 추가와 감사 기록: 지원되는 쓰기 요청에는 에이전트가 수행한 작업임을 나타내는 정보를 추가하고, 민감한 내용을 정리한 감사 이벤트를 생성할 수 있습니다.
- 실행 전 차단: 허용되지 않은 작업은 MCP 도구의 실제 처리 함수가 실행되기 전에 막습니다.
중요한 차이는 정책을 개별 에이전트의 프롬프트나 로컬 설정에만 두지 않는다는 점입니다. 클라이언트마다 확인 절차가 다를 수 있고 사용자가 클라이언트 측 통제를 끌 수도 있기 때문에, Cloudflare는 서버 포털에 가까운 공통 계층에서 쓰기 정책을 적용하는 방식을 택했습니다. 여러 MCP 클라이언트와 장시간 실행되는 에이전트 서비스를 함께 운영하는 팀이라면 이 중앙화가 특히 의미 있습니다.
WriteGuard는 기존 MCP 서버 자체를 수정하지 않고 도구 옆에 정책을 정의하도록 설계됐습니다. Cloudflare 내부 환경에서는 이 설정을 TypeScript 기반 MCP 모노레포에서 관리하며, 비공개 베타가 확대되면 포털을 통해 같은 종류의 정책을 설정할 수 있게 할 계획입니다. 다만 베타 버전에서 지원되는 서버 유형, 설정 방식, 적용 지역과 계정 조건은 발표문만으로 모두 확정할 수 없으므로 실제 도입 전에 별도 확인이 필요합니다.
도구별 위험 등급을 어떻게 읽어야 하나
각 MCP 도구에는 위험 등급, 활성화 여부, 라벨 설정을 부여할 수 있습니다. 위험 등급은 호출 허용 여부와 기록 방식을 결정하고, 감사 로그를 위험도별로 조회하는 기준으로도 사용됩니다. Cloudflare가 제시한 분류와 사례는 다음과 같습니다.
| 위험 등급 | 작업 성격 | 예시 | 도입 시 판단 기준 |
|---|---|---|---|
| Read Only | 상태를 바꾸지 않는 조회 | 이슈 검색, 병합 요청 읽기, 파이프라인 상태 확인 | 조회 가능한 데이터 범위와 민감정보 노출 여부를 확인합니다. |
| Minimal Impact | 영향이 제한적인 가벼운 변경 | 반응 추가, 알림을 읽음으로 표시, 이슈 구독 | 대량 반복 시에도 사용자나 시스템에 부담이 없는지 봅니다. |
| Contained Write | 범위가 비교적 명확한 쓰기 | 댓글 추가, 병합 요청 생성, 이슈 필드 변경 | 대상 범위, 빈도 제한, 에이전트 표시와 복구 절차가 필요합니다. |
| Critical | 서비스나 데이터에 큰 영향을 줄 수 있는 작업 | 병합 실행, 프로덕션 배포, 레코드 일괄 삭제 | 기본 차단 여부와 별도 승인 절차를 우선 검토해야 합니다. |
이 등급은 도구 이름만 보고 일괄 배정하기보다 실제 처리 결과를 기준으로 정해야 합니다. 예를 들어 “업데이트”라는 이름의 도구도 개인 메모 한 줄을 수정하는 경우와 수천 건의 고객 데이터를 바꾸는 경우는 위험도가 다릅니다. 반대로 단순 조회 도구라도 민감한 운영 정보나 연구 데이터를 광범위하게 반환한다면 접근 정책을 느슨하게 둘 수 없습니다.
또한 Minimal Impact라는 명칭이 무해함을 뜻하지는 않습니다. 에이전트가 동일 호출을 빠르게 반복하면 알림 폭주나 외부 API 사용량 증가가 생길 수 있습니다. 등급을 정할 때는 한 번의 호출뿐 아니라 반복 실행 속도, 최대 대상 수, 외부 시스템의 되돌리기 기능까지 함께 평가하는 편이 안전합니다.
사람의 권한을 유지하면서 에이전트를 표시하는 방식
Cloudflare 내부 MCP 서버는 Cloudflare Access와 OAuth로 사용자를 식별합니다. 에이전트도 해당 사용자의 권한 안에서 작동하므로, 사용자가 특정 이슈를 닫을 수 없다면 그 사용자를 대신하는 에이전트도 닫을 수 없습니다. 별도의 에이전트 계정을 만들지 않고 기존 사용자 권한 모델을 유지한 이유는 관리해야 할 권한 체계가 이중화되는 것을 피하고, 에이전트에 책임이 있는 사람과의 연결을 분명하게 하기 위해서입니다.
하지만 하위 애플리케이션에는 사용자의 자격 증명만 전달되므로, 추가 정보가 없다면 사람이 직접 수행한 작업과 에이전트가 대신 수행한 작업이 같아 보일 수 있습니다. WriteGuard는 여기에 MCP 클라이언트와 세션 맥락을 결합해, 특정 에이전트 세션이 특정 사용자를 대신해 수행한 쓰기임을 식별하도록 합니다.
라벨은 사고 조사에만 필요한 것이 아닙니다. 이슈 댓글이나 변경 내역을 보는 사람은 작업이 사람의 직접 판단인지 자동화된 에이전트의 결과인지에 따라 검토 방법을 달리할 수 있습니다. Cloudflare는 하위 애플리케이션에 맞는 텍스트 형식으로 라벨을 삽입할 수 있도록 일반 텍스트와 HTML 같은 지원 형식을 예로 들었습니다. 실제로 어떤 필드와 형식이 지원되는지는 연결 대상별로 확인해야 합니다.
개발자가 먼저 확인할 적용 범위
개인 서버와 사이드 프로젝트
혼자 운영하는 서비스라도 에이전트가 배포, 데이터 수정, 이메일 발송 권한을 갖는 순간 중앙 정책과 감사 기록의 가치가 생깁니다. 다만 WriteGuard를 쓰기 위해 Cloudflare MCP server portal 구성이 필요한지, 현재 사용 중인 MCP 서버와 클라이언트가 베타 대상인지부터 확인해야 합니다. 단일 MCP 서버에 쓰기 도구가 몇 개뿐이라면 기존 서버의 권한 검사와 승인 로직으로 충분한지도 비교할 필요가 있습니다.
학생과 연구자
연구 자료 정리나 실험 자동화에서는 원본 데이터 변경, 파일 삭제, 공유 문서 수정 같은 작업을 별도 위험 등급으로 분리하는 것이 좋습니다. 개인 식별 정보나 공개 전 연구 결과가 포함된다면 감사 이벤트에 무엇이 남고 무엇이 제거되는지 확인해야 합니다. “scrubbed audit event”라는 설명만으로 특정 데이터 보호 요구사항을 충족한다고 단정할 수는 없습니다.
CI/CD와 개발 자동화 팀
병합과 프로덕션 배포는 Cloudflare의 예시에서도 Critical 등급입니다. WriteGuard가 호출을 차단할 수 있더라도 기존 저장소 보호 규칙, 배포 승인, 비밀정보 관리, 하위 시스템의 권한 검사를 대체한다고 보기는 어렵습니다. 서버 포털의 정책과 Git 저장소·CI 시스템의 정책이 충돌하지 않는지, 차단된 호출이 실패로 어떻게 전달되는지, 재시도가 무한 반복되지 않는지를 시험해야 합니다.
여러 MCP 서버를 운영하는 조직
Cloudflare 내부 포털은 발표 당시 27개의 MCP 서버를 연결하고 있었으며, 앞서 공개한 4월 시점의 13개에서 늘어났습니다. 처음에는 모두 읽기 전용으로 시작했고, 경험이 쌓이면서 여러 부서에서 실제 작업을 수행하는 도구를 요구했다고 설명합니다. 서버와 클라이언트 수가 늘어나는 조직에서는 개별 서버마다 서로 다른 방식으로 통제를 구현하는 비용이 커지므로, 공통 정책과 감사 계층이 더 유용할 수 있습니다.
비공개 베타 신청 전 체크포인트
- 가용성: 사용 중인 계정, 지역, MCP 서버 포털과 연결 대상이 비공개 베타에 포함되는지 확인합니다.
- 가격: 발표문에는 확정적인 요금 조건이 제시되지 않았으므로 베타 비용, 향후 과금 기준, 감사 로그 보관에 따른 비용을 공식 문서에서 확인합니다.
- 정책 단위: 서버 전체의 기본 Access 정책과 개별 도구의 WriteGuard 정책이 어떤 순서로 적용되는지 살펴봅니다.
- 차단 시점: 호출이 실제 핸들러 실행 전에 막히는지, 이미 시작된 하위 작업이나 비동기 작업에는 어떤 영향을 주는지 시험합니다.
- 귀속 정보: 사용자, MCP 클라이언트, 세션 가운데 무엇을 기록하고 하위 애플리케이션에는 어떤 라벨을 남기는지 확인합니다.
- 감사 데이터: 감사 이벤트에서 제거되는 정보, 저장 위치, 보존 기간, 조회 권한과 내보내기 방법을 점검합니다.
- 복구 가능성: 잘못된 쓰기를 탐지한 뒤 취소하거나 이전 상태로 되돌릴 수 있는지 연결 대상별로 문서화합니다.
- 기존 통제와의 관계: OAuth 권한, 저장소 보호 규칙, 배포 승인, 데이터베이스 권한과 중복되거나 빈틈이 생기지 않는지 비교합니다.
안전하게 시험하는 방법
처음부터 모든 쓰기 도구를 열기보다 조회 전용 도구와 영향이 작은 쓰기 도구를 분리해 단계적으로 적용하는 편이 좋습니다. 테스트 환경에서 사용자 직접 작업과 여러 에이전트 세션의 작업을 섞어 실행한 뒤, 감사 기록만으로 각각을 구별할 수 있는지 확인합니다. 정책이 의도대로 호출을 차단하는지뿐 아니라 허용된 호출에 정확한 사용자와 세션 정보가 붙는지도 검증해야 합니다.
- 현재 MCP 도구 목록과 각 도구가 변경하는 시스템을 정리합니다.
- 단일 호출의 영향과 반복 호출의 최대 피해 범위를 따로 평가합니다.
- 조회 전용, 제한적 쓰기, 중요 쓰기를 구분하고 중요 작업은 기본 차단 상태에서 시작합니다.
- 사람이 직접 한 변경과 에이전트가 수행한 변경이 하위 애플리케이션과 감사 기록에서 구별되는지 확인합니다.
- 잘못된 대량 호출을 재현해 차단, 조사, 복구에 필요한 시간을 측정합니다.
- 정책을 끄거나 이전 운영 방식으로 돌아가는 절차를 마련한 뒤 적용 범위를 넓힙니다.
도입 판단에서 과대평가하지 말아야 할 점
WriteGuard의 핵심 가치는 모델의 판단 정확도를 높이는 데 있지 않습니다. 잘못된 판단이 발생할 수 있다는 전제에서 실행 가능한 작업을 통제하고, 누가 어떤 에이전트 세션을 통해 작업했는지 남기며, 사고 조사에 필요한 맥락을 중앙에서 제공하는 데 있습니다. 따라서 프롬프트 개선이나 사용자 교육과 경쟁하는 기능이라기보다 서버 측 방어 계층에 가깝습니다.
동시에 WriteGuard 하나만으로 모든 운영 위험이 해결된다고 볼 수는 없습니다. 발표에서 확인되는 것은 도구별 정책, 실행 전 차단, 에이전트 귀속 표시, 위험도 기반 감사 기능입니다. 호출 횟수 제한, 별도 인간 승인, 자동 복구, 감사 데이터의 구체적인 보존 정책과 같은 기능은 제공 여부를 공식 문서에서 확인해야 합니다. 필요한 통제가 베타에 없다면 기존 하위 시스템의 권한과 승인 절차를 유지해야 합니다.
도입 가치는 MCP 쓰기 도구의 수, 연결된 시스템의 중요도, 동시에 실행되는 에이전트 세션 수에 따라 달라집니다. 읽기 전용 서버만 운영하거나 쓰기 작업이 매우 제한적이라면 즉시 이전할 이유가 크지 않을 수 있습니다. 반대로 여러 클라이언트가 같은 MCP 서버를 사용하고 배포·고객 응대·데이터 수정까지 자동화한다면, 클라이언트별 설정보다 중앙 통제와 추적 가능성을 우선 검토할 만합니다.
출처와 검증
WriteGuard의 기능과 비공개 베타 계획은 2026년 8월 5일 공개된 Cloudflare Blog 발표를 기준으로 정리했습니다. 베타 대상, 계정 조건, 가격, 지원되는 라벨 형식과 감사 데이터 정책은 변경될 수 있으므로 적용 시점의 공식 문서를 함께 확인해야 합니다.
Cloudflare Blog 원문: WriteGuard: fine-grained controls for MCP Servers