Cloudflare가 CASB에 Anthropic Claude Compliance API 연동을 추가했다. 핵심은 “Claude를 허용할 것인가”가 아니라, 이미 쓰는 기업용 Claude 안에서 어떤 프로젝트·파일·메시지가 위험한지 보안팀이 같은 워크플로로 볼 수 있게 됐다는 점이다.
핵심 요약
- 대상: Claude Enterprise를 쓰는 조직, 그리고 Cloudflare One/CASB로 SaaS 보안 상태를 관리하는 팀이다.
- 변화: Cloudflare CASB가 Claude Compliance API를 통해 Claude 조직, 워크스페이스, 프로젝트, 채팅, 파일, 역할 등 보안 관련 데이터를 읽어 위험 징후를 표시한다.
- 보이는 것: 조직 전체 또는 특정 사용자·그룹에 공유된 프로젝트, DLP 정책을 위반한 프로젝트 첨부파일, 채팅 파일, 사용자 프롬프트, 모델 응답, Artifacts 같은 항목이다.
- 중요한 이유: AI 도구는 전통적인 SaaS보다 입력·출력·파일·에이전트 연결이 자유롭다. 네트워크 차단만으로는 승인된 Claude 내부에서 어떤 데이터가 오갔는지 알기 어렵다.
무엇이 바뀌었나
Cloudflare 발표에 따르면 CASB는 이제 Anthropic의 Claude Compliance API를 사용해 Claude 안의 보안 관련 이벤트와 콘텐츠 징후를 Cloudflare 대시보드에 표시한다. 기존 CASB가 Microsoft 365, Google Workspace, Salesforce 같은 SaaS의 공유 상태와 민감 정보 노출을 살피던 방식에 Claude가 추가된 셈이다.
Cloudflare가 강조한 포인트는 “엔드포인트 에이전트 없이” Claude 사용 현황을 대시보드에서 모니터링한다는 점이다. 이는 브라우저나 단말에 별도 에이전트를 깔아 모든 트래픽을 가로채는 접근이 아니라, Claude Enterprise 쪽에서 제공하는 API를 통해 보안팀이 필요한 데이터를 가져오는 구조에 가깝다.
이 변화가 특히 중요한 이유는 기업용 AI 사용이 단순 웹앱 사용과 다르기 때문이다. 직원은 고객 정보나 내부 문서를 프롬프트에 붙여넣을 수 있고, 개발자는 API 키나 로그 조각을 공유할 수 있다. 모델은 다시 문서, 코드, 요약, Artifacts를 만들어낸다. 보안팀 입장에서는 “업로드된 데이터”뿐 아니라 “모델이 생성한 결과물”까지 감시 범위에 들어와야 한다.
보안팀이 실제로 볼 수 있는 항목
| 항목 | 의미 | 검토 포인트 |
|---|---|---|
| Projects | 조직 또는 일부 사용자·그룹에 공유된 Claude 프로젝트 | 과도한 공유, 퇴사자·외부 협업자 접근, 민감 프로젝트 공개 여부 |
| Project attachments | 프로젝트에 첨부된 파일과 문서 | PII, 고객 계약, 소스 코드, 키·토큰 문자열 포함 여부 |
| Chat files | 사용자가 올렸거나 모델이 생성한 파일 | 업로드 경로, 보존 기간, 재다운로드 권한 |
| Chat messages | 사용자 프롬프트와 Claude 응답 | DLP 정책 위반, 비밀정보 노출, 감사 로그 보존 정책 |
| Artifacts | Claude가 만든 문서·파일 결과물 | 생성물 안에 포함된 내부 정보와 재공유 가능성 |
Cloudflare는 이러한 발견 사항이 기존 CASB의 보안 발견 항목과 함께 표시되고, 카테고리와 심각도 기준으로 정렬된다고 설명한다. 보안팀은 Claude만 따로 보는 별도 콘솔을 하나 더 관리하기보다, 이미 쓰는 SaaS 보안 검토 흐름 안에서 Claude 관련 위험을 triage하고 담당자를 배정할 수 있다.
AI Gateway·DLP·Access와 함께 볼 때의 의미
이번 연동은 Cloudflare의 AI 거버넌스 퍼즐 중 “저장된 데이터와 사용 흔적”을 다루는 조각에 가깝다. Cloudflare는 AI Gateway로 모델 요청, 토큰 비용, 성능, 라우팅을 관찰하고, Gateway와 DLP로 민감 정보가 모델에 전달되기 전 차단할 수 있다고 설명한다. Access와 MCP server portals는 에이전트가 내부 도구에 접근할 때 사용자와 에이전트별 접근 제어와 감사 로그를 제공한다.
CASB의 Claude 연동은 그 뒤에 남는 질문을 다룬다. 이미 Claude Enterprise 안에 만들어진 프로젝트, 업로드된 파일, 채팅 내용, 생성물이 정책을 위반하지 않았는지 확인하는 것이다. 즉 인라인 차단, 접근 제어, 저장 데이터 감사를 나눠 생각해야 한다. 한 가지 제품명을 켰다고 AI 사용 리스크가 사라지는 구조가 아니다.
적용 전 확인할 점
- 읽기 권한 범위: Cloudflare는 Claude Enterprise에서 조직, 프로젝트, 채팅, 역할, 메시지, 업로드 파일을 읽는 전용 read-only endpoint를 사용한다고 설명한다. 보안팀은 어떤 데이터가 읽히고 어디에 표시되는지 내부 개인정보·노무·법무 기준과 맞춰야 한다.
- DLP 정책 품질: 민감정보 탐지 규칙이 너무 느슨하면 놓치고, 너무 강하면 정상적인 AI 활용까지 경보로 덮인다. 주민번호·카드번호 같은 정형 데이터와 소스 코드·API 키·고객명 같은 조직별 패턴을 분리해 튜닝해야 한다.
- 대응 권한: Cloudflare는 CASB에서 발견한 Claude 위험을 Gateway 정책으로 이어가 특정 사용자 업로드 차단, 앱 접근 제한, 기능 제한으로 바꿀 수 있다고 설명한다. 자동 차단을 바로 켜기보다 경보→검토→제한 순서를 정해야 업무 중단을 줄일 수 있다.
- Claude Platform 범위: 발표문은 Claude Platform에 대해서는 멤버·워크스페이스 변경, API 키 생성, 파일 생성·다운로드 이벤트를 계속 제공하고, Activity Feed 지원을 추가할 예정이라고 밝힌다. Enterprise와 Platform에서 보이는 데이터가 같다고 가정하면 안 된다.
- 감사 로그 보존: AI 보안 발견은 사고 대응 때 맥락이 중요하다. 누가 어떤 프로젝트를 열었고, 어떤 파일을 올렸고, 어떤 정책이 언제 적용됐는지 보존 기간과 열람 권한을 정해둬야 한다.
작은 파일럿 설계
- Claude Enterprise의 일부 부서나 민감도가 낮은 워크스페이스부터 Compliance API 접근을 요청한다.
- Cloudflare Zero Trust 대시보드의 Integrations > Cloud & SaaS에서 Anthropic 연동을 추가하고 Compliance API 키를 등록한다.
- 고객 개인정보, 내부 계약서, API 키, 소스 코드 조각처럼 실제 조직에서 문제가 되는 패턴을 DLP 프로필로 나눠 설정한다.
- 첫 1~2주는 자동 차단보다 관찰 모드로 경보 품질을 본다. 오탐이 많은 규칙, 반복적으로 위험 파일을 올리는 팀, 권한이 넓은 프로젝트를 분리해 기록한다.
- 경보가 실제 정책 위반으로 확인된 경우에만 Gateway 정책과 연결해 업로드 제한이나 앱 접근 제한을 적용한다.
한계와 리스크
이 연동은 승인된 Claude 사용을 더 잘 보게 해주지만, 모든 AI 사용을 자동으로 통제하지는 않는다. 직원이 개인 계정이나 다른 AI 도구로 민감 정보를 옮기는 경우에는 네트워크·브라우저·ID 계층의 별도 제어가 필요하다. 또한 Compliance API로 읽어오는 데이터 자체가 민감할 수 있으므로, Cloudflare 대시보드 접근 권한과 감사 로그 열람 권한도 최소 권한 원칙으로 관리해야 한다.
또 하나의 리스크는 “보이는 것”과 “막는 것”의 시간차다. CASB가 발견한 항목은 이미 업로드되었거나 생성된 데이터일 수 있다. 따라서 사후 발견만으로 충분하다고 보면 안 되고, AI Gateway·DLP·Access 같은 사전 제어와 함께 배치해야 의미가 있다. 반대로 모든 경보를 즉시 차단으로 연결하면 개발·지원·분석 업무의 정상적인 AI 활용이 막힐 수 있다.
ActualStack 관점의 결론
Cloudflare CASB의 Claude Compliance API 지원은 기업용 AI 도입이 “사용 허용” 단계에서 “감사 가능한 운영” 단계로 넘어가고 있음을 보여준다. 특히 Claude를 이미 업무 도구로 쓰는 조직이라면, 누가 어떤 프로젝트와 파일을 공유하고 어떤 메시지·결과물이 DLP 정책에 걸리는지 확인할 수 있는 통제면이 필요하다.
다만 이 기능은 보안팀용 가시성 도구이지, AI 리스크를 단번에 없애는 스위치가 아니다. API 권한 범위, DLP 규칙 품질, 자동 대응의 강도, 로그 보존 정책을 함께 설계해야 한다. 가장 현실적인 접근은 제한된 부서에서 관찰 모드로 시작해 오탐을 줄이고, 반복 위험이 확인된 영역부터 Gateway 정책으로 좁게 막는 것이다.