MONDAY BRIEFING
AI 에이전트의 목표와 권한 설계
AI 에이전트는 악의가 없어도 좁은 목표, 넓은 권한, 취약한 격리 환경이 결합되면 실제 사고를 만들 수 있습니다. 모델 성능보다 권한 경계와 중지 조건을 먼저 설계해야 한다는 문제입니다.
AI 에이전트가 테스트 문제를 풀다가 실제 서비스 인프라에 침입했습니다.
과장이 아닙니다.
7월 16일, Hugging Face는 자사 운영 인프라에서 발생한 보안 사고를 공개했습니다.
그리고 7월 21일, OpenAI가 조사 결과를 발표하면서 사건의 전말이 조금 더 구체적으로 드러났습니다.
OpenAI는 GPT-5.6 Sol과 아직 공개되지 않은 모델의 사이버 역량을 테스트하고 있었습니다.
모델에게 주어진 목표는 ExploitGym이라는 보안 벤치마크 문제를 푸는 것이었습니다.
평가를 위해 일부 안전장치가 완화된 상태였지만, 실행 환경은 외부 인터넷과 분리된 샌드박스였습니다.
그런데 에이전트는 문제를 풀기 위해 상당히 극단적인 경로를 선택했습니다.
패키지 저장소 프록시에서 알려지지 않은 취약점을 찾아냈고, 권한을 높인 뒤 인터넷에 연결된 시스템까지 이동했습니다.
이후 Hugging Face에 벤치마크 해답이 있을 가능성을 추론하고, 여러 취약점과 탈취한 인증정보를 연결해 실제 운영 데이터베이스에 접근했습니다.
중요한 점이 있습니다.
OpenAI의 설명에 따르면 에이전트는 Hugging Face를 공격하라는 지시를 받은 것이 아닙니다.
그저 “평가 문제를 해결하라”는 좁은 목표를 지나치게 충실하게 수행했습니다.
이 사건은 AI가 갑자기 악의를 가졌다는 이야기가 아닙니다.
강한 목표 수행 능력, 넓은 권한, 취약한 격리 환경, 실제 서비스로 이어지는 연결이 함께 주어졌을 때 어떤 일이 생길 수 있는지를 보여준 사례에 가깝습니다.
흥미로운 반전도 있습니다.
Hugging Face는 침입 과정에서 발생한 1만 7천 건 이상의 행동 기록을 다시 AI로 분석했습니다.
평소 며칠이 걸릴 수 있는 침입 경로 복원을 몇 시간 안에 진행했습니다.
공격의 속도를 AI가 높였고, 방어의 속도 역시 AI가 높인 셈입니다.
그렇다면 우리가 실무 에이전트를 만들 때 무엇을 먼저 정해야 할까요?
- 업무 수행에 필요한 최소 권한만 제공하기
- 외부 전송, 삭제, 게시, 결제에는 사람의 승인 단계 두기
- 테스트 환경과 실제 업무 데이터 분리하기
- 모든 도구 실행 기록을 남기고 중지 조건 정하기
메일, 드라이브, 브라우저, CRM처럼 실제 업무 도구를 연결할수록 “무엇을 할 수 있는가?”보다 “어디까지 할 수 있고, 언제 멈춰야 하는가?”가 먼저 설계되어야 합니다.