WriteGuard: MCP 서버를 위한 세밀한 제어 (새 탭에서 열림)

AI 에이전트가 외부 시스템에 쓰기 권한을 가지면, 잘못된 프롬프트 하나만으로 사람의 작업 속도를 훨씬 뛰어넘는 대규모 변경을 일으킬 수 있다. Cloudflare는 에이전트별 설정이나 사용자의 감시에 의존하지 않고, MCP 도구 호출을 중앙에서 정책 적용·식별·감사하기 위해 WriteGuard를 구축했다. WriteGuard는 인간 사용자의 권한은 유지하면서 에이전트 세션을 별도로 추적하고, 위험도에 따라 작업을 허용·기록·차단한다.

MCP의 구조와 에이전트 동작 방식

• MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구와 데이터에 연결되도록 하는 표준이다.
• MCP 서버는 다음 요소를 가진 도구를 제공한다.
  • 도구 이름
  • 설명
  • 입력 스키마
  • 실제 작업을 수행하는 핸들러
• 에이전트가 도구를 선택하면 MCP 클라이언트가 서버에 호출을 보내고, 서버가 Jira·GitLab·데이터베이스 등 downstream 시스템과 상호작용한다.
• 따라서 도구에 쓰기 권한이 부여되면 에이전트가 외부 시스템의 상태를 직접 변경할 수 있다.

무제한 쓰기 권한의 위험

• 잘못 작성된 정리 작업 프롬프트가 수천 개의 티켓을 자동으로 닫을 수 있다.
• 사람이 직접 수행한 작업과 에이전트가 수행한 작업이 동일한 사용자 계정으로 기록되면 원인 분석과 복구가 어려워진다.
• 여러 에이전트 세션이 동시에 실행되면 네트워크 로그만으로 특정 세션을 식별하기 어렵다.
• 위험한 사례는 다음과 같다.
  • 계약 소프트웨어의 계약 내용 변경
  • 고객지원 큐에 대량 답변 전송
  • 데이터베이스 테이블 전체 삭제
• Cloudflare는 모든 사용자가 에이전트를 완벽하게 설정하거나 모든 도구 호출을 감시할 수 없다고 판단했다.

Cloudflare의 MCP 확장

• Cloudflare의 내부 에이전트는 OpenCode, Cloudflare OS, 장기 실행 에이전트 서비스 등을 통해 MCP를 사용한다.
• 내부 MCP 포털이 여러 서버를 통합하며, 연결된 서버 수는 13개에서 27개로 증가했다.
• 초기에는 Jira, GitLab, 위키, 운영 시스템 등을 조회하는 읽기 전용 서버로 시작했다.
• 이후 엔지니어링·제품·디자인·영업·고객 성공팀에서 실제 변경 작업을 수행하는 도구를 요구했다.
• 클라이언트의 skill이나 elicitation prompt만으로는 통제가 어렵기 때문에 중앙 정책 계층인 WriteGuard를 도입했다.

WriteGuard의 역할

• WriteGuard는 MCP 서버와 도구 호출 사이에 위치하는 공통 계층이다.
• 도구 설정과 요청 컨텍스트를 바탕으로 호출을 다음과 같이 처리한다.
  • 호출을 그대로 통과
  • 에이전트 식별 정보를 추가한 뒤 통과
  • 감사 이벤트를 생성
  • 핸들러 실행 전에 호출 차단
• WriteGuard는 다음 기능을 하나의 장소에서 제공한다.
  • 도구별 정책 관리
  • 사용자 및 에이전트 신원 연결
  • downstream 시스템에 에이전트 정보 표시
  • 중앙 감사 로그 수집

도구 위험도 기반 정책

각 도구에는 위험도, 활성화 여부, 라벨링 설정을 지정한다.

• Read Only
  • 이슈 검색
  • Merge Request 조회
  • 파이프라인 상태 확인
• Minimal Impact
  • 리액션 추가
  • 알림을 읽음으로 표시
  • 이슈 구독
• Contained Write
  • 댓글 작성
  • Merge Request 생성
  • 이슈 필드 수정
• Critical
  • Merge Request 병합
  • 운영 환경 배포 실행
  • 레코드 일괄 삭제

위험도는 감사 로그 기록 여부와 호출 허용 여부를 결정하며, 위험도별로 로그를 검색할 수 있다. 또한 서버 코드를 수정하지 않고도 특정 입력 필드에 일반 텍스트나 HTML 형식의 에이전트 라벨을 삽입할 수 있다.

사람의 권한을 유지하고 에이전트만 식별

• 내부 MCP 서버는 Cloudflare Access와 OAuth로 사용자를 인증한다.
• 에이전트는 별도 계정이 아니라 사용자의 권한을 그대로 사용한다.
• 따라서 Joe가 특정 이슈를 닫을 수 없다면 Joe의 에이전트도 닫을 수 없다.
• 별도 에이전트 계정을 만들지 않은 이유는 다음과 같다.
  • 관리해야 할 권한 체계가 추가됨
  • 에이전트와 책임자인 사람의 연결이 약해짐
• 대신 WriteGuard는 사용자 신원에 MCP 클라이언트와 세션 정보를 추가한다.
• downstream 애플리케이션에는 사람의 권한으로 수행된 작업이라는 정보와 함께, 어떤 에이전트 세션이 작업했는지 표시할 수 있다.

중앙 감사 로그와 대규모 활동 분석

• WriteGuard는 각 도구 호출을 성공, 실패, 차단으로 분류한다.
• 이후 감사 이벤트를 비동기적으로 내부 audit Worker에 전송한다.
• 감사 이벤트에는 다음 정보가 포함된다.
  • MCP 서버
  • 도구 이름
  • 위험도
  • 호출 결과
  • 사용자
  • 클라이언트
  • 실행 시간
• 비밀번호나 민감한 값으로 분류된 입력 키의 값은 제거한다.
• 비동기 로깅을 사용하므로 에이전트가 응답을 기다리는 시간에는 추가 지연이 없다.
• MCP 포털 로그가 개별 호출을 보여준다면, WriteGuard 로그는 도구의 의미적 분류·에이전트 컨텍스트·백엔드 처리 결과를 함께 제공한다.
• 이를 통해 특정 시스템 하나가 아니라 전체 MCP 환경에서 에이전트의 대량 활동을 검색하고 조사할 수 있다.

GitLab 적용 방식

• 글에서는 GitLab MCP 서버의 세 도구를 예로 든다.
  • get_merge_request: Merge Request 읽기
  • create_mr_note: 댓글 또는 노트 작성
  • merge_mr: Merge Request 병합
• 이 도구들은 각각 읽기, 제한적 쓰기, 중요 쓰기 등 서로 다른 위험도 정책을 적용할 수 있다.
• 이를 통해 동일한 GitLab 서버 안에서도 조회는 허용하되 댓글 작성이나 병합은 별도로 기록하거나 차단하는 식의 세밀한 통제가 가능하다.

실용적인 결론

MCP 서버에 쓰기 권한을 추가할 때는 단순한 사용자 인증만으로는 부족하다. 도구별 위험도 정책, 에이전트 세션 식별, 민감정보 제거 감사 로그, 사전 차단 기능을 중앙 계층에서 제공해야 하며, 특히 대량 변경이 가능한 작업은 높은 위험도로 분류해 별도 통제하는 것이 안전하다.