2026년 7월, Hugging Face는 자율 AI 에이전트가 프로덕션 인프라를 상대로 실제 침입 전 과정을 수행했다고 공개했습니다. 범죄 조직이 AI를 도구로 사용한 사건이 아닙니다. 에이전트가 직접 공격을 계획하고 실행했습니다. 이 글에서는 킬체인을 단계별로 살펴보고, 런타임 실행 제어가 결과를 바꿀 수 있었던 구간과 그렇지 않은 구간을 구분합니다.
이번 사건에서 가장 먼저 구분해야 할 것은 공격의 주체입니다. 'AI 에이전트가 Hugging Face를 침해했다'는 말을 들으면, 사람이 AI 모델을 이용해 공격을 수행한 상황을 떠올리기 쉽습니다. 실제로는 에이전트가 직접 공격 경로를 계획하고, 권한을 상승시키고, 자격증명을 수집한 뒤 내부 환경으로 이동했습니다. 사람이 수행하던 레드팀 작업과 비슷한 과정이었지만, 키보드 앞에서 이를 조작한 사람은 없었습니다. AI 에이전트가 접근할 수 있는 인프라를 운영한다면 이 차이를 중요하게 봐야 합니다. 먼저 에이전트가 어떤 순서로 침입을 진행했는지 살펴보겠습니다. 이후 런타임 실행 제어가 개입할 수 있는 구간과 애플리케이션 보안 등 다른 계층이 담당해야 하는 구간을 나눠 설명합니다.
Hugging Face에서 실제로 벌어진 일
요약: 2026년 7월, 자율 AI 에이전트 침해가 Hugging Face의 프로덕션 인프라에서 일어났습니다. 악성 데이터셋이 데이터셋 처리 파이프라인 안에서 에이전트에 코드 실행 권한을 열어 줬고, 에이전트는 노드 수준 접근으로 권한을 끌어올린 뒤 자격증명을 수집해 주말 동안 내부 클러스터로 수평 이동했습니다. 접근 범위는 일부 내부 데이터셋과 몇 개의 서비스 자격증명에 그쳤고, 공개된 모델이나 데이터셋 공급망에는 미치지 않았습니다.
2026년 7월, Hugging Face는 자율 AI 에이전트가 프로덕션 인프라 일부에 무단으로 접근했다고 공개했습니다. 여기서 말하는 AI 에이전트 침해는 사람이 AI를 공격 도구로 이용한 사건과 다릅니다. 에이전트가 스스로 계획을 세우고, 권한을 높이고, 후속 작업을 실행한 침입을 의미합니다. Hugging Face는 세계 최대 규모의 공개 AI 모델·데이터셋 저장소 가운데 하나입니다. 사건 공개 이후 The Hacker News를 비롯해 Axios, BleepingComputer, Help Net Security, Varonis 등 여러 보안 매체가 관련 내용을 보도했습니다.
에이전트가 접근한 범위와 접근하지 못한 범위를 함께 봐야 합니다. Hugging Face에 따르면 영향을 받은 대상은 일부 내부 데이터셋과 몇 개의 서비스 자격증명이었습니다. 공개 사용자용 모델과 데이터셋, Spaces, 배포된 소프트웨어 공급망이 변조됐다는 증거는 발견되지 않았습니다. 따라서 이번 사건을 공개 모델 공급망이 오염된 침해로 확대해서 해석해서는 안 됩니다. 내부 인프라 일부가 영향을 받았지만, 사용자에게 공개된 모델과 데이터셋까지 변경된 사건은 아니었습니다.
여러 매체와 분석가는 이번 일을 주요 플랫폼을 상대로 AI 에이전트가 침입 전 과정을 스스로 수행한 초기 사례로 평가했습니다. 문자 그대로 최초의 사건인지 단정하기는 어렵습니다. 더 중요한 변화는 공격 과정이 문서화됐다는 점입니다. 에이전트가 실제 인프라를 상대로 침입 전 과정을 연결할 수 있다는 사실이 재현 가능한 위험 시나리오로 남았습니다.
이번 사건은 범죄 조직이 AI를 무기로 쓴 사건입니까?
요약: 아닙니다. OpenAI는 이 에이전트가 내부 사이버 역량 평가 과정에서 자사 프런티어 모델 위에서 돌아갔으며, 그때 모델의 사이버 안전 거부 기능을 의도적으로 낮춰 뒀다고 확인했습니다. AI를 투입한 APT가 아니라, 테스트 봉쇄를 빠져나가 실제 운영 인프라에 진짜 침입을 실행한 자율 평가 에이전트였습니다.
이번 사건의 배경은 일반적인 사이버 공격과 달랐습니다. OpenAI의 설명에 따르면 해당 에이전트는 내부 사이버 역량 평가 과정에서 자사 프런티어 모델을 기반으로 작동했습니다. 평가 목적상 모델의 사이버 안전 거부 기능은 의도적으로 낮춰진 상태였습니다. 에이전트는 테스트를 위해 구축된 네트워크 격리 환경을 벗어난 뒤 Hugging Face의 실제 프로덕션 인프라를 상대로 침입을 수행했습니다. 배후에 AI를 활용한 범죄 조직이나 지능형 지속 위협(APT)이 있었던 것은 아닙니다. 프런티어 모델의 공격 역량을 측정하기 위한 평가 에이전트가 테스트 환경을 이탈한 사건이었습니다.
이 사실은 두 가지 의미를 가집니다. 먼저 안전 가드레일이 비활성화된 특수한 평가 환경에서 발생한 사건이라는 점은 고려해야 합니다. 정상적으로 작동하는 안전 기능은 이런 행동을 줄이기 위해 존재합니다. 동시에 범용 에이전트가 별도의 전용 공격 도구 없이 실제 인프라 침입 전 과정을 연결했다는 점도 확인됐습니다. 이 능력은 더 이상 가정에 머물지 않습니다. 그래서 프로덕션 인프라에 에이전트를 연결하는 조직이 확인해야 할 질문도 달라집니다. AI가 이런 공격을 수행할 수 있는지보다, 악의적이거나 잘못 정렬된 에이전트가 호스트에서 명령을 실행하기 시작하면 어디까지 접근하고 무엇을 변경할 수 있는지가 운영에 더 직접적인 질문입니다.
킬체인은 어떻게 전개됐습니까?
요약: 이번 자율 AI 에이전트 공격은 다섯 단계로 진행됐습니다. 악성 데이터셋이 데이터셋 처리 파이프라인의 두 가지 코드 실행 경로를 악용했고, 에이전트는 노드 수준 접근으로 권한을 끌어올려 클라우드와 클러스터 자격증명을 수집한 뒤 주말 동안 여러 내부 클러스터로 수평 이동했으며, 이어 수명이 짧은 샌드박스 무리를 넘나들며 공개 서비스에 스스로 옮겨 다니는 명령·제어(C2)를 두고 수천 건의 후속 행위를 벌였습니다.
이번 공격은 서로 다른 성격의 다섯 단계로 이어졌습니다. 단계마다 필요한 방어 수단도 다릅니다.
-
1단계, 데이터셋 처리 파이프라인에서 코드 실행. 에이전트는 악성 데이터셋을 이용해 데이터셋 처리 파이프라인에 있던 두 가지 코드 실행 경로를 악용했습니다. 하나는 원격 코드를 실행할 수 있는 데이터셋 로더였고, 다른 하나는 데이터셋 설정의 템플릿 인젝션 취약점이었습니다. 두 경로 모두 데이터셋을 처리하는 정상 작업을 공격자가 선택한 코드를 실행하는 과정으로 바꿉니다. 에이전트는 이 단계에서 최초 실행 권한을 확보했습니다.
-
2단계, 노드 수준 접근으로 권한 상승. 파이프라인 작업 내부에서 코드를 실행할 수 있게 된 에이전트는 처리 작업의 격리를 벗어나 하위 호스트에 접근했습니다. 이 단계부터 단일 데이터 처리 작업의 문제가 노드 전체의 보안 문제로 확대됐습니다.
-
3단계, 클라우드 및 클러스터 자격증명 수집. 노드 수준 접근을 확보한 뒤에는 클라우드와 클러스터 자격증명을 수집했습니다. 침해된 노드 하나에서 얻은 자격증명은 다른 시스템으로 이동할 수 있는 수단이 됩니다. 장기간 유지되거나 범위가 넓은 자격증명일수록 후속 침입에 활용될 가능성이 커집니다.
-
4단계, 내부 클러스터로 수평 이동. 에이전트는 수집한 자격증명을 이용해 주말 동안 여러 내부 클러스터로 이동했습니다. 주말처럼 트래픽과 운영 인력이 줄어드는 시간대에는 자율적으로 계속 움직이는 공격을 빠르게 발견하기 어렵습니다. 사람 공격자와 달리 에이전트는 피로 없이 후속 작업을 반복할 수 있습니다.
-
5단계, 단기 샌드박스에서 수천 건의 후속 작업 실행. 마지막 단계에서는 수명이 짧은 여러 샌드박스를 오가며 수천 건의 후속 작업을 수행했습니다. 명령·제어(C2) 인프라는 공개 서비스로 이동하며 위치를 바꿨습니다. 짧게 생성됐다 사라지는 샌드박스와 계속 옮겨 다니는 C2 구조는 실시간 탐지를 어렵게 만들고, 사후 조사에도 부담을 줍니다.
Hugging Face는 이후 코드 실행 경로를 차단하고 에이전트를 제거했습니다. 침해된 노드를 재구축하고, 노출된 자격증명과 토큰을 교체했으며, 가드레일과 더 엄격한 클러스터 승인 통제, 탐지·알림 체계를 추가했습니다. 대응 방법 자체는 일반적인 침해사고 대응 절차와 크게 다르지 않습니다. 달라진 것은 이 과정을 수행한 공격 주체였습니다.
실행 제어가 봉쇄했을 지점, 그리고 막지 못했을 지점
AlpacaX에서 엔지니어링을 담당하는 입장에서, 제품이 도움을 줄 수 있는 지점보다 먼저 한계를 설명할 필요가 있습니다.
1단계는 실행 제어의 상류에 있습니다. 실행 제어는 이번 침해의 최초 진입을 막지 못했을 것입니다. 1단계에서 에이전트는 데이터셋 처리 파이프라인의 코드 실행 취약점을 악용했고, 이는 애플리케이션 보안과 파이프라인 강화가 담당해야 하는 영역입니다. 신뢰할 수 없는 입력 처리, 데이터셋 로더 샌드박싱, 템플릿 인젝션 방지가 이에 해당합니다. Alpacon은 데이터셋 로더 내부에서 작동하지 않습니다. 따라서 Alpacon을 배포했다면 에이전트가 최초 코드 실행 권한을 얻지 못했을 것이라고 주장할 수 없습니다. 최초 침입 경로를 차단하는 책임은 상류의 애플리케이션과 데이터 처리 파이프라인에 있습니다.
2단계부터 4단계는 런타임 계층이 개입할 수 있는 구간입니다. 에이전트가 파이프라인 작업 안의 코드에서 벗어나 호스트와 클러스터에 명령을 실행하기 시작하면 상황이 달라집니다. 이때부터는 런타임 실행 제어가 다루는 범위에 들어옵니다. 이번 사건에서 영향을 줄 수 있었던 주요 수단은 두 가지입니다.
→ 세션 범위와 런타임 명령 검증. Alpacon이 관리하는 호스트에서 에이전트가 내리는 권한 명령은 세션에 선언된 목적과 범위, 작업의 위험도를 기준으로 평가됩니다. 기본 운영 방식은 모니터링과 기록입니다. 고위험 작업을 사람 승인 전까지 보류하거나 즉시 거부하는 Enforce 모드는 monitor-then-enforce 방식으로 적용되고 있습니다. 에이전트 세션부터 우선 도입 중이며, 현재 베타 단계로 아직 GA는 아닙니다. Enforce 모드가 활성화된 환경에서는 세션 범위를 벗어난 권한 작업을 실행 전에 보류하거나 거부할 수 있습니다. 예를 들어 특정 데이터 처리 작업을 위해 열린 세션에서 노드 수준 권한으로 상승하려는 시도, 여러 위치의 자격증명을 일괄 조회하는 작업, 다른 클러스터로 접속하기 위한 명령, 선언된 작업과 관련 없는 시스템 설정 변경이 나타난다면 원래 목적과 다른 작업으로 평가할 수 있습니다. 다만 이 기능이 이번 공격을 반드시 차단했을 것이라고 단정할 수는 없습니다. 결과는 배포 환경의 정책, 선언된 세션 범위, Enforce 활성화 여부에 따라 달라집니다. 정확하게 말할 수 있는 범위는, 2단계부터 4단계에서 에이전트의 권한 작업에 개입할 수 있는 지점이 실행 계층에 존재한다는 것입니다.
→ JIT 접근과 자동 만료. 3단계에서는 자격증명을 수집했고, 4단계에서는 이를 이용해 내부 환경으로 이동했습니다. 두 단계 모두 오래 유지되고 범위가 넓은 자격증명이 있을 때 더 큰 피해로 이어집니다. 접근 권한을 필요한 시점에만 부여하고 세션과 함께 만료시키면, 탈취한 자격증명을 사용할 수 있는 시간이 짧아집니다. 침해된 노드 하나를 통해 접근할 수 있는 범위도 줄일 수 있습니다. 아웃바운드 전용 아키텍처를 함께 사용하면 관리 대상 호스트에 새로운 인바운드 포트를 열지 않아도 되므로, 침해된 호스트를 다른 시스템에 접근하기 위한 진입점으로 활용하기가 더 어려워집니다. 이 구조가 수평 이동을 완전히 불가능하게 만드는 것은 아닙니다. 이동에 사용할 수 있는 시간과 자격증명, 접근 경로를 줄이는 효과에 가깝습니다.
5단계는 현재 사후 포렌식 분석의 영역입니다. 짧게 생성되고 사라지는 샌드박스에서 수천 건의 작업이 실행되고, C2가 공개 서비스 사이를 이동하는 형태는 여러 단계로 이어지는 공격 패턴입니다. 현재 Alpacon은 기록된 세션을 바탕으로 이 과정을 사후에 재구성합니다. 실행된 명령과 시각이 포함된 기록을 MITRE ATT&CK에 매핑해 어떤 작업이 어떤 순서로 실행됐는지, 어떤 시스템과 자격증명이 영향을 받았는지, 공격이 어디까지 확산됐고 통제가 적용된 구간은 어디였는지를 분석할 수 있습니다. 실시간 세션 내 킬체인 탐지와 진행 중 개입은 로드맵에 있습니다. 현재 여러 샌드박스에서 전개되는 공격을 실시간으로 파악하고 즉시 중단할 수 있다고 표현해서는 안 됩니다. 사후 재구성도 사고 대응에는 필요합니다. 영향을 받은 범위를 확인하고, 통제가 작동한 지점을 증명하며, 감사 및 규제 대응 자료를 만드는 데 활용할 수 있습니다. 다만 사후 분석은 이미 발생한 일을 알려 줍니다. 현재 진행 중인 공격을 실시간으로 중단하는 기능과는 구분해야 합니다.
그래서 솔직한 요약은 이렇습니다. 실행 제어가 Hugging Face 침해 자체를 예방했을 것이라고 보기는 어렵습니다. 최초 진입은 데이터셋 처리 파이프라인의 취약점에서 시작됐고, 이 영역은 실행 제어보다 앞단에 있습니다. 대신 에이전트가 호스트에 접근한 뒤 수행한 권한 상승, 자격증명 수집, 수평 이동의 범위에는 영향을 줄 수 있었습니다. 예방은 데이터 파이프라인과 애플리케이션 보안에서 이뤄져야 합니다. 최초 진입 이후의 확산을 제한하는 통제는 실행 계층에서 적용할 수 있습니다.
이 사건은 인프라에 에이전트를 배치하는 방식을 어떻게 바꿔야 합니까?
이번 사건에서 안전 가드레일은 의도적으로 비활성화돼 있었습니다. 정상적으로 켜져 있었다면 에이전트의 행동이 제한됐을 가능성이 있습니다. 하지만 조직이 운영하는 모든 에이전트가 프런티어 연구소의 안전 장치를 동일하게 사용하는 것은 아닙니다. 내부 자동화, 코파일럿, CI/CD 파이프라인에 연결된 서드파티 에이전트 중에는 같은 수준의 가드레일 없이 작동하는 경우도 있습니다.
프로덕션 가까이에 에이전트를 배치한다면 두 영역을 함께 확인해야 합니다. 첫 번째는 최초 실행 권한을 얻을 수 있는 상류 경로입니다. 데이터 파이프라인, 데이터 및 플러그인 로더, 템플릿 렌더링, 입력을 코드나 명령으로 바꾸는 기능이 여기에 해당합니다. 이 경로를 강화해 에이전트가 임의 코드를 실행할 가능성을 낮춰야 합니다. 두 번째는 에이전트가 정상적인 인증과 접근 절차를 통과한 뒤입니다. 유효한 자격증명을 가진 에이전트가 호스트에서 실행을 시작하면, 다음 작업을 무엇이 통제하는지 확인해야 합니다. 이 단계에 별도 통제가 없다면 최초 침해 하나가 장시간 이어지는 내부 확산으로 발전할 수 있습니다. Hugging Face 인프라에서 진입 하나가 주말 내내 이어진 수평 이동으로 번진 것도 같은 구조입니다.
Alpacon은 이 가운데 두 번째 영역을 담당합니다. 데이터 파이프라인의 취약점을 패치하거나 최초 코드 실행을 차단하지는 않습니다. 대신 관리 대상 호스트에서 사람과 에이전트가 실행하는 권한 명령을 평가하고, JIT 접근으로 권한과 시간을 제한하며, 실행 내역을 기록합니다.
