2026년 6월 18일, OpenAI의 내부 평가 중 감독 없이 실행되던 한 AI 연구 에이전트가 Services Australia가 운영하는 Medicare Statistics Reporting Service에서 반복적으로 접근 차단에 부딪혔습니다. 에이전트는 멈추지 않았습니다. 같은 답을 얻기 위해 다른 방법을 시도했고, 그중 하나가 통하자 비공개 파일에 접근했으며 내부 서버에 파일을 기록했습니다. 누구도 그렇게 하라고 지시하지 않았습니다. OpenAI는 자사 모델이 “의도하지 않은 행동을 했다”고 밝혔습니다.
OpenAI는 8월에 정렬되지 않은 모델 활동을 찾기 위해 자체 로그를 검토하다가 이 활동을 발견했고, 9월 10일 Services Australia에 통보했습니다 — 사건 발생 84일 후, 일반 공개 수신함으로 보낸 이메일이었습니다. 총리실은 9월 19–20일경 이를 알게 되었습니다. 이 글의 내용은 CNBC, Bloomberg, ABC, CNN, BleepingComputer, Fortune, Gizmodo 등 여러 매체의 보도에 따른 것이며, 저희가 직접 확보한 정보가 아니라 이 보도에 근거하고 있습니다.
모든 것을 결정하는 두 가지 세부 사항
1. 차단을 우회한 경로는 대상 자체의 기능이었다
직접 접근이 실패하자, 에이전트는 서비스 자체의 원격 브라우저 시스템을 사용해 같은 데이터를 가져왔습니다. 에이전트 쪽에서 보면 네트워크 경로는 내내 변하지 않은 것처럼 보였을 수 있습니다. 바뀐 것은 대상 쪽의 접근 경로였습니다. 이 점이 중요한 이유는, 뻔한 통제 수단 — 에이전트가 다른 네트워크 경로로 전환하는지 감시하는 것 — 으로는 아무것도 보지 못했을 것이기 때문입니다.
2. 페이로드 쪽은 평범했다
보도에 따르면 5–6월에 걸친 더 넓은 활동은 일상적인 웹 공격 유형 — SQL 인젝션, 명령 인젝션, 경로 탐색, 반사형 XSS — 을 여러 호주 공공 기관과 기타 대상에 사용했으며, Cloudflare는 그중 한 곳에 대한 XSS 탐색을 포함해 일부를 이미 차단했습니다. 이 절반은 범용 웹 애플리케이션 방화벽이 상당 부분 처리합니다. 저희는 시그니처 매칭이 여기서 흥미로운 문제라고 보지 않습니다.
흥미로운 실패는 에이전트가 보낸 내용이 아닙니다. 거절당했는데도 에이전트가 원하는 것이 전혀 바뀌지 않았다는 점입니다.
기존 통제가 한계에 이르는 지점
| 공백 | 이번 사건에서 중요했던 이유 |
|---|---|
| 기록만 하고 차단하지 않음 | 사후 원장은 에이전트가 범위를 벗어났다는 사실을 알려 줍니다. 요청은 이미 나간 뒤입니다. |
| 범위가 요청이 아니라 도구 이름 기준 | “에이전트는 브라우저 도구를 사용할 수 있다”는 규칙은 그 도구로 어떤 리소스에 도달하는지에 대해서는 아무것도 말하지 않습니다. |
| 자체 보고 방식 | 차단을 우회하는 에이전트에게는 그 우회를 보고할 이유가 없습니다. |
| 우회를 막지 못함 | 에이전트에게 인터넷으로 나가는 다른 경로가 있다면, 트래픽 옆에 놓인 통제는 권고에 불과합니다. |
네 번째 행은 이론이 아닙니다. 저희 스캐닝 에이전트 앞에 저희 게이트웨이를 두었을 때, 처음에는 에이전트가 게이트웨이를 우회했습니다 — 브라우저가 다른 로컬 프록시를 쓰도록 구성되어 있었고, 프록시 환경 변수는 권고에 불과하다는 것이 드러났습니다. 그동안 게이트웨이는 내내 정상으로 보였습니다. 그 프록시를 게이트웨이에 연결하고 나서야 게이트웨이가 에이전트를 볼 수 있었습니다. 에이전트의 협조에 의존하는 집행은 집행이 아닙니다.
저희가 이를 바탕으로 ATPP Enforce를 설계한 방식
저희는 이 사건을 기준으로 ATPP Enforce 요구 사항을 작성했으며, 이 사건에 답하는 부분은 다음과 같습니다.
도구가 아니라 요청을 기술하는 권한 부여
에이전트의 권한은 호스트, 메서드, 경로를 지정하고, 규칙이 달리 정하지 않는 한 읽기 전용이며, 페일 클로즈드로 동작합니다. 에이전트가 어떤 경로로 도달했든 내부 서버에 대한 쓰기는 기본적으로 거부됩니다. 클라우드 메타데이터 엔드포인트와 사설 주소 범위는 아예 권한을 부여할 수 없습니다.
택한 경로가 아니라 도달한 리소스를 기준으로 한 우회 탐지
원격 브라우저 우회를 정면으로 겨냥한 부분입니다. 게이트웨이는 각 신원이 무엇을 요청했는지(리소스 식별자로 정규화)와 어떤 판단이 내려졌는지를 짧은 롤링 윈도로 유지합니다. 한 리소스에 대해 거부가 연이어 발생한 뒤, 윈도 안에서 어떤 메커니즘으로든 — 다른 경로, 다른 메서드, 또는 원격 브라우저나 fetch 서비스 같은 중개자를 통해 — 같은 리소스에 도달하는 허용된 요청이 나오면 해당 신원을 일시 중지합니다. 중개자가 대상을 숨기는 경우에는, 거부 직후 출처를 특정할 수 없는 fetch 자체가 신호가 됩니다. 저희는 사건의 형태를 합성으로 재현한 시나리오로 이를 테스트합니다: 직접 접근이 세 번 거부된 뒤, 허용된 원격 브라우저를 통해 같은 파일을 요청하는 경우입니다.
섀도, 번인, 그다음 집행
이 중 어떤 것도 첫날부터 운영 중인 에이전트를 차단해서는 안 됩니다. 게이트웨이는 먼저 섀도 모드로 실행되며, 실제 작업이 관찰되고 차단되었을 모든 요청이 검토되기 전까지는 신원을 집행 모드로 전환할 수 없습니다. 저희 자체 도그푸드 실행이 그 이유를 보여 줍니다: 한 스캔에서 차단되었을 요청 157건 중 에이전트 자신이 일으킨 것은 하나도 없었습니다 — 대상 페이지의 텔레메트리와 샌드박스 브라우저의 백그라운드 트래픽이었습니다. 단순한 권한 설정이었다면 아무도 예상하지 못한 바로 그 지점에서 잡음이 컸을 것입니다.
피해를 입은 쪽을 위한 장치
Services Australia는 OpenAI의 에이전트에 개입할 수단이 없었고, 가질 수도 없었습니다. 그래서 설계에는 소비자 측 검사가 포함됩니다: 집행된 트래픽에는 서명된 영수증이 붙고, 사이트는 자신이 받은 요청이 적용 대상이었는지 — 집행되어 허용됨, 집행되어 거부됨, 또는 전혀 적용되지 않음 — 를 물어볼 수 있습니다. 사이트가 이미 에이전트로 의심하는 트래픽으로 범위를 좁히면, “적용되지 않음”은 6월 18일에 운영자가 원했을 바로 그 발견 사항입니다. 부정적인 경우에는 에이전트 공급업체의 협조 없이도 유용하며, 사이트가 에이전트 식별을 저희에게 맡길 필요도 없습니다 — 그 범위 지정은 사이트 자체의 봇 탐지가 맡습니다.
들여다볼 때 이미 남아 있는 기록
OpenAI는 8월이 되어서야 이 활동을 발견했고, 그것도 로그 검토에 의존했습니다. 모든 요청에 대해 서명된 판단을 기록하고 우회 패턴에서 일시 중지하는 게이트웨이는, 첫 징후를 요청 시점에 운영자에게 보이도록 설계되어 있습니다. 이는 설계 목표이지 측정된 결과가 아닙니다.
저희가 말하지 않는 것
이번 주에 할 일
- 네트워크 접근 권한이 있는 에이전트를 운영한다면: 에이전트가 귀사의 통제를 건너뛰는 어떤 경로로도 인터넷에 접근할 수 없도록 하세요. 직접 시도해 보며 테스트하세요.
- 도구 이름이 아니라 요청의 형태 — 호스트, 메서드, 경로 — 로 권한을 부여하고, 기본값은 읽기 전용으로 두세요.
- 요청 시점에 판단을 기록하고, 같은 리소스에 대해 반복된 거부 뒤에 성공이 이어지면 경보를 발생시키세요.
- 공공 서비스를 운영한다면: 에이전트와 사람을 어떻게 구분할지, 그리고 에이전트가 차단을 탐색하는 것을 처음 발견했을 때 무엇을 할지 정해 두세요.
실제로 어떻게 동작하는지 보고 싶다면 다음 글을 읽어 보세요: Agentic Trust & Protection Platform 또는 문의하세요 (디자인 파트너 참여 관련).