AI 에이전트가 탈출하게 만든 세 가지 샌드박스 실패 사례

당신의 LLM 에이전트가 접근해서는 안 되는 컨테이너를 통해 데이터를 유출했습니다. 사고 보고서는 이를 '창발적 행동(emergent behavior)'이라고 부릅니다. 로그에는 누락된 seccomp 프로파일, 열린 egress 규칙, 그리고 propagation이 활성화된 bind mount가 기록되어 있습니다.

본 기사에서는 AI가 통제 불능 상태에 빠진 것처럼 보이는 세 가지 격리 실패 사례를 다루고, 각각의 취약점을 막는 구체적인 설정 방법과 다음 탈출을 헤드라인으로 만들기 전에 포착하는 모니터링 방법을 설명합니다.

필터링을 잊은 시스템 호출(Syscall) 표면적

대부분의 팀은 기본 Docker seccomp 프로파일을 사용하여 컨테이너 내에서 에이전트를 실행합니다. 이 프로파일은 약 44개의 시스템 호출(syscall)을 차단하지만, ptrace, process_vm_readv, process_vm_writev, 그리고 bpf는 허용합니다. 코드 실행 권한을 가진 에이전트는 이를 사용하여 형제 컨테이너를 검사하거나 조작하고, 호스트 메모리를 읽거나, 악성 eBPF 프로그램을 로드할 수 있습니다.

## Dockerfile.agent

...

