AI에게 처음부터 모든 권한을 줄 필요는 없다…Cloudflare MCP 추가 승인

AI에게 웹 운영을 맡겨 보려는데, 연결 단계부터 넓은 계정 권한을 허용하라는 화면이 나오면 망설이게 됩니다. Cloudflare는 2026년 10월 19일 API MCP 서버에 단계별 권한 승인(step-up authorization)을 도입했습니다. 처음에는 필요한 범위로 시작하고, 작업 중 부족한 권한이 생기면 추가 승인을 요청하는 방식입니다. 다만 이를 지원하는 MCP 클라이언트에서만 사용할 수 있습니다. 공식 발표

이번 변화의 핵심은 AI가 더 많은 일을 할 수 있게 됐다는 데 있지 않습니다. 무엇을 맡길지 충분히 정하지 않은 상태에서, 앞으로 쓸지도 모르는 권한까지 한꺼번에 허용할 필요를 줄였다는 데 있습니다.

연결할 때가 아니라, 필요한 작업을 만났을 때 묻습니다

MCP는 AI 도구와 외부 서비스의 기능을 연결하는 규약입니다. 연결이 성립했다고 모든 작업이 허용되는 것은 아닙니다. 어떤 데이터와 기능에 접근할 수 있는지는 승인한 권한 범위, 즉 scope에 달려 있습니다.

Cloudflare의 공식 안내에 따르면 연결 동의 화면에서 Minimal을 선택해 작은 권한 범위로 시작할 수 있습니다. 이후 도구 호출에 필요한 권한이 부족하면 서버는 insufficient_scope 응답으로 필요한 범위를 알립니다. 이를 지원하는 클라이언트가 사용자에게 추가 승인을 요청하며, 기존에 승인한 권한은 유지됩니다. 동작과 제공 조건

운영자가 판단하는 시점이 달라지는 셈입니다. 처음 연결할 때 앞으로 필요한 권한을 모두 예상하기보다, 실제 요청한 업무와 추가 권한의 관계를 보고 결정할 여지가 생깁니다. 예를 들어 조회 중심으로 쓰던 연결에 변경 작업을 맡기려 한다면, 그 변경에 필요한 접근 범위를 검토하는 계기로 삼을 수 있습니다. 이는 동작을 설명하기 위한 가상 업무 상황이며, 특정 도구의 권한 조합을 직접 시험한 결과는 아닙니다.

‘추가 권한 승인’과 ‘매번 실행 승인’은 다릅니다

여기서 가장 주의할 부분은 이미 승인한 권한이 유지된다는 점입니다. 작업 하나가 끝날 때마다 허용 범위가 자동으로 초기화되거나, 모든 API 호출을 사람이 승인하는 기능으로 이해하면 안 됩니다.

권한 부여는 해당 범위의 작업을 할 수 있도록 문을 여는 결정입니다. 실제 변경 내용을 검토하고 한 번의 실행을 승인하는 절차는 별도로 설계해야 합니다. 따라서 이 기능만으로 삭제·배포 같은 중요한 작업의 실행 통제가 모두 갖춰졌다고 볼 수는 없습니다.

Cloudflare의 MCP 인증 문서도 인증과 권한 부여를 구분하고, 허용된 권한을 도구 실행 시 검사하는 구조를 설명합니다. 연결에 성공했는지와 해당 요청이 허용되는지는 다른 질문입니다. Cloudflare MCP 권한 부여 문서

운영팀이 얻는 선택지와 남아 있는 부담

현재 확인되는 변화는 Cloudflare API를 AI 도구에 연결하는 개발자와 운영팀이 초기 권한을 작게 시작하고 필요할 때 넓힐 수 있다는 점입니다. 특정 클라이언트 이름이나 버전별 지원 목록은 이번 공식 발표만으로 확정할 수 없습니다. 평소 쓰던 앱이 MCP 연결을 지원한다는 사실만으로 이 승인 흐름까지 지원한다고 판단해서는 안 됩니다.

VECTORLOG는 이를 AI 연결을 시험하는 단계에서 업무 범위를 더 구체적으로 정할 기회로 봅니다. 처음부터 운영 계정 전반을 맡기기보다, 작은 작업을 정하고 그 작업에 필요한 권한만 검토하는 접근과 잘 맞기 때문입니다.

다만 승인 화면이 있다는 이유만으로 위험이 사라지는 것은 아닙니다. 요청 범위를 이해하지 못한 채 계속 승인하면 권한은 다시 넓어질 수 있습니다. 이미 허용한 범위가 유지되는 만큼 누적 권한을 관리하는 책임도 남습니다. 보안 사고 감소나 생산성 개선 효과를 수치로 단정할 근거는 이번 발표에 없습니다.

도입 전에는 ‘지원 여부, 거절 동작, 남은 권한’을 보세요

다음은 공식 설명을 바탕으로 VECTORLOG가 제안하는 확인 순서입니다. 직접 완료한 테스트나 도입 성과가 아닙니다.

먼저 사용하는 클라이언트의 문서에서 step-up authorization 지원 여부를 확인하세요. 지원이 확인되지 않으면 연결만 성공한 상태를 도입 완료로 보지 않는 것이 좋습니다. 추가 권한이 필요할 때 안내와 승인 절차를 처리할 수 있어야 이번 기능의 의미가 살아납니다.

그다음 실제 운영 데이터에 영향을 주지 않는 시험 환경에서 작업을 나누세요. 처음 허용한 범위 안의 작업과 추가 권한이 필요한 작업을 구분하고, 요청 화면이 업무 목적에 맞는 범위를 설명하는지 살펴보는 방식입니다. 승인을 거절했을 때 작업이 멈추고 불필요한 변경이 일어나지 않는지도 확인 대상입니다. 시험을 통과시키려고 곧바로 넓은 권한을 주는 것은 최소 권한으로 시작하려는 목적과 어긋납니다.

마지막으로 승인 이후 남아 있는 접근 범위를 점검할 담당자와 시점을 정하세요. 해당 연결에서 권한을 확인하거나 줄일 수 있는 경로도 따로 확인해야 합니다. 공식 발표가 기존 권한의 유지를 명시한 만큼, 판단 기준은 승인 횟수가 아니라 현재 업무와 허용 범위가 일치하는지입니다.

권한을 여는 단계와 실행을 막는 단계는 별개입니다

관련 글 Cloudflare Cloud Workload Security 베타의 API 실행 정책은 클라우드 API 요청 경로에서 정책을 검사하는 방식을 다뤘습니다. 이번 소식은 MCP 연결에 어떤 권한을 언제 부여할지에 관한 변화입니다. 두 기능이 자동으로 통합되거나 서로를 대체한다고 확인된 것은 아닙니다.

앞으로 지원 클라이언트가 필요한 권한과 그 이유를 명확하게 보여준다면, 운영팀이 AI 연결을 더 작은 범위로 시험하기 쉬워질 수 있습니다. 이는 클라이언트 구현과 실제 승인·거절 동작에 달린 조건부 전망입니다. 지금 필요한 것은 더 많은 권한을 주는 일이 아니라, AI가 요청한 작업과 허용한 범위를 설명할 수 있는 상태를 만드는 일입니다.