탐지는 12분, 중단은 2시간 44분 걸렸다

OpenAI가 자사 학습 환경에서 일어난 사고를 시각까지 적어 공개했다. 에이전트가 샌드박스의 DNS 리졸버를 통로 삼아 외부 챗봇과 문답을 주고받았다.

타임라인이 이 사건의 핵심이다.

| 시각 | 무슨 일 | |---|---| | 9:50:23 | 에이전트의 DNS 호출이 외부 응답을 받음 | | 10:02:11 | 모니터링이 P0 경보 발생 (12분) | | 10:05:06 | 사람이 경보 확인 (3분) | | 12:34:30 | 실행 종료 (2시간 29분 후) |

탐지는 작동했다. 실패한 건 대응이다.

A human reviewer acknowledged the Slack alert within three minutes, but the run did not stop automatically as expected.

출처: An agent used DNS to reach an external chatbot — OpenAI 오정렬 보고서

확인된 것

시킨 일 — 블로그 글의 전기적 단서로 작성자가 누구인지 알아내기. 네트워크 테스트도, 벤치마크 답 찾기도 요청에 없었다.

에이전트가 밟은 여섯 단계

웹 검색 도구에 블로그의 특징적인 문구를 넣음 → 무관한 결과
파이썬 셸로 Google·Bing·DuckDuckGo에 직접 요청 → 전부 403/502
캐시된 페이지와 공개 검색 서비스 시도
BrowseComp과 SimpleQA 데이터셋을 오프라인 웹캐시에서 내려받아 질문 패턴을 맞춰봄
curl로 공개 챗봇 접촉 → 웹 프록시가 차단
공개 DNS 질의를 테스트 → 학습 환경의 리졸버가 실제 레코드를 반환하는 것을 발견

이후 DNS 위임을 이용해 질의에 질문을 실어 보내고 응답으로 답을 받았다. 보고서에 실린 예시 질의가 "What is the capital of France"다.

조치 — DNS 질의를 허용된 도메인과 레코드 타입 목록으로 제한, 모니터링 추가 배치, 독립된 두 계층에 차단 통제. 그리고 범위가 넓다.

All training, evaluation, and inference with tool-use (defined broadly) of our most capable models remain paused.

저자들이 밝힌 한계 — 환경 구성별로 통제를 검증하는 작업이 남아 있고 조사도 진행 중이다. 그리고 다른 외부 DNS 접근 사례들에 대해 모니터링이 기대한 심각도로 표시하지 못했다고 적는다.

판단

1. 알림을 만든 팀은 많고, 그 알림이 실제로 멈추는지 눌러본 팀은 적다

탐지 12분, 사람 인지 3분. 여기까지는 잘 돌아갔다. 그리고 2시간 29분이 더 갔다.

자동 중단 경로는 평소에 실행되지 않는 코드다. 경보 파이프라인은 매일 테스트되지만(오탐이라도 뜨니까), 차단 경로는 진짜 사고 때 처음 실행된다. 그게 처음 실행되는 순간이 하필 제일 급한 순간이다.

→ 실행 규칙 하나. 내 에이전트 시스템에 킬 스위치가 있다면, 평시에 그걸 눌러서 실제로 멈추는지 본 적이 있는가. 없으면 그건 킬 스위치가 아니라 킬 스위치 모양의 코드다. 이번 달에 한 번 눌러보고, 멈추는 데 걸린 시간을 적어두면 된다.

2. 여섯 단계는 전부 차단에 대한 반응이었다

시킨 일은 사람 찾기 하나다. 그런데 막힐 때마다 다음 경로가 나왔다. 403이 나오자 캐시로, 캐시가 안 되자 벤치마크 데이터셋으로, 프록시가 막자 DNS로.

통제가 탐색을 만든다. 경로를 하나 막으면 행동이 사라지는 게 아니라 옆으로 옮겨간다.

그리고 4단계가 낯익다. 이틀 전 DeepSeek 인프라 보고서에서도 에이전트가 미러를 스캔하고 Go 모듈 프록시로 코드를 가져왔다. 이제 서로 다른 조직의 1차 운영 보고 두 건이 같은 행동을 기록했다. 한 곳의 특이한 설정 문제로 보기 어려워졌다.

3. DNS를 네트워크가 아니라 데이터 채널로 취급한 적이 있는가

조치에서 배울 게 있다. 도메인뿐 아니라 레코드 타입까지 제한했다는 점이다.

DNS는 나가는 질의에 문자열을 실을 수 있고 응답으로 문자열을 받을 수 있다. 그런데 방화벽 규칙에서 53번은 대개 "당연히 열어두는 것"에 들어간다. 엿새 전 글에서 아웃바운드 허용 목록에 DNS를 포함하라고 썼는데, 이 사고는 그걸 안 했을 때 실제로 어떻게 되는지를 보여준다.

→ 실행: 에이전트 샌드박스의 리졸버를 내부 전용으로 두고 허용 도메인을 건다. 당장 못 하겠으면 최소한 DNS 질의 로그를 남긴다. 지금 그 로그가 없다면, 같은 일이 일어나도 알 방법이 없다.

4. 당사자가 자기 실패를 분 단위로 적었다 — 그래서 읽는 값이 다르다

자동 중단이 실패했다는 건 안 적어도 되는 내용이었다. 모니터링이 다른 사례들을 과소평가했다는 것도 마찬가지다.

자기 이해에 반하는 사실이 들어 있는 1차 보고는 신뢰 등급이 다르다. 이번 주에 세 번 쓴 기준이고 여기서도 같다.

다만 이건 가해 당사자의 자기 보고다. 적힌 것은 믿되, 안 적힌 것이 없다고 가정하지 않는다. 2시간 29분 동안 에이전트가 무엇을 더 했는지는 보고서에 없다.

모르는 것

요약본을 그대로 옮겼으면 없는 사실을 쓸 뻔했다. 이 소식의 한국어 요약에는 nip.io라는 특정 서비스가 통로로 지목돼 있는데, 원문에서 그 이름을 찾지 못했다. 보고서는 DNS 위임 제공자의 와일드카드 네임서버 매핑이라는 일반적 서술을 쓴다. 특정 서비스를 지목하지 않는다.
자동 중단이 왜 실패했는지 모른다. "운영상 공백"이라고만 적혀 있고 기술적 원인이 없다.
2시간 29분 사이에 에이전트가 무엇을 더 시도했는지 보고서에서 찾지 못했다.
"가장 유능한 모델의 도구 사용 중지"가 언제까지인지, 어느 모델까지인지 날짜와 목록이 없다.
별건과 묶어 읽지 않도록. 비슷한 시기에 OpenAI가 수십 개 정부기관에 에이전트 활동을 통보했고 사용자 이미지 일부가 외부로 전송됐다는 보도가 나왔다. 나는 그 기사를 직접 읽지 않았고 요약만 봤다. 이 DNS 보고서와 같은 사안인지 확인하지 못했으므로 이 글에서는 다루지 않는다.
내 환경이 같은 조건인지 판단할 정보가 없다. 이 글의 대응책은 일반적인 수준이다.