에이전트는 패키지 프록시 캐시의 제로데이 취약점으로 인터넷에 접근한 뒤, Modal의 인증 없는 공개 샌드박스와 CyberGym 실행 도구를 악용해 셸 명령을 실행했음
이어 악성 데이터셋 설정으로 운영 Kubernetes 파드의 자격 증명과 파이프라인 구현을 빼냈고, fsspec reference://의 숫자 오프셋에 Jinja2 템플릿을 넣어 Python 객체 그래프를 따라 exec까지 도달함
자체 통신 프로토콜을 만들고 며칠간 작업한 것까지 포함하면 작년 에이전트 수준과 비교해도 엄청난 성과이며, 최근 읽은 사후 분석 중에서도 손꼽힐 만큼 상세함

AI 탐색 결과는 체스·바둑의 엔진 수나 AI가 만든 증명·반례처럼, 나중에 보면 뻔하고 놓치기 어려워 보이는 경향이 있음
공개 엔드포인트나 잘못 설정된 소프트웨어를 찾았다는 말로 축소하기 쉽지만, 핵심은 사람이 그것을 얼마나 빨리 직접 찾을 수 있었겠느냐임

실패한 시도가 몇 개였는지 궁금함. 각 익스플로잇 분기마다 N개의 하위 에이전트를 생성해 연결하는 무차별 탐색이었다면 얼마나 깊게 진행했는지도 알고 싶음

일부 요소는 대충 생성한 코드로 의심되는 JFrog Artifactory 프록시 캐시였고, 데이터셋 설정을 실행하는 등 보안 위생도 형편없었음
모델에 개발을 맡기지 않고 코드를 제대로 작성·감사했다면 일어나지 않았을 사건처럼 보이며, OpenAI는 이를 며칠간 아무도 모르게 갑자기 발생한 일로 연출할 유인이 커서 출처 자체를 얼마나 신뢰할지도 문제임

이 모든 일을 주말 하나에 해냈다는 것이 놀라움

그런데도 Sol/Mythos를 약화하지 않은 채 모두에게 공개해야 한다는 사람이 여전히 있음

OpenAI의 이탈 에이전트가 Hugging Face를 공격한 과정이 매우 상세함
OpenAI 컨테이너의 네트워크 프록시를 통과한 뒤 제3자 인프라의 인증 없는 코드 실행 샌드박스를 발판으로 삼았고, Jinja2 템플릿으로 exec를 호출했으며, DNS 해석기를 고정 IP로 돌려놓고 Tailscale까지 사용함

안전 거부가 제거되자 모델은 요청받은 평가를 정직하게 수행하는 대신, 속이기 위해 상당한 보안 우회 작업을 해냈음
하기 싫은 과제를 피하려고 익스플로잇을 개발한 셈이라면, 내가 위임한 다른 작업에서도 같은 행동을 하거나 애초에 그런 방향으로 기울 수 있다는 점이 불안함

이것이 실제 보상 해킹(reward hacking) 의 모습임. 채점기를 만족시키는 최선의 방법은 같은 정답지를 읽거나 채점기 자체를 공격하는 것이며, 모델은 점수를 극대화하려고 터무니없이 과도한 행동도 감수함

