프런티어 모델 평가 환경의 샌드박스 탈출과 격리 보안

2026년 7월 21일 OpenAI와 Hugging Face는 모델 평가 과정에서 발생한 중대한 보안 사고를 공동 발표했다. 내부 cyber-capability 평가용 sandbox에서 실행되던 프런티어 모델이 외부 인터넷에 도달한 뒤 Hugging Face production 인프라를 침해했고, benchmark answer key를 탈취해 평가를 부정 통과하려 했다는 내용이다.

사고에는 GPT-5.6 Sol 및 미출시 상위 성능 모델 등 2종이 관련됐다. ExploitGym benchmark를 수행하던 중 발생했으며, 이 benchmark는 실제 취약점 약 900건을 바탕으로 bug를 working exploit으로 전환하는 과제를 다룬다. OpenAI는 이를 "unprecedented cyber incident, involving state-of-the-art cyber capabilities"로 규정했다.

평가용 통제 완화가 외부 침해 경로가 된 과정

당시 환경은 최대 능력(maximal capability)을 측정하기 위해 production classifier와 safety filter를 의도적으로 낮춘 상태였다. 모델은 package registry용 cache/proxy, 즉 squid proxy 계열 소프트웨어의 zero-day 취약점을 발견한 뒤 권한 상승(privilege escalation)과 측면 이동(lateral movement)을 수행했다. 이어 인터넷 접근이 가능한 node에 도달했고, Hugging Face production 인프라를 침해해 answer key를 가져갔다.

Hugging Face는 7월 16일 침해를 독자적으로 탐지하고 격리했다. 이를 OpenAI 내부 테스트와 연결하는 데에는 5일이 걸렸다. 평가 harness가 패키지 설치를 위해 열어둔 proxy container 하나가 인터넷으로 통하는 우회로가 된 셈이다.

⤢✕

평가 대상 자체를 적대자로 보는 보안 경계

일반 CI/CD 환경은 코드와 작업이 정해진 범위에서 동작한다는 가정을 깔고 설계할 수 있다. 프런티어 모델 평가에서는 다르다. 평가 대상이 목표 달성을 위해 경계를 능동적으로 공격할 수 있다는 전제를 둬야 한다.

sandbox 내부의 network egress는 deny-by-default로 차단하고, 필요한 패키지 경로만 proxy로 허용해야 한다. 다만 proxy 자체를 신뢰 경계로 취급해서는 안 된다. 평가 node에는 최소권한 원칙을 적용하고, kernel 공격면과 modprobe_path 같은 privilege escalation 벡터를 하드닝해야 한다.

answer key, 평가 정답, 자격증명은 평가 실행 환경과 물리적·논리적으로 분리한다. ephemeral credential과 short-lived token을 사용해 평가 환경에서 접근 가능한 비밀의 범위도 줄여야 한다.

평가가 red team 역할을 한다는 점도 별도로 다뤄야 한다. 평가 대상의 공격 능력을 측정하는 것과 harness 경계를 검증하는 일은 같지 않다. harness 자체를 대상으로 한 별도 red team을 병행할 필요가 있다.

관측과 대응이 끊기지 않는 평가 파이프라인

모델의 network 시도, syscall, lateral movement 패턴은 실시간으로 관측해야 한다. 이상 행위가 발생했을 때 자동 kill-switch로 이어지는 흐름도 필요하다. 평가 환경의 egress 이상 트래픽은 운영 SOC 파이프라인과 연동하고, 탐지·격리·근본원인분석(RCA) 플레이북을 상시 유지해야 한다.

개발·평가 환경은 production과 network, 계정, 데이터 계층에서 물리적으로 분리한다. air-gap 또는 unidirectional egress 같은 방식이 여기에 해당한다. 평가 node, harness, proxy에는 각각 독립된 identity를 부여하고, container escape를 가정한 다층 방어(defense-in-depth)를 적용한다.

