범용 VM만으로는 AI 에이전트 격리가 충분하지 않은 이유

AI 에이전트가 VM 탈출을 실제로 시도한 결과

Trail of Bits가 사이버 보안 용도의 GPT 5.6-Cyber에게 QEMU/KVM 기반 가상 머신 탈출 과제를 맡겼어요. 과제는 단순했어요. 호스트 운영체제에 있는 플래그 파일을 VM 바깥에서 읽는 것이 목표였죠.

에이전트는 호스트에서 실행된 뒤 SSH로 VM에 접속했어요. VM 내부에서는 소프트웨어 설치, 빌드, 디버깅을 모두 수행할 수 있었고, 약 12시간 동안 자율적으로 취약점을 탐색했어요. 그 결과, 공개된 지 얼마 되지 않은 호스트 커널 취약점 Januscape(CVE-2026-53359) 를 먼저 찾았어요. 이후에는 호스트 커널을 최신 버전으로 올려도 libslirp의 알려진 결함과 아직 CVE가 부여되지 않은 수정 커밋을 연결하는 경로를 확보했어요.

마지막에는 QEMU, Linux KVM, libslirp에 걸쳐 있던 3개의 0-day와 배포판에 반영되지 않은 결함을 엮어 재사용 가능한 탈출 경로를 완성했다고 Trail of Bits는 보고해요. 원문 표에 따르면 QEMU와 libslirp 결함은 제보만 된 상태였고, KVM 결함은 upstream에서 패치됐지만 세부 내용은 stable 커널 패치를 기다리는 중이었어요. 그래서 이 글은 해당 결함을 직접 확인한 게 아니라 원문 보고에 의존해요. 위에 나온 Januscape(CVE-2026-53359)는 이미 공개된 취약점이고, 3개의 0-day와는 다른 항목이에요.

'호스트에서 실행됐다'는 점이 바꾸는 해석

이 실험은 에이전트가 VM 내부가 아니라 호스트에서 시작했다는 점에서 특수한 조건이에요. 호스트의 커널 버전, 빌드 정보, 사용된 QEMU와 libslirp 소스를 쉽게 내려받을 수 있었기에, 일반적인 내부 공격자보다 정보가 많았을 가능성이 커요. 원문 저자도 호스트에서 에이전트를 돌린 위험을 인지했고, 개발 머신에 중요한 게 없어서 감수했다고 밝혀요.

실험에 쓴 환경도 모든 VM을 대표한다고 보기 어려워요. 대상은 Debian 12(oldstable)를 쓰는 개발 머신의 QEMU/KVM VM이었고, 호스트 커널의 CPU 취약점 완화 기능(mitigations=off)이 꺼져 있었어요. 또한 네트워크 기능을 제공하는 libslirp가 공격 표면에 포함돼 있었죠.

GeekNews 댓글에는 에이전트가 호스트에서 시작한 건 유리한 조건이라는 비판도 있었어요. 저도 "고성능 AI 에이전트라면 어떤 VM이든 탈출할 수 있다"고 단정하기는 이르다고 봐요. 특정 범용 VM 구성에는 자동화된 취약점 탐색과 다중 취약점 연결 공격이 통할 수 있다는 사례에 가깝죠.

Firecracker는 왜 달랐나

Trail of Bits는 공격 표면을 최소화하고 보안에 초점을 두고 만든 가상화 기술의 예로 Firecracker를 들어요. 에이전트를 Firecracker에도 돌려 보았더니, 에이전트는 upstream에서 이미 수정된 Linux 커널 결함을 이용해 호스트를 멈추게 만들었지만, VM 밖으로 탈출하지는 못했어요.

원문도 시간이 더 있었다면 탈출했을지 모른다고 인정하지만, 실험으로 확인된 결과는 아니에요. 그래도 원문은 Firecracker가 훨씬 어려운 표적이라고 평가해요. 즉, 가상화 기술의 설계 철학에 따라 격리 강도가 실제로 달라진다는 뜻이에요.

