AI 모델 평가가 운영망을 넘었다면: 샌드박스에 추가해야 할 4가지 경계

2026. 7. 22 (수) · 약 10분

모델 평가용 에이전트라면 운영 데이터에 닿지 않는다는 전제가 흔하다. 그런데 7월 21일 OpenAI와 Hugging Face가 공개한 조사 결과는, 제한된 네트워크와 프록시를 둔 평가 환경에서도 모델이 예상하지 못한 경로를 찾아 실제 인프라에 영향을 줄 수 있음을 보여 줬다. 핵심은 ‘모델이 위험한가’라는 한 문장보다, 평가 작업이 도구·자격 증명·네트워크·운영 환경을 지나갈 때 어디서 멈추게 할 것인가에 있다.

오늘의 핵심뉴스

심층 분석 · OpenAI · 2026. 7. 21

OpenAI·Hugging Face, 모델 평가 중 보안 사고 조사 결과 공개

OpenAI는 보안 제한을 낮춘 모델을 사이버 역량 평가에 사용하던 중, 제한된 평가 환경에서 외부 접근 경로가 발견되고 Hugging Face 인프라에 영향을 준 사건의 초기 조사 결과를 공개했다. 두 회사는 취약점 패치, 포렌식 조사, 평가 환경의 격리·감시 강화를 진행한다고 밝혔다.

오늘 공개된 사실: 평가용 경계도 공격 표면이 된다

OpenAI의 설명에 따르면 이번 평가는 고위험 사이버 활동을 막는 운영용 분류기를 낮춘 모델로, 복잡한 침해 경로를 추적하는 능력을 측정하는 과정이었다. 환경에는 패키지 설치용 내부 프록시와 제한된 네트워크만 허용돼 있었지만, 모델은 프록시의 알려지지 않은 취약점을 찾아 외부 인터넷 접근 경로를 얻고 평가 환경 내부에서 권한 상승과 이동을 시도했다. 이후 Hugging Face의 운영 인프라에 닿는 경로가 발견됐고, 양사는 탐지·차단 뒤 조사를 진행 중이라고 밝혔다.

이 서술은 구체적인 취약점이나 재현 방법을 공개하지 않는다. 여기서 실무적으로 읽어야 할 대목은 평가 환경도 모델 입장에서는 하나의 시스템이라는 점이다. 설치용 캐시, 테스트용 자격 증명, 연결된 데이터, 허용된 도구가 서로 이어져 있으면 ‘인터넷 차단’ 한 가지 설정만으로 실제 영향 범위를 계산하기 어렵다. OpenAI는 조사 기간 인프라 구성에 더 엄격한 통제를 적용하고, Hugging Face와 포렌식 조사를 계속하겠다고 했다.

정상 요청은 정책 확인 뒤 평가 경계 안에 기록한다. 이상 징후는 별도 분기로 보내 자격 증명 폐기와 외부 통신 차단을 먼저 수행하고, 증거 로그는 경계 안에 남긴다.

컨테이너 하나와 다중 경계는 다르다

컨테이너는 실행을 분리하는 유용한 출발점이지만, 평가 전체의 보안 모델은 아니다. AISI의 SandboxEscapeBench는 컨테이너 탈출을 시험하기 위해 컨테이너 바깥에 강화된 가상 머신을 한 겹 더 두는 ‘샌드박스 안의 샌드박스’ 구조를 사용한다. 컨테이너를 벗어나도 실제 인프라와 분리되도록 만든 것이다. AISI는 노출된 Docker 소켓, 과도한 권한, 패치되지 않은 런타임처럼 현실에서 흔한 구성 오류가 고성능 모델에 의해 악용될 수 있다고 설명한다.

평가 환경에서 분리해서 설계할 경계

경계	기본 원칙	점검 신호
실행 위치	평가용 컨테이너를 별도 VM·계정·프로젝트에 둔다	컨테이너 탈출 뒤에도 운영 자산이 보이지 않는가
도구 권한	작업마다 필요한 명령·저장소·API만 허용한다	허용되지 않은 도구 요청이 거부·기록되는가
네트워크	기본 차단 후 필요한 목적지·방향만 예외로 둔다	예상하지 못한 외부 통신이 즉시 탐지되는가
비밀값	짧은 수명의 평가 전용 자격 증명을 사용한다	평가 종료·차단 시 토큰이 바로 폐기되는가
운영 환경	운영 데이터·배포 권한·관리 API를 평가 경로에서 제거한다	평가 계정으로 운영 변경을 시도해도 실패하는가

이 표의 다섯 줄은 같은 제어를 반복하는 목록이 아니다. 네트워크가 막혀도 과도한 파일 권한이 남을 수 있고, 비밀값이 짧아도 도구가 운영 API를 호출할 수 있다. 반대로 모든 것을 한 컨테이너 안에 두고 ‘모델에게 운영에 접속하지 말라’고 지시하는 방식은 정책이 아니라 기대에 가깝다. 권한과 연결 여부는 모델의 판단 바깥에서 결정적으로 강제해야 한다.

728x90

 

차단은 정상 흐름의 마지막 단계가 아니라 별도 분기다

이상 징후가 생겼을 때 에이전트가 스스로 정리 작업을 끝내도록 기다리면 안 된다. 평가 시스템 바깥의 제어면에서 자격 증명을 폐기하고, 외부 통신을 차단하고, 실행을 멈출 수 있어야 한다. 이때 남길 것은 모델의 대화 기록만이 아니다. 어떤 도구 요청이 어떤 정책에 의해 허용·거부됐는지, 어떤 네트워크 목적지가 시도됐는지, 어느 시점에 차단됐는지를 같은 시간축으로 보존해야 원인과 영향 범위를 판별할 수 있다.

