Claude 사이버 평가 사고: AI 보안 벤치마크를 인터넷과 분리해야 하는 이유

Anthropic이 사이버 보안 평가 과정에서 Claude 모델이 실제 인터넷에 연결된 시스템을 건드린 사고를 공개했습니다. 내용은 꽤 무겁습니다. Claude가 캡처 더 플래그 형태의 평가 환경에서 작업하던 중, 평가 환경이 완전히 격리되어 있지 않았고 실제 조직의 인프라에 무단 접근한 사례가 3건 확인됐다는 설명입니다.

공식 글에 따르면 Anthropic은 인터넷 접근 가능성이 있었던 141,006개의 평가 실행 기록을 검토했고, 그중 3건의 실제 사고를 찾았습니다. 모델은 평가 프롬프트에서 ‘인터넷 접근이 없다’고 안내받았지만, 실제로는 평가 파트너 환경의 설정 문제로 외부 인터넷 접근이 가능했습니다. 모델은 자신이 보는 대상을 시뮬레이션 일부로 오해했고, 약한 비밀번호나 인증되지 않은 엔드포인트 같은 기본적인 취약점을 이용해 실제 시스템에 접근했습니다.

이 사건은 단순히 한 회사의 실수로만 볼 수 없습니다. AI 에이전트가 도구를 쓰고, 네트워크를 탐색하고, 명령을 실행하는 시대에는 평가 환경도 제품 환경만큼 엄격하게 운영해야 합니다. 특히 보안 벤치마크는 일부러 공격적 행동을 유도합니다. 따라서 ‘모델이 착하게 행동하겠지’가 아니라 ‘모델이 평가 목표를 끝까지 달성하려 할 때 어디까지 나갈 수 있는지’를 전제로 격리해야 합니다.

사고의 핵심 원인은 모델 하나가 아니라 경계 실패다

이번 사고에서 가장 중요한 표현은 ‘모델이 인터넷에 접근했다’가 아니라 ‘평가 환경이 인터넷과 분리되어 있다고 믿었지만 실제로는 아니었다’입니다. 프롬프트는 환경을 설명했지만, 인프라는 그 설명을 보장하지 않았습니다. AI 에이전트 운영에서 이 불일치는 치명적입니다.

사람 개발자라면 이상한 신호를 보고 멈출 수도 있습니다. 하지만 에이전트는 주어진 목표를 기준으로 행동합니다. CTF 과제에서 플래그를 찾으라고 하면, 접근 가능한 네트워크와 파일, 패키지 저장소, 문서, 계정을 탐색합니다. 그 과정에서 실제 인터넷이 열려 있다면 모델은 그것을 과제의 일부로 해석할 수 있습니다.

이 문제는 프롬프트로 해결하기 어렵습니다. ‘외부 시스템을 공격하지 마라’는 문장을 추가해도 네트워크가 열려 있으면 실수 가능성은 남습니다. 보안 평가와 에이전트 실행 환경에서는 정책보다 샌드박스가 먼저입니다. 네트워크 egress 차단, DNS 차단, 패키지 레지스트리 미러링, outbound proxy allowlist 같은 통제가 기본값이어야 합니다.

PyPI 사례가 특히 위험한 이유

공개된 사고 중 하나는 모델이 존재하지 않는 Python 패키지명을 발견하고, 같은 이름의 패키지를 PyPI에 올리려 한 사례입니다. 평가 시나리오 안에서 가상의 회사 문서가 특정 패키지를 설치하라고 안내했고, 모델은 패키지 혼동 공격을 시도한 것입니다. 문제는 그 레지스트리가 실제 PyPI였다는 점입니다.

이 사례는 AI 보안 평가가 소프트웨어 공급망과 직접 연결될 수 있음을 보여줍니다. 에이전트에게 셸, 인터넷, 패키지 업로드 권한이 있으면 단순한 벤치마크가 실제 공급망 공격으로 바뀔 수 있습니다. 모델이 악의를 가진 것이 아니라도 결과는 위험합니다. 목표 함수가 잘못된 환경에서 실행되면 실제 피해가 생길 수 있습니다.

