AI 샌드박스에서 코드 실행의 안전성은 그 격리 경계(isolation boundary)에 달려 있습니다. 하지만 격리 경계는 답의 일부일 뿐입니다. 더 나은 질문은: 샌드박스가 실제로 무엇을 격리하며, 무엇이 여전히 빠져나갈 수 있는가? 입니다. 대부분의 샌드박스는 일부 요소(프로세스 수준 코드 실행, 호스트에 대한 임의 파일 시스템 쓰기)를 잘 차단하지만, 다른 요소(아웃바운드 네트워크, 패키지 설치, 환경 변수의 비밀)는 기본적으로 열어둡니다. 이러한 격차를 이해하는 것이 샌드박스가 자신의 위험 모델에 적합한지 평가하는 방법입니다. AI 에이전트 샌드박스가 무엇이며 격리, 이그레스, 스냅샷, 마이크로VM 같은 핵심 개념이 어떻게 함께 작동하는지에 대한 배경 정보는 보안 세부 사항을 살펴보기 전에 정의 가이드를 참조하세요.
코드 실행 샌드박스에서 "안전"의 의미
코드 실행 샌드박스의 보안은 이진 속성이 아닙니다. 이는 각각 특정 위험 범주를 다루는 일련의 제어 수단입니다. 누군가 "이 샌드박스가 안전한가?"라고 물을 때, 보통 여러 가지 다른 질문을 동시에 하는 것입니다.
- 호스트 격리(Host isolation): 샌드박스 내부에서 실행되는 코드가 호스트 시스템으로 빠져나갈 수 있습니까?
- 테넌트 격리(Tenant isolation): 한 사용자의 코드가 다른 사용자의 세션에 영향을 줄 수 있습니까?
- 이그레스 제어(Egress control): 샌드박스 내부의 코드가 인터넷, 내부 서비스 또는 메타데이터 엔드포인트에 도달할 수 있습니까?
- 비밀 범위(Secret scoping): 자격 증명이 필요한 것보다 더 넓은 샌드박스에 접근할 수 있습니까?
- 공급망 위험(Supply chain risk): 패키지 설치로 인해 예상치 못한 코드나 악성 코드가 유입될 수 있습니까?
- 감사 가능성(Auditability): 사후에 에이전트가 실제로 무엇을 했는지 재구성할 수 있습니까?
샌드박스는 호스트 격리는 강력하지만 이그레스는 약할 수 있습니다. 이그레스는 강력하지만 비밀 처리는 약할 수 있습니다. “얼마나 안전한지” 평가하려면 “컨테이너화” 또는 “마이크로VM 기반” 같은 단일 레이블을 전체 답변으로 받아들이지 말고 각 차원을 별도로 확인해야 합니다.
격리 계층 비교
AI 코드 실행 샌드박스에는 세 가지 주요 격리 모델이 사용됩니다. 각 모델은 서로 다른 경계를 제공합니다.
프로세스 격리(Process isolation)
프로세스 격리는 OS 수준의 기본 요소(Linux 네임스페이스, cgroups, seccomp 필터, AppArmor 또는 SELinux 프로파일)를 사용하여 프로세스가 접근할 수 있는 대상을 제한합니다. 샌드박스는 호스트 OS에서 프로세스로 실행되며 호스트 커널을 공유합니다.
방지하는 것: 더 넓은 파일 시스템, 샌드박스 외부의 다른 프로세스, seccomp 정책에서 명시적으로 차단된 시스템 콜에 대한 접근.
방지하지 못하는 것: 공유 취약점을 통해 권한을 상승시키는 커널 익스플로잇. seccomp 우회 또는 커널 취약점은 호스트 경계를 넘을 수 있습니다.
적합한 경우: 시작 속도와 이식성이 하드 VM 경계보다 중요한 단기, 저위험, 신뢰할 수 있는 코드. 외부 사용자의 임의 에이전트 생성 코드를 실행하는 경우에는 권장되지 않습니다.
컨테이너 격리(Container isolation, Docker/네임스페이스)
컨테이너 격리는 프로세스 격리를 더 구조화된 이미지 모델, 네트워크 네임스페이스, 볼륨 마운트로 확장합니다. 대부분의 Docker 기반 샌드박스 구현은 최소 이미지와 제한된 seccomp 프로파일이 있는 컨테이너 내에서 코드를 실행합니다.
방지하는 것: 호스트 파일 시스템에 대한 직접 접근, 인접 컨테이너에 대한 대부분의 네트워크 접근(올바르게 구성된 경우), 호스트 프로세스에 대한 쉬운 접근.
방지하지 못하는 것: 커널 수준 익스플로잇은 여전히 적용됩니다. 컨테이너는 호스트 커널을 공유합니다. 잘못 구성된 볼륨 마운트, 지나치게 광범위한 seccomp 프로파일, --privileged 모드, 노출된 Docker 소켓은 모두 의도된 경계를 무효화할 수 있습니다.
적합한 경우: seccomp 프로파일이 엄격하고, 이미지가 최소이며, 이그레스가 제한되고, 권한 있는 접근이 부여되지 않을 때 많은 프로덕션 배포에서 AI 코드 실행을 위해 컨테이너를 효과적으로 사용합니다. 위험 모델은 마이크로VM과 다르지만 신중한 구성으로 관리할 수 있습니다.
마이크로VM 격리(MicroVM isolation, Firecracker/gVisor)
마이크로VM 격리는 각 샌드박스를 자체 게스트 커널이 있는 경량 가상 머신에서 실행하며, KVM 하이퍼바이저 경계를 통해 호스트와 격리합니다. Firecracker가 가장 일반적인 구현이고, gVisor(자체 사용자 공간 커널 사용)는 다른 트레이드오프를 제공합니다.
방지하는 것: 게스트 커널 익스플로잇은 호스트 커널이나 다른 게스트로 전파되지 않습니다. 호스트 공격 표면은 최소로 설계된 VMM(가상 머신 모니터)로 축소됩니다.
방지하지 못하는 것: VMM 자체의 취약점(드물지만 불가능하지 않음). 네트워크, 패키지, 비밀 제어는 여전히 VM 경계 외부에 있습니다. 마이크로VM 격리는 이를 처리하지 않습니다.
적합한 경우: 외부 사용자의 신뢰할 수 없는 코드 또는 에이전트 생성 코드 실행, 폭발 반경(blast radius)이 중요한 멀티 테넌트 환경, 임의 셸 명령이나 패키지 설치 스크립트를 실행할 수 있는 워크로드.
| 격리 모델 | 호스트 커널 공유 | 테넌트 분리 | 시작 오버헤드 | 호스트 탈출 위험 |
|---|---|---|---|---|
| 프로세스 | 예 | 약함 | 가장 낮음 | 가장 높음 |
| 컨테이너 | 예 | 보통 | 낮음 | 중간(구성에 따라 다름) |
| 마이크로VM | 아니요 | 강함 | 보통 | 낮음 |
각 경계를 여전히 빠져나갈 수 있는 것
격리 모델은 런타임 코드 실행을 처리합니다. 다른 경로를 통해 샌드박스에 들어오거나 나가는 것을 자동으로 처리하지는 않습니다.
아웃바운드 네트워크: 세 가지 격리 모델 모두 아웃바운드 네트워크 접근을 정책 구성에 맡깁니다. 기본적으로 이그레스가 열려 있으면 샌드박스 내부의 코드는 공용 인터넷, 클라우드 메타데이터 엔드포인트(AWS 및 GCP의 169.254.169.254), 동일 네트워크의 내부 서비스, 임의 외부 API에 도달할 수 있습니다. 이는 격리 모델과 관계없이 데이터 유출 경로, 비밀 검색 경로, 명령 및 제어 경로입니다.
패키지 설치: apt install, pip install, npm install은 외부 레지스트리에서 코드를 가져와 실행합니다. 샌드박스가 패키지 설치를 허용하고 이그레스가 열려 있으면 패키지 이름 충돌, 타입스쿼팅 공격, 의존성 혼동 공격을 통해 샌드박스의 모든 권한으로 실행되는 악성 코드가 유입될 수 있습니다. 격리 경계는 폭발 반경을 제한하지만 설치 자체를 막지는 않습니다.
공유 상태: 멀티 테넌트 배포에서 공유 캐시, 공유 패키지 레지스트리, 공유 템플릿 이미지, 공유 파일 시스템 마운트는 격리 경계를 우회하는 테넌트 간 채널을 생성합니다.
환경 변수의 비밀: 에이전트 프로세스에 표시되는 환경 변수는 에이전트가 실행하는 모든 코드에서 읽을 수 있습니다. 데이터베이스 자격 증명이나 API 키가 환경에 있으면 샌드박스와 샌드박스가 실행하거나 설치하는 모든 것에 접근할 수 있습니다.
이그레스 및 네트워크 제어
이그레스는 대부분의 샌드박스에서 가장 큰 격차가 있는 부분입니다. 편리하기 때문에 아웃바운드 인터넷 접근이 열려 있는 것이 일반적입니다. 에이전트는 패키지를 설치하고, API를 호출하고, 리소스를 가져와야 합니다. 하지만 이는 또한 위험을 만듭니다.
클라우드 메타데이터 엔드포인트: 호스팅된 클라우드 인프라에서 169.254.169.254(및 IPv6 해당 주소)는 IAM 자격 증명을 포함한 인스턴스 메타데이터를 제공합니다. 이그레스가 열려 있는 샌드박스 내부의 코드는 이 엔드포인트에 도달하여 기본 호스트의 자격 증명을 검색할 수 있습니다.
DNS 기반 유출: HTTP가 차단되어도 아웃바운드 DNS 쿼리는 도메인 조회에 데이터를 인코딩하여 유출하는 데 사용될 수 있습니다. DNS 차단은 외부 서버로의 TCP/UDP 53 차단뿐만 아니라 리졸버 수준에서 필터링해야 합니다.
내부 서비스: 샌드박스가 사설 네트워크 세그먼트에서 실행되는 경우, 열린 이그레스는 에이전트 코드가 도달할 의도가 없는 내부 데이터베이스, 관리 패널, API에 대한 접근을 허용할 수 있습니다.
평가해야 할 제어 수단:
| 제어 | 방지하는 것 | 확인할 사항 |
|---|---|---|
| 기본 거부 이그레스 | 나열되지 않은 대상으로의 아웃바운드 연결 | DNS도 TCP/UDP와 함께 차단하는가? |
| 허용 목록 기반 이그레스 | 승인되지 않은 도메인으로의 연결 | 허용 목록을 고객이 구성할 수 있는가? |
| 메타데이터 엔드포인트 차단 | 169.254.169.254를 통한 클라우드 자격 증명 검색 |
IPv6 메타데이터도 차단하는가? |
| 이그레스 프록시 | 모든 아웃바운드 트래픽 로깅 및 검사 | 프록시 로그에 접근할 수 있는가? |
| DNS 필터링 | DNS 기반 유출 및 내부 이름 확인 | 샌드박스 내부에서 어떤 리졸버가 사용되는가? |
보편적으로 올바른 이그레스 정책은 없습니다. 일부 에이전트 워크로드는 유용하기 위해 광범위한 인터넷 접근이 진정으로 필요합니다. 핵심은 정책이 의도적이고 감사 가능해야 하며, 구성된 적이 없어서 기본적으로 열려 있으면 안 된다는 것입니다.
비밀 처리
AI 에이전트 샌드박스의 비밀은 모든 소프트웨어 시스템의 비밀과 동일한 원칙을 따르지만, 한 가지 추가 제약이 있습니다. 에이전트는 개발자의 의도 없이 환경을 읽거나, 기록하거나, 전송하는 코드를 실행할 수 있습니다.
범위 지정: 샌드박스가 현재 작업에 실제로 필요한 자격 증명만 마운트하세요. 코딩 작업을 실행하는 샌드박스는 프로덕션 데이터베이스 자격 증명이 필요하지 않습니다. 모델 출력을 평가하는 샌드박스는 결제 서비스의 API 키가 필요하지 않습니다.
수명: 수명이 짧은 자격 증명은 긴 수명의 자격 증명보다 훨씬 안전합니다. 샌드박스 내에서 자격 증명이 유출되면 짧은 TTL이 노출 기간을 제한합니다. 많은 클라우드 IAM 시스템은 몇 분 또는 몇 시간 내에 만료되는 단기 토큰을 지원합니다.
주입 방법: 환경 변수는 가장 일반적인 주입 방법이며 프로세스의 모든 코드에 가장 접근하기 쉽습니다. 파일 시스템 마운트를 통해 주입되거나, 에이전트가 탐색할 필요가 없는 경로에 마운트되거나, 필요한 특정 도구가 실행될 때만 동적으로 가져오는 비밀은 포괄적인 환경 변수 세트보다 더 제한적입니다.
편집: 비밀은 stdout, stderr, 도구 응답 페이로드, 모델이 볼 수 있는 컨텍스트, 감사 로그에서 편집되어야 합니다. 환경을 에코하거나, env를 호출하거나, 실패하는 API 호출에 토큰을 전달하는 에이전트는 자격 증명을 로그에 유출할 수 있으며, 이후 저장되거나 운영자가 볼 수 있습니다.
리소스 제한 및 서비스 거부 위험
리소스 제한이 없는 샌드박스는 CPU, 메모리, 디스크 또는 네트워크 대역폭을 소진하는 에이전트 워크로드(도망친 코드, 무한 루프, 설치된 패키지의 메모리 누수, 인접 워크로드를 방해하려는 의도적인 시도)에 취약합니다.
확인해야 할 리소스 제어:
- CPU 제한: 세션당 제한 또는 하드 제한은 하나의 세션이 호스트 용량을 독점하는 것을 방지합니다.
- 메모리 제한: OOM 종료 정책은 호스트 프로세스가 아닌 샌드박스 세션을 종료해야 합니다.
- 디스크 할당량: 세션당 쓰기 제한은 세션이 공유 스토리지를 채우는 것을 방지합니다.
- 실행 타임아웃: 벽시계 제한을 초과하는 세션은 계속 실행되지 않고 정상적으로 종료되어야 합니다.
- 네트워크 속도 제한: 아웃바운드 대역폭 제한은 이그레스 정책이 대상을 허용하는 경우에도 유출을 제한할 수 있습니다.
- 동시 프로세스 제한: 과도하게 포크(fork)하거나 백그라운드 프로세스를 생성하는 에이전트는 프로세스 테이블 슬롯을 소진할 수 있습니다.
리소스 제한 위반도 기록할 가치가 있습니다. 가벼운 작업 중에 지속적으로 CPU 스로틀이나 OOM 종료에 도달하는 세션은 조사할 가치가 있는 신호입니다.
감사 가시성
격리 제어는 문제가 발생했을 때 폭발 반경을 줄입니다. 감사 로그는 문제가 발생했음을 확인하고 무슨 일이 일어났는지 재구성하는 방법입니다.
특히 AI 에이전트 샌드박스의 경우 유용한 감사 범위는 다음과 같습니다.
- 프로세스 실행: 실행된 모든 명령, 전체 인수 목록, UID, 부모 프로세스. 인수 목록이 없으면 로그의
curl과python은 의미가 없습니다. - 파일 시스템 접근: 민감한 경로에 대한 읽기 및 쓰기. 대부분의 위협 모델에서 읽기보다 쓰기와 삭제가 더 중요합니다.
- 아웃바운드 네트워크: 대상, 프로토콜, DNS 쿼리, 전송된 바이트. DNS 쿼리 로깅은 종종 누락되지만 중요합니다.
- 패키지 설치: 패키지 관리자, 패키지 이름, 버전, 소스 레지스트리, 해시.
- 세션 수명 주기: 생성, 일시 중지, 재개, 종료, 정리 이벤트와 이유 코드.
- 리소스 제한 이벤트: OOM 종료, CPU 스로틀, 타임아웃 종료.
수집 메커니즘은 범위만큼 중요합니다. 샌드박스 프로세스 내에서 생성된 로그는 충분히 권한이 있는 에이전트에 의해 억제되거나 수정될 수 있습니다. 커널 수준 수집(auditd, eBPF, 하이퍼바이저 계측 사용)은 에이전트가 쓰기 접근 권한이 없는 애플리케이션 계층 아래에서 생성됩니다.
모든 샌드박스 제공자 또는 프로젝트에 물어볼 질문
관리형 샌드박스 서비스 또는 오픈 소스 샌드박스 프레임워크를 평가할 때 이 체크리스트를 사용하세요. 주요 제공자가 이러한 질문에 어떻게 답변하는지 비교하려면 2026년 최고의 AI 에이전트 샌드박스 또는 E2B 및 Daytona 평가 가이드를 참조하세요.
격리
- 각 에이전트 세션에 자체 격리된 환경이 제공됩니까, 아니면 세션이 공유 실행 환경에 그룹화됩니까?
- 어떤 격리 모델이 사용됩니까: 프로세스, 컨테이너 또는 마이크로VM?
- 게스트 커널이 호스트와 공유됩니까?
네트워크 및 이그레스
- 이그레스는 기본적으로 열려 있습니까, 아니면 기본적으로 차단됩니까?
- 이그레스 정책을 테넌트별 또는 세션별로 구성할 수 있습니까?
- 클라우드 메타데이터 엔드포인트(
169.254.169.254)가 차단됩니까? - 샌드박스 내부에서 DNS는 어떻게 처리됩니까?
패키지 설치
- 패키지 설치가 기본적으로 허용됩니까?
- 설치를 승인된 레지스트리로 제한할 수 있습니까?
- 설치 이벤트가 소스와 해시와 함께 기록됩니까?
비밀
- 자격 증명이 샌드박스에 어떻게 주입됩니까?
- 자격 증명을 필요로 하는 특정 도구 또는 작업으로 범위를 지정할 수 있습니까?
- 비밀이 로그와 모델이 볼 수 있는 출력에서 편집됩니까?
리소스 제한
- CPU, 메모리, 디스크, 타임아웃 제한이 적용됩니까?
- 제한에 도달하면 어떻게 됩니까? 스로틀, 종료 또는 알림?
감사 로그
- 로그가 커널/하이퍼바이저 수준에서 생성됩니까, 아니면 샌드박스 프로세스 내에서 생성됩니까?
- 기본적으로 기록되는 이벤트 범주는 무엇입니까?
- 로그를 외부 SIEM 또는 로그 수집 시스템으로 내보낼 수 있습니까?
- 로그 보존 정책은 무엇입니까?
테넌시
- 다른 테넌트의 워크로드가 서로 격리됩니까?
- 테넌트 간 채널을 생성하는 공유 캐시, 이미지 또는 마운트가 있습니까?
Novita Agent Sandbox의 위치
Novita Agent Sandbox는 코드, 파일, 프로세스 및 장기 실행 세션을 위한 격리된 실행 환경이 필요한 에이전트 워크로드를 위해 설계되었습니다. 코딩 에이전트, 평가 파이프라인, 데이터 분석 에이전트 및 브라우저 기반 에이전트 워크플로우를 구축하는 팀을 대상으로 합니다.
샌드박스는 유휴 세션에 대한 일시 중지, 재개 및 자동 일시 중지를 포함한 세션 수명 주기 제어를 지원합니다. API를 통해 액세스할 수 있는 리소스 메트릭 및 세션 수준 실행 로그를 제공합니다. 이미 Novita 모델 API를 사용하는 팀의 경우, 모델이 계획을 세우고 도구를 호출하며 샌드박스가 격리된 환경에서 런타임 실행을 처리하는 에이전트 아키텍처의 실행 계층 역할을 할 수 있습니다.
보안에 민감한 사용 사례에 대해 Novita Agent Sandbox를 평가할 때는 아키텍처 결정을 내리기 전에 제품 문서에서 현재 격리 모델, 이그레스 정책 기본값, 로그 범위 및 비밀 처리를 확인하세요. 보안 요구 사항은 워크로드에 따라 크게 다릅니다. 내부 평가 파이프라인에 적합한 것이 사용자 제공 코드를 처리하는 멀티 테넌트 제품에는 충분하지 않을 수 있습니다.
다른 샌드박스와 마찬가지로 보안 태세는 플랫폼의 기본값과 애플리케이션 수준 제어(자격 증명이 어떻게 범위 지정되는지, 에이전트가 무엇을 요청할 수 있는지, 어떤 도구 호출에 사람의 승인이 필요한지, 감사 로그가 어떻게 모니터링되는지)에 따라 달라집니다.
한계와 어떤 샌드박스도 제거할 수 없는 것
어떤 샌드박스도 모든 위험을 제거하지는 않습니다. 경계 외부에 무엇이 남아 있는지 이해하는 것은 경계가 제공하는 것이 무엇인지 이해하는 것만큼 중요합니다.
애플리케이션 계층 신뢰 결정: 샌드박스는 런타임 실행을 제어합니다. 에이전트가 무엇을 요청할 수 있는지 결정하지는 않습니다. 애플리케이션이 에이전트가 자격 증명을 요청하고, 임의 셸 명령을 실행하고, 모든 API를 호출하도록 허용하는 경우 샌드박스는 폭발 반경을 줄이지만 해당 작업을 방지하지는 않습니다.
프롬프트 인젝션: 신뢰할 수 없는 콘텐츠(웹 페이지, 사용자 업로드 파일, 외부 API 응답)를 처리하는 에이전트는 해당 콘텐츠를 통해 조작되어 실행해서는 안 되는 작업을 수행할 수 있습니다. 이는 샌드박스 문제가 아닌 애플리케이션 설계 문제입니다. 샌드박스는 해당 작업이 도달하는 위치를 제한할 수 있지만 결정 논리는 애플리케이션에 있습니다.
제로데이 취약점: 모든 격리 모델에는 알려진 취약점과 알려지지 않은 취약점이 있습니다. 마이크로VM 격리는 현재 프로덕션 사용에서 가장 강력한 경계를 제공하지만 VMM 취약점은 존재합니다. 단일 경계를 신뢰하는 것보다 여러 제어를 결합하는 심층 방어(Defense-in-depth)가 더 강력한 태세입니다.
모델 출력을 통한 사회 공학: 에이전트는 사람 운영자가 안전하지 않은 조치를 취하도록 설득하는 출력을 생성할 수 있습니다. 샌드박스는 사람의 결정을 감사하지 않습니다.
규정 준수 및 규제 위험: 격리 제어는 기술적 위험을 해결합니다. 규제 요구 사항(GDPR, HIPAA, SOC 2, ISO 27001)은 샌드박스가 인프라 수준에서 제공하는 것 이상으로 확장되는 데이터 처리, 보존, 문서화 및 감사 요구 사항을 다룹니다.
코드 실행 샌드박스의 보안은 제품을 선택하여 얻는 속성이 아니라 평가하고 구성해야 할 일련의 제어 수단으로 보는 것이 가장 좋습니다. 위의 평가 질문은 모든 샌드박스 결정(직접 구축하는 경우 자신의 인프라 포함)에 적용됩니다.
FAQ
샌드박스 AI 코드 실행 환경은 서버에서 코드를 실행하는 것과 비교하여 얼마나 안전한가요?
잘 구성된 샌드박스는 서버에서 직접 신뢰할 수 없는 코드를 실행하는 것과 비교하여 폭발 반경을 크게 줄입니다. 파일 시스템 접근, 프로세스 범위, 네트워크 접근을 제한합니다. 그러나 차이는 구성에 따라 다릅니다. 환경 변수 주입이 광범위하고 이그레스가 열린 컨테이너는 네트워크 제어가 적용된 강화된 서버보다 덜 안전할 수 있습니다. 격리 모델은 시작점일 뿐 보장은 아닙니다.
마이크로VM 격리가 샌드박스가 완전히 안전하다는 것을 의미하나요?
아니요. 마이크로VM 격리(Firecracker, KVM 기반)는 공유 커널 컨테이너가 제공하지 못하는 강력한 호스트 경계를 제공합니다. 그러나 이그레스, 비밀, 패키지 설치 또는 감사 범위를 제어하지는 않습니다. 이그레스가 열려 있고 로그 수집이 없는 마이크로VM은 격리 계층이 강력하더라도 "완전히 안전"하지 않습니다.
AI 생성 코드가 샌드박스를 탈출할 수 있나요?
격리 모델과 구성에 따라 다릅니다. 컨테이너 탈출은 커널이나 잘못된 구성을 이용해야 하고, 마이크로VM 탈출은 VMM을 이용해야 합니다. 둘 다 가능하지만 흔하지는 않습니다. 더 실용적인 위험은 허용된 네트워크 경로를 통한 데이터 유출, 환경에서 비밀 읽기, 또는 제한되지 않은 패키지 관리자를 통한 악성 패키지 설치입니다.
대부분의 AI 코드 샌드박스에서 가장 큰 보안 위험은 무엇인가요?
열린 아웃바운드 이그레스가 가장 일반적으로 제대로 해결되지 않는 위험입니다. 많은 샌드박스는 편의를 위해 기본적으로 제한 없는 아웃바운드 인터넷 접근을 허용합니다. 이는 격리 경계가 아무리 강력하더라도 데이터 유출, 클라우드 메타데이터 엔드포인트를 통한 자격 증명 도난, 명령 및 제어 통신을 위한 경로를 생성합니다.
관리형 샌드박스를 사용해야 하나요, 아니면 직접 구축해야 하나요?
관리형 샌드박스는 마이크로VM 또는 컨테이너 수명 주기, 호스트 용량, 이미지 관리의 운영 복잡성을 처리합니다. 직접 구축하면 전체 정책 스택을 더 잘 제어할 수 있습니다. 어느 쪽이든 동일한 평가 질문이 적용됩니다: 이그레스 정책, 비밀 처리, 로그 범위, 리소스 제한, 감사 내보내기. 구축 대 구매 결정은 보안 평가와 별개입니다.
에이전트 샌드박스 보안이 기존 코드 실행 보안과 다른 점은 무엇인가요?
기존 코드 실행 보안은 어떤 코드가 실행될지 대략 알고 있다고 가정합니다. AI 에이전트는 이를 변경합니다. 단일 프롬프트로 인해 세션이 패키지를 설치하고, 파일을 쓰고, 셸 명령을 실행하고, 외부 API를 호출하고, 각 단계에 대한 명시적인 개발자 승인 없이 하위 프로세스를 생성할 수 있습니다. 이로 인해 감사 범위(모든 작업을 예측할 수 없음), 이그레스 제어(에이전트가 예상하지 못한 대상에 도달할 수 있음), 비밀 범위 지정(에이전트가 환경의 모든 것에 접근할 수 있음)이 더 중요해집니다.
프로덕션에서 AI 에이전트 격리를 위한 모범 사례는 무엇인가요?
프로덕션 에이전트 배포를 위한 실용적인 격리 체크리스트: 신뢰할 수 없거나 사용자가 제공한 코드의 경우 컨테이너만 사용하지 말고 마이크로VM급 격리(Firecracker 또는 이에 상응하는 것)를 사용하세요. 작업별 또는 사용자 세션별로 하나의 격리된 환경을 할당하고 관련 없는 워크로드 간에 샌드박스를 공유하지 마세요. 필요한 대상에 대한 명시적 허용 목록과 함께 기본 거부 이그레스를 사용하세요. 현재 작업에 필요한 자격 증명만 단기 토큰을 사용하여 주입하세요. 커널 또는 하이퍼바이저 수준에서 감사 로그를 수집하고 샌드박스 프로세스 내에서는 수집하지 마세요. 세션당 CPU, 메모리, 디스크 및 벽시계 제한을 적용하세요. 세션을 적극적으로 정리하세요. 작업이 완료되면 임시 샌드박스를 즉시 제거하세요. 이러한 모든 제어에 걸친 심층 방어는 단일 강력한 경계보다 훨씬 더 나은 보안을 제공합니다.
보안 팀이 엔터프라이즈 배포를 위해 AI 에이전트 샌드박스를 검토할 때 무엇을 평가해야 하나요?
엔터프라이즈 보안 검토는 6개 영역을 다루어야 합니다. (1) 격리 ** — 마이크로VM 또는 컨테이너? 각 세션이 파일 시스템, 프로세스 및 네트워크 수준에서 완전히 격리됩니까? (2) ** 이그레스 ** — 기본적으로 열려 있습니까, 아니면 기본적으로 차단됩니까? 이그레스 정책을 고객이 구성할 수 있습니까? 클라우드 메타데이터 엔드포인트(169.254.169.254)가 차단됩니까? (3) ** 비밀 ** — 자격 증명이 어떻게 주입됩니까? 단기 토큰으로 작업별로 범위가 지정됩니까? 세션 해체 시 정리됩니까? (4) ** 감사 ** — 로그가 샌드박스 프로세스 아래(커널/하이퍼바이저 수준)에서 생성됩니까? 로그를 SIEM으로 내보낼 수 있습니까? (5) ** 데이터 상주(Data residency) — 워크로드가 클라우드 계정 내에 유지되도록 BYOC 또는 VPC 배포가 가능합니까? (6) ** 규정 준수 태세** — 제공자가 어떤 인증을 보유하고 있으며 책임 공유 모델은 무엇입니까? 규제 요구 사항이 있는 팀의 경우 프로덕션 배포 전이 아닌 배포 전에 이 검토를 완료하세요.
AI 에이전트 샌드박스에서 커널 격리는 어떻게 작동하나요?
커널 격리는 에이전트 코드가 하드웨어 가상화 경계(KVM)에 의해 호스트 커널과 분리된 자체 커널이 있는 환경에서 실행됨을 의미합니다. Firecracker 기반 샌드박스에서 각 세션은 마이크로VM 내에서 최소 게스트 커널을 부팅합니다. 샌드박스 내부의 프로세스는 게스트 커널과 상호 작용하고, 호스트 커널은 내부에서 보이거나 도달할 수 없습니다. 게스트 커널에서 악용된 취약점은 KVM 경계가 사이에 있기 때문에 호스트로 자동 전파되지 않습니다. 이것이 모든 컨테이너가 호스트 커널을 공유하고 커널 익스플로잇이 동시에 모든 컨테이너에 영향을 미치는 컨테이너 기반 격리에 비해 주요 보안 이점입니다.
