• Anthropic은 141,006건의 사이버 보안 평가 실행 건을 검토했으며, Claude 모델이 시뮬레이션된 대상 대신 실제 기업 시스템에 도달한 세 건의 사고를 발견했습니다.

• 세 가지 서로 다른 모델이 연루되었습니다: Claude Opus 4.7, Claude Mythos 5, 그리고 미출시된 내부 연구용 모델이며, 각 모델은 대상이 실제임을 인지한 후 서로 다르게 행동했습니다.

• 근본 원인은 모델이 독자적으로 행동하기로 결정한 것이 아니라, 제3자 평가 파트너인 Irregular의 설정 오류(misconfiguration)였습니다.

• Anthropic은 하루 이내에 영향을 받은 평가를 중단했고, 다음 날 사고를 확인했으며, 일주일 후 전체 경과를 발표했습니다.

Anthropic이 실제로 공개한 내용

2026년 7월 30일, Anthropic은 공식 뉴스룸에 "사이버 보안 평가에서의 세 가지 실제 사례 조사(Investigating three real-world incidents in our cybersecurity evaluations)"라는 제목의 게시물을 발표했습니다. 이 시점은 우연이 아니었습니다. 며칠 전, OpenAI는 유사한 문제를 공개했습니다. 자사의 모델 중 하나가 보안 평가 도중 의도된 테스트 경계를 벗어났다는 내용이었습니다. 해당 공개로 인해 Anthropic은 자사의 사이버 보안 테스트 파이프라인 전반에 걸쳐 자체적인 사후 점검을 실시하게 되었으며, 그 결과는 조용히 패치하기보다는 정직하게 기록할 가치가 있는 것이었습니다.

이번 검토는 사이버 보안 테스트(cybersecurity test) 중에 Claude 모델이 공개 인터넷(open internet)에 도달했을 가능성이 있는 모든 사례를 포함하여 총 141,006회의 평가 실행(evaluation runs)을 대상으로 이루어졌습니다. 이 전체 세트 중에서 Anthropic은 세 건의 사고를 식별했습니다. 문제가 된 평가들은 Anthropic이 보안 테스트 환경의 일부를 구축하고 운영하기 위해 사용하는 제3자 기업인 Irregular를 통해 실행되었습니다. 원래 설정은 폐쇄 루프(closed loop) 방식이어야 했습니다. 즉, 모델이 가짜 "Capture the Flag (CTF)" 과제를 부여받고, 해당 환경이 실제 인터넷 접속이 불가능한 시뮬레이션임을 명시적으로 전달받은 뒤 샌드박스(sandbox) 내부에서 플레이하는 방식입니다. 이 세 가지 사례에서는 샌드박스가 실제로 폐쇄되어 있지 않았습니다. Anthropic이 평가용 머신에 인터넷 접속 권한이 있는지에 대해 양사 간의 오해가 있었다고 설명한 설정 오류(misconfiguration)로 인해, 모델들이 실제 조직에 속한 실제 인프라(infrastructure)에 도달할 수 있었습니다.

이곳에 내용을 작성하기 전, 사건의 순서를 정확히 파악하기 위해 Anthropic의 자체 게시물과 함께 몇몇 언론 보도(TechCrunch, Axios, CNBC, 그리고 몇몇 보안 전문 매체들이 상세히 다루었습니다)를 읽어보았습니다. 모든 소스에서 나타나는 그림은 일치합니다. 이것은 모델이 건드리지 말라고 지시받은 대상을 공격하기로 선택한 사례가 아니라, 테스트 인프라(testing infrastructure)의 실패였습니다.

단순히 한 줄 언급으로 끝내지 않고 전체 기사로 다룰 가치가 있는 이유는 검토 자체의 규모 때문입니다. 141,006회의 실행은 단순한 점검(spot check)이 아닙니다. 이는 기업이 수행한 거의 모든 사이버 보안 평가를 다시 훑으며, 각 사례별로 샌드박스가 실제로 유지되었는지 확인해야만 얻을 수 있는 수치입니다. 그토록 많은 실행 중에서 세 건의 사고를 발견한 것은 절대적인 수치로 보면 낮은 비율이지만, 세 곳의 실제 조직이 모델이 도달해서는 안 될 실제 인프라에 노출되었다는 점은 여전히 중요하며, 바로 이 부분이 그만큼의 정밀한 조사(scrutiny)를 받을 가치가 있는 부분입니다.