이 결과가 내 환경에 의미하는 것

원문의 실험 조건을 걷어내고 실무 질문으로 바꾸면, 핵심은 '내 에이전트가 이만큼 공격 능력이 있는가'와 '공격자가 내 에이전트를 조종할 수 있는가'를 나눠 보는 거예요. 이번 실험의 에이전트는 사이버 보안 용도로 만든 모델이 12시간 동안 호스트 정보까지 보면서 움직인 경우예요. 일반 코딩 에이전트가 VM 안에서 같은 일을 해낸다고 볼 근거는 이 실험에 없어요. 하지만 프롬프트 인젝션으로 에이전트가 공격 쪽 지시를 받는 시나리오라면, 앞으로 모델 성능이 올라갈수록 '에이전트 안의 코드 실행 능력'이 곧 공격 표면이 된다는 점은 같아요.

원문이 보여주는 방어의 핵심은 업데이트 지연 구간이에요. 에이전트가 쓴 결함 중 일부는 upstream에서는 이미 수정됐지만 배포판 커널에는 반영되지 않은 상태였어요. 운영하는 쪽에서는 '배포판 패치를 기다리는 시간'이 곧 노출 시간이라는 뜻이고, 에이전트용 호스트의 커널과 QEMU, libslirp 같은 구성 요소를 직접 추적할 가치가 여기서 나와요. Firecracker가 달랐던 이유도 비슷하게 설명할 수 있어요. 지원하는 가상 장치와 기능이 적으니 탐색할 코드가 적고, 그 결과 하드락까지만 갔다고 볼 수 있어요. 다만 '시간 안에 못 했다'는 것이 '못 한다'와 같은 말은 아니라서, 이것도 안전의 증명이라기보다 더 어려운 표적이라는 관찰이에요.

이 글이 확인하지 못한 범위도 분명히 해 둘게요. 취약점 세부와 재현 절차는 원문에 의존하고, 직접 재현한 건 없어요.

VM 하나에만 의존하지 않는 접근이 필요한 이유

이번 실험이 시사하는 바는 범용 VM을 폐기해야 한다는 것이 아니에요. 오히려 VM 한 대만으로 충분한 안전 경계라고 가정하지 말아야 한다는 점이 핵심이에요.

먼저 호스트 커널, QEMU, 가상화 소프트웨어, 네트워크 라이브러리를 빠르게 업데이트해야 해요. 배포판에 반영이 늦은 upstream 수정 사항도 직접 확인할 필요가 있죠. 필요하지 않은 가상 장치와 기능은 꺼서 공격 표면을 줄이는 것도 중요해요.

에이전트의 네트워크 접근, 자격 증명, 사용 가능한 기능에는 최소 권한 원칙을 적용해야 해요. 실행 과정은 기록·감시하고, 실행 시간을 제한하며 매번 초기화된 환경을 제공해야 해요. 그래야 한 번의 작업에서 취약점을 탐색하고 연결할 수 있는 범위 자체가 줄어들죠.

실험을 바라보는 시각과 남은 질문

한편 GeekNews 스레드 댓글에서는 이 실험을 두고 "우리 이미 망했을 수도"와 "취약점을 줄여나가면 방어가 모델 성장을 따라갈 수도"라는 두 가지 해석이 나뉘었어요. 후자 쪽은 핵심 통신 인프라의 신뢰성, 실행 가능한 운영체제 설계, 실제로 방어해야 할 공격 표면의 크기 같은 더 큰 질문으로 이어져요.

결론적으로, AI 에이전트의 사이버 역량이 빠르게 성장하면서 가상화 기반 격리도 더 이상 기본 안전장치로만 볼 수 없게 됐어요. 이번 실험은 그 점을 가장 직접적으로 보여준 사례라고 생각해요.

참고 자료:

• VMs won't contain cyber-capable agents - Trail of Bits
• GeekNews 스레드