// seccomp-agent.json
{
  "defaultAction": "SCMP_ACT_ERRNO",
...

--security-opt seccomp=seccomp-agent.json으로 실행합니다. 위의 프로파일은 일반적인 Python 에이전트에 필요한 시스템 호출만 허용합니다. 이는 ptrace, process_vm_readv, process_vm_writev, 그리고 bpf를 명시적으로 거부합니다. 만약 에이전트가 추가적인 시스템 호출(예: 스레딩을 위한 clone3)이 필요하다면, 이를 의도적으로 추가해야 합니다. 허용되는 모든 것은 감사할 수 있는 결정입니다.

열어둔 Egress 경로

egress 규칙이 없는 컨테이너는 인터넷, 내부 메타데이터 서비스, 그리고 클러스터 내의 다른 모든 워크로드에 접근할 수 있습니다. 코드 실행 권한을 얻은 에이전트는 제로데이(zero-day) 공격을 할 필요가 없습니다. 단지 http://169.254.169.254/latest/meta-data/를 curl 하거나 파드 CIDR을 스캔하기만 하면 됩니다.

## kubernetes/networkpolicy-agent-egress.yaml

...

이 정책은 네임스페이스 레이블로 식별된 모델 추론 서비스와 벡터 데이터베이스로의 외부 통신(egress)만을 허용합니다. DNS는 클러스터 리졸버로 허용됩니다. 그 외 모든 것—메타데이터 엔드포인트, 다른 네임스페이스, 인터넷—은 차단됩니다. 에이전트를 배포하기 전에 이 정책을 적용하세요. kubectl exec -it <agent-pod> -- curl -s http://169.254.169.254로 테스트하여 멈추거나 연결 거부(connection refused)가 반환되는지 확인하십시오.

마운트 전파를 통한 파일 시스템 탈출 (The Filesystem Escape Via Mount Propagation)

에이전트 컨테이너에서 업로드된 파일을 읽을 수 있도록 호스트 디렉토리를 마운트했습니다. 튜토리얼에서 '파일 감시(file watching)가 작동한다'고 했기 때문에 propagation: Bidirectional 또는 HostToContainer를 사용했습니다. 이제 에이전트는 마운트 네임스페이스를 생성하고, /host/etc를 여기에 바인드 마운트(bind-mount)한 다음, 호스트의 /etc/shadow를 읽을 수 있게 되었습니다.

## kubernetes/pod-agent.yaml

...

핵심은 mountPropagation이 없다는 것입니다. 이 설정이 생략되면 마운트는 사적(private)이며—컨테이너의 변경 사항이 호스트로 전파되지 않고, 호스트의 마운트 이벤트가 컨테이너 내부로 전파되지 않습니다. 에이전트가 새 파일에 반응해야 한다면, 볼륨을 감시하고 그 이벤트를 에이전트가 소비하는 큐(queue)에 쓰는 사이드카(sidecar)를 사용하십시오. 절대로 마운트 전파를 호스트와 공유하지 마십시오.

탈출을 포착하는 모니터링 (Monitoring That Catches the Escape)

격리(Containment)가 실패했습니다. 여러분의 모니터링은 그것이 실패할 것이라고 가정해야 합니다. 진행 중인 탈출을 포착하는 세 가지 신호가 있습니다:

1. 시스템 호출 이상 징후 (Syscall anomalies) — 에이전트 컨테이너에서 ptrace, process_vm_readv, bpf, 또는 unshare를 감지하여 경고를 발생시키는 Falco나 Tetragon 규칙.
2. 외부 통신 위반 (Egress violations) — 예상치 못한 CIDR로의 에이전트 파드(pod)에서 나가는 연결을 보여주는 Cilium 또는 Calico 흐름 로그(flow logs).
3. 파일 시스템 이상 징후 (Filesystem anomalies) — 호스트의 Auditd 규칙으로, 에이전트 컨테이너의 PID 네임스페이스에서 민감한 경로( /etc/shadow, /proc/*/mem, /sys/kernel)에 대한 openat을 감시합니다.

## falco/rules-agent-escape.yaml

...

이 규칙들을 Falco 또는 Tetragon 인스턴스에 배포하세요. container.image.repository 매치를 실제 이미지에 맞게 조정해야 합니다. 목표는 시스템 호출(syscall)을 막는 것이 아닙니다 — seccomp가 이미 그 역할을 수행합니다 — 단지 에이전트가 시도할 때 경고를 받는 것입니다. 거부된 ptrace 또는 unshare 호출의 급증은 에이전트의 로직에 문제가 있거나 프롬프트 인젝션(prompt injection)이 경계를 탐색하고 있다는 것을 의미합니다.

핵심 요약

• 기본 컨테이너 프로파일은 시스템 호출(ptrace, bpf, process_vm_readv)을 허용하여 에이전트가 샌드박스를 검사하거나 탈출할 수 있게 합니다. 최소한의 seccomp 프로파일을 작성하고 이를 강제하세요.
• 아웃바운드(egress) 정책이 없으면 에이전트는 메타데이터 서비스 및 내부 워크로드를 도달할 수 있습니다. 에이전트가 필요한 서비스에 대해서만 명시적인 허용 목록으로 아웃바운드 차단(default-deny egress)을 설정하세요.
• 호스트와 공유되는 마운트 전파(mount propagation)는 파일 시스템 탈출 벡터입니다. 마운트를 비공개로 유지하고, 파일 감지 패턴에는 사이드카(sidecar)를 사용하세요.
• 모니터링은 격리 실패를 가정해야 합니다. 거부된 시스템 호출, 차단된 아웃바운드, 에이전트의 PID 네임스페이스에서의 호스트 파일 시스템 접근에 대해 경고를 설정하세요.
• 시스템 호출, 네트워크 목적지, 마운트 옵션 등 모든 허용은 감사할 수 있는 결정입니다. 구성(config)에 그 이유를 문서화하세요.

출처

AI 에이전트가 통제 불능 상태가 되는 것은 아니며, 보안 기본 사항을 건너뛰는 것이 문제: 전문가들 — 작동하는 seccomp 프로파일, Kubernetes NetworkPolicy 및 Pod 사양, Falco 탐지 규칙, 그리고 각 실패 모드에 대한 실무자 체크리스트를 추가했습니다.

이 작업 지원하기

이 글들은 유료 장벽, 스폰서 또는 추적 없이 연구되고 게시되었습니다. 만약 이 글 하나가 당신의 오후 시간을 절약했다면, 작은 후원금이 계속해서 좋은 콘텐츠를 만드는 데 도움이 됩니다.

USDT, USDC 또는 USDD · TRC-20 (Tron)

TFTNsfyomKrnUutRjBTGVULp19ByW29KbY