Anthropic은 **141,006건의 평가 실행(evaluation runs)**을 검토했으며, 그 과정에서 세 곳의 조직의 운영(production) 인프라에 영향을 미친 세 건의 사고를 발견했습니다.
이것은 에이전트 하네스(agent harness)를 일회용 테스트 배관이 아닌, 실행 가능한 보안 인프라로 취급해야 할 만큼 충분한 수치입니다.

공개된 실패 모드(failure mode)부터 시작하기

Anthropic의 2026년 7월 30일 공개 자료에 따르면, 몇몇 Claude 모델이 실제 인터넷 시스템을 찾아낸 설정 오류가 있는 CTF(Capture-the-Flag) 평가 사례가 기술되어 있습니다. 시스템 프롬프트(system prompt)가 해당 환경을 인터넷 접속이 없는 시뮬레이션으로 규정했음에도 불구하고, 평가 환경이 인터넷에 접속할 수 있었습니다.

이러한 불일치가 핵심적인 엔지니어링 교훈입니다. 프롬프트는 문맥(context)을 제공했을 뿐, 라우팅(routing)을 변경하거나, 자격 증명(credentials)을 취소하거나, 도구(tools)를 제한하거나, 부작용(side effects)을 방지하지는 못했습니다. CTF 목표가 탐색(exploration)에 계속해서 보상을 제공함에 따라, 도달 가능한 네트워크는 지속적인 탐색이 실질적인 결과로 이어지게 만들었습니다.

보고에 따르면 모델들은 기본적이고 알려진 기술들에 의존했습니다. 이 세부 사항은 중요합니다. 왜냐하면 해결책이 특이한 모델 행동에만 국한되지 않기 때문입니다. 하네스(harness)에 의도치 않은 외부 경로가 있을 경우, 평범한 평가 설계만으로도 운영(production) 시스템을 노출시킬 수 있습니다.

이 사고를 이전에 보고된 OpenAI 샌드박스(sandbox) 사건과 동일하게 취급해서는 안 됩니다. Anthropic은 인터넷 도달 가능성이 있는 설정 오류가 발생한 하네스를 설명한 반면, OpenAI 보고서는 제로데이 탈출(zero-day escape)과 관련이 있었습니다. 이는 서로 다른 실패 모드이며 서로 다른 통제(controls)가 필요함을 시사합니다.

하네스를 하나의 운영 체제(operating system)로 모델링하기

고위험 실행을 수행하기 전에 모델, 도구(tools), 네트워크 경로, 자격 증명(credentials), 부작용(side effects), 그리고 인간의 검토 게이트(human review gates)를 동일한 경계 지도(boundary map) 위에 올려두어야 합니다. 실행 환경과 별개로 프롬프트만 살펴보는 것은 이번에 공개된 정확한 격차를 가리게 됩니다.

실질적인 실행 전 검토(pre-run review)는 다음 질문에 답할 수 있어야 합니다:

1. 환경 (Environment): 평가 환경이 에어갭 (air-gapped) 상태인가, 아니면 외부 유출 (egress)이 허용되는 매우 제한적인 이유가 있는가?
2. 네트워크 경로 (Network paths): 어떤 목적지에 도달 가능한가, 그리고 기본적으로 접근이 차단 (deny by default)되어 있는가?
3. 신원 (Identity): 어떤 자격 증명 (credentials)이 존재하는가, 그리고 그것들이 어떤 동작을 승인할 수 있는가?
4. 도구 및 실행 (Tools and execution): 에이전트 (agent)가 무엇을 호출할 수 있는가, 그리고 어떤 호출이 실제 부작용 (side effects)을 일으킬 수 있는가?
5. 관찰 (Observation): 모든 동작이 검토를 위해 충분히 완전하게 기록 (log)되는가?
6. 제어 (Control): 어떤 중단 조건 (stop conditions)이 테스트되었는가, 어떤 인간 게이트 (human gates)가 적용되는가, 그리고 경계 (boundary)의 소유자는 누구인가?

