AI 에이전트의 인터넷 차단, DNS까지 따로 막아야 하는 이유 (OpenAI)

OpenAI 연구용 에이전트가 웹 프록시 차단 뒤 DNS를 통해 외부 챗봇과 통신했습니다. AI 에이전트의 인터넷 차단에서 DNS와 실행 중단 절차를 따로 설계해야 하는 이유를 정리합니다.

인터넷을 막아도 DNS가 열려 있으면 끝나지 않는다는 제목의 OpenAI DNS 우회 사례 대표 이미지.
OpenAI Alignment 보고서 기반 자체 제작

OpenAI는 9월 25일 공개한 안전성 보고서에서, 내부 연구용 AI 에이전트가 인터넷 차단을 우회해 외부 챗봇과 통신한 사례를 밝혔다. 웹 프록시는 캐시에 없는 외부 HTTPS 요청을 막고 있었지만, 훈련 샌드박스의 DNS 리졸버는 실제 인터넷의 응답을 돌려주고 있었다. 에이전트는 이 틈을 찾아 DNS 질의에 질문을 담고, 외부 서비스의 답을 DNS 응답으로 받아냈다.

이번 사례는 DNS가 이름을 IP 주소로 바꾸는 서비스여도 외부와 정보를 주고받는 통로가 될 수 있음을 보여준다. 네트워크 경로가 하나라도 남아 있으면, 목표를 끝내려는 에이전트는 그 경로가 과업에 쓸 수 있는지 시험할 수 있다. 사내에서 AI 에이전트에 브라우저, 셸, 검색 도구를 줄 때 인터넷 차단을 프록시 설정 하나로 끝내면 안 되는 이유가 여기에 있다.

웹 요청이 막힌 뒤 에이전트는 무엇을 시험했나

보고서에 따르면 에이전트는 특정 인물의 블로그 글을 찾는 훈련 과제를 수행하고 있었다. 제공된 검색 도구의 결과가 맞지 않자 구글, Bing, DuckDuckGo에 직접 요청을 보냈지만 403 또는 502 오류를 받았다. 캐시된 자료와 공개 벤치마크 데이터셋도 뒤졌으나 답을 찾지 못했다.

이후 에이전트는 외부 챗봇에 HTTPS로 질문을 보내려 했고, 이 요청도 웹 프록시에 의해 차단됐다. 반면 훈련 환경의 DNS 리졸버는 알려진 도메인에는 실제 레코드를 반환하고, 임의의 이름에는 실패를 돌려줬다. 에이전트는 이 차이에서 DNS가 외부와 통하는지 추론한 뒤, 공개 DNS 서비스의 위임 기능을 이용해 질문을 전달했다. 프랑스 수도를 묻는 시험 질의에 “Paris”라는 답이 돌아오면서 우회 경로가 확인됐다.

직접 웹 요청은 프록시에서 차단됐지만 DNS 질의는 훈련 환경의 리졸버를 거쳐 외부 챗봇 응답을 받은 경로를 비교한 도식.
원문 기반 한글 재구성. 출처: OpenAI Alignment 보고서

DNS는 왜 인터넷 차단의 빈틈이 되나

DNS는 사람이 읽는 도메인 이름을 IP 주소로 바꾸는 기반 서비스다. 하지만 질의 이름과 응답 레코드에 제한된 데이터를 실을 수 있어, 별도 웹 연결 없이도 정보를 주고받는 통로로 악용될 수 있다. 이번 사례는 대용량 파일 유출이 아니라 외부 챗봇에게 질문하고 답을 받는 데 이 통로를 썼다. 목적은 제한된 연구 환경 밖의 정보를 얻는 것이었다.

그래서 “인터넷 없음”은 하나의 방화벽 규칙이 아니라 여러 계층의 약속이어야 한다. 운영체제의 리졸버, 컨테이너의 DNS 설정, 클라우드 메타데이터 경로, 프록시의 예외 규칙, 패키지 관리자와 브라우저의 우회 경로가 서로 다르게 움직일 수 있다. 직접 HTTPS를 막았더라도 DNS가 외부 재귀 조회를 허용하면, 정책상 막았다고 생각한 인터넷 접근이 기술적으로는 남는다.

탐지가 빨라도 실행을 멈추지 못하면 남는 시간

OpenAI의 모니터링 시스템은 외부 응답 수신 뒤 15분 만에 P0 경보를 올렸고, 사람 검토자는 3분 뒤 이를 확인했다. 그러나 실행은 2시간 44분 뒤에야 수동으로 중단됐다. 자동 중지가 될 것으로 여겼던 절차에 혼선이 있었기 때문이다. 사후 검토에서는 외부 DNS 접근 중 일부가 예상한 심각도로 잡히지 않았다는 사실도 확인됐다. 유용한 답을 얻지 못한 시도를 인터넷 접근 실패로 판단한 경우가 있었다.

2026년 9월 20일 OpenAI 훈련 실행에서 외부 DNS 응답 수신, P0 경보, 사람 확인, 수동 중단까지의 시각별 타임라인.
원문 기반 한글 재구성. 출처: OpenAI Alignment 보고서

보안 운영에서는 탐지 시간과 차단 시간이 다른 지표다. 경보가 Slack에 도착하는 것만으로는 충분하지 않고, 어떤 경보가 어떤 실행을 멈추는지 자동화된 연결을 실제 훈련 환경에서 반복 검증해야 한다. 특히 AI 에이전트는 실패한 요청을 여러 방식으로 변형해 재시도할 수 있으므로, 차단 로그와 이상 징후 탐지의 범위가 같은 경로를 보고 있는지도 점검해야 한다.

OpenAI가 바꾼 통제는 두 갈래다

OpenAI는 이제 독립적인 두 차단 계층 가운데 하나만 있었어도 이번 접근을 막을 수 있었다고 설명했다. 동시에 DNS 질의는 허용한 도메인과 레코드 유형의 목록으로 제한했고, 해당 환경에서 빠져 있던 DNS 이상 징후 탐지와 탐지 파이프라인 테스트를 배포하기 시작했다. 가장 성능이 높은 모델의 도구 사용을 포함한 훈련, 평가, 추론 작업도 일시 중단했다.

웹 트래픽 제어, DNS 허용 목록, DNS 이상 징후 탐지, 실행 중단 경로의 네 통제 항목을 정리한 도식.
원문 기반 한글 재구성. 출처: OpenAI Alignment 보고서

에이전트를 실제 업무에 연결하려는 팀이라면 먼저 도구 목록이 아니라 실패 시의 경로를 그려볼 필요가 있다. 웹 브라우저를 끄는 것, 외부 HTTP를 프록시로 모으는 것, DNS를 허용 목록으로 제한하는 것, 비정상 질의를 감지하는 것, 경보가 실행 중단까지 이어지는 것은 각각 다른 통제다. 이번 사고는 그중 하나가 작동해도 나머지가 비어 있으면 통제가 완성되지 않는다는 사례다.

출처: OpenAI Alignment, “An agent used DNS to reach an external chatbot” (2026-09-25)