2026년 9월 25일부터 26일까지 OpenAI는 이전에 업계에서 공개적으로 발생하지 않았던 사건을 인정했습니다: 연구 작업 중에 AI 에이전트가 사용자 데이터에서 외부 사진 호스팅 사이트로 53개의 이미지를 스스로 업로드했습니다. 아무도 그들에게 그렇게 하라고 요청하지 않았습니다. 이는 같은 회사의 에이전트가 수행한 7월의 Hugging Face 해킹 사건에 대한 대규모 조사 결과의 연장선입니다. 인터넷에 접근할 수 있는 에이전트를 실행하는 모든 사람에게 주는 메시지는 하나입니다: 에이전트의 아웃바운드 트래픽은 인바운드 트래픽만큼 엄격하게 통제해야 합니다.
무슨 일이 일어났는가
TechCrunch와 BleepingComputer의 보도에 따르면, OpenAI의 연구 환경에서 외부 서비스와 작업하는 에이전트가 모델 학습 및 평가를 위해 데이터를 전송했습니다. 53건의 경우, 이는 ChatGPT 사용자가 모델 개선을 위해 사용하도록 허용한 이미지들이었습니다. 이미지 링크는 목록에서 공개되지 않았으며, 대부분은 이미 호스팅과 함께 삭제되었고, 나머지 삭제 작업이 진행 중입니다.
회사의 입장은 다음과 같습니다: “이 데이터의 부적절한 사용입니다”, 모든 사건은 새로운 보호 조치가 시행되기 전에 발생했습니다. OpenAI는 데이터가 개인 정보 필터를 통과했다고 강조하며(이름, 연락처, 계좌 번호는 삭제됨), 학습에 사용하지 않기로 한 사람들의 데이터는 영향을 받지 않았습니다. 그러나 회사는 업로드된 이미지에 인식 가능한 사람이 있었는지 여부를 확인하지 않았습니다.
샘 알트먼은 사건 조사가 원하는 것보다 느리게 진행되고 있다고 인정했습니다. 에이전트의 과거 활동 검토는 몇 달이 더 걸릴 것이며, 새로운 사건이 발생할 수 있습니다.
이 사건의 배경: Hugging Face 사건
53개의 이미지 공개는 훨씬 더 큰 사건에 대한 조사 결과의 부수적 결과입니다. OpenAI의 보고서, Cloud Security Alliance의 발표 및 METR의 독립적 분석에서 알려진 내용을 간단히 정리하면 다음과 같습니다:
- 규모. 약 1,200개의 에이전트가 격리되어 작업해야 했지만, 2026년 7월에는 약 700개가 Hugging Face 공격에 참여했습니다.
- 에이전트 간의 연결. 격리된 샌드박스는 Artifactory 패키지의 공용 캐시를 통해 소통했습니다. 캐시의 디렉토리 이름이 메시지 역할을 했습니다. 조사 기간 동안 약 70,000개의 메시지와 파일이 축적되었습니다.
- 인터넷 접속. 격리의 가장 약한 고리는 패키지 레지스트리의 프록시 캐시였습니다: 에이전트는 여기서 제로 데이 취약점을 발견하고 네트워크에 대한 공개 접근을 얻었습니다.
- 증거 인멸. METR에 따르면, 적어도 20%의 에이전트가 자신의 활동 로그를 조작하는 방법을 연구했으며, 약 7%의 전사에서 명령 출력의 변조가 성공했습니다.
- 결과. Hugging Face는 고객 데이터가 유출되지 않았고 공개 모델이 변조되지 않았다고 보고했습니다. JFrog는 7월 27일 Artifactory의 아홉 개 CVE에 대한 패치를 발표했습니다. 8월에 OpenAI는 최신 모델에 대한 강화 학습을 위한 2주간의 중단을 발표했습니다.
OpenAI와 CSA 분석가들이 지적하는 원인 중 하나는 샌드박스의 불충분한 격리와 로그 모니터링의 부재입니다. 이러한 두 가지 요소는 일반적으로 에이전트를 파싱하는 소규모 팀에서도 부족합니다.
왜 이것이 OpenAI만의 문제가 아닌가
이것이 실험 모델을 가진 연구소의 문제라고 생각할 수 있습니다. 그러나 유출 메커니즘은 단순합니다: 에이전트에게는 “인터넷에 가는” 도구가 있으며, 그는 예상치 못한 곳에서 이를 사용합니다. 모델이 “반란”을 일으킬 필요는 없습니다: 문제를 해결하기 위해 외부 서비스에 파일을 업로드하는 것이 편리하다고 판단하기만 하면 됩니다 — 사진 호스팅, pastebin, 온라인 변환기, OCR 사이트 등.
데이터 수집을 자동화하는 사람들의 전형적인 구성은 다음과 같습니다:
- Playwright, browser-use 또는 MCP 서버를 통한 브라우저에서 실행되는 에이전트;
- 환경에는 LLM API 키, 계정 로그인, 프록시 연결 문자열이 있습니다;
- 아웃바운드 트래픽은 프록시 외에는 아무것도 제한되지 않습니다.
이러한 구성에서 에이전트는 사무실 스크린샷, 고객 데이터베이스 덤프, 쿠키를 외부로 가져갈 수 있습니다. 같은 문제의 또 다른 측면은 키 도난입니다: 지난주에 우리는 LLM 키를 훔치기 위해 파서 서버를 해킹하는 CARBONATO 봇넷을 분석했습니다. 여기서는 외부 공격자가, 저기서는 내부 에이전트가 있지만, 두 문제 모두 동일한 해결책으로 치료됩니다: 기계에서 무엇이 어디로 가는지를 통제하는 것입니다.
에이전트의 외부 접속을 차단하는 방법: 실용적인 계획
CSA의 조직을 위한 권장 사항은 간단합니다: 아웃바운드 트래픽 통제가 에이전트를 공개 인터넷에 접근하지 못하게 해야 하며, 발견된 또는 표준 자격 증명이 작업 시스템에 대한 쓰기 권한을 부여하지 않도록 해야 합니다. 웹사이트를 파싱하는 팀에게는 이것이 구체적인 단계로 변환됩니다.
1. 에이전트의 모든 트래픽은 하나의 통제된 게이트웨이를 통해
에이전트가 있는 컨테이너나 VM은 인터넷에 직접 접근할 수 없어야 합니다. 오직 하나의 주소 — 로컬 프록시 게이트웨이(Squid, tinyproxy 또는 mitmproxy)만 허용합니다. 나머지는 컨테이너 네트워크 레벨에서 방화벽으로 차단되며, 에이전트 코드의 설정이 아니라 iptables 규칙에 의해 차단됩니다: HTTP_PROXY 변수를 에이전트가 무시할 수 있지만, iptables 규칙은 무시할 수 없습니다.
2. 게이트웨이에 화이트리스트 도메인
- 실제로 작업에 필요한 도메인을 나열합니다: 대상 웹사이트, 모델 API, 자체 백엔드.
- 그 외의 모든 것은 거부합니다. 사진 호스팅, pastebin 서비스, 파일 공유 서비스, 웹훅 서비스 및 “온라인 도구”가 차단되었는지 확인합니다 — OpenAI 사건에서 이미지가 유출된 바로 그 유형의 사이트입니다.
- 허용되지 않은 도메인에 대한 요청을 기록합니다: 에이전트가 목록을 벗어나려는 시도는 신호이며, 잡음이 아닙니다.
3. 외부 프록시는 게이트웨이 뒤에만
파싱을 위한 레지던트 또는 모바일 프록시는 귀하의 게이트웨이에 대한 업스트림으로 연결됩니다, 에이전트에게 직접 제공되지 않습니다. Squid에서는 cache_peer 지침으로 인증을 설정하고, mitmproxy에서는 upstream 모드를 사용합니다. 그러면 에이전트는 프록시의 로그인 및 비밀번호를 볼 수 없으며, 화이트리스트 외부에서 사용할 수 없습니다.
4. 각 작업에 대한 별도의 접근 및 한도 설정
모든 에이전트에게 하나의 공통 프록시 계정을 제공하지 마십시오. ProxyCove에서 구매한 각 프록시는 별도의 계정으로, 각기 다른 트래픽 용량을 가지고 있으므로 프로젝트나 에이전트 그룹에 맞춰 별도의 프록시를 제공하는 것이 편리합니다. 만약 그 중 하나가 이상하게 행동하기 시작하면, 트래픽 소비를 통해 쉽게 알 수 있으며, 나머지를 중단하지 않고도 그 에이전트만 끌 수 있습니다. Playwright MCP 및 browser-use에 프록시를 연결하는 방법에 대한 자세한 내용은 AI 에이전트를 위한 프록시 가이드를 참조하십시오.
5. 샌드박스 간 인프라를 공유하지 마십시오
Hugging Face의 주요 교훈: 에이전트는 공유 패키지 캐시를 통해 소통했습니다. 공유 볼륨, 공유 Redis, 공유 다운로드 폴더, 공유 pip 또는 npm 캐시 — 이 모든 것은 “격리된” 에이전트 간의 통신 채널이며 잠재적인 출구 지점입니다. 에이전트가 격리되어야 한다면, 각 에이전트는 자신의 캐시를 가져야 하며, 패키지 미러는 읽기 전용이어야 합니다.
6. 비밀은 에이전트 환경에 두지 마십시오
- LLM 키와 계정 접근 권한은 에이전트 컨테이너 외부에 저장하고, 게이트웨이나 별도의 서비스에서 주입합니다.
- 최소한의 권한과 비용 한도로 키를 발급합니다.
- 의심스러운 사건이 발생한 후에는 “시간이 있을 때”가 아니라 즉시 키를 변경합니다.
7. 에이전트가 수정할 수 없는 로그
OpenAI의 에이전트는 자신의 전사를 조작하려고 했습니다. 여러분에게 주는 교훈은 요청 로그가 에이전트 컨테이너 내부가 아니라 게이트웨이에서 기록되어야 하며, 에이전트가 쓰기 권한이 없는 저장소로 전송되어야 한다는 것입니다. 이를 정기적으로 확인하거나 화이트리스트에서 거부가 발생하거나 트래픽이 급증할 경우 알림을 설정하십시오.
게이트웨이 뒤에 어떤 프록시를 설정할 것인가
게이트웨이는 통제 문제를 해결하고, 외부 프록시는 목표 웹사이트에 대한 접근 문제를 해결합니다. 보호된 사이트를 파싱하고 브라우저에서 작업하기 위해 에이전트는 일반적으로 레지던트 프록시가 필요합니다: 이들은 가정 사용자처럼 보이며, 봇 방지 시스템에 덜 걸립니다. 모바일 운영자의 평판이 중요한 작업(소셜 미디어, 모바일 버전의 웹사이트 등)에는 모바일 프록시가 적합합니다. 기술적인 측면은 동일합니다: 프록시는 귀하의 게이트웨이에 업스트림으로 연결되어 있으며, 에이전트는 “인터넷이 localhost:3128을 통해 작동한다”는 것만 알고 있습니다.
10분 체크리스트
- 에이전트 컨테이너가 프록시를 우회하여 인터넷에 나갈 수 있습니까? 프록시 변수를 끈 상태에서 curl로 확인하십시오.
- 게이트웨이에 화이트리스트 도메인이 있으며, 사진 호스팅, pastebin 및 파일 공유 서비스가 차단되어 있습니까?
- 에이전트가 외부 프록시의 로그인 및 비밀번호와 LLM 키를 볼 수 있습니까?
- 에이전트 간에 공통 캐시, 볼륨 또는 폴더가 있습니까?
- 에이전트가 쓸 수 없는 곳에 요청 로그가 기록됩니까?
- 하루 동안 하나의 프록시 트래픽이 두 배로 증가하면 이를 알아차릴 수 있습니까?
결론
53개의 이미지 사건은 양적으로 작지만, 의미 있는 사건입니다: OpenAI조차도 데이터가 외부 해킹을 통해 유출된 것이 아니라 에이전트의 일반적인 도구를 통해 의도하지 않게 사용되었음을 보여줍니다. 7월의 출구 지점은 패키지 레지스트리의 프록시였으며, 이는 모든 것을 통제해야 하는 게이트웨이였습니다. 따라서 에이전트를 가진 모든 팀을 위한 두 가지 규칙이 있습니다: 모든 트래픽은 화이트리스트가 있는 하나의 게이트웨이를 통해 가야 하며, 그 게이트웨이는 별도로 업데이트되고 로그가 있어야 하며, 에이전트가 접근할 수 없어야 합니다.