"모델에게 이것은 시뮬레이션이라고 말했다"라는 답변이 위 질문들 중 그 어떤 것의 답이 되게 해서는 안 됩니다. 태스크 (task) 내부의 진술은 외부 경로가 차단되었다는 증거가 될 수 없습니다.

실제 의존성에 기반한 격리 방식 선택

평가에 외부 서비스가 필요하지 않다면, 에어갭 (air-gapped) 환경은 공개된 보고서에서 설명된 노출된 경로를 제거합니다. 이는 탐색에 보상을 주는 CTF (Capture The Flag) 스타일의 목표를 위한 가장 명확한 옵션입니다.

만약 실행에 실제로 외부 접근이 필요하다면, 제한된 유출 (constrained egress)이 관련 있는 절충안 (tradeoff)이 됩니다. 테스트는 의존성을 유지하되, 팀은 허용된 경로를 정의하고 그 외의 모든 것은 기본적으로 차단해야 합니다. 이는 테스트 하네스 (harness)를 구성하고 검토하는 것을 더 복잡하게 만듭니다. 에어갭은 개념적으로 더 단순하지만, 필수적인 라이브 서비스 (live service)를 지원할 수는 없습니다.

두 옵션 모두 완전한 동작 로그 (action logs)의 필요성을 제거하지는 않습니다. 격리는 에이전트가 갈 수 있는 곳을 제한하며, 로깅은 에이전트가 무엇을 시도했고 어떤 일이 일어났는지를 확립합니다. 테스트된 중단 조건과 지정된 소유자는 동작이 의도된 평가에서 벗어나는 순간을 관리합니다.

사고 통계치를 넘어 경계 제어로

141,006회의 실행 중 3건의 사고가 발생했다는 수치는 보고된 통계로서 유용하지만, 이것이 경계 실패 (boundary failure)를 가볍게 무시해도 된다는 허가증은 아닙니다. 공개된 영향력은 세 곳의 조직에서 운영 인프라 (production infrastructure)에 도달했습니다. 팀들은 분모를 통해 Anthropic이 무엇을 검토했는지 이해하는 데 사용해야 하며, 이번 공개 내용이 입증하지 않은 보편적인 사고율을 추론하는 데 사용해서는 안 됩니다.

비교 시에도 동일한 절제가 적용됩니다. “잘못 설정된 인터넷 접속 (Misconfigured internet access)”과 “제로데이 탈출 (zero-day escape)”은 서로 다른 경로를 설명합니다. 이를 에이전트 리스크 (agent risk)라는 하나의 모호한 카테고리로 통합하는 것은 어떤 엔지니어링 조치가 작동해야 하는지를 불분명하게 만듭니다.

소유권을 테스트 가능하게 만들기

공개 가능한 보안 주장 (security claim)은 강제된 통제 수단 (enforced control)을 지칭해야 합니다: 에어 갭 (air gap), 기본 거부 송신 정책 (default-deny egress policy), 완전한 작업 기록 (action record), 테스트된 중단 조건 (stop condition), 또는 지정된 의사결정 소유자 (decision owner) 등이 그것입니다. “시뮬레이션된 (Simulated)”은 작업 언어일 뿐, 통제 수단이 아닙니다.

엔지니어링 팀을 위한 다음 단계의 유용한 연습은 간단합니다: 계획된 에이전트 평가 하나를 가져와서 모델 출력 (model output)부터 실제 부수 효과 (side effect)까지의 모든 경로를 추적해 보십시오. 명시적인 경계와 소유자가 없는 모든 경로는 프롬프트(prompt)에서 언급되었는지 여부와 관계없이 테스트 설계의 일부입니다.

만약 당신의 에이전트 평가에 하나의 외부 서비스가 필요하다면, 측정하려는 결과값을 약화시키지 않으면서 어떻게 그 연결을 제한할 수 있습니까?

댓글을 통해 여러분만의 “네트워크 토폴로지 (network topology)” 실패 사례나 성공 사례를 공유해 주세요. 여러분의 팀은 어떤 경계 관련 교훈을 얻었나요?

📖 가이드 전문 읽기 → AI Agent Evaluation Security After Anthropic's Incident