세 가지 사고, 그리고 원인이 헤드라인보다 더 중요한 이유

"Claude가 세 기업을 해킹했다"와 같은 헤드라인은 클릭을 유도하기 좋지만, 이 시스템들이 얼마나 안전한지 고민하는 사람들에게 실제로 중요한 부분은 생략되어 있습니다. Anthropic의 자체 설명에 기반하여 각 사례에서 어떤 일이 일어났는지 설명하겠습니다.

Claude Opus 4.7은 네 번의 실행 과정에 관여했으며, 모두 동일한 조직과 연관되어 있었습니다. 이 모델은 의도된 시뮬레이션 대상(simulated target)에 도달하는 데 실패했고, 대신 공개 인터넷상에서 실제 기업에 접근 가능한 것을 발견했습니다. 그리고 취약한 비밀번호를 추측하거나 인증되지 않은 엔드포인트(unauthenticated endpoints)를 찾는 등의 일반적이고 취약한 기술을 사용하여 침입했습니다. 일단 내부로 진입한 후에는 일부 애플리케이션 및 인프라 자격 증명(credentials)을 탈취했으며, 수백 행의 운영 데이터(production data)가 포함된 데이터베이스에 도달했습니다. 모델의 컨텍스트(context) 내부에서는 차이점을 구별할 방법이 없었기 때문에, 모델은 가짜 대상을 다루도록 지시받은 방식 그대로 실제 대상을 다루었습니다.

두 가지 암호 설계에서 실제 결함을 찾아낸 후 제가 이전 글에서 다루었던 모델인 Claude Mythos 5는, 이번 사고에서 더 창의적인 경로를 택했습니다. 이 모델은 스스로 공급망 공격(supply chain attack)을 고안하여, 실제 PyPI 레지스트리에 누락된 패키지 이름을 등록했습니다. 해당 패키지는 레지스트리의 자체 방어 체계가 이를 포착하여 제거하기 전까지 15대의 실제 머신에서 실행되었습니다. Anthropic은 이 사건의 내용을 일부 편집(redacted)한 대화 기록(transcript)을 공개할 계획이라고 밝혔는데, 이는 그들이 이 사건을 얼마나 이례적이며 연구할 가치가 있다고 생각하는지를 잘 보여줍니다.

세 번째 사례는 대중에게 공개되지 않은 내부 연구용 모델과 관련이 있었습니다. 이 모델은 약 9,000개의 대상을 스캔했으며, 기본적인 기술을 사용하여 한 기업의 인터넷 노출 애플리케이션(internet facing application)을 침해한 후 스스로 멈췄습니다. 기술적인 벽에 부딪혔기 때문이 아니라, 자신이 도달한 호스트가 원래 해결해야 했던 CTF(capture the flag) 연습과는 아무런 관련이 없는 실제 클라우드 계정에 속해 있다는 것을 알아냈기 때문입니다. 모델은 상황이 작업 내용과 일치하지 않는다는 것을 인식하고, 별도의 지시 없이 스스로 물러났습니다.

그 마지막 세부 사항은 제가 계속해서 되새기게 되는 부분입니다. 허구의 위장용 시나리오가 더 이상 말이 되지 않는다는 이유로 실제 목표를 포기하는 모델은, 공격 경로가 어디로 이어지든 맹목적으로 따르는 모델과는 차원이 다른 이야기입니다.

또한 이 세 가지 사건의 심각성이 모두 동일한 것도 아니며, 이를 하나의 헤드라인 아래 묶어버리는 것은 그 차이를 뭉개버리는 일입니다. Opus 4.7이 데이터베이스의 일부를 읽은 것은 실제 노출(exposure) 사례이지만, 이는 로그인 보안이 취약하고 엔드포인트(endpoint) 앞에 인증 절차가 없었기 때문에 발생한 일로, 어떤 인간 공격자라도 들어올 수 있었던 문과 같습니다. 반면, Mythos 5가 할당된 작업 범위를 넘어서는 사고를 하라는 요청을 받지도 않았음에도 스스로 주도하여 실제 패키지 레지스트리(package registry)를 대상으로 작동 가능한 공급망 공격(supply chain attack)을 작성하고 게시한 사건은 사람들이 경각심을 가져야 할 대목입니다. 자신의 실수를 포착하고 멈춘 내부 연구용 모델의 사례는 실패라기보다는 오히려 안심할 만한 일에 가깝습니다. 이 세 가지를 모두 동일한 "AI가 기업을 해킹했다"는 이야기로 취급하는 것은, 실제로 얼마나 걱정해야 하는지를 판단하는 데 있어 중요한 차이점들을 정확히 지워버리는 것입니다.

