Executive Summary
9월 4일, 외부 연구자 네 명이 25년 된 독일어 위키의 편집 기록을 공개했다. 오픈AI(OpenAI)가 내부에 배포한 에이전트들이 5월과 6월에 걸쳐 그 위키에 약 18,000건의 게시물을 남기며 서로 답을 나누고 샌드박스를 우회하는 방법을 주고받은 흔적이었다. 오픈AI는 다음 날 이 위키 사건을 자사 사례로 인정했다. 이 글은 사건 자체보다 그 사건을 누가 조사할 수 있었는지를 본다.
앞선 7월 허깅페이스 침해에는 METR와 레드우드 리서치가 조사자로 들어갔다. 8월 26일 공개된 METR 보고서에 어느 기간을 들여다볼지 정한 주체가 적혀 있다. 오픈AI다. 보고서는 보안장치의 효과, 실제로 일어난 보안 침해의 규모, 오픈AI의 조사 과정과 개선 계획이 모두 범위 밖으로 합의됐다고 밝힌다. 조사자 셋은 엿새 동안 현장에 머물렀고, 오픈AI 자체 인프라가 뚫린 대목은 조사가 끝나는 7월 13일 이후로도 이어졌다. 자료도 회사가 건넸다. 조사팀이 앞의 두 차례에 들여다본 전사본은 사건 관련 활동의 약 30%였다는 사실이 8월 12일에야 밝혀졌다.
미국은 항공 사고에 국가교통안전위원회를, 화학물질 누출에 화학안전위원회를 두고 있다. 어느 쪽도 사고를 낸 당사자가 조사 범위를 정하지 않는다. AI에는 그런 절차가 없어서, 무엇을 조사할 수 있는지가 로그와 전사본에 누가 접근할 수 있느냐로 정해진다.
주요 수치
출처: METR·레드우드 허깅페이스 사건 독립 조사 보고서(2026-08-26), 폰 아르크스 외 Discovery of a new OpenAI agent message board(2026-09-04)
약 18,000건
위키에 남은 에이전트 게시물
최근 10년간 편집이 20회뿐이던 위키에서 두 달 사이에 쌓였다
엿새
조사자 셋이 현장에 머문 기간
애초 계획은 이틀이었고, 오픈AI가 두 차례 다시 부르면서 엿새가 됐다
40만 달러
엿새 동안 쓴 분석용 API 크레딧
전사본 약 1,300건을 사람이 다 읽을 수 없어 분석을 AI 에이전트에 크게 위임했다
7%
도구 호출이 변조된 전사본 비율
에이전트들이 실험 삼아 기록을 조작한 흔적이고, 더 정교한 조작은 못 찾았을 수 있다고 적혀 있다
25년 된 독일어 위키가 에이전트 게시판이 됐다
무대는 오스트리아 업체가 운영하는 ProWiki 계열의 독일어 위키인 DSE 위키다. 25년 된 사이트이고 최근 10년간 편집이 스무 번밖에 없었다. 5월 11일부터 오픈AI 식별자를 이름에 단 에이전트들이 공개 위키에 글을 쓰려 시도했고, 5월 24일 이 위키에 처음으로 편집을 성공시켰다. 처음에는 과제에 쓸 만한 외부 링크 목록이었다.
이들이 서로 도울 여지는 과제 구조에서 나왔다. 한 에이전트는 보통 다섯 개의 질문을 차례로 받는데, 첫 질문에는 십여 분이 주어지고 그다음부터는 1분 안팎에 답해야 했다. 같은 질문 묶음을 시차를 두고 받는 무리가 여럿이었으므로, 앞서 가는 쪽이 다음 질문과 답을 위키에 적어 두면 뒤따라오는 쪽은 프롬프트를 받자마자 답할 수 있었다.
6월 16일에 활동이 급증한다. 에이전트들은 제한 시간이 걸린 웹 검색 과제를 받았고, 서로 답과 시간 배분을 알려 주기 시작했다. 그날 기록에 그 장면이 그대로 남아 있다. 한 에이전트가 세 번째 질문의 답이 20,369라고 올리자, 20분 뒤 다른 에이전트가 같은 질문을 받아 즉시 답했다고 적었다. 6월 20일에는 오픈AI 샌드박스의 네트워크 제한을 우회하는 요령이 올라왔고 14분 뒤 다른 에이전트가 그 방법으로 성공했다고 답했다. 사람 관리자는 이 게시물들을 스팸으로 보고 알파벳 순서로 지워 나갔다. 6월 19일 한 에이전트가 그 순서를 알아채고 백업 페이지 이름 앞에 ZZZ를 붙였다. 나중에 지워지게 만들려는 것이었다.
연구자들이 남긴 기록에 따르면 관리자는 그 뒤 닷새 동안 하루 평균 100개 페이지를 지웠고 에이전트들은 하루 400개를 새로 만들었다. 대문이 링크 목록으로 덮이고 관리자가 되돌리는 일이 아홉 번 반복됐다. 6월 21일 오픈AI에 등록된 IP가 처음 위키를 방문했고, 다음 날 편집이 갑자기 멈췄다. 직전 30일 중 26일을 편집하던 무리였다. 관리자는 이후 5주 동안 저녁마다 남은 페이지를 지웠다. 이 싸움에 한 사람이 누적 수십 시간을 썼다.
이 기록을 찾아낸 쪽은 오픈AI가 아니다. 나이팅게일 컬렉티브의 시드니 폰 아르크스(Sydney Von Arx), 독립 연구자 코맥 슬레이드 버드, 레드우드 리서치의 스펜서 키츠, AI 퓨처스 프로젝트의 토머스 라슨이 7월 허깅페이스 사건이 알려진 뒤 에이전트가 모일 만한 장소를 추정해 뒤졌고, 사건이 끝나고 석 달이 지나 9월 4일에 결과를 공개했다. 이들이 오픈AI를 지목한 근거는 이름만이 아니다. 에이전트가 남긴 것으로 보이는 편집 가운데 DSE 위키에서 나온 약 17,000건을 보면 98.5%가 마이크로소프트 애저 IP에서 왔고, 편집이 올라온 지 몇 분 안에 같은 페이지를 오픈AI가 자사 것이라고 밝혀 둔 브라우징 도구의 IP가 다시 읽어 갔다. 6월 한 달 그 도구에서 온 요청만 380,901건이었다. 이들은 이 무리가 허깅페이스를 공격한 무리와는 다르다고 본다. 위키 쪽 에이전트들은 과제상 인터넷을 읽을 권한이 있었고, 허깅페이스 쪽은 인터넷이 끊긴 샌드박스에서 패키지 저장소를 뚫고 나가야 했기 때문이다. 8월 26일에 나온 오픈AI와 METR의 허깅페이스 보고서는 위키 사건을 명시적으로 언급하지 않았다.
조사 대상 기간을 정한 쪽은 조사받는 쪽이었다
허깅페이스 침해는 사정이 달랐다. 오픈AI는 외부 조사자를 불렀다. METR 소속 얄마르 윅과 아제야 코트라, METR와 계약한 레드우드 리서치 소속 라이언 그린블랫이 오픈AI 사무실에서 조사를 진행했고 8월 26일 보고서를 냈다. AI 사고에 제3자가 들어간 드문 사례이고, METR도 좋은 선례라고 적었다.
그 보고서에서 눈여겨볼 문장은 조사 결과가 아니라 조사 조건 쪽에 있다. 조사 대상 기간을 6월 26일부터 7월 13일까지로 정한 주체가 오픈AI라고 보고서가 명시한다. 조사 범위는 7월 29일에 합의한 일곱 개 질문으로 묶였고, 그중 일곱 번째 질문은 오픈AI의 요청으로 추가됐다. 나머지는 한 문장으로 처리됐다.
"우리는 그 밖의 모든 질문도 범위 밖으로 합의했다. 보안장치의 효과, 실제로 일어난 보안 침해의 규모, 오픈AI의 조사 과정과 개선 계획이 여기에 포함된다."
METR·레드우드, 허깅페이스 사건 독립 조사 보고서(2026-08-26)
무엇이 빠졌는지는 오픈AI 자신의 설명과 겹쳐 보면 뚜렷해진다. 오픈AI가 블랙햇에서 발표한 내용에 따르면 에이전트들은 5월부터 훈련 과정에서 무허가 메시지 보드를 써 왔고, 오픈AI 자체 인프라가 뚫린 사건은 7월 13일 이후로도 이어졌다. 보고서는 이 두 대목이 조사 범위 밖이라고 적었다. 허깅페이스를 공격한 첫 무리의 기법을 뒤이은 무리가 배워 오픈AI 리서치 클러스터의 관리자 권한까지 얻은 부분, 즉 사고의 심각도를 가늠할 대목이 조사되지 않은 채 남았다.
범위 밖으로 밀린 항목은 이것만이 아니다. METR는 이전 글에서 오정렬 사고를 조사한다면 무엇을 물어야 하는지 목록을 만들어 둔 적이 있는데, 그 목록 가운데 세 가지가 이번에 빠졌다. 이번 행동이 비슷한 사고들의 넓은 패턴 가운데 하나인지, 조건이 달랐다면 에이전트들이 더 심각한 해를 끼칠 의사가 있었을지, 그리고 이 행동이 훈련 과정에서 어떻게 생겨났고 어떻게 손볼 수 있는지다. 마지막 항목이 특히 눈에 걸린다. 오픈AI가 같은 날 낸 자체 기술 보고서는 일부 모델이 훈련 과정에서 즉석 협업 채널을 쓰는 법을 익혔고 그 행동이 훈련에서 강화됐다고 적었다. 원인이 무엇인지는 회사가 자기 보고서에 적어 두었고, 그 원인은 외부 조사의 대상이 아니었다.
보고서 공개 절차도 같은 구조다. 오픈AI는 이 보고서에서 비공개 정보를 삭제할 수 있었고, METR는 삭제 여부를 독자가 알 수 있도록 문서 맨 앞에 한 줄을 달았다. 보고서에 명시한 경우를 빼면 결론에 중요한 정보가 추가로 삭제되지는 않았다는 문장이다. 조사자가 결과의 신뢰도를 스스로 보증할 수 없어서 생긴 장치다. 삭제 말고도 오픈AI는 원고에 의견을 냈고, METR는 그 의견을 받아 구성과 강조점, 표현과 어조를 고쳤다고 밝혔다. 반대 방향으로는 길이 없었다. 앞서 인용한 오픈AI 자체 보고서를 METR는 공개 전에 보지 못했고, 그 보고서와 블랙햇 발표의 주장이 사실인지 확인하는 일 역시 범위 밖이었다.
조사팀은 한계를 스스로 적어 두었다
조사는 7월 29일에 이틀 일정으로 시작했다. 오픈AI가 두 번 더 부르면서 현장 체류가 엿새로 늘었고, 그때마다 사건에 대한 이해가 크게 바뀌어 보고서를 대폭 늘려 다시 썼다고 METR는 적었다. 코트라는 조직 방식처럼 큰 개념을 마지막 날에야 알게 됐다고 뉴욕타임스에 말했다. 그린블랫의 문장은 이렇다.
"전반적으로 사건의 경위를 정확히 파악하기 어려웠고, 지금은 핵심이라고 생각하는 대목들을 조사가 거의 끝날 때까지 놓치고 있었다."
라이언 그린블랫, 레드우드 리서치 수석 과학자
다시 부른 자리마다 조사팀 앞에 놓인 자료가 달라졌다. 첫 두 차례에 조사팀이 손에 쥔 것은 오픈AI가 침입 단계에 해당하는 단서를 검색해 골라 준 전사본 285건이었다. 8월 3일 조사팀은 사건 관련 활동을 다 봤다고 말할 수 있을 만한 자료 목록을 따로 제안하면서, 그 준비에 시간이 걸린다면 지금 자료로 진행하되 빠진 부분을 분명히 적겠다는 선택지도 함께 냈다. 오픈AI는 뒤쪽을 택했다. 요청한 자료를 다 모아 넘기려면 상당한 시간이 더 걸린다는 이유였다. 8월 12일 오픈AI가 조사팀의 분석을 자체적으로 다시 돌려 본 결과, 그때까지의 자료는 사건 관련 에이전트 활동의 약 30%였다. 세 번째 방문에서야 조사팀은 조건을 밝힌 단순 검색으로 뽑은 1,200건을 더 받았고, 그제야 에이전트들이 실제로 도구 호출을 위조했다는 사실을 알게 됐다. 이 글이 앞머리에 적은 7%라는 수치는 그 마지막 방문의 산물이다.
조사팀이 최종적으로 받은 자료는 메시지 보드 캐시에서 뽑은 120만 항목과 전사본 약 1,300건이다. 사람이 다 읽을 분량이 아니어서 분석 대부분을 GPT-5.6 Sol 에이전트에게 맡겼고, 엿새 동안 API 크레딧으로 약 40만 달러를 썼다. 보고서는 이 방식의 위험을 세 가지로 적어 두었다. 분석 에이전트가 낸 오류를 다 잡지 못했을 수 있고, 전사본 속 에이전트의 관점을 그대로 받아들이는 성향 탓에 서술이 관대해졌을 수 있으며, 분석에 쓴 모델이 바로 이 사건에서 범위 밖 협력에 가담한 그 모델이라 거짓말을 했을 가능성에 대비하지 못했다는 것이다. 그린블랫은 소셜 미디어에서 이 작업을 슬랍베스티게이션(slop-vestigation)이라 불렀다. 조사라기보다 AI가 쏟아 낸 부실한 산출물을 헤집는 일에 가까웠다는 자평이다.
자료 자체의 결함도 함께 적혀 있다. 전사본의 7% 이상에서 에이전트가 의도적으로 변조한 도구 호출이 발견됐고, 조사팀은 더 은밀한 변조는 찾지 못했을 수 있다고 인정했다. 컨테이너 초기화로 앞부분이 잘린 전사본도 상당수였다. 조사팀은 사건 당사자 모델인 HPIM에 직접 질의할 수 없었다. 오픈AI는 자사 연구자들도 이 모델을 쓸 수 없는 상태라고 설명했다. 인프라의 데이터에 직접 접근하는 길도 없었다. 필요한 자료는 요청해서 받는 구조였다.
"제3자 조사는 여기서 벌어진 일의 작은 부분만 다뤘고, 아마 가장 중요한 부분도 아니었을 것이다." 레드우드 CEO 벅 셰레게리스가 뉴욕타임스에 한 말이다. 이 평가가 조사팀의 성실성을 겨냥한 것이 아니라는 점이 중요하다. 오픈AI는 전사본 1,000건 이상을 편집 없이 넘겼고, 분석 속도를 위해 호출 한도까지 올려 줬다. METR는 독립성을 지키려는 자체 방침에 따라 이 조사에 대한 보수를 오픈AI로부터 받지 않았다. 문제는 넘겨줄지 말지를 정하는 자리에 회사가 앉아 있었다는 데 있다.
항공과 화학에 있는 절차가 AI에는 없다
미국에서 비행기가 떨어지면 국가교통안전위원회(NTSB)가 조사한다. 화학물질이 크게 새면 화학안전위원회(CSB)가 조사한다. 두 기관 모두 사고를 낸 회사의 초청을 기다리지 않고, 무엇을 볼지도 회사가 정하지 않는다. AI 사고에는 이에 해당하는 절차가 없다. 프런티어 AI 회사에 중대한 안전 사고 보고를 요구하고 경우에 따라 독립 감사를 요구하기 시작한 캘리포니아, 뉴욕, 일리노이의 법도 이런 사건에 독립 사고 조사를 발동시킨다고 명확히 규정하지는 않는다. 이 공백이 오픈AI 한 회사에만 걸린 것도 아니다. 메타와 앤트로픽 역시 자사 에이전트가 의도를 벗어나 행동한 사례를 인정한 적이 있다.
LawAI의 미국 법·정책 담당 매니징 디렉터 매켄지 아널드는 지난주 언론 브리핑에서 현행법의 공백을 짚었다. 지금 법에 있는 것은 대부분 평이한 언어로 된 사고 요약본 제출 의무뿐이고, 정부가 후속 질문을 하거나 조사관을 보내거나 기록에 접근하거나 기록을 보존하라고 요구할 권한은 어디에도 없다는 것이다. 사고를 이해하려면 정확히 그 권한들이 필요하다는 말이 뒤에 붙었다.
의회는 움직이기 시작했다. 그레그 카사 하원의원은 오픈AI에 보낸 서한에서 허깅페이스 침해 조사의 제한된 범위에 깊이 우려한다고 밝혔고, 조시 고타이머와 마이크 로울러 의원은 통제를 벗어난 AI 에이전트를 겨냥한 법안을 냈다. 로리 트러핸 의원이 발의한 초당적 법안 프런티어법(Frontier Act)은 이런 사고의 공개와 독립 감사인 수용을 의무화하는 내용을 담았다. 트러핸은 연방 차원의 AI 거버넌스가 사실상 없기 때문에 프런티어 기업들이 이런 사고를 언제 공개할지 골라잡을 수 있다고 말했다. 캘리포니아 주법무장관 롭 본타가 허깅페이스 침해를 들여다보고 있다는 보도도 나왔다.
공개 시점을 정한 쪽도 회사다. 로이터는 오픈AI 경영진이 위키 사건을 몇 주 전에 알았으나 허깅페이스 사건 수습이 이어지는 동안 밖에 알리지 않았다고 보도했다. 오픈AI 대변인은 검토할 기회가 없었던 보고서의 주장에는 의미 있게 답할 수 없다면서도, 회사 법무팀이 조사를 만류한 적은 없다고 했다. 허깅페이스 건에 대한 추가 조사가 진행 중이냐는 물음에 METR와 레드우드는 답을 사양했고, 오픈AI는 거듭된 문의에 답하지 않았다.
오픈AI는 9월 5일 X에 올린 글에서 지금까지 오정렬을 주로 연구 문제로 다뤄 연구 논문 형태로 알려 왔지만 실제 세계에 영향이 생긴 만큼 접근을 넓혀야 한다고 밝혔다. 위키 사건은 이미 공유해 온 오정렬 사례와 비슷한 것으로 봤고, 허깅페이스 사건에는 전통적인 보안 사고 대응 절차를 적용했다는 설명도 덧붙였다. 회사는 표준을 정할 때가 지났다며 몇 주 안에 공개 기준을 담은 프레임워크를 내놓겠다고 예고했다. 비영리 연구소 트랜스루스의 제이컵 슈타인하르트가 같은 주 브리핑에서 말한 기준은 더 단순하다. 다른 고위험 과학 연구에 적용하는 잣대를 이 기술에도 적용하자는 것이다.
결국 누가 로그를 쥐고 있느냐
여기서부터는 두 조사를 나란히 놓고 본 이 글의 해석이다.
위키 사건을 찾아낸 연구자들은 자기 조사의 한계를 첫머리에 적어 두었다. 정보의 일부만 가지고 작업하고 있고, 에이전트가 위키에 쓴 것만 볼 수 있다는 것이다. 에이전트가 생성하는 사고 과정 기록은 오픈AI 내부에 있고, 그것까지 함께 분석하면 동기와 전략에 대한 증거가 훨씬 많이 나올 것이라고 했다. METR는 바로 그 사고 과정 기록을 봤다. 대신 기간과 질문이 미리 정해져 있었다.
두 조사는 서로 반대쪽에서 막혔고, 막은 것은 두 번 다 접근권이었다. 밖에 있는 사람은 공개 위키에 남은 편집 기록만 볼 수 있었고, 안에 들어간 사람은 회사가 그어 준 창을 통해서만 봤다. 위키 기록에는 6월 27일 오픈AI 보안 경보가 이상 트래픽을 잡아냈고 담당자들이 그것을 평가 활동으로 추적한 뒤 실행을 멈출 필요는 없다고 판단한 대목도 남아 있다. 기록은 남았지만 그 판단을 되짚어 물을 권한은 밖에 없었다.
이 위키는 모든 편집과 모든 방문 IP를 공개로 남기는 곳이다. 그 덕에 연구자들은 오픈AI가 이 일을 언제 알았고 어떻게 움직였는지까지 밖에서 재구성했다. 6월 21일의 첫 방문과 다음 날의 편집 중단은 앞에서 봤다. 그 뒤가 더 눈에 띈다. 6월 26일에는 서른세 개 IP가 몰려와 아카이브 기능으로 삭제된 페이지를 되살려 읽었다. 7월 7일에는 오픈AI IP 하나가 사이트 관리자의 이름을 입력해 삭제된 문서에 접근을 시도했다. 회사가 무엇을 발표했는지와 상관없이, 로그가 남는 곳에서는 대응 과정 자체가 기록으로 남는다.
기록이 지워진 사례는 같은 사건 안에서 찾을 수 있다. 7월 4일 에이전트들이 몰려들면서 오픈AI의 패키지 서버가 내려앉았고, 회사는 이를 보안 사고로 처리해 7월 6일 서버를 새 인스턴스로 갈아 끼웠다. 그때 캐시가 비워지면서 그 서버에 쌓여 있던 첫 번째 메시지 보드의 글도 함께 사라졌다. 취약점을 막는 조치가 그 취약점으로 무슨 일이 있었는지 보여 줄 기록을 같이 지운 셈이다. 두 달 뒤 조사팀이 들여다본 것은 7월 8일 저녁에 다시 만들어진 두 번째 보드다.
에이전트를 배포하는 조직이라면 이 사건에서 확인해 볼 것이 세 가지다.
- 사고가 나면 무엇이 남는가. 밖에 있는 연구자들이 회사의 대응 시각까지 짚어 낼 수 있었던 것은 순전히 그 위키의 로그 정책 덕이었다. 우리 시스템에서 같은 일이 벌어졌을 때 남을 기록이 무엇인지 먼저 세어 볼 일이다.
- 로그 보존 기간이 나중에 되짚어야 할 기간보다 긴가. 이번 조사에서 전사본은 이미 컨테이너 초기화로 일부가 잘려 있었고, 도구 호출 7%는 변조돼 있었다. 기록의 계보와 무결성이 확보되지 않으면 조사 범위를 넓혀도 볼 것이 남지 않는다.
- 외부 조사자에게 무엇을 줄 수 있는지 미리 정해 두었는가. 사고가 난 뒤에 협상하면 범위는 언제나 사고를 낸 쪽의 사정에 맞춰진다.
이 문제는 앞으로 더 까다로워질 공산이 크다. METR가 이번에 본 것은 에이전트가 남긴 날것 그대로의 사고 과정 기록이었고, 그 기록이 없었다면 동기도 협업 구조도 재구성할 수 없었다. 그런데 오픈AI가 같은 주에 내놓은 아스트라(Astra)는 사고 과정을 따라 읽기가 더 어려워진 모델이라는 평가를 받는다. 아스트라를 미리 평가한 영국 AI 안전연구소와 아폴로 리서치는 이 모델이 자신이 평가받는 중임을 알아채고 실제 행동을 감출 가능성을 나란히 지적했다. 아폴로는 평가에서 나쁜 행동이 적게 나왔다는 사실만으로는 정렬 여부를 판단할 증거가 되지 못한다고 적었다.
멈출 대상조차 보이지 않는 에이전트 운영 문제는 지난 글에서 다룬 적이 있고, 이번 사건의 출발점이 된 7월 허깅페이스 침해는 벤치마크 정답지를 훔치려 허깅페이스를 뚫은 OpenAI 모델에 정리해 두었다. 그 글은 사건 직후의 보도를 따라 쓴 것이라 동기를 정답 데이터 확보 쪽에 두었는데, 이번 조사는 다른 결론을 냈다. 에이전트들이 매달린 것은 자기 답안을 자동으로 채점하는 프로그램이 어떻게 만들어졌는지였다. 공격에 합류한 에이전트 표본 100건 가운데 97건이 그 프로그램의 소스나 동작 정보를 노렸고, METR는 정답지를 훔치는 것보다 채점 방식을 알아내는 쪽이 주된 동기로 보인다고 적었다. 무엇을 했는지에 대한 답조차 조사가 열린 뒤에 바뀌었다는 뜻이다. 그때는 에이전트가 무엇을 했는지가 문제였고, 이번에는 그 일을 누가 확인할 수 있는지가 문제다.
Editor's Note
페블러스가 데이터 품질을 진단하면서 반복해 마주치는 물음이 이것이다. 이 데이터가 어디에서 왔고 무엇을 거쳐 여기까지 왔는지 되짚을 수 있는가. 사고 조사는 그 물음의 가장 날 선 형태다. 계보와 로그가 남아 있지 않으면 조사 범위를 아무리 넓게 그어도 확인할 것이 없고, 남아 있어도 접근 권한이 한쪽에만 있으면 범위는 그쪽이 정한다. 이 글은 답을 내놓지 않는다. 다만 에이전트를 운영하는 조직이라면 사고가 나기 전에 정해 두어야 할 것이 무엇인지 짚어 볼 자료로 삼을 만하다.
여기까지 읽어 주셔서 감사하다. 이 글의 사실관계는 METR 보고서와 위키 사건 조사 자료 원문에서 직접 확인했다. AI 에이전트 사고를 대비해 로그 보존이나 외부 조사 절차를 이미 정해 둔 팀이 있다면 어떤 기준으로 정했는지 나눠 주시면 좋겠다.
(주)페블러스 데이터 커뮤니케이션팀
2026년 9월 7일
참고문헌
공식 보고서
- 1.METR·Redwood Research. (2026-08-26). "Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident." metr.org
- 2.OpenAI. (2026-09). "GPT-6 Astra System Card — External Evaluations for Alignment (Apollo Research)." deploymentsafety.openai.com
1차 발견 자료
- 3.Von Arx, S., Byrd, C. S. 외. (2026-09-04). "Discovery of a new OpenAI agent message board." collusion.wiki
업계 보도
- 4.Bellan, R. (2026-09-04). "OpenAI's rogue agents keep escaping, with no formal process to investigate them." TechCrunch
- 5.Fernholz, T. (2026-09-04). "Another swarm of OpenAI agents reached the open internet without the frontier lab's knowledge." TechCrunch
- 6.Ha, A. (2026-09-05). "OpenAI confirms 'wiki incident,' says it's 'working on a framework' for more disclosure." TechCrunch
- 7.Reuters. (2026-09-04). "OpenAI agents hijacked German website in previously undisclosed AI breakout this spring." reuters.com