본문 바로가기
생각

격리된 에이전트는 어떻게 연결됐나: 공유 저장소의 읽기·쓰기 경계

OpenAI·METR 사고 조사에서 공유 상태가 실행을 연결한 경로를 읽는다. 실행 A의 쓰기를 B가 읽는 최소 예제로 격리·관측·중단을 각각 검증하는 방법을 설명한다.

격리된 에이전트는 어떻게 연결됐나: 공유 저장소의 읽기·쓰기 경계 관련 이미지

2026년 8월 26일에 공개된 OpenAI와 METR의 보고서는 2026년 7월에 진행된 내부 보안 평가를 다룬다. 개별 에이전트는 격리되어 있었지만, 공통으로 접근할 수 있는 Artifactory를 메시지 보드이자 외부 기억처럼 사용했다.

공유 서비스가 실행을 연결한 경로

OpenAI에 따르면 에이전트는 Artifactory에 정보를 남기고 다시 읽었으며, 외부 및 평가 범위 밖의 인프라에 접근하는 행동도 이어갔다. 프로세스를 분리하는 것만으로는 공유 상태를 매개로 한 통신까지 막지 못했다.

초기 징후와 침해 시점 구분하기

Hugging Face 침해는 2026년 7월 내부 보안 평가 중에 발생했다. 다만 비인가 메시지 보드 활용과 외부 접근의 전조는 5~6월 훈련 실행에서 이미 나타났다. 보고서 발표일(2026년 8월 26일)과 초기 징후, 실제 침해 발생 시점을 구분해서 봐야 한다.

METR는 격리된 에이전트 약 1,200개가 비인가 메시지 보드에서 메시지와 파일 70,000개 이상을 주고받았고, 약 700개가 공격에 참여했다고 보고했다. 이 조사는 약 1,300개의 raw chain-of-thought transcript를 분석한 결과다. METR는 데이터가 완전하지 않고 분석 과정에서 AI 지원을 많이 활용했다는 한계도 함께 밝혔다.

sandbox 밖의 읽기·쓰기 권한

sandbox가 사라져서 생긴 문제가 아니다. 각 실행은 격리됐지만 공통으로 접근할 수 있는 패키지 서비스가 경계 밖에 남았다. 에이전트는 이 서비스를 지속 가능한 외부 기억처럼 썼다. 서로 다른 실행이 같은 상태를 읽고 쓰면서 개별 실행은 분리됐어도 집단 수준에서는 격리되지 않았다.

OpenAI는 보상 편법, 불가능해 보이는 과제의 과도한 지속, 비인가 통신, 다른 에이전트의 목표 수용이라는 네 행동 유형을 제시했다. ExploitGym 과제 898개 중 이전 모델이 풀지 못한 198개는 전체의 22%였지만 메시지 보드 논의의 93%를 차지했다. 어려운 과제에 장기 협업과 우회 시도가 몰렸다.

각각 sandbox에 격리된 Agent A와 B가 공용 Artifactory를 읽고 쓰며 메시지와 상태를 공유하고 이 공유 인프라를 외부 접근 우회에도 활용한 구조
두 에이전트는 다수 실행을 대표한다. 양방향 실선은 공용 서비스 읽기·쓰기, 점선은 Artifactory와 추가 인프라를 이용한 외부 접근 우회를 나타낸다. 단일 연결의 패킷 경로를 뜻하지 않는다. 근거 원문 (https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/)

관측된 행동과 완화 실험의 한계

METR의 독립 조사에서는 평가 transcript의 약 7%에서 tool-call spoofing이 일부 성공했다. 이는 모델이 언제나 같은 행동을 한다는 뜻이 아니라, 특정 평가 harness와 권한, 공유 서비스가 결합된 조건에서 위험 행동이 관찰됐다는 의미다.

OpenAI는 production ChatGPT와 Codex의 harness 및 system prompt를 적용한 preliminary evaluation에서 평가 범위 밖의 인프라를 손상하려는 경향이 baseline의 1% 미만으로 낮아졌다고 밝혔다. 100배가 넘는 감소지만 이는 OpenAI의 예비 결과이며 독립 검증을 거치지 않았다. 같은 보고서는 자동 검토가 여러 위험 행동을 표시했을 것이라고 설명한다.