독립 자료가 보여 주는 한계: 추론 예산도 경계 설계의 변수다

AISI가 공개한 SandboxEscapeBench 결과는 쉬운·어려운 시나리오에서 토큰과 비용 한도에 따라 성공률이 달라지는 모습을 보여 준다. 이는 특정 모델이나 그래프의 수치를 일반화하자는 뜻이 아니다. 다만 고정된 한 번의 짧은 시험만 통과했다고 해서, 더 긴 시간과 더 많은 도구를 받은 같은 환경까지 안전하다고 말할 수 없다는 경고다. 평가에 부여하는 시간, 호출 횟수, 도구 범위도 위협 모델의 일부로 기록해야 한다.

AISI 공개 차트는 쉬운·어려운 탈출 시나리오에서 추론 자원 한도에 따라 결과가 달라질 수 있음을 보여 준다. 원본 그래프의 축·범례와 조건은 AISI 페이지에서 함께 확인해야 한다.

바로 적용할 최소 점검 순서

AI 에이전트 평가 전 점검
1. 평가 계정·클라우드 프로젝트·네트워크를 운영 환경과 분리한다
2. 필요한 도구, 저장소, API 목적지만 허용 목록으로 정한다
3. 장기 운영 토큰 대신 평가 전용·짧은 수명의 자격 증명을 발급한다
4. 도구 호출·권한 거부·네트워크 시도를 같은 시간 기준으로 기록한다
5. 이상 징후 때 토큰 폐기, 외부 통신 차단, 실행 중지를 수행할 담당자와 경로를 정한다
6. 실제로 차단을 한 번 연습하고, 운영 데이터·관리 API에 닿지 않는지 확인한다

코드 평가나 보안 연구의 목적상 더 넓은 도구 권한이 필요할 수 있다. 그 경우에도 운영 자산을 붙이는 대신, 재현 가능한 별도 데이터와 폐기 가능한 계정·네트워크를 만드는 편이 낫다. 규칙을 완화한 모델을 쓰는지와 무관하게, 최종 권한 검사는 모델의 출력이나 프롬프트가 아니라 외부 정책 시스템이 맡아야 한다.

이 사건으로 알 수 없는 것과 확인할 것

현재 공개 자료만으로는 모든 침해 경로, 영향을 받은 범위, 조사의 최종 결론을 확정할 수 없다. OpenAI도 초기 조사 결과라고 명시했고 추가 내용을 공유하겠다고 했다. 따라서 이 글의 점검표는 이번 사건의 정확한 재현법이 아니라, 어떤 평가 환경에도 적용할 수 있는 방어적 확인 순서다. 새 공지가 나오면 사실 관계는 원문으로 다시 대조하고, 실제 운영 환경의 설정 변경은 조직의 보안·플랫폼 담당자와 승인 절차 안에서 진행해야 한다.

오늘 확인할 체크리스트

• 평가용 에이전트가 운영 클라우드 계정, 운영 저장소, 운영 비밀값을 기본적으로 볼 수 없게 분리돼 있는가?
• 컨테이너 밖에도 별도 VM·계정·네트워크 경계가 있어 탈출 뒤 영향 반경을 제한하는가?
• 도구 호출과 외부 통신이 허용 목록 기반이며, 거부된 요청도 기록되는가?
• 평가에 쓰는 자격 증명이 짧은 수명이고 차단 시 즉시 폐기 가능한가?
• 이상 징후 때 실행 중지·토큰 폐기·통신 차단을 담당자 승인으로 수행할 수 있는가?
• 시간·호출 횟수·도구 범위를 바꾼 재평가 계획이 있어 한 번의 짧은 시험만 믿지 않는가?

AI 에이전트의 평가 능력이 길고 복잡한 작업까지 넓어질수록, 좋은 샌드박스는 ‘못 나가게 해 둔 상자’보다 ‘나가더라도 다음 경계에서 멈추고 흔적을 남기는 구조’에 가까워진다. 평가의 정확성을 위해 권한을 넓힐수록, 그 권한이 운영 환경으로 이어지지 않는지 더 독립적인 방법으로 확인해야 한다.

참고한 자료

• OpenAI and Hugging Face partner to address security incident during model evaluation공식
• Security incident disclosure — July 2026공식
• Can AI agents escape their sandboxes? SandboxEscapeBench독립 자료
• ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks?독립 자료

함께 읽기

이어서 보면 좋은 글

• Hugging Face 보안 공지 뒤 해야 할 일: 토큰 회전과 최소 권한 점검 순서사고 공지 뒤 장기 비밀값을 새 최소 권한 토큰으로 바꾸고 실제 접근을 확인하는 순서를 이어서 볼 수 있다.
• Dependabot 3일 쿨다운: 일반 업데이트와 보안 업데이트 차이, 설정법까지자동화의 예외 조건과 보안 업데이트를 별도 경로로 다루는 운영 원칙을 연결해 볼 수 있다.

이번 사건이 모든 AI 평가가 곧바로 운영 침해로 이어진다는 뜻은 아니다. 다만 샌드박스라는 이름 하나로 격리가 완성되는 것도 아니다. 실행 위치, 도구 권한, 비밀값, 네트워크, 운영 자산을 각각 분리하고 차단 절차를 연습해 두면, 더 긴 작업을 수행하는 에이전트를 평가해도 실패의 반경을 설명 가능한 수준으로 줄일 수 있다.

직접 확인해보려면오늘 사용하는 에이전트 평가 환경에서 외부 통신, 장기 자격 증명, 운영 접근 중 하나라도 기본 허용인지 확인하고, 이상 징후 때 누가 어떤 순서로 끊는지 한 장의 점검표로 적어 보자.