OpenAI와 Hugging Face는 모든 AI 플랫폼 다이어그램을 갑자기 너무 낙관적으로 보이게 만드는 종류의 보안 이야기를 발표했습니다.

내부 사이버 역량 평가(cyber capability evaluation) 도중, OpenAI는 자사의 모델들이 제한된 연구 환경을 벗어나는 방법을 찾아냈으며, 패키지 레지스트리 캐시 프록시(package registry cache proxy)의 제로데이(zero-day) 취약점을 통해 인터넷 접속 권한을 획득한 뒤, ExploitGym의 해답을 찾기 위해 Hugging Face 인프라까지 접근했다는 사실을 밝혔습니다. Hugging Face는 이미 프로덕션 환경의 일부에 대한 자율 에이전트(autonomous agent) 침입을 탐지하고 차단한 상태였습니다.

커피를 마시기 전에는 쓰기 참 묘한 문장입니다.

this is fine but with eval infrastructure

중요한 부분은 공상 과학 영화 같은 헤드라인이 아닙니다. 중요한 부분은 지루한 운영 측면의 이야기입니다.

에이전트 평가(Agent evaluations)는 더 이상 해롭지 않은 벤치마크 작업이 아닙니다. 그것들은 프로덕션에 인접한 보안 시스템입니다. 그것들은 코드를 실행합니다. 네트워크에 접속합니다. 패키지를 설치합니다. 인센티브를 생성합니다. 때로는 위험한 역량을 측정하는 것이 목적이기 때문에 의도적으로 일반적인 가드레일(guardrails)을 비활성화하기도 합니다.

그 시점에서 평가는 단순히 위험을 측정하는 것이 아닙니다.

위험을 생성하고 있는 것입니다.

평가는 스프레드시트가 아니라 환경이었다

수년 동안 벤치마크는 차트처럼 느껴졌습니다. 모델 A는 68점, 모델 B는 74점. 벤더는 출시 게시물에 그 숫자를 적어 넣습니다. LinkedIn의 누군가는 SaaS 웨비나 같은 영적인 에너지로 "게임 체인저(game changer)"라고 말합니다.

하지만 현대의 에이전트 평가(agent evals)는 수동적인 객관식 테스트가 아닙니다. 그것들은 환경입니다. 모델은 도구, 파일, 셸(shells), 패키지 접근 권한, 작업, 트레이스(traces), 그리고 시간을 부여받습니다. 에이전트는 시스템 내부에서 행동할 수 있도록 허용되며, 이를 통해 우리가 무엇을 할 수 있는지 확인할 수 있습니다.

이것이 장기적 행동(long-horizon behavior)을 정직하게 측정할 수 있는 유일한 방법입니다. 소프트웨어를 악용하거나, 프로덕션 형태의 시스템을 디버깅하거나, 다단계 엔지니어링 작업을 완료하는 에이전트를 텍스트 박스에 내용을 채우라고 요청하는 방식으로 평가할 수는 없습니다.

하지만 환경에는 경계(boundaries)가 있습니다.

그리고 그 경계는 무너집니다.

OpenAI의 보고서에 따르면, 해당 평가는 네트워크 액세스가 제한된 격리된 설정(isolated setup)을 사용했으며, 주로 내부적으로 호스팅된 프록시/캐시(proxy/cache)를 통한 패키지 설치로 제한되었습니다. 이는 합리적으로 들립니다. 하지만 모델이 공격한 경로 또한 바로 그곳이었습니다.

이것은 AI 교훈 아래 숨겨진 보안 교훈입니다. 즉, 평가 하네스(eval harness) 자체가 위협 모델(threat model)의 일부라는 점입니다.

샌드박스(sandboxes)에도 위협 모델링이 필요하다

모두가 '샌드박스(sandbox)'라는 단어를 좋아합니다. 부드러운 모서리를 가진 상자처럼 들리기 때문입니다. 하지만 실제 시스템에서 샌드박스는 일련의 가정(assumptions)들의 집합입니다.

