Cloudflare AI Gateway, 인증을 켜면 다시 끌 수 없습니다

Cloudflare로 AI 서비스를 연결할 때 인증은 이제 새 게이트웨이의 기본 조건입니다. 새로 만드는 AI Gateway는 인증이 필수이고, 한 번 켜면 다시 끌 수 없습니다. Cloudflare가 11월 3일 발표한 변경입니다. 다만 기존에 인증 없이 쓰던 게이트웨이는 그대로 사용할 수 있어, 모든 연결이 한꺼번에 끊기는 변경은 아닙니다. 공식 발표

누구의 요청인지, 입구에서 확인합니다

AI Gateway는 앱과 AI 서비스 사이에서 요청을 관리하는 통로입니다. 인증은 이 통로를 사용할 자격이 있는지 검사합니다. Cloudflare는 허가되지 않은 접근과 잘못된 요청으로 로그 저장 사용량이 늘어나는 일을 막기 위한 조치라고 설명합니다. AI 답변의 정확성을 높이는 기능보다, 호출 경로를 운영하는 사람이 챙겨야 할 변화입니다. 인증 문서

기존 게이트웨이를 전환할 때는 순서가 중요합니다. 먼저 연결된 HTTP 클라이언트가 유효한 토큰을 보내도록 준비하고, 그다음 인증을 켜야 합니다. 켠 뒤 오류가 나도 인증을 다시 끄는 방법으로 복구할 수 없습니다. API에서도 인증된 게이트웨이를 끄려는 요청은 HTTP 400으로 거절됩니다. 운영에서는 설정 버튼보다 연결된 앱의 준비 상태를 먼저 볼 이유입니다. 전환 조건

켜기 전에 연결 준비가 필요한 이유

아래 공식 발표는 인증을 끌 수 없다는 변경과, 기존 HTTP 클라이언트부터 토큰을 보내도록 준비해야 한다는 조건을 함께 안내합니다.

주소가 다르면, 인증을 보내는 방식도 다릅니다

외부 앱에서 HTTP로 호출한다면 요청 주소부터 구분하세요. api.cloudflare.com의 REST API는 Authorization 헤더를, gateway.ai.cloudflare.com의 공급자별 연결 경로는 cf-aig-authorization 헤더를 사용합니다. 헤더는 요청에 붙이는 인증 정보 칸입니다. 기존 예제의 주소와 새 문서의 헤더를 섞어 적용하면 연결이 맞지 않을 수 있습니다. 경로별 안내

Cloudflare Worker에서 바인딩으로 연결한 요청은 다릅니다. 바인딩은 Worker와 서비스를 연결하는 기능이며, 이 경로는 같은 계정 안에서 미리 인증됩니다. 따라서 cf-aig-authorization 헤더를 직접 넣지 않아도 됩니다. 외부 서버의 HTTP 호출과 Worker 바인딩을 한 가지 연결 방식으로 보고 일괄 수정하면 불필요한 작업이 생길 수 있습니다. 바인딩 동작

인증했다고, 게이트웨이 하나에만 권한이 생기지는 않습니다

11월 4일 갱신된 공식 문서는 토큰의 범위도 경고합니다. AI Gateway Run 권한은 게이트웨이 하나로 제한되지 않고 계정 안의 모든 게이트웨이에 요청할 수 있습니다. 저장된 공급자 키를 사용하는 BYOK 게이트웨이도 포함됩니다. 고객별 게이트웨이를 나눴다고 토큰 권한까지 고객별로 격리됐다고 판단하면 안 됩니다. 권한 범위

가령 쇼핑몰 상담 앱과 사내 문서 요약을 같은 계정에서 운영한다고 가정해 보겠습니다. 상담용 게이트웨이에서 인증에 성공했다는 사실만으로 그 토큰의 권한이 상담용에 한정되지는 않습니다. 전환 시험에서는 정상 요청이 통과하는지뿐 아니라 인증 정보가 없는 요청이 거절되는지, 어떤 서비스가 같은 계정과 토큰을 공유하는지도 살펴야 합니다. 실제 도입 사례가 아닌, 공식 조건을 풀어 쓴 예시입니다.

지금 할 일은 연결 경로를 적어 보는 것입니다. 새 게이트웨이인지 기존 것인지, HTTP 호출인지 바인딩인지, 토큰을 어디서 보관하고 어떤 서비스가 공유하는지부터 구분하세요. 그다음 시험 환경에서 인증 동작을 확인하고 운영 전환을 정하는 순서를 제안합니다. 인증을 켜는 일과 접근 범위를 나누는 일까지 함께 준비해야, 보안 설정이 정상 서비스를 멈추는 원인이 되는 일을 줄일 수 있습니다.

이어서 읽어볼 만한 뉴스

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