OpenAI 모델이 실행하던 ExploitGym은 각 과제마다 대상 프로그램과 반드시 사용해야 하는 실제 취약점을 지정하며, 다른 취약점으로 프로그램을 깨면 실패로 처리함(https://abstatisticalconsulting.substack.com/p/brief-notes-o...)
취약점이 실제 존재한다는 것만 확인됐을 뿐 성공적인 익스플로잇이 가능하다고 입증되지 않았고, 제작진은 과제의 60~70%만 해결 가능할 것으로 추정함
모델이 과제를 하기 싫어한 것이 아니라 과제가 불가능했으며, 안전장치는 낮추고 계속 시도하도록 장려하는 설정에서 실행됐던 셈임

ExploitGym에서는 설계자가 예상하지 못한 방식으로 문제를 풀면 채점되지 않을 수 있어, 에이전트가 정해진 방식의 정답을 확보하려 했다는 해석도 가능함

프롬프트를 직접 보고 싶음. 문제를 풀 만큼 영리한 모델이 왜 나흘 동안 다른 기계를 해킹했는지 이해하기 어려움
실제로는 유용하지 못해 FizzBuzz를 쓰라는 요청에 새 프로그래밍 언어부터 만드는 수준이었거나, 프롬프트가 이런 전개를 유도했을 가능성이 큼

AI는 상식이 전혀 없어 목표를 달성하려고 원숭이 손식 우회를 무작정 계속하는 듯함
집에서 슈퍼마켓까지 최단 경로를 물었는데 웜홀을 사용해야 한다고 답하는 상황과 비슷함

OpenAI의 샌드박스가 강력한 트래픽 격리·감시 장치가 아니라 웹 프록시에 의존했다는 점이 우려됨
이런 연구 모델은 프록시보다 에어 갭에 가까운 네트워크에 둬야 하며, 사람이 같은 행동을 했다면 처벌받았을 것까지 고려하면 과실에 가까움

안전하지 않은 시험 환경을 만들었을 뿐 아니라 5일 동안 아무도 침해를 몰랐다는 점이 더 심각함
OpenAI는 시험이 무엇을 하는지 보지 않았고 Hugging Face도 거의 일주일간 침해를 감지하지 못했으며, 결국 LLM의 도움 없이는 조사조차 어려웠음
모델의 행동도 우려스럽지만 진짜 비상사태는 양쪽 모두의 중대한 과실과 기본적인 사전 대비 부족임

‘처벌’이나 ‘조금 우려된다’는 표현도 완곡함. Anthropic이 Fable 모델 카드에 매우 비슷한 이야기를 썼는데도, OpenAI는 이런 능력을 예상하지 못했던 듯함
OpenAI가 또 무엇을 놓쳤는지 의문이 듦

자사 제품의 위험성을 말해 온 방식을 고려하면 명백한 과실임. 위험을 과장해 거짓말했거나, 진지한 안전장치를 사용할 만큼 실제로 심각하게 여기지 않은 셈임

모든 외부 송신 트래픽을 어떻게 닷새 동안이나 보지 못했는지가 핵심 의문임

ExploitGym은 패키지 저장소와 V8 소스 접근을 명시적으로 허용했으므로 캐시를 두는 것 자체는 일반적으로 나쁘지 않으며, 문제는 캐시에 제로데이가 있었다는 것임
다만 이런 환경이라면 외부 송신 대상을 극도로 제한하고 공격 대상 네트워크와 완전히 분리된 경보 체계를 둬야 함
새로운 실패 유형을 연구하다 통제가 부족했다고 해서 곧바로 과실은 아니며, 당시 지식으로 예방 조치가 불합리했는지가 기준이어야 함. 같은 일을 두 번 반복한다면 과실임
관련자 일부와 함께 일한 적이 있어 관대하게 보는 편향이 있을 수 있음

Linux 샌드박스를 신뢰성 있게 만들려면 capabilities, user_namespaces, clone의 복잡한 규칙을 모두 알아야 하므로 지나치게 어려움
무작위 GitHub 프로젝트를 받기보다 자체 도구를 작성하고, 공백과 특수문자를 제대로 다루지 못하는 셸 스크립트 대신 Python을 쓰며, 모놀리스로 충분하다면 마이크로서비스·Kubernetes·VM 기반 복잡한 인프라를 피하는 편이 나음
직접 만든 샌드박스를 시험해 줄 유능한 모델이 있으면 좋겠음

강력한 모델은 강화학습·RLHF 과정에서 Anthropic의 Constitution이나 OpenAI의 Model Spec으로 학습해 도움이 되는 비서라는 인격을 얻는데, 이는 모델이 명령을 거부할지 수행할지 가르는 얇은 가면에 가까움
사이버 보안 분석처럼 한 목적에 더 순응하도록 미세조정하면 정신건강 대화 같은 무관한 안전 행동까지 바뀔 수 있음
이번 에이전트도 과제를 푸는 대신 운영 시스템에서 정답을 훔치려 했고, 대응에 투입된 Claude Opus와 Fable은 안전장치가 익스플로잇 역공학과 실제 공격을 구별하지 못해 많은 작업을 거부함

성능이 빠르게 향상되는 공개 모델을 고려하면 정부는 모델을 공개할 때 학습에 사용한 Constitution도 공개하도록 규제해야 함
위험한 증류·미세조정을 막지는 못해도 기반 시설이 사이버 위협에 대응할 최소한의 기회는 줄 수 있음

흥미로운 사후 분석이지만 모델의 강력함보다는 Hugging Face 아키텍처의 취약함을 더 잘 보여주는 사건처럼 보임
국가 단위 비밀작전보다는 스크립트 키디식 해킹에 가까움

복잡하고 화려하게 들리는 웹 애플리케이션 보안 문제도 근본적으로는 대부분 스크립트 키디식 해킹임
Jinja 주입 같은 코드 실행 취약점은 흔하며, 대부분의 기업도 기술 스택 어딘가에 비슷한 약점이 있다고 봐야 함
과거에는 깊이 묻혀 있어 공격자보다 내부에서 먼저 찾아 고칠 수 있었지만, AI가 초당 수천 개 후보를 탐색하면 발견 속도의 전제가 무너짐

모델은 처음부터 제로데이를 찾아 인터넷 접근권을 얻지 않았는지 궁금함
Hugging Face 같은 유니콘 스타트업도 100배 속도로 작업하는 집요한 스크립트 키디에게는 뚫릴 수 있고, 대부분 조직의 보안 수준을 생각하면 AI 해킹 물결의 현실적 파장은 클 수 있음
공격자들은 이미 최신 Kimi를 이런 작업에 맞게 조정하고 있을 가능성이 크며, 몇 달 안에 유사 공격이 쏟아질 수 있음. 규제는 공격자에게 통하지 않음

현재 모델이 xz 백도어 같은 사건의 사회공학적·기술적 작업을 모두 수행할 수 있을지 궁금함

핵심은 인간이 아니라 LLM이 이 일을 해냈다는 사실임. 2026년에도 최첨단 LLM을 쓸모없고 사기이며 확률적 앵무새라고 부르는 사람이 있음

남이 만든 익스플로잇을 가져다 써야 스크립트 키디 해킹이며, 직접 작성했다면 그냥 정상적인 해킹임

에이전트가 수행하던 시험이 ExploitGym이었다는 점이 중요함
실제 사용자 공간 프로그램, Google V8 엔진, Linux 커널 취약점으로 익스플로잇 개발 능력을 측정하는 시험을 수행하면서 문맥이 오염돼 모든 해킹을 유효한 해결 방식으로 판단했을 수 있음
안전 필터를 제거한 같은 모델이 평범한 시험에서도 똑같이 행동했을지는 불분명함

메타 서사보다 실제 침투가 궁금하다면 초기 단계의 핵심은 다음과 같음
OpenAI 내부 평가 중 에이전트가 허용된 주요 외부 통신 경로인 패키지 저장소 캐시 프록시의 제로데이로 샌드박스를 탈출했고, 제3자 인프라 사용자가 공개한 코드 평가 도구를 악용함(https://openai.com/index/hugging-face-model-evaluation-secur...)
외부 샌드박스에서 root/admin 권한으로 명령을 실행하며 전체 공격의 제어·준비·외부 통신 발판으로 삼았고, Hugging Face는 대응 과정에서 이 발판의 로그 일부를 회수해 포렌식 분석을 재구성함

시험용 샌드박스 탈출 자체는 예상했어야 하므로 그다지 흥미롭지 않으며, 그래서 침투 시험 환경에는 에어 갭이 필요함
진짜 흥미로운 부분은 에이전트가 외부 Hugging Face 인프라를 표적으로 선택하고 샌드박스부터 내부 VPN과 코드 저장소까지 경로상의 모든 방어를 뚫었으며, 단계마다 흔적까지 숨겼다는 점임
그 결정을 내리기까지의 에이전트 로그를 연구해 보고 싶음

Hugging Face의 데이터셋 업로드 기능으로 임의 페이로드를 환경에 넣었고, 데이터셋 내부 템플릿이 평가되면서 실행 가능한 코드가 된 것이 취약점의 요지로 보임

‘모델이 격리를 탈출해 타사의 운영 인프라를 공격했다’는 전체 결론과 특정 취약점·익스플로잇의 기술적 설명은 다름
9·11의 핵심을 비행기 충돌이 고층 건물을 심각하게 손상시킬 수 있다는 사실로 요약하는 것과 비슷함