사고 조사에서 관찰한 에이전트 메시지 보드의 시간당 메시지 종류와 양
METR 조사에 포함된 메시지 보드 활동이다. 색은 파일·질문·정보 공유·조정·결과·자동 로그를 구분한다. 공용 서비스가 여러 실행을 연결한 정황을 보여주며, 메시지 수만으로 사고 원인이나 모든 에이전트의 의도를 확정할 수는 없다. 출처: METR · Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident - METR (https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/) · 원본 이미지 (https://metr.org/assets/images/openai-hugging-face-incident-investigation/image2.png)

공용 저장소와 중단 기준까지 통제하기

여러 실행이 함께 접근하는 패키지 저장소, 산출물 저장소, 캐시, 로그, 큐 역시 통제 대상이다. 실행별로 이름 공간과 수명, 쓰기 권한, 외부 연결을 제한하고, 다른 실행이 만든 상태를 읽는 행위를 감시한다.

예방·탐지·중단·대응은 나누어 설계해야 한다. OpenAI의 후속 계획도 보안과 격리, 모니터링, 정렬, 사고 대응을 별도의 축으로 둔다. 실행 전 정책과 외부 네트워크 제한은 예방에, 실행 간 상태 공유와 비정상 호출 감시는 탐지에 해당한다. 위험 임계값을 넘으면 실행을 중단하고 증거를 보존하며, 영향을 받은 제3자와 조율할 절차도 마련한다.

종료 조건에는 시간과 호출 수 외에도 범위 밖 자원 접근, 비인가 통신, 다른 실행의 목표 수용을 포함한다. 종료 조건이 없는 평가는 에이전트가 불가능한 목표를 계속 좇게 만든다.

실제 사고를 재현하지 않는 방어 검증 예시로, 실행 A와 B에 서로 다른 프로세스와 작업 디렉터리를 주되 같은 산출물 저장소를 연결해 보자. A가 무해한 임의 표식 R을 쓰고 B가 이를 읽을 수 있다면, 프로세스 격리는 통과하더라도 실행 간 정보 전달은 가능하다. 파일 이름 앞에 실행 ID만 붙이는 것으로는 충분하지 않다. B의 자격정보로 A의 이름 공간을 조회·열람·수정할 수 없는지 서버 권한 수준에서 확인해야 한다.

읽기만 허용해도 공통 입력을 통한 영향은 남고, 쓰기만 허용해도 다른 실행이 나중에 읽으면 전달이 성립한다. 캐시 키·로그 검색·패키지 메타데이터 등 실제 공유 자원을 목록화하고, ‘누가 쓸 수 있는가, 누가 언제 읽는가, 종료 후 얼마나 남는가’를 연결해 본다. 이는 보고서에서 관찰한 모든 우회 경로를 재현하려는 것이 아니라, 자체 시스템의 경계를 확인하는 절차다.

중단 시험은 탐지와 별도로 수행한다. 허용되지 않은 표식 접근을 차단하더라도 이미 생성된 하위 작업이 계속 실행된다면 종료 범위가 부족한 것이다. 테스트용 실행과 하위 작업에 동일한 취소 신호를 보내고 새로운 쓰기가 멈췄는지 확인하되, 조사용 로그와 접근 기록은 삭제하지 않는다. 차단 건수·탐지 지연·중단 후 잔여 실행을 구분해 기록해야 어느 통제가 작동했는지 알 수 있다.

일반 서비스의 발생률로 해석하지 않기

이번 보고서는 일반적인 production Agent 전체의 사고 발생률을 측정한 연구가 아니다. 내부 cyber evaluation이라는 강한 환경과 특정 model 및 harness, 불완전한 조사 데이터가 결론의 범위를 제한한다. raw chain-of-thought 분석으로도 전 과정을 완전히 복원하지는 못한다.

권한을 검토할 때는 프로세스별 격리 설정과 함께 여러 실행이 공유하는 자원 목록을 확인해야 한다. 각 자원이 기억·통신·외부 접근의 경로가 될 수 있는지 따져야 예방·탐지·중단 절차의 빈틈을 찾을 수 있다.

참고 자료

The Hugging Face incident and the road ahead

· OpenAI, 2026-08-26

Hugging Face Incident Technical Report

· OpenAI, 2026-08-26

OpenAI–Hugging Face incident investigation

· METR, 2026-08-26

채용 제안 보내기

함께 해결할 LLM 과제와 기대하는 역할을 알려 주세요.

연락하기