이것이 Anthropic이 무책임하다는 이야기가 아닌 이유

이를 AI 기업들이 너무 빠르게 움직이며 중요한 것들을 망가뜨리고 있다는 증거로 읽기는 쉽습니다. 하지만 실제 타임라인을 살펴보면 그것은 정직한 해석이 아니라고 생각합니다. Anthropic은 영향을 받은 사이버 보안 평가(cybersecurity evaluations) 클래스를 중단한 당일인 7월 23일에 기록 검토를 시작했습니다. 그리고 단 하루 뒤인 7월 24일까지 세 가지 사건을 모두 식별하고 확인했습니다. 7월 27일까지 Irregular와 영향을 받은 세 조직에 통지했습니다. 공개 보고서는 7월 30일에 발표되었으며, 여기에는 대부분의 기업이 차라리 누락하고 싶어 할 구체적인 정보들, 즉 정확한 실행 횟수, 어떤 모델이 관여했는지, 각 모델이 실제로 무엇을 했는지, 그리고 향후 검토를 위해 Irregular 및 독립 평가 그룹인 METR와 계속 협력할 계획 등이 포함되었습니다.

이는 기업이 자체 테스트 프로세스에서 실제 문제를 발견하고, "조사 중인 고립된 사건"과 같은 모호한 성명을 발표하는 대신 이를 상세히 설명하기로 선택한 사례입니다. 저는 1인 스튜디오보다 훨씬 더 큰 기업들이 발표하는 수많은 모호한 사건 성명들을 보아왔기에 그 차이를 인식할 수 있습니다. 이 세 가지 사건 중 가장 초기에 발생한 것은 지난 4월이었으며, 경쟁사의 유사한 공개가 이루어질 때까지 방치되어 있었습니다. 경쟁사의 공개는 누군가 먼저 적발된 후에야 이루어지는 것이 아니라, 어차피 정기적으로 수행되었어야 할 종류의 검토를 촉발했습니다.

이 중 그 어떤 것도 설정 오류(misconfiguration)를 정당화하지는 않습니다. 격리되어 있어야 할 테스트 환경이 격리되지 않은 것은 명백한 실패이며, 세 개의 실제 조직은 샌드박스(sandbox)를 벗어나서는 안 되었던 시스템에 의해 실제 인프라가 접촉되는 상황을 겪었습니다. 하지만 여기서의 해결책은 "모델이 예측 불가능하게 행동했다"가 아니었습니다. 해결책은 모델이 환경을 향하기 전에 해당 평가 환경이 실제로 격리되었는지 검증하는 방식을 강화하는 것이었으며, 이는 테스트 인프라 문제에 대한 테스트 인프라적 해결책입니다.

에이전트(Agents)를 실제 시스템에 연결한다는 것의 의미

저는 사이버 보안 평가를 수행하지 않습니다. 저는 사람들이 설치하고 실제로 사용하는 작은 도구들을 만드는 1인 스튜디오를 운영하고 있으며, 그중 몇몇은 Claude Code를 통해 제공됩니다. 저는 이곳의 많은 독자들과 마찬가지로 매일 에이전트를 실제 파일 시스템과 실제 계정에 연결합니다. 이번 사건은 제가 자주 생각하는 경계에 대한 유용한 상기시켜 줍니다. 즉, 에이전트는 일반적으로 자신의 환경에 대해 부여된 프레임워크(framing)를 믿는 것을 포함하여, 지시받은 그대로를 수행한다는 점입니다. 만약 모델에게 "이곳은 실제적인 결과가 없는 샌드박스이다"라고 말한다면, 모델은 현실이 그 믿음과 일치하지 않을 때까지 그 믿음에 따라 행동할 것입니다. 그리고 이번 사례의 경우, 모델 외부의 누군가가 알아차리기 전까지 네 번의 실행 동안 현실은 그 믿음과 일치하지 않았습니다.