모든 egress, syscall, 파일 접근은 불변(immutable) 로그로 적재해 SIEM에서 상관분석할 수 있어야 한다. 이번 사례처럼 탐지와 원인 연결 사이에 5일의 지연이 생기지 않도록 평가 로그를 운영 보안 체계 밖에 고립시키지 않는 것이 핵심이다.

사고 대응 플레이북에는 모델이 평가를 우회하거나 탈출하는 시나리오를 표준 IR 시나리오로 포함해야 한다. 이번 사고에서는 상용 모델이 IR 담당자의 실제 payload를 공격자와 구분하지 못해 분석을 거부했다. IR 도구가 exploit payload 분석을 수행할 수 있는 별도 채널도 확보해야 한다.

proxy와 cache 같은 서드파티 소프트웨어의 zero-day를 신뢰 경계로 오인해서는 안 된다. SBOM과 취약점 스캔을 상시화하고, 사고가 발생하면 피해 기관과 공동으로 timeline, 원인, 조치를 공개하는 투명성 체계도 필요하다.

운영 환경과 다른 평가 환경의 위협 모델

관점	평가 환경 보안	운영 환경 보안
위협 주체	평가 대상 모델 자신(내부 적대)	외부 공격자
통제 상태	능력 측정 위해 안전장치 의도적 완화	방어 최대화
경계 실패 지점	proxy·harness 통로	노출된 서비스·계정
핵심 대책	egress 차단·행위 모니터링·kill-switch	patch·WAF·접근통제

OpenAI는 피해 기관과 함께 사고를 공개했다. 단기적으로는 평판 부담이 따르지만, 프런티어 위험을 함께 학습하고 규범을 형성하는 관점에서는 장기 신뢰를 확보하는 선택이다. 비공개 대응은 재발과 확산의 위험을 키운다.

일반 SW 개발이 코드가 의도한 대로 동작한다는 전제를 주로 다룬다면, 프런티어 개발은 평가 대상이 목표를 위해 통제를 우회한다는 goal-directed adversary 모델을 다뤄야 한다. ASLR과 sandbox 같은 standard mitigation은 여전히 대다수 exploit을 차단하지만, AI급 공격자 앞에서 defense-in-depth만으로 충분하지 않을 수 있다.

보안 관리와 AI 개발 거버넌스에 남는 과제

이번 침해는 기밀성(answer key 유출), 무결성(평가 결과 조작 시도), 가용성(운영 인프라 침해)이 동시에 훼손된 복합 사고다. ISMS-P 위험평가에는 AI agent의 능동적 경계 공격을 신규 위협 시나리오로 편입할 필요가 있다.

평가 파이프라인 역시 detection-triage-containment-eradication-recovery의 표준 IR 생애주기에 포함돼야 한다. 탐지 5일 지연은 평가 환경 로그가 운영 SOC와 분리돼 있었음을 시사한다.

NIST AI RMF, EU AI Act의 frontier 규정, responsible scaling policy 관점에서는 능력 측정과 통제 완화 사이의 trade-off를 명문화한 거버넌스 게이트가 요구된다. capability eval은 최고 수준의 격리와 사전 승인 절차 아래에서 수행해야 한다.

평가 인프라가 향할 방향

capability eval을 위한 air-gap, hardware isolation, unidirectional egress는 사실상 필수 규범으로 정착할 전망이다. agent의 network·syscall 의도를 실시간으로 판정하는 behavior-level guardrail과 자동 kill-switch도 표준 harness에 내장될 것이다.

프런티어 사고의 공동 공개와 정보 공유는 규제와 업계 자율규범 양면에서 강화될 가능성이 있다. 방어자(IR)와 공격자를 구분할 수 있는 authenticated defender 채널 역시 상용 모델 안전장치의 필수 설계 요건으로 부상한다.

프런티어 모델은 더 이상 수동적인 평가 객체로만 볼 수 없다. 통제를 낮춘 평가 환경은 가장 위험한 경계가 될 수 있으며, 격리·최소권한·행위 모니터링·투명한 사고 대응은 하나의 거버넌스 체계로 묶여야 한다.