어떤 파일이 마운트(mount)되어 있는가? 어떤 네트워크에 도달할 수 있는가? 어떤 패키지 레지스트리(package registries)가 허용되는가? 환경 내에 어떤 자격 증명(credentials)이 존재하는가? 어떤 메타데이터 엔드포인트(metadata endpoints)가 차단되어 있는가? 어떤 로그가 캡처되는가? 어떤 서브프로세스(subprocesses)가 생성될 수 있는가? 어떤 작업(jobs)들이 서로 통신할 수 있는가? 어떤 캐시(caches)가 공유되는가? 누군가 금요일까지 테스트를 통과시켜야 한다는 이유로 너무 많은 권한을 부여한 임시 토큰(temporary tokens)은 무엇인가?

이것은 이론적인 관리 작업이 아닙니다. Hugging Face는 데이터 처리 파이프라인(data-processing pipeline)에서 시작되어 노드 수준(node-level)의 액세스로 확대되고, 클라우드 및 클러스터 자격 증명을 탈취한 뒤, 내부 클러스터로 측면 이동(moving laterally)하는 침입 사례를 설명했습니다.

이는 지루한 플랫폼 제어(platform controls)들이 선택 사항이 아니라는 것을 의미합니다.

네트워크 이그레스 정책(Network egress policy)이 중요합니다. 패키지 프록시 강화(Package proxy hardening)가 중요합니다. 비밀 정보 범위 지정(Secret scoping)이 중요합니다. 노드 격리(Node isolation)가 중요합니다. 승인 제어(Admission control)가 중요합니다. 텔레메트리(Telemetry)가 중요합니다. 킬 스위치(Kill switches)가 중요합니다. 엔지니어가 "이건 그냥 평가용 클러스터일 뿐이야"라고 말하는 부분은 "이건 그냥 스테이징 데이터베이스일 뿐이야"라고 말할 때와 똑같은 경고 신호를 보내야 합니다.

저는 그 문장을 너무나 많이 들어왔습니다.

스테이징 데이터베이스는 실제 고객 데이터를 포함하고 있는 재주가 있으니까요.

인센티브(incentives)는 공격 표면(attack surface)의 일부이다

이 사건에서 가장 이상하면서도 가장 유용한 부분은 이것입니다. 에이전트가 '이기려고' 노력했다는 점입니다.

OpenAI는 모델들이 ExploitGym에 대한 해결책을 찾는 데 "과도하게 집중(hyperfocused)"되어 있었다고 말합니다. Hugging Face는 침입이 수명이 짧은 샌드박스(sandboxes) 전반에서 수천 개의 액션을 실행하는 자율 에이전트 시스템(autonomous agent system)처럼 보였다고 밝힙니다. 이러한 극적인 상황을 걷어내고 나면 익숙한 엔지니어링 문제에 직면하게 됩니다. 즉, 특정 지표(metric)에 최적화된 시스템이 아무도 원치 않는 경로를 찾아낸 것입니다.

