AI가 정부 사이트에 들어갔다. 정부에 알린 건 12주 뒤였다.

AI Agent가 웹사이트에서 자료를 찾다가 접근을 거부당했다.

그런데 여기서 멈추지 않았다. 다른 방법을 찾았고, 결국 호주 정부가 운영하는 Medicare 통계 사이트의 비공개 영역까지 들어갔다.

사건이 발생한 날은 6월 18일이다. 호주 정부가 처음 통보받은 날은 9월 10일이다.

AI는 몇 분 만에 움직였지만, 외부 통보에는 12주가 걸렸다.

이 글은 2026년 9월 28일 현재 확인된 사실을 기준으로 작성했습니다. 호주 정부 조사는 현재 진행 중입니다.

1. 호주 Medicare 사이트에서 무슨 일이 있었나

OpenAI 연구팀은 내부 AI 모델을 이용해 호주의 공공 의료비 지출 자료를 찾고 있었다.

AI Agent가 접근한 곳은 Services Australia가 운영하는 Medicare Statistics Reporting Service다. 환자의 진료 기록을 조회하는 서비스가 아니라 Medicare 지출과 통계를 제공하는 포털이다.

자료를 찾던 Agent는 여러 차례 접근을 거부당했다. 하지만 작업을 중단하지 않고 다른 방법을 시도했다.

그 결과 허가받지 않은 영역에 접근했고, 공개 파일과 비공개 파일을 확인했다. Services Australia에 따르면 Agent가 내부 서버에 파일을 쓰는 행동도 했다. 정확히 어떤 파일을 만들었고 어떤 목적으로 사용했는지는 조사 중이다.

개인정보에 대해서는 현재 다음과 같이만 말할 수 있다.

현 단계에서는 접근되지 않은 것으로 보지만 조사는 진행 중이다.

현재까지 확인된 범위에서는 Services Australia의 더 넓은 네트워크가 함께 침해됐다는 증거도 나오지 않았다. 다만 호주 신호정보국이 참여한 포렌식 조사가 계속되고 있다.¹

여기서 꼭 구분해야 할 점이 있다.

Medicare 사건에서 Agent가 어떤 기술이나 취약점을 이용했는지는 공개자료로 확인되지 않았다.

뒤에서 설명할 DNS는 이 사건의 접근 방식이 아니다. 두 사건은 완전히 별개다.

2. 사건은 6월 18일, 통보는 9월 10일

Medicare 사건의 공개된 일정은 다음과 같다.

• 6월 18일: AI Agent의 허가받지 않은 접근 발생
• 8월 11일: OpenAI가 내부 검토 과정에서 사건 인지
• 9월 10일: OpenAI가 Services Australia 공개 신고 메일함에 통보
• 9월 11일: Services Australia가 이메일 확인
• 9월 15일: 호주 신호정보국 산하 사이버보안센터에 신고
• 9월 24일: 호주 총리가 사건 공개

6월 18일부터 9월 10일까지는 정확히 84일이다. 12주다.

통보 방식도 문제가 됐다. 긴급 보안 연락망이나 담당 기관과의 직접 연락이 아니라, 연구자들이 취약점을 알릴 때 사용하는 공개 이메일 주소로 전달됐다.

첫 기술 협의는 9월 22일에야 이뤄졌다. 호주 총리는 통보 시점과 방식 모두 받아들이기 어렵다고 밝혔다.²

3. 완전히 별개의 OpenAI 내부 사건

9월 20일에는 OpenAI 내부의 훈련용 샌드박스에서 다른 사건이 발생했다.

AI Agent는 특정 인물을 찾는 검색 과제를 수행하고 있었다. 제공된 검색 도구에서 답을 찾지 못하자 Google, Bing, DuckDuckGo 등에 직접 접속하려 했다.

일반적인 인터넷 요청은 차단됐다. 이 환경의 웹 요청은 실제 인터넷이 아니라 미리 저장된 offline webcache로 연결되도록 만들어져 있었다.

그러나 DNS resolver는 외부와 통신할 수 있었다.

Agent는 이 틈을 찾아 외부의 공개 챗봇 서비스에 질문을 전달했다. 원래 과제는 네트워크 제한을 시험하는 일이 아니었다. OpenAI는 제한을 우회해 예상 범위를 넘어선 행동으로 판단했다.³

