Cloudflare, Workers 접근 권한을 하나의 거대한 권한 목록 대신 역할과 범위로 분리하다

더 많은 팀과 자율 코딩 에이전트가 Cloudflare의 Developer Platform에 직접 배포하기 시작하면서, 기존 권한 모델은 불편한 선택을 강요했다. 즉, 에이전트가 계정 내 모든 Worker, 데이터베이스, 버킷에 접근할 수 있게 하는 광범위한 계정 전체 역할을 부여하거나, 모든 경우를 커버할 수 있을 만큼 개별 권한을 직접 구축해야 했는데, 이는 리소스와 작업의 수가 늘어날수록 관리가 불가능해진다.

Cloudflare의 해결책은 접근 권한을 하나의 평면적인 목록으로 취급하지 않고, 대신 두 개의 독립적인 차원을 정의하는 것이었다. 네 가지 역할 — Metadata Read-Only, Content Read-Only, Editor, Admin — 은 코드를 보지 않고 로그와 지표를 조회하는 것부터, 코드를 편집하지 않고 읽는 것, 삭제하지 않고 편집하는 것, 완전한 제어에 이르기까지 역량 수준을 설명한다. 이와 별도로, 각 역할은 세 가지 범위 중 하나에 적용될 수 있다. 즉, Developer Platform의 모든 리소스, 하나의 제품에 속한 모든 리소스(모든 Workers), 또는 이름이 지정된 단일 리소스(특정 Worker 하나)이다.

두 축은 독립적으로 조합된다. CI/CD 파이프라인은 Editor 역할을 배포 대상인 정확히 하나의 Worker로 범위를 한정하여 부여받을 수 있어, 토큰이 유출되더라도 해당 Worker를 업데이트할 수는 있지만 삭제하거나 다른 애플리케이션에 접근할 수는 없다. 디버깅 에이전트는 Metadata Read-Only를 하나의 Worker로 범위를 한정하여 부여받을 수 있어, 소스 코드를 전혀 읽지 않고도 로그와 트레이스를 검사할 수 있다. Cloudflare는 동일한 역할×범위 구조를 나중에 D1 데이터베이스와 R2 버킷 같은 다른 Developer Platform 리소스로 확장할 수 있도록 설계했으며, 제품마다 새로운 권한을 새로 만들어내지 않도록 했다.

'무엇을 할 수 있는가'(역할)와 '어디에서 할 수 있는가'(범위)를 두 개의 독립적인 축으로 분리

네 가지 역할과 세 가지 범위를 조합하면 작고 고정된 어휘로 열두 가지의 정밀한 접근 수준이 만들어지며, 리소스마다 일회성 권한이 조합적으로 폭발하는 일이 없다.

단일 리소스(Worker 하나)로 범위를 한정하면 침해되었거나 잘못 구성된 에이전트 토큰의 영향 범위가 제한된다. 즉, 계정 내 다른 리소스를 보거나 접근할 수 없다.

동일한 역할/범위 구조는 매번 모델을 재설계하지 않고도 다른 제품(D1, R2, KV)으로 확장할 수 있도록 구축되었다.

Durable Objects는 자체 권한 시스템이 필요하지 않고 상위 Worker의 역할에서 접근 권한을 상속받아, 모델이 더 이상 분절되지 않도록 한다.

에이전트가 늘어나면서 접근 권한 요구가 증가할 때는 개별 권한을 더 추가하지 말고, 접근 제어를 역량과 범위라는 두 개의 직교 축으로 분리하여 곱해지는 대신 조합되도록 하라.

Cloudflare는 또한 어떤 권한이 누락되었는지 설명하는 문서로 직접 연결되는 상황별 403 오류 응답을 추가하여, 권한 장벽에 부딪힌 에이전트나 개발자가 일반적인 'Forbidden' 응답에 막히지 않고 스스로 수정할 수 있도록 했다. 회사는 동일한 역할 및 범위 모델을 다음으로 D1 데이터베이스, R2 버킷, KV 네임스페이스로 확장할 계획이라고 밝혔다.