Claude Enterprise Tenant Restrictions 설정: 개인 계정 접속을 막고 승인된 조직만 여는 법
TL;DR
Tenant Restrictions는 회사 네트워크에서 승인한 Claude 조직만 접근하도록 제한하는 기능입니다. 프록시가
anthropic-allowed-org-ids
헤더를 요청마다 덮어씁니다. 그러면 Anthropic이 허용 목록에 없는 조직 접근을 막습니다. 설정 저장으로 끝내지 말고 승인 조직의 정상 업무와 미승인 조직의 403 차단, 잘못된 헤더의 400 응답을 각각 확인해야 합니다.
이 글의 첫 완료 범위는 제한된 비민감 테스트 네트워크에서 양쪽 결과를 기록하는 데까지입니다. 실제 운영 조직 UUID, 인증값, 고객 데이터, 전사 프록시 배포는 별도 승인 없이 테스트 자료나 프롬프트에 넣지 않습니다.
핵심 3줄 요약
핵심 1
핵심 1: Enterprise 플랜 구성원과 Console 조직에서 사용할 수 있습니다. 회사 네트워크의 개인 계정·미승인 조직 사용을 제한합니다.
핵심 2
핵심 2: 프록시는 Claude 관련 요청에 허용 조직 UUID 헤더를 주입합니다. 같은 이름의 헤더를 추가하지 않고 매 요청마다 덮어써야 합니다.
핵심 3
핵심 3: 승인 조직 성공, 미승인 조직의 403, 헤더 구성 오류의 400, 대표 정상 업무 유지를 함께 확인해야 완료입니다.
이 글에서 다룰 내용
이 글은 Tenant Restrictions의 정의, 제공 범위, 조직 ID 확인 경로, 프록시 헤더 규칙, 제한 네트워크에서의 양방향 테스트, 오류 판정과 복구 기준을 차례로 다룹니다. 설정값을 공개 문서에 복사하거나 실제 운영 프록시를 바로 변경하는 방법은 다루지 않습니다.
읽고 나면 관리자는 네트워크 제한을 계정 권한이나 데이터 유출 방지 기능과 구분할 수 있습니다. 허용과 차단을 한 쌍으로 검증하는 내부 체크리스트도 만들 수 있습니다.
Tenant Restrictions는 무엇인가
Tenant Restrictions는 회사 네트워크의 Claude 요청을 승인된 조직 계정으로 제한하는 네트워크 수준 접근 제어입니다. 공식 도움말에 따르면 Enterprise 플랜 구성원과 Console 조직에서 사용할 수 있습니다. Enterprise 환경의 IT 관리자는 이 기능으로 회사 네트워크에서 개인 계정이나 승인되지 않은 조직을 사용하는 것을 막을 수 있습니다.
네트워크 프록시는 Claude로 향하는 요청에
anthropic-allowed-org-ids
헤더를 주입합니다. Anthropic은 헤더의 조직 UUID 목록을 확인한 뒤 허용 목록에 없는 조직의 접근을 차단합니다. 이 규칙은 웹, 데스크톱·앱, API 키 인증, OAuth 토큰 인증에 적용됩니다.
이 기능은 사용자 한 명의 Claude 설정을 바꾸는 기능이 아닙니다. 조직이 관리하는 네트워크 경로에서 프록시 정책을 적용하는 기능입니다. 제한을 구성하지 않은 네트워크에는 영향이 없습니다. 그곳에서는 표준 인증이 계속됩니다. 회사 네트워크 밖의 개인 계정까지 자동으로 차단한다고 설명하면 안 됩니다.
또한 Tenant Restrictions는 데이터 분류, 파일 권한, SSO, MFA, 기기 관리, DLP를 대신하지 않습니다. 승인된 조직에 들어갔다고 해서 그 사용자가 모든 프로젝트·대화·연결 앱을 볼 수 있는 것도 아닙니다. 계정 인증과 조직 내부 권한은 별도로 검토해야 합니다.
언제 설정하면 좋은가
회사 네트워크에서 Claude Enterprise나 Claude Console의 승인 조직만 사용하게 해야 할 때 적합합니다. 예를 들어 업무 자료가 개인 Claude 계정이나 승인되지 않은 파트너 조직으로 이동하는 경로를 줄이려는 경우입니다. 네트워크 프록시를 중앙에서 관리하고 TLS 검사 정책을 검토할 수 있는 조직에서 적용을 고려할 수 있습니다.
반대로 모바일 통신망, 개인 테더링, 관리되지 않는 외부 네트워크까지 같은 결과를 기대한다면 이 기능 하나로는 부족합니다. 공식 도움말은 Tenant Restrictions가 구성되지 않은 네트워크에 영향을 주지 않는다고 밝힙니다. 적용 범위는 관리하는 프록시를 통과하는 네트워크로 한정해 설명해야 합니다.
관리자 역할이나 제품별 메뉴 이름도 임의로 늘리지 않습니다. 공식 문서는 Enterprise의 IT 관리자와 Console 조직을 설명합니다. 하지만 특정 프록시 제품의 실제 관리자 역할이나 승인 절차까지 대신 정의하지는 않습니다. 변경 소유자, 승인자, 네트워크 담당자, 복구 담당자는 조직 내부 정책으로 별도 기록합니다.
변경 전에 기록할 항목
대상 네트워크와 승인 조직부터 구분해 적습니다. 내부 검토본에는 실제 UUID 대신
승인 조직 A
,
승인 조직 B
처럼 레이블을 씁니다. 실제 값은 접근이 제한된 변경 기록에만 둡니다. 테스트에는 실데이터가 없는 전용 계정을 사용합니다.
조직 ID 확인 경로는 표면에 따라 다릅니다. Enterprise 구성원은
Settings > Account > Organization ID
또는
Organization settings > Organization
페이지 하단에서 확인할 수 있습니다. Console 조직 구성원은
Settings > Organization
에서 확인합니다. 표시 이름이나 회사명을 UUID 대신 사용하지 않습니다.
프록시 범위도 기록합니다. 공식 도움말의 구성 예시는
claude.ai
,
api.anthropic.com
,
claude.com
,
anthropic.com
을 대상으로 제시합니다. TLS inspection이 필요하다고 명시되어 있으므로, 인증서 배포와 사내 보안 정책의 준비 여부를 변경 전에 확인합니다. 글에서는 특정 프록시 제품의 메뉴를 일반화하지 않습니다.
성공 기준은 허용과 차단으로 나눠 씁니다. 승인 조직은 제한된 네트워크에서 비민감 테스트와 대표 정상 업무를 수행할 수 있어야 합니다. 미승인 조직은 같은 네트워크에서 403
tenant_restriction_violation
으로 차단되어야 합니다. 헤더 자체가 잘못 구성됐다면 400 오류로 따로 기록합니다.
따라 하는 7단계
1단계: 변경 소유자와 완료 경계를 정합니다
변경 소유자, 독립 승인자, 네트워크 담당자, 테스트 사용자, 복구 담당자를 먼저 기록합니다. 테스트는 비민감 전용 계정과 비민감 요청으로 제한합니다. 운영 UUID, API 키, OAuth 토큰, 세션값, 고객 데이터는 공개 문서나 AI 프롬프트에 넣지 않습니다.
첫 완료 범위는 전사 적용이 아닙니다. 제한된 테스트 네트워크에서 승인 조직과 미승인 조직의 결과를 비교합니다. 대표 정상 업무가 유지되는지 확인한 내부 검증 기록까지가 완료 범위입니다. 광범위한 배포는 검증 결과를 사람이 승인한 뒤 별도 변경으로 진행합니다.
2단계: 조직 ID와 허용 범위를 확인합니다
Enterprise 또는 Console의 공식 경로에서 Organization ID를 확인합니다. 내부 체크리스트에는 실제 UUID를 복사하지 않고 레이블과 보관 위치만 적습니다. 여러 조직을 허용한다면 각 조직의 소유자와 필요 근거를 분리합니다.
헤더 값은 쉼표로 구분한 organization UUID 목록이며 값 사이에 공백을 두지 않습니다. 항목을 늘릴수록 허용 범위가 넓어지므로, 파트너 조직이나 테스트 조직을 관성적으로 포함하지 않습니다. 목적이 끝난 조직은 별도 승인 후 제거할 대상으로 기록합니다.
3단계: 프록시 규칙을 변경안으로 만듭니다
프록시 규칙의 목적은 Claude 요청에
anthropic-allowed-org-ids
를 주입하는 것입니다. 공식 구성 예시에 나온 대상 도메인과 TLS inspection 요구를 변경안에 적습니다. 특정 제품의 화면 이름이나 클릭 경로는 해당 프록시의 현재 문서에서 따로 확인합니다.
같은 이름의 헤더가 요청에 이미 있어도 값을 덧붙이지 않습니다. 프록시는 매 요청에서 관리자가 승인한 값으로 헤더를 덮어써야 합니다. 동일 헤더가 한 요청에 여러 번 나타나면 400 구성 오류가 날 수 있습니다.
4단계: 긴 허용 목록의 형식을 검토합니다
한 줄에 목록이 들어가지 않으면 공식 continuation header 형식을 사용합니다. 기본 헤더에
;n=K
로 전체 줄 수를 선언합니다. 뒤쪽 값은 번호가 붙은 헤더에 나눕니다. 공식 도움말의 현재 제한은 최대 10개 헤더 줄과 전체 500개 organization UUID입니다.
선언한 슬롯은 모두 요청에 있어야 합니다. 예를 들어 세 줄을 선언하고 한 줄이 빠지면 허용 여부를 추측하지 않고 헤더 구성 오류로 처리합니다. 이 글의 프롬프트에는 실제 UUID나 완성된 운영 헤더를 만들게 하지 않습니다.
5단계: 제한된 네트워크에 검토용 정책을 적용합니다
독립 승인자가 변경안, 허용 조직 레이블, 테스트 범위, 복구 조건을 확인한 뒤에만 검토용 정책을 적용합니다. 운영 전면 배포가 아니라 되돌릴 수 있는 제한된 범위에서 시작합니다. 공식 문서가 특정 프록시 제품의 staged rollout 기능을 보장하지 않으므로, 조직이 실제로 가진 배포 수단만 사용합니다.
적용 뒤 헤더가 보인다는 이유만으로 성공을 선언하지 않습니다. 헤더가 정확해도 승인 조직의 인증이나 내부 권한은 별도로 실패할 수 있습니다. 웹 화면이 열렸더라도 미승인 조직 차단이 작동했다는 뜻은 아닙니다.
6단계: 허용과 차단을 양쪽에서 검증합니다
같은 제한 네트워크에서
승인 조직 A
의 비민감 테스트를 실행합니다. 로그인 또는 인증 후 대표 정상 업무가 성공하는지 기록합니다. 이어서
미승인 조직 B
또는 비민감 개인 테스트 계정으로 같은 범위의 접근을 시도합니다. 이때 403과
tenant_restriction_violation
을 확인합니다.
잘못된 구성도 별도로 구분합니다. 같은 헤더가 중복되거나
;n=K
가 잘못되었거나 선언한 continuation 슬롯이 빠지면 400 오류가 날 수 있습니다. 이 결과는 보안 정책이 미승인 조직을 차단한 403과 같은 통과로 처리하지 않습니다.
7단계: 정상 업무와 복구 조건을 대조합니다
승인 조직에서 대표 정상 업무가 계속되는지 다시 확인합니다. 웹만 확인하고 데스크톱·앱이나 API 키·OAuth 인증 범위를 모두 통과했다고 일반화하지 않습니다. 조직이 실제로 사용하는 표면만 비민감 fixture로 각각 검증합니다.
승인 조직이 막히거나 미승인 조직이 열리거나 헤더 구성 오류가 남으면 배포를 확대하지 않습니다. 변경 전 상태로 복구합니다. 어떤 네트워크·인증 표면·조직 레이블에서 어떤 상태 코드가 나왔는지도 기록합니다. 사람이 결과를 검토하고 승인할 때까지 완료로 표시하지 않습니다.
그대로 복사해 쓸 프롬프트
목표: Claude Tenant Restrictions 변경안을 실제 적용 전에 검토하고 허용·차단 양쪽 테스트 표를 만든다.
허용 입력: 대상 네트워크 레이블, 승인 조직 레이블, 사용 인증 표면, 변경 소유자, 승인자, 복구 담당자, 예상 상태 코드.
제외 입력·금지 작업: 실제 organization UUID, 인증값·토큰·세션값, 고객 데이터, 운영 프록시 직접 변경, 전사 배포, 외부 공유.
출력 형식: 변경 전 상태, 허용 조직 테스트, 미승인 조직 테스트, 헤더 오류 테스트, 정상 업무 확인, 결과, 확인 필요, 승인자 표.
완료 기준: 승인 조직은 비민감 정상 업무 성공, 미승인 조직은 403 tenant_restriction_violation, 잘못된 헤더는 400으로 분리되고 복구 조건과 승인자가 기록되어 있다.
추정 금지: 실제 UUID와 헤더값, 프록시 제품 메뉴, 지원되지 않은 네트워크 범위, DLP·SSO·MFA 효과, 데이터 권한과 정확성.
승인 지점: 변경안 작성 뒤 네트워크 적용 전, 제한 테스트 결과 확인 뒤 배포 확대 전 각각 사람 승인을 받는다.
이 프롬프트는 운영 헤더를 생성하거나 적용하는 지시가 아닙니다. 민감값이 없는 변경 검토표를 만들기 위한 것입니다. 실제 값은 조직의 승인된 변경 시스템에서만 다룹니다.
실전 활용 팁
403과 400은 같은 실패가 아닙니다. 403
tenant_restriction_violation
은 조직이 허용 목록에 없어 차단된 결과입니다. 400은 중복 헤더, 잘못된
;n=K
, 빠진 continuation 슬롯, 허용 목록 제한 초과 같은 구성 문제일 수 있습니다. 두 오류를 나눠 기록하면 네트워크 담당자가 정책 판정과 문법 오류를 더 빨리 구분할 수 있습니다.
검증 표에는
네트워크 레이블
,
인증 표면
,
조직 레이블
,
예상 결과
,
실제 상태
,
오류 코드
,
대표 정상 업무
,
검토자
,
판정
을 둡니다. 판정은
통과
,
실패
,
확인 필요
로 제한합니다. 화면이 열렸다는 설명만으로 통과하지 않습니다. 승인 조직의 정상 업무와 미승인 조직의 차단을 모두 확인합니다.
관리되지 않는 네트워크는 별도 범위로 남깁니다. 공식 문서는 Tenant Restrictions를 구성하지 않은 네트워크의 표준 인증이 계속된다고 설명합니다. 외부 네트워크까지 차단해야 한다면 Tenant Restrictions가 아닌 별도 접근·기기·네트워크 정책 검토가 필요합니다.
주의할 점
실제 조직 UUID와 인증값을 복사 가능한 예시에 넣지 마세요. 조직 ID는 계정 비밀번호와 같지는 않지만 운영 구조를 드러내는 식별자입니다. 공개 원고와 AI 프롬프트에는 레이블만 씁니다. 실제 값은 접근이 제한된 변경 기록에서 관리합니다.
Tenant Restrictions를 모든 보안 문제의 해결책으로 설명하면 안 됩니다. 이 기능은 승인 조직 계정의 범위를 네트워크에서 제한합니다. 조직 안의 프로젝트 권한, 연결 앱 권한, 대화 공유, 파일 분류, 데이터 보존, SSO·MFA, 기기 상태는 별도 통제입니다.
공식 도움말의 프록시 플랫폼 목록은 지원 예시이지 모든 제품의 동일한 메뉴를 보장하는 목록이 아닙니다. Cato Networks, Cloudflare Zero Trust, Netskope, Palo Alto Prisma Access, Zscaler ZIA와 일반 HTTPS 프록시가 언급됩니다. 실제 설정 경로와 호환성은 각 제품의 현재 문서와 조직 정책에서 확인합니다.
마지막으로 미승인 조직 차단만 확인하고 끝내지 않습니다. 보안 변경이 정상 업무를 깨뜨릴 수 있으므로 승인 조직의 웹·앱·API·OAuth 중 실제 사용 표면을 따로 검증합니다. 한 표면의 성공을 나머지 표면의 성공으로 확대 해석하지 않습니다.
자주 묻는 질문
개인 Claude 계정은 어디서나 차단되나요?
아닙니다. 공식 문서는 Tenant Restrictions가 구성된 회사 네트워크에서 승인 조직만 접근하도록 한다고 설명합니다. 제한을 구성하지 않은 네트워크에는 영향이 없고 표준 인증이 계속됩니다. 회사 밖의 네트워크까지 자동 차단한다고 표현하면 안 됩니다.
IP allowlisting과 같은 기능인가요?
아닙니다. IP allowlisting은 어떤 출발지 IP가 조직에 접근할 수 있는지 제한합니다. Tenant Restrictions는 관리 네트워크에서 어떤 Claude 조직 계정을 사용할 수 있는지 헤더로 제한합니다. 출발지 네트워크와 허용 조직이라는 통제 대상이 다릅니다.
403이 나오면 설정이 정상이라는 뜻인가요?
항상 그렇지는 않습니다. 미승인 조직에서
tenant_restriction_violation
403이 나왔다면 예상한 차단 결과일 수 있습니다. 승인 조직에서 같은 오류가 나면 허용 목록이나 조직 ID를 확인해야 합니다. 중복·누락·잘못된 continuation header는 400 구성 오류로 분리합니다.
기존 API 키 인증은 바뀌나요?
공식 도움말은 Tenant Restrictions가 구성되지 않은 네트워크에서 기존 API 키 인증이 그대로이고 표준 인증이 계속된다고 설명합니다. 제한 네트워크에서는 API 키 인증도 지원 표면에 포함되므로 승인 조직 여부를 검증합니다. API 키 권한과 보관 정책 자체는 별도로 관리합니다.
출처
마무리
Tenant Restrictions는 회사 네트워크에서 승인된 Claude 조직만 쓰게 하는 기능입니다. 헤더 한 줄을 추가했다고 끝나는 작업은 아닙니다. 조직 ID를 확인합니다. 프록시가 매 요청에서 헤더를 덮어쓰게 한 뒤 승인 조직의 정상 업무와 미승인 조직의 차단을 한 테스트 계획에서 검증해야 합니다.
처음에는 비민감 fixture와 제한된 범위로 결과를 확인하세요. 403 정책 차단과 400 구성 오류를 나눕니다. 정상 업무가 유지되는지까지 확인한 뒤 사람이 배포 확대를 승인해야 합니다. 이 순서를 지키면 보안 강화가 업무 중단이나 잘못된 완료 판정으로 이어지는 위험을 줄일 수 있습니다.