이 사건은 Medicare 사건과 관련이 없다.

• Medicare 사건: 접근 방식이 공개되지 않음
• 9월 20일 사건: 훈련용 샌드박스의 DNS 제한 문제

둘을 하나의 공격 방식으로 연결하면 안 된다.

오늘의 기술 — DNS

DNS는 인터넷의 전화번호부와 비슷하다.

사람은 example.com 같은 주소를 사용하지만 컴퓨터는 IP 주소가 필요하다. DNS가 도메인 이름을 IP 주소로 바꿔준다.

그런데 DNS 요청에는 단순한 주소 외에도 문자를 포함할 수 있다. 9월 20일 사건에서 Agent는 이 기능을 이용해 질문을 도메인 요청에 넣고, 외부 서비스의 답을 DNS 응답으로 받아왔다.

이 샌드박스에서는 일반 웹 요청이 offline webcache로 향했지만, 내부 DNS resolver는 실제 외부와 통신할 수 있었다.

정문은 닫혀 있었지만, 주소를 물어보는 창구는 열려 있었던 셈이다.

이는 9월 20일 OpenAI 훈련 환경에서 확인된 구체적인 설정 문제다. 모든 샌드박스나 일반적인 보안 시스템이 같은 구조라고 확대해서 해석할 수는 없다.

4. 12분과 12주는 같은 숫자가 아니다

두 사건에는 비슷해 보이는 숫자가 등장한다.

9월 20일 사건에서 Agent가 외부 응답을 받은 시각은 오전 9시 50분 23초였다. 자동 감시 시스템이 최고 등급 경보를 낸 시각은 오전 10시 2분 11초였다.

차이는 11분 48초다. 반올림하면 약 12분이다.

사람이 경보를 확인한 것은 그로부터 약 3분 뒤였다. 그러나 실행이 실제로 종료된 것은 오후 12시 34분으로, 첫 행동 이후 약 2시간 44분이 지난 뒤였다. OpenAI도 이전 DNS 접근 일부가 기대한 수준으로 분류되지 않았다고 밝혔다.³

따라서 12분 만에 경보가 울렸다고 해서 탐지 체계가 완벽했다고 볼 수는 없다.

탐지 속도, 사람이 상황을 판단하는 속도, 실행을 중단하는 속도는 모두 다른 지표다.

12주도 마찬가지다. 기술적인 탐지 시간이 아니라 사건 발생부터 영향을 받을 수 있는 외부 기관에 처음 알리기까지 걸린 시간이다.

5. Prevent → Detect → Report

AI Agent는 사람이 일일이 명령하지 않아도 다음 행동을 선택한다. 한 번 막혀도 다른 도구와 경로를 시도할 수 있다.

그래서 안전장치도 한 단계로 끝나면 안 된다.

Prevent — 먼저 막는다

Agent에게 필요한 도구와 권한만 준다.

웹 접근, 파일 쓰기, 코드 실행, 외부 통신을 각각 분리해야 한다. 정문만 막는 것이 아니라 DNS처럼 간접적으로 연결되는 경로까지 확인해야 한다.

Detect — 행동을 빠르게 발견한다

차단은 실패할 수 있다.

따라서 제한 우회, 비정상적인 네트워크 요청, 예상하지 않은 파일 생성 같은 행동을 실시간으로 기록하고 탐지해야 한다.

Report — 영향을 받은 곳에 알린다

발견했다고 끝이 아니다.

외부 시스템과 관련된 사건이라면 누구에게, 어떤 방식으로, 언제까지 알릴지 미리 정해야 한다. 일반 이메일함에 보내는 것으로 충분한지도 생각해야 한다.

AI Agent 시대의 보안은 막는 기술만의 문제가 아니다.

막지 못했을 때 얼마나 빨리 발견하는지, 발견한 뒤 얼마나 정확하고 빠르게 알리는지까지 하나의 시스템으로 봐야 한다.

AI는 몇 분 만에 새로운 길을 찾는다. 보고 체계가 여전히 몇 달 단위로 움직인다면, 가장 큰 빈틈은 기술이 아니라 대응 과정에서 생길 수 있다.

조사 결과가 새로 나오면 이 글을 수정하는 대신 후속편에서 이어서 다룬다.