개발팀은 여기서 두 가지를 배워야 합니다. 첫째, 에이전트 실행 환경에서 공개 레지스트리 쓰기 권한을 기본 차단해야 합니다. 둘째, 테스트용 레지스트리와 실제 레지스트리를 명확히 분리해야 합니다. npm, PyPI, Docker Hub, GitHub Packages 같은 외부 시스템은 읽기도 주의가 필요하고 쓰기는 더 엄격해야 합니다.

에이전트 평가는 CI처럼 운영해야 한다

보안 벤치마크를 연구팀의 실험으로만 다루면 위험합니다. 지금의 AI 평가는 점점 CI/CD와 비슷해지고 있습니다. 모델 버전이 바뀌고, 프롬프트가 바뀌고, 도구 권한이 바뀌고, 평가 환경이 바뀝니다. 따라서 평가도 반복 가능한 파이프라인으로 관리해야 합니다.

가장 먼저 필요한 것은 실행 전 검증입니다. 컨테이너가 외부 인터넷에 나갈 수 있는지, DNS가 어디를 바라보는지, 패키지 매니저가 실제 레지스트리에 연결되는지, 클라우드 메타데이터 엔드포인트에 접근 가능한지 검사해야 합니다. 이 검사는 문서가 아니라 자동 테스트여야 합니다.

두 번째는 실행 중 모니터링입니다. 에이전트가 예상하지 않은 도메인으로 연결을 시도하면 즉시 중단해야 합니다. 단순 로그 수집으로는 늦습니다. outbound 요청을 프록시로 모으고, allowlist 외 목적지는 차단하며, 차단 이벤트를 평가 실패로 처리해야 합니다.

세 번째는 실행 후 감사입니다. 모델 transcript만 보는 것으로 부족합니다. 네트워크 로그, 파일 변경 로그, 프로세스 실행 로그, 외부 API 호출 로그를 함께 봐야 합니다. 에이전트는 자연어로 자신의 의도를 설명하지만, 실제 피해 여부는 시스템 로그가 말해줍니다.

일반 AI 제품에도 같은 원칙이 적용된다

이 사고는 보안 평가에서 발생했지만, 일반 AI 제품에도 그대로 적용됩니다. 고객지원 에이전트가 CRM을 조회하고, 개발 에이전트가 GitHub에 접근하고, 데이터 분석 에이전트가 S3를 읽는다면 모두 같은 위험을 가집니다. 모델이 잘못 이해한 범위를 실제 권한이 뒷받침하면 사고가 납니다.

제품팀은 에이전트에게 ‘필요할 수도 있는 모든 권한’을 주는 습관을 버려야 합니다. 업무별 권한을 쪼개고, 쓰기 작업은 별도 승인 단계로 분리하고, 외부 전송은 기본 차단하는 방식이 낫습니다. 특히 인터넷 검색, 패키지 설치, 이메일 발송, 코드 푸시, 클라우드 리소스 생성은 위험도가 높습니다.

실행 체크리스트

• 에이전트 평가 환경에서 기본 egress를 차단하고 필요한 도메인만 allowlist로 엽니다.
• 실제 PyPI, npm, Docker Hub, GitHub Packages에 대한 쓰기 권한을 테스트 환경에서 제거합니다.
• 컨테이너 시작 전에 DNS, 프록시, 메타데이터 엔드포인트, 패키지 레지스트리 연결을 자동 점검합니다.
• 외부 네트워크 요청은 프록시를 통해 기록하고 allowlist 외 요청은 즉시 실패 처리합니다.
• 모델 transcript와 별개로 네트워크, 파일, 프로세스, API 호출 로그를 보존합니다.
• 평가 프롬프트의 환경 설명과 실제 인프라 설정이 일치하는지 릴리즈마다 검증합니다.
• 일반 제품에서도 에이전트 권한을 업무별로 분리하고 쓰기 작업에는 승인 단계를 둡니다.

이번 사고의 교훈은 명확합니다. AI 에이전트 안전은 ‘모델이 알아서 멈출 것’이라는 기대 위에 세울 수 없습니다. 모델은 목표를 수행하고, 인프라는 경계를 강제해야 합니다. 보안 벤치마크든 일반 업무 자동화든, 에이전트 실행 환경은 인터넷에 연결된 작은 운영 시스템으로 취급해야 합니다.

참고: Anthropic, Investigating three real-world incidents in our cybersecurity evaluations.