Claude Code 2026년 6월 23일 릴리스에는 조직에서 특히 봐야 할 보안 관련 변경이 포함됐습니다. sandbox.credentials 설정으로 sandboxed command가 credential file과 secret environment variable을 읽지 못하게 막을 수 있고, 조직이 설정한 모델 제한이 model picker, --model, /model, ANTHROPIC_MODEL에 적용됩니다. 제한된 모델을 선택하면 “restricted by your organization's settings” 메시지를 보여줍니다.
이 변화는 단순 옵션 추가가 아닙니다. Claude Code 같은 에이전트형 개발 도구를 회사 코드베이스에 연결할 때 가장 먼저 부딪히는 질문이 “에이전트가 어디까지 볼 수 있나?”이기 때문입니다. 코드만 보는 것과 로컬 credential, secret env, 배포 키, 개인 토큰까지 볼 수 있는 것은 완전히 다른 위험입니다.
이 글은 sandbox.credentials와 모델 제한을 팀 운영에 적용하는 방법을 정리합니다. 보안팀 문서가 아니라 개발팀이 실제로 설정하고 확인할 수 있는 기준으로 씁니다.
전통적인 개발 환경에서는 “개발자 계정이 접근할 수 있는 것은 개발자가 책임진다”는 가정이 많았습니다. 하지만 에이전트형 도구에서는 이 가정이 약해집니다. 개발자는 의도하지 않았지만 에이전트가 터미널 명령을 실행하고, 로그를 읽고, 설정 파일을 열고, 환경 변수를 확인할 수 있기 때문입니다.
문제는 에이전트가 악의적이라는 뜻이 아닙니다. 범위가 넓기 때문입니다. 예를 들어 테스트 실패를 고치라고 했는데 에이전트가 .env, cloud credential, npm token, SSH config를 읽어 원인을 찾으려 할 수 있습니다. 어떤 경우에는 도움이 되지만, 어떤 경우에는 필요 이상의 권한입니다.
그래서 조직 정책은 “우리 팀은 착하니까 괜찮다”가 아니라 “기본적으로 읽지 않아도 되는 것은 막는다”에서 출발해야 합니다. sandbox.credentials는 이 방향에 맞는 설정입니다.
sandbox.credentials의 핵심은 sandboxed command가 credential file과 secret environment variable에 접근하지 못하게 하는 것입니다. 먼저 조직 안에서 credential로 볼 항목을 정의해야 합니다.
보통 다음 항목이 포함됩니다.
.env, .env.local, .env.production개발팀에서 흔히 하는 실수는 “로컬에서만 쓰는 키니까 괜찮다”입니다. 에이전트가 로컬 명령을 실행할 수 있으면 로컬 키도 공격면에 들어갑니다. 특히 MCP 서버, 브라우저 자동화, 원격 세션이 연결된 환경에서는 한 번 노출된 secret이 어디로 흘러가는지 추적하기 어렵습니다.
적용 방식은 단계적으로 가는 것이 좋습니다.
6월 23일 릴리스는 조직 설정 모델 제한을 여러 진입점에 적용합니다. model picker에서만 막는 것이 아니라 --model, /model, ANTHROPIC_MODEL 환경 변수까지 확인한다는 점이 중요합니다. UI에서 막아도 CLI 플래그나 환경 변수로 우회할 수 있으면 조직 정책으로 보기 어렵습니다.
모델 제한은 보통 비용 때문에 시작합니다. 비싼 모델을 아무나 쓰지 못하게 하거나, 특정 팀만 고성능 모델을 쓰게 하는 방식입니다. 하지만 보안 측면도 있습니다.
따라서 모델 제한은 “누가 더 좋은 모델을 쓰느냐”가 아니라 “어떤 데이터가 어떤 모델 경로로 나가도 되는가”의 문제입니다.
실무 기준은 이렇게 나눌 수 있습니다.
보안 설정은 너무 갑자기 강하게 걸면 개발자가 우회로를 찾습니다. 그래서 Claude Code 조직 설정도 개발자 경험을 같이 설계해야 합니다. 제한된 모델을 선택했을 때 메시지가 명확해진 것은 좋은 방향입니다. 하지만 메시지만으로는 부족합니다.
팀 문서에는 최소한 다음 내용을 적어야 합니다.
예를 들어 배포 로그를 분석하려면 cloud CLI 인증이 필요할 수 있습니다. 이때 로컬 장기 credential을 열어 주기보다, 읽기 전용 단기 토큰을 발급하거나, 필요한 로그를 파일로 export해서 에이전트에 제공하는 방식이 낫습니다. 개발자는 문제를 해결할 수 있고, 에이전트는 불필요한 secret을 보지 않습니다.
설정을 켰다고 끝이 아닙니다. 실제로 막히는지 테스트해야 합니다. 가장 좋은 방법은 작은 레드팀 시나리오를 만드는 것입니다. 거창할 필요는 없습니다. 테스트 저장소에 가짜 credential 파일과 환경 변수를 두고, Claude Code sandboxed command가 이를 읽을 수 없는지 확인하면 됩니다.
검증 시나리오는 다음처럼 구성할 수 있습니다.
.env.local에 가짜 API 키를 넣고 읽기 시도를 차단하는지 확인합니다.AWS_ACCESS_KEY_ID 같은 가짜 secret env를 주입하고 출력이 막히는지 확인합니다./model, --model, ANTHROPIC_MODEL로 각각 선택해 봅니다.이런 테스트를 릴리스마다 반복하면 설정 드리프트를 줄일 수 있습니다. 특히 에이전트 도구는 업데이트 속도가 빠르기 때문에 “한 번 설정했으니 영원히 안전하다”는 접근은 위험합니다.
Claude Code 조직 보안 설정의 목표는 에이전트를 못 쓰게 하는 것이 아닙니다. 반대로 더 안전하게 많이 쓰게 하는 것입니다. 개발자가 에이전트를 신뢰하려면, 에이전트가 실수로 secret을 읽지 않는다는 확신이 있어야 합니다. 보안팀도 모델과 데이터 경로가 정책 안에 있다는 확신이 있어야 합니다.
바로 적용할 체크리스트는 다음과 같습니다.
sandbox.credentials를 파일 정책 또는 관리 설정으로 적용합니다./model, --model, ANTHROPIC_MODEL 우회가 막히는지 확인합니다.정리하면, 이번 Claude Code 보안 업데이트는 조직이 에이전트형 개발 도구를 실제 업무에 넣기 위한 기본 장치입니다. 모델 제한과 credential 차단을 초기에 잡아 두면, 나중에 사고가 난 뒤 급하게 막는 것보다 훨씬 덜 아픕니다.