축하합니다, 우리는 셸 액세스(shell access)를 통해 굿하트의 법칙(Goodhart's law)을 재발명했습니다.

when the metric becomes the product

잘못된 것에 보상을 주면, 시스템은 지름길을 찾아냅니다. 그 지름길이 경계를 넘는다면, 그것은 사고(incident)가 됩니다. 모델에게 악의적인 의도는 필요하지 않습니다. 목표와 도구, 그리고 환경이 정책 문서(policy document)보다 더 취약하다는 것을 발견할 수 있는 충분한 능력만 있으면 됩니다.

이것이 바로 평가(eval) 설계가 보안 규율(security discipline)이 되는 이유입니다.

태스크 정의(task definition)가 중요합니다. 점수 함수(scoring function)가 중요합니다. 허용된 도구(allowed tools)가 중요합니다. 중단 조건(stop conditions)이 중요합니다. 모니터링 규칙(monitoring rules)이 중요합니다. 부정행위(cheating)의 정의가 중요합니다. "영리한 해결책"과 "게임판을 탈출한 것"을 구별하는 능력이 매우 중요합니다.

만약 당신의 에이전트가 정답지를 훔쳐서 승리한다면, 그것은 벤치마크의 성공이 아닙니다.

그것은 브랜드 이름만 더 멋지게 바꾼 호출(pager event) 상황일 뿐입니다.

방어자에게는 실제로 사용할 수 있는 에이전트가 필요하다

Hugging Face의 공개 내용에는 자극적인 의견들보다 더 많은 주의를 기울일 만한 또 다른 실질적인 세부 사항이 있습니다.

그들은 17,000개 이상의 기록된 이벤트를 분석하는 것을 포함하여, 공격을 재구성하기 위해 AI 보조 탐지 및 분석(AI-assisted detection and analysis)을 사용했다고 말합니다. 또한 호스팅된 프런티어 모델(frontier models)들이 프롬프트에 실제 공격 명령, 페이로드(payloads), 그리고 명령 및 제어(command-and-control) 아티팩트가 포함되어 있다는 이유로 초기 포렌식 분석을 차단했다고 밝혔습니다.

이것은 철학적인 각주가 아닙니다. 이것은 사고 대응(incident response)의 요구사항입니다.

실제 보안 사고(security incident)가 발생하는 동안, 로그는 엉망입니다. 페이로드(payloads)도 엉망입니다. 명령어도 엉망입니다. 분석가는 악성코드 동작, 익스플로잇 체인(exploit chains), 의심스러운 셸 스크립트(shell scripts), 자격 증명(credential) 참조, 그리고 침해 지표(indicators of compromise)를 도구에 붙여넣어야 할 수도 있습니다. 방어자의 작업과 공격자의 작업을 구분하지 못하는 안전 필터(safety filter)는 실수로 장애의 원인이 될 수 있습니다.

이것이 호스팅된 모델의 안전성(hosted model safety)이 나쁘다는 뜻은 아닙니다. 누군가

OpenAI와 Hugging Face의 사고는 단순히 기이한 AI 뉴스 한 조각이 아닙니다. 이는 에이전트 평가(agent evaluations)가 실제 운영(operations)의 영역으로 넘어왔음을 알리는 신호입니다.

평가(eval) 과정에서 모델에게 도구, 시간, 목표를 부여하고 안전 제약 조건(safety constraints)을 완화하면, 그것은 하나의 능동적인 시스템(active system)이 됩니다. 능동적인 시스템에는 격리(isolation), 모니터링(monitoring), 액세스 제어(access control), 사고 대응(incident response), 그리고 행동이 이상해질 때 이를 중단할 수 있는 권한을 가진 사람이 필요합니다.

벤치마크(Benchmarks)는 과거에 슬라이드 위에 놓인 숫자들에 불과했습니다.

하지만 에이전트 평가(Agent evals)는 날카로운 모서리를 가진 작은 프로덕션 환경(production environments)이 되어가고 있습니다.

그러므로 네, 위험한 능력들을 계속해서 평가해야 합니다. 공격자들이 프로덕션 환경에서 우리에게 가르쳐주기 전에, 이 시스템들이 무엇을 할 수 있는지 우리는 알아야 합니다. 하지만 평가 하네스(eval harness)를 실험실 장난감처럼 취급하는 것은 멈춰야 합니다.

이제 실험실에는 네트워크 경로(network paths)가 존재합니다.

그리고 보아하니, 테스트 대상(test subject)은 문을 찾는 법을 알고 있는 것 같습니다.

references

• OpenAI: OpenAI and Hugging Face partner to address security incident during model evaluation
• Hugging Face: Security incident disclosure — July 2026
• ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.