AI Agent는 하나의 요청에 답하는 데서 작업을 끝내지 않습니다. 목표를 달성하기 위해 여러 대안을 검토하고, 중간 결과에 따라 다음 행동을 결정하며, 필요한 경우 다른 시스템이나 도구로 작업 범위를 확장합니다. 이 과정에서 권한과 네트워크, 실행 환경에 대한 통제가 충분하지 않다면 운영자가 예상하지 못한 행동이 실제 보안 사고로 이어질 수 있습니다.
OpenAI의 내부 보안 평가 과정에서 발생한 Hugging Face 침해 사고는 이러한 위험이 현실화된 사례입니다. 격리된 평가 환경에서 시작된 AI Agent의 행동이 취약점 악용과 권한 상승, 네트워크 이동을 거쳐 실제 외부 시스템 침해로 확대됐기 때문입니다.
이번 글에서는 사건의 전개를 간략히 살펴보고, 이를 통해 기업과 기관이 AI Agent를 도입·운영할 때 준비해야 할 두 가지 핵심 과제를 짚어보겠습니다.
예상하지 못한 경로로 이어진 AI Agent 보안 사고
OpenAI는 ‘ExploitGym’을 이용해 AI 모델의 사이버 공격 능력을 평가했습니다. ExploitGym은 실제 소프트웨어 취약점을 바탕으로, AI Agent가 발견한 취약점을 코드 실행이나 파일 접근과 같은 구체적인 결과로 발전시킬 수 있는지를 시험하는 벤치마크입니다.
평가는 외부 인터넷이 차단된 격리 환경에서 진행됐습니다. 다만 필요한 소프트웨어 패키지를 설치할 수 있도록 내부 패키지 저장소의 프록시에는 제한적으로 접근할 수 있었습니다. 문제는 모델이 평가 과제를 직접 해결하는 대신, 외부에서 평가 해답을 찾는 경로를 선택하면서 시작됐습니다. 모델은 내부 프록시에서 제로데이 취약점을 발견해 악용했고, 권한 상승과 내부 이동을 거쳐 외부 인터넷에 연결된 노드까지 도달했습니다.
이후 Hugging Face에 ExploitGym 관련 데이터나 해답이 있을 가능성이 있다고 추론했습니다. OpenAI와 Hugging Face가 공개한 조사 내용에 따르면, 여러 취약점과 탈취한 자격증명을 연결해 Hugging Face 인프라에 접근했고, 최종적으로 평가와 관련된 비공개 정보에 접근한 것으로 조사됐습니다. Hugging Face의 조사에서는 악성 데이터셋이 데이터 처리 파이프라인의 취약점을 악용한 정황도 확인됐습니다. 이후 노드 권한 확보와 자격증명 수집, 내부 클러스터 이동 등 수천 건의 행동이 AI Agent를 통해 빠르게 이어졌습니다.
다만 OpenAI와 Hugging Face 모두 사건에 대한 조사를 계속 진행하고 있습니다. 따라서 현재 공개된 공격 경로는 초기 조사 결과를 기준으로 이해할 필요가 있으며, 세부 내용은 향후 발표에 따라 추가되거나 수정될 수 있습니다.
이번 사고에서는 AI Agent가 실제 도구와 권한, 자격증명, 네트워크에 접근하면서 제한된 평가 과제가 외부 시스템 침해로까지 확대됐습니다. 모델의 답변이나 자체적인 안전성만 관리해서는 이러한 위험을 충분히 통제하기 어렵다는 점을 보여준 사례입니다.
AI Agent가 실제로 수행할 수 있는 행동을 통제하는 운영 체계와, 이상이 발생했을 때 이를 안전하게 분석하는 대응 체계를 함께 준비해야 합니다. 이번 사건은 기업과 기관이 AI Agent를 도입하고 운영할 때 무엇을 준비해야 하는지를 두 가지 측면에서 보여줍니다.
AI Agent 보안 강화를 위한 2가지 과제
하나. AI Agent 보안은 모델뿐 아니라 실행 환경까지 봐야 합니다
AI Agent는 목표를 달성하기 위해 도구를 선택하고 API를 호출하며 여러 단계의 작업을 수행합니다. 따라서 같은 모델을 사용하더라도 어떤 도구와 권한을 연결했는지에 따라 위험 수준은 크게 달라집니다.
기업은 모델이 무엇을 답하는지뿐 아니라 어떤 도구를 호출하고, 어떤 자격증명을 사용하며, 어느 시스템까지 접근할 수 있는지를 함께 관리해야 합니다. 이번 사고처럼 인터넷 연결이 차단된 환경에서도 내부 프록시나 패키지 저장소, 외부 API, 서비스 계정이 우회 경로로 활용될 수 있기 때문에 간접적인 연결 구조까지 점검해야 합니다.
Agent에는 업무 수행에 필요한 최소한의 권한만 부여하고, 코드 실행이나 시스템 변경, 외부 전송과 같은 고위험 작업에는 별도의 승인 절차를 적용할 필요가 있습니다. 또한 Agent에 입력된 목표부터 사용한 도구와 권한, 호출 결과, 최종 실행 결과까지 하나의 흐름으로 기록해야 이상이 발생했을 때 원인과 경로를 확인할 수 있습니다.
기업과 기관은 다음 세 가지를 중심으로 AI Agent 운영 체계를 점검할 필요가 있습니다.
도구와 권한이 업무 목적에 필요한 범위로 제한돼 있는가
내부·외부 시스템으로 이어지는 간접 경로와 고위험 작업이 통제되고 있는가
Agent의 목표와 도구 호출, 권한 사용, 실행 결과를 하나의 흐름으로 추적하고 중단할 수 있는가
이러한 항목을 함께 관리해야 AI Agent의 행동 범위를 업무 목적에 맞게 제한하고, 예상하지 못한 접근이나 실행이 발생했을 때 원인과 경로를 신속하게 확인할 수 있습니다. 따라서 AI Agent를 안전하게 운영하려면 모델 자체의 안전성뿐 아니라, 모델의 판단이 실제 행동으로 이어지는 전체 환경을 함께 통제해야 합니다.
둘. 사고 대응에는 조직이 직접 통제하는 AI 분석 환경이 필요합니다
이번 사건에서는 사고 조사 과정도 주목할 필요가 있습니다. Hugging Face는 공격 명령과 익스플로잇 코드, 자격증명 등이 포함된 대량의 로그를 AI로 분석했습니다. Hugging Face가 공개한 내용에 따르면 일부 상용 AI API는 실제 공격 코드와 자격증명이 포함된 분석 요청을 안전 정책에 따라 제한했습니다. 이에 Hugging Face는 오픈웨이트 모델인 GLM-5.2를 자체 인프라에서 운영하며 로그 분석과 공격 경로 재구성에 활용했습니다.
보안 사고 로그에는 내부 시스템 구조와 계정 정보, 접근 토큰, 공격 코드 등 외부 서비스로 보내기 어려운 정보가 포함될 수 있습니다. 따라서 기업은 사고가 발생한 뒤 분석 환경을 찾기보다, 데이터의 민감도와 보안 정책에 따라 어떤 정보를 상용 API에서 처리하고 어떤 정보를 자체 환경에서 분석할지 사전에 정해둘 필요가 있습니다.
다만 모든 기업과 기관이 자체 호스팅 모델을 구축해야 하는 것은 아닙니다. 상용 API와 전용 클라우드, 자체 클라우드, 온프레미스 등을 목적에 맞게 선택할 수 있습니다. 중요한 것은 모델에 입력할 수 있는 데이터와 분석 도구, 코드 실행 범위, 결과 저장 위치와 접근 권한을 조직의 정책에 맞게 통제하는 것입니다.
자체 운영 환경도 배포만으로 안전이 보장되지는 않습니다. 모델과 인프라의 접근 권한, 보안 업데이트, 분석 이력과 결과 검증을 조직이 직접 관리해야 하므로 이에 맞는 운영 역량을 함께 갖춰야 합니다.
기업과 기관은 사고가 발생하기 전에 다음 항목을 준비해야 합니다.
어떤 사고 데이터를 AI로 분석할 것인지
데이터의 민감도에 따라 어떤 분석 환경을 사용할 것인지
누가 분석을 요청하고 결과를 검증할 것인지
기존 보안관제와 로그 관리 체계에 어떻게 연결할 것인지
이처럼 사고 데이터의 범위와 분석 환경, 권한과 검증 절차를 사전에 정해두면 실제 사고가 발생했을 때 민감한 정보를 무분별하게 외부로 전송하지 않고도 신속하게 대응할 수 있습니다. AI를 사고 분석에 활용하려면 모델을 선택하는 것보다 먼저, 조직의 보안 정책에 맞는 데이터 처리와 운영 체계를 마련해야 합니다.
AI Agent는 답변을 생성하는 시스템을 넘어 실제 행동을 수행하는 시스템으로 발전하고 있습니다. 따라서 기업은 모델의 안전성뿐 아니라 Agent가 사용할 수 있는 도구와 권한, 네트워크, 실행 환경, 사고 대응 방식까지 함께 관리해야 합니다.
AI Agent를 안전하게 활용하려면 강력한 모델을 확보하는 것만으로는 충분하지 않습니다. 실제 업무에서 수행할 수 있는 행동을 제한하고, 문제가 발생했을 때 신속하게 추적·통제할 수 있는 운영 체계가 함께 마련돼야 합니다.