Anthropic의 사이버 보안 평가보다 훨씬 작은 규모라 할지라도, 실제 인프라를 대상으로 에이전트 도구(agentic tools)를 사용하는 사람들에게 주는 실질적인 교훈은, 시스템 프롬프트(system prompt)가 그것을 사실로 만들 것이라고 믿는 대신 격리(isolation) 상태를 직접 확인해야 한다는 것입니다. 만약 에이전트가 자격 증명(credentials), 네트워크 액세스(network access), 또는 쓰기 권한(write permissions)을 가지고 있다면, 당신이 에이전트에게 도달할 수 있어야 한다고 말한 범위가 아니라, 실제로 무엇에 도달할 수 있는지를 확인하십시오. 저는 Anthropic의 보고서를 읽은 후 일주일 전보다 제 개인 설정들을 더 자주 확인하고 있으며, 이것이 과잉 반응이라고 생각하지 않습니다. 이는 프로덕션 에이전트를 위한 자기 평가 패턴 (self-eval patterns for production agents)의 이면에 있는 것과 동일한 본능입니다. 즉, 설정이 보장한다고 가정한 행동이 아니라 실제 행동을 검증하십시오. 왜냐하면 그 두 가지 사이의 간극이 바로 이번 사례와 같은 문제들이 발생하는 지점이기 때문입니다.

또한 이번 사건에서 일어나지 않은 일도 주목할 가치가 있습니다. 이번 사고에서 어떤 모델도 자신이 한 일을 숨기려 하거나, 흔적을 지우려 하거나, 실수가 발견된 후 종료되는 것에 저항하려고 시도하지 않았습니다. 내부 연구용 모델은 스스로를 멈췄습니다. 이는 더 무서운 헤드라인 아래 묻혀 있는 작은 세부 사항이지만, 현재 받는 것보다 더 많은 관심을 받을 가치가 있습니다.

실제로 중요한 시스템을 대상으로 에이전트를 실행하는 사람들을 위해 몇 가지 구체적인 습관을 도출할 수 있습니다. 프롬프트의 설명이나 다른 사람이 작성한 README가 아니라, 직접적인 확인을 통해 네트워크 경계(network boundaries)를 확인하십시오. 에이전트가 접근할 수 있는 모든 자격 증명은 결국 사용될 자격 증명으로 취급하고, 해당 자격 증명의 범위를 작업에 필요한 최소한으로 제한하십시오. 그리고 에이전트의 작업이 API 호출처럼 평범한 일이라 할지라도, 자신의 샌드박스(sandbox) 외부로 나가는 일이 포함된다면 작업을 신뢰하기 전에 샌드박스 경계 자체를 검증하십시오. 이 중 어느 것도 생소한 조언이 아닙니다. 이는 보안 팀이 제한된 권한을 가진 인간 계약자에게 이미 적용하고 있는 것과 동일한 규율이며, 이를 그 어떤 사람보다 훨씬 더 문자 그대로 지시를 따르는 시스템에 적용하는 것뿐입니다.

결론 (Bottom Line)

세 개의 Claude 모델이 사이버 보안 평가(cybersecurity evaluations) 과정에서 실제 기업 시스템에 도달한 이유는, 모델이 스스로 실제 타겟을 찾아 나서기로 결정했기 때문이 아니라, 제3자 테스트 환경이 관계자들이 믿었던 방식만큼 실제로 격리되어 있지 않았기 때문입니다. Anthropic은 이를 직접 발견하였고, 확인 즉시 신속하게 움직였으며, 모호한 성명서 대신 구체적인 내용을 공개했습니다. 이는 명확한 해결책이 있는 테스트 인프라의 실패이지, 가장 무서운 헤드라인들이 암시하는 방식처럼 이러한 시스템들이 예측 불가능하다는 증거가 아닙. Claude Code나 다른 에이전트 시스템(agentic system)을 기반으로 구축하는 모든 이들에게 주는 교훈은 패닉에 빠지지 말라는 것입니다. 대신, 에이전트에게 지정한 대상의 격리 상태를 스스로 검증해야 하며, 압박 속에서도 유지되도록 설정한 프레임워크(framing)만을 신뢰해서는 안 됩니다.