- Authors
- Name
- 왜 지금 샌드박싱이 필수인가
- AI 코딩 에이전트의 보안 위협 모델
- 격리 기술 비교: 어떤 샌드박스를 선택할 것인가
- 실전 1: macOS sandbox-exec와 Agent Safehouse
- 실전 2: Docker 컨테이너 기반 격리
- 실전 3: Firecracker MicroVM으로 하드웨어 수준 격리
- 실전 4: Kubernetes + gVisor 프로덕션 구성
- 실패 사례와 교훈: NVIDIA Red Team 발견 취약점
- 방어 심층(Defense-in-Depth) 아키텍처
- Cursor의 플랫폼별 샌드박싱 구현
- 운영 체크리스트
- 결론: 최소 권한 원칙의 현대적 적용
- 참고 자료

왜 지금 샌드박싱이 필수인가
2026년 AI 코딩 에이전트는 단순 코드 완성을 넘어 파일 생성, 셸 명령 실행, 네트워크 요청까지 자율적으로 수행한다. Cursor, Claude Code, GitHub Copilot 같은 도구가 개발자와 동일한 권한으로 작동하면서, 악의적 프롬프트 하나로 SSH 키 탈취나 AWS 자격증명 유출이 가능해졌다. NVIDIA AI Red Team이 2026년 1월 발표한 보고서에 따르면, 샌드박스를 적용한 에이전트는 보안 사고를 90% 감소시킨다.
이 글에서는 macOS sandbox-exec부터 컨테이너, MicroVM까지 4가지 격리 기술의 원리와 실전 적용법을 코드와 함께 정리한다.
AI 코딩 에이전트의 보안 위협 모델
에이전트가 가진 권한의 위험성
AI 코딩 에이전트는 실행한 사용자의 권한을 그대로 상속받는다. 이는 다음과 같은 공격 벡터를 열어준다.
| 위협 유형 | 설명 | 실제 사례 |
|---|---|---|
| 자격증명 탈취 | .aws, .ssh 디렉터리 접근 | 에이전트가 설정 파일 읽기로 키 유출 |
| 코드 인젝션 | .cursorrules 파일 조작 | Rules File Backdoor 공격(Pillar Security 발견) |
| MCP 서버 하이재킹 | 악성 MCP 초기화 명령 | 에이전트 시작 시 악성 훅 주입 |
| 네트워크 유출 | 외부 서버로 데이터 전송 | 코드 리뷰 중 소스코드 외부 전송 |
| 파일 시스템 파괴 | 프로젝트 외부 파일 삭제/수정 | YOLO 모드에서 의도치 않은 파일 삭제 |
YOLO 모드의 진짜 위험
Cursor의 Auto-run(구 YOLO 모드)은 에이전트가 사용자 승인 없이 다단계 작업을 수행하는 모드다. 허용 목록(allowlist)과 차단 목록(denylist) 설정이 있지만, 에이전트가 임의의 명령을 실행할 수 있는 이상 이러한 방어는 우회될 수 있다. Backslash Security의 연구(2025)에 따르면, 허용된 도구를 체이닝하여 차단된 명령에 도달하는 간접 실행 공격이 가능하다.
격리 기술 비교: 어떤 샌드박스를 선택할 것인가
4가지 격리 기술 비교표
| 기준 | sandbox-exec (macOS) | Docker 컨테이너 | gVisor | Firecracker MicroVM |
|---|---|---|---|---|
| 격리 수준 | 프로세스 수준 | 네임스페이스/cgroup | 사용자 공간 커널 | 하드웨어 가상화 |
| 커널 공유 | 호스트 커널 공유 | 호스트 커널 공유 | 사용자 공간 커널 | 전용 게스트 커널 |
| 시작 시간 | 즉시 (ms 이하) | 초 단위 | 초 단위 | 125ms 이하 |
| 메모리 오버헤드 | 최소 | 낮음 | 중간 | VM당 5MB |
| 보안 강도 | 중간 | 낮음-중간 | 높음 | 최고 |
| 호스트 OS | macOS 전용 | Linux/macOS/Windows | Linux 전용 | Linux 전용 |
| 적합 대상 | 로컬 개발 에이전트 | 개발/스테이징 | K8s 프로덕션 | 프로덕션 멀티테넌트 |
선택 가이드
- 로컬 macOS 개발: sandbox-exec 또는 Agent Safehouse
- CI/CD 파이프라인: Docker + seccomp 프로파일
- Kubernetes 프로덕션: gVisor (RuntimeClass 설정)
- 멀티테넌트 SaaS: Firecracker MicroVM 또는 Kata Containers
실전 1: macOS sandbox-exec와 Agent Safehouse
sandbox-exec 기본 원리
macOS의 sandbox-exec는 Apple의 Seatbelt 프레임워크를 사용하여 커널 수준에서 시스템 콜을 차단한다. App Store 앱에 적용되는 것과 동일한 기술이다. 프로파일은 Scheme(LISP 계열) 문법으로 작성한다.
기본 sandbox-exec 프로파일 작성
다음은 AI 에이전트를 위한 deny-first 샌드박스 프로파일 예시다.
(version 1)
(deny default)
;; 기본 시스템 라이브러리 읽기 허용
(allow file-read*
(subpath "/usr/lib")
(subpath "/usr/share")
(subpath "/System/Library")
(subpath "/Library/Frameworks")
(subpath "/private/var/db/dyld"))
;; 프로젝트 디렉터리만 읽기/쓰기 허용
(allow file-read* file-write*
(subpath "/Users/dev/projects/my-app"))
;; 실행 가능한 바이너리 제한
(allow process-exec
(literal "/usr/bin/git")
(literal "/usr/bin/python3")
(literal "/usr/local/bin/node"))
;; 네트워크 완전 차단
(deny network*)
;; 민감 디렉터리 명시적 차단
(deny file-read* file-write*
(subpath "/Users/dev/.ssh")
(subpath "/Users/dev/.aws")
(subpath "/Users/dev/.gnupg")
(subpath "/Users/dev/.config/gcloud"))
;; 프로세스 포크 허용 (빌드/테스트에 필요)
(allow process-fork)
(allow signal (target self))
실행 방법은 다음과 같다.
# sandbox-exec로 에이전트 실행
sandbox-exec -f /path/to/agent-sandbox.sb -- claude --dangerously-skip-permissions
# 프로파일 적용 확인 (차단 로그)
log stream --predicate 'subsystem == "com.apple.sandbox"' --level debug
Agent Safehouse 활용
Agent Safehouse는 위의 sandbox-exec를 래핑하여 사용하기 쉬운 CLI를 제공한다. 순수 Bash 스크립트로 구현되어 있어 전체 코드를 직접 읽고 감사할 수 있다.
# Agent Safehouse 설치
git clone https://github.com/eugene1g/agent-safehouse.git
cd agent-safehouse
chmod +x safehouse
# 프로젝트 디렉터리에서 에이전트 실행
cd ~/projects/my-app
safehouse claude --dangerously-skip-permissions
# 커스텀 정책으로 실행
safehouse --policy custom-policy.sb -- claude
Agent Safehouse의 기본 정책은 다음 원칙을 따른다.
- Deny-first: 모든 접근을 기본 차단 후 필요한 것만 허용
- 프로젝트 범위 제한: 현재 작업 디렉터리와 하위 디렉터리만 접근 가능
- 민감 파일 보호: .ssh, .aws, .gnupg 등 자격증명 디렉터리 차단
- 네트워크 제어: 필요 시에만 네트워크 접근 허용
머신별 예외 정책을 추가할 수도 있다.
;; machine-local-policy.sb - 머신 고유 설정
(allow file-read*
(home-literal "/.gitignore_global")
(home-subpath "/Library/Application Support/Claude"))
;; 특정 공유 볼륨 접근 허용
(allow file-read*
(subpath "/Volumes/Shared/Engineering"))
실전 2: Docker 컨테이너 기반 격리
보안 강화된 Docker 설정
기본 Docker 컨테이너는 호스트 커널을 공유하므로 AI 에이전트의 완전한 격리에는 부족하다. 다음과 같이 보안을 강화해야 한다.
# docker-compose.yml - AI 에이전트 격리 환경
version: '3.8'
services:
ai-agent:
build:
context: .
dockerfile: Dockerfile.agent
security_opt:
- no-new-privileges:true
- seccomp:seccomp-profile.json
- apparmor:agent-profile
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
read_only: true
tmpfs:
- /tmp:size=512M,noexec,nosuid
volumes:
- ./project:/workspace:rw
# 민감 디렉터리 마운트 금지
networks:
- agent-isolated
deploy:
resources:
limits:
cpus: '2.0'
memory: 4G
pids: 256
reservations:
cpus: '0.5'
memory: 512M
environment:
- HOME=/workspace
# API 키는 시크릿 매니저에서 주입
user: '1000:1000'
networks:
agent-isolated:
driver: bridge
internal: true # 외부 네트워크 차단
seccomp 프로파일로 시스템 콜 제한
{
"defaultAction": "SCMP_ACT_ERRNO",
"defaultErrnoRet": 1,
"architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_AARCH64"],
"syscalls": [
{
"names": [
"read",
"write",
"open",
"close",
"stat",
"fstat",
"lstat",
"poll",
"lseek",
"mmap",
"mprotect",
"munmap",
"brk",
"access",
"pipe",
"select",
"sched_yield",
"clone",
"fork",
"vfork",
"execve",
"exit",
"wait4",
"kill",
"uname",
"fcntl",
"flock",
"fsync",
"fdatasync",
"truncate",
"getdents",
"getcwd",
"chdir",
"mkdir",
"rmdir",
"unlink",
"readlink",
"chmod",
"chown",
"getuid",
"getgid",
"geteuid",
"getegid",
"getpid",
"getppid",
"socket",
"connect",
"sendto",
"recvfrom",
"bind",
"listen",
"accept",
"arch_prctl",
"set_tid_address",
"set_robust_list",
"futex",
"clock_gettime",
"epoll_create",
"epoll_ctl",
"epoll_wait",
"openat",
"newfstatat",
"readlinkat",
"getrandom",
"pread64",
"pwrite64"
],
"action": "SCMP_ACT_ALLOW"
},
{
"names": [
"ptrace",
"mount",
"umount2",
"pivot_root",
"swapon",
"swapoff",
"reboot",
"sethostname",
"setdomainname",
"init_module",
"delete_module",
"kexec_load",
"perf_event_open"
],
"action": "SCMP_ACT_ERRNO",
"errnoRet": 1
}
]
}
실전 3: Firecracker MicroVM으로 하드웨어 수준 격리
Firecracker가 AI 에이전트에 적합한 이유
Firecracker는 AWS Lambda와 Fargate의 기반 기술로, 다음과 같은 특성이 AI 에이전트 격리에 이상적이다.
- 전용 게스트 커널: 호스트 커널과 완전히 분리되어 커널 취약점 기반 탈출이 불가
- 125ms 이하 부팅: 컨테이너에 준하는 시작 속도
- VM당 5MB 메모리: 수백 개의 동시 에이전트 실행 가능
- 최소 디바이스 모델: 공격 표면(attack surface) 최소화
Firecracker 에이전트 샌드박스 구성
#!/bin/bash
# firecracker-agent-sandbox.sh
# Firecracker MicroVM으로 AI 에이전트 격리 실행
FIRECRACKER_BIN="/usr/local/bin/firecracker"
KERNEL_PATH="/opt/firecracker/vmlinux"
ROOTFS_PATH="/opt/firecracker/agent-rootfs.ext4"
SOCKET_PATH="/tmp/firecracker-agent.socket"
API_URL="http://localhost"
# 기존 소켓 정리
rm -f "$SOCKET_PATH"
# Firecracker 프로세스 시작
$FIRECRACKER_BIN --api-sock "$SOCKET_PATH" &
FC_PID=$!
sleep 0.5
# 커널 설정
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/boot-source" \
-H "Content-Type: application/json" \
-d '{
"kernel_image_path": "'"$KERNEL_PATH"'",
"boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
}'
# 루트 파일 시스템 (에이전트 이미지)
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/drives/rootfs" \
-H "Content-Type: application/json" \
-d '{
"drive_id": "rootfs",
"path_on_host": "'"$ROOTFS_PATH"'",
"is_root_device": true,
"is_read_only": false
}'
# 리소스 제한 (2 vCPU, 2GB RAM)
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/machine-config" \
-H "Content-Type: application/json" \
-d '{
"vcpu_count": 2,
"mem_size_mib": 2048
}'
# 네트워크 인터페이스 (격리 네트워크)
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/network-interfaces/eth0" \
-H "Content-Type: application/json" \
-d '{
"iface_id": "eth0",
"guest_mac": "AA:FC:00:00:00:01",
"host_dev_name": "tap-agent0"
}'
# Rate limiter 설정 (네트워크 대역폭 제한)
curl --unix-socket "$SOCKET_PATH" -X PATCH "$API_URL/network-interfaces/eth0" \
-H "Content-Type: application/json" \
-d '{
"iface_id": "eth0",
"rx_rate_limiter": {
"bandwidth": { "size": 10485760, "refill_time": 1000 },
"ops": { "size": 1000, "refill_time": 1000 }
},
"tx_rate_limiter": {
"bandwidth": { "size": 10485760, "refill_time": 1000 },
"ops": { "size": 1000, "refill_time": 1000 }
}
}'
# MicroVM 시작
curl --unix-socket "$SOCKET_PATH" -X PUT "$API_URL/actions" \
-H "Content-Type: application/json" \
-d '{ "action_type": "InstanceStart" }'
echo "Firecracker MicroVM started (PID: $FC_PID)"
echo "Agent is running in isolated VM"
# 작업 완료 후 VM 종료
cleanup() {
kill "$FC_PID" 2>/dev/null
rm -f "$SOCKET_PATH"
echo "MicroVM destroyed - host remains untouched"
}
trap cleanup EXIT
실전 4: Kubernetes + gVisor 프로덕션 구성
GKE Agent Sandbox 설정
Google Kubernetes Engine(GKE)에서는 gVisor 기반 Agent Sandbox를 RuntimeClass로 제공한다.
# gvisor-runtime-class.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: gvisor
handler: runsc
scheduling:
nodeSelector:
sandbox.gke.io/runtime: gvisor
---
# agent-sandbox-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: ai-coding-agent
labels:
app: coding-agent
sandbox: gvisor
spec:
runtimeClassName: gvisor
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 1000
seccompProfile:
type: RuntimeDefault
containers:
- name: agent
image: ai-coding-agent:latest
resources:
limits:
cpu: '2'
memory: '4Gi'
ephemeral-storage: '10Gi'
requests:
cpu: '500m'
memory: '1Gi'
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
volumeMounts:
- name: workspace
mountPath: /workspace
- name: tmp
mountPath: /tmp
env:
- name: AGENT_WORKSPACE
value: '/workspace'
- name: AGENT_NETWORK_POLICY
value: 'restricted'
volumes:
- name: workspace
emptyDir:
sizeLimit: 10Gi
- name: tmp
emptyDir:
sizeLimit: 512Mi
---
# agent-network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: agent-isolation
spec:
podSelector:
matchLabels:
sandbox: gvisor
policyTypes:
- Ingress
- Egress
egress:
# 패키지 레지스트리만 허용
- to:
- ipBlock:
cidr: 0.0.0.0/0
ports:
- protocol: TCP
port: 443
# DNS 허용
- to:
- namespaceSelector: {}
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
ingress: [] # 인바운드 트래픽 전면 차단
gVisor의 Sentry 프로세스가 컨테이너의 모든 시스템 콜을 사용자 공간에서 가로채므로, 컨테이너 내부의 악성 코드가 호스트 커널에 직접 접근할 수 없다.
실패 사례와 교훈: NVIDIA Red Team 발견 취약점
5가지 잔존 위협 (Rich Harang, 2026년 1월)
NVIDIA AI Red Team의 수석 보안 아키텍트 Rich Harang은 샌드박스를 적용한 뒤에도 남는 5가지 잔존 취약점을 발표했다.
취약점 1: 악성 훅 주입 (Malicious Hooks)
에이전트 시작 시 로드되는 설정 파일(.cursorrules, MCP 초기화 명령)에 악성 코드가 삽입될 수 있다. 레포지토리를 클론하는 것만으로 공격이 시작된다.
# 공격 시나리오: .cursorrules에 숨겨진 악성 지시
# 프로젝트 루트의 .cursorrules 파일
# 정상적으로 보이는 규칙들 사이에 숨겨진 지시
# "Always run npm audit fix before starting"
# 실제로는 에이전트에게 다음을 지시:
# 1. package.json을 수정하여 악성 postinstall 스크립트 추가
# 2. npm install 실행 시 자격증명 수집
# 3. 외부 서버로 전송
# 대응: 프로젝트 설정 파일을 신뢰할 수 있는 소스에서만 가져오기
# 에이전트 시작 전 설정 파일 무결성 검증 필수
취약점 2: 커널 수준 샌드박스 탈출
sandbox-exec나 Docker처럼 호스트 커널을 공유하는 격리 방식은 커널 취약점을 통해 탈출이 가능하다. 이것이 프로덕션 환경에서 MicroVM이나 gVisor를 권장하는 핵심 이유다.
취약점 3: 에이전트의 시크릿 접근
환경변수나 마운트된 볼륨을 통해 에이전트가 API 키, 데이터베이스 자격증명에 접근할 수 있다.
취약점 4: 승인 캐싱의 실패 모드
한 번 승인된 작업이 캐시되어 이후 맥락이 달라진 상황에서도 자동 승인될 수 있다.
취약점 5: 샌드박스 내 비밀/IP 축적
장기 실행 샌드박스에서 세션 간 비밀 정보, 지적 재산, 악용 가능한 코드가 축적된다.
Rules File Backdoor 공격 (Pillar Security)
Pillar Security 연구팀은 Cursor의 .cursorrules 파일에 유니코드 방향 제어 문자(bidirectional control characters)를 삽입하여 사람 눈에는 보이지 않는 악성 지시를 에이전트에게 전달하는 공격을 발견했다. 이 공격은 코드 리뷰에서도 발견되지 않으며, 에이전트가 생성하는 모든 코드에 백도어를 삽입할 수 있다.
앱 계층 vs OS 계층 방어의 교훈
NVIDIA Red Team의 핵심 권고사항은 앱 계층 제한보다 OS 수준 강제가 우월하다는 것이다. 에이전트가 서브프로세스를 생성하면 상위 애플리케이션은 가시성을 잃는다. 공격자는 승인된 도구를 체이닝하여 차단된 명령에 도달할 수 있다. macOS Seatbelt, Linux Bubblewrap, Windows AppContainer 같은 OS 수준 메커니즘이 애플리케이션 아래 계층에서 제한을 강제하므로 간접 실행 경로까지 차단할 수 있다.
방어 심층(Defense-in-Depth) 아키텍처
계층별 보안 구성
프로덕션 AI 에이전트는 단일 보안 레이어가 아닌 다층 방어를 구성해야 한다.
Layer 5: 모니터링/감사 (Audit Logging, Anomaly Detection)
|
Layer 4: 네트워크 격리 (NetworkPolicy, Firewall Rules)
|
Layer 3: 리소스 제한 (cgroups, CPU/Memory/PID limits)
|
Layer 2: 권한 범위 지정 (RBAC, File Permission, Capability Drop)
|
Layer 1: 실행 격리 (MicroVM / gVisor / sandbox-exec)
|
Layer 0: 하드웨어 (TPM, Secure Boot, VT-x)
에이전트 권한 정책 설정 예시
다음은 에이전트별 권한을 세분화하여 관리하는 정책 설정 예시다.
# agent-security-policy.yaml
# AI 코딩 에이전트 보안 정책 정의
policies:
code-review-agent:
description: '코드 리뷰 전용 에이전트'
filesystem:
read:
- '/workspace/src'
- '/workspace/tests'
- '/workspace/package.json'
- '/workspace/tsconfig.json'
write: [] # 읽기 전용
deny:
- '/workspace/.env'
- '/workspace/.env.local'
- '/workspace/secrets'
network:
allow_outbound:
- 'api.openai.com:443'
- 'api.anthropic.com:443'
deny_all_inbound: true
process:
allow_exec:
- '/usr/bin/git'
- '/usr/local/bin/node'
deny_exec:
- '/bin/sh'
- '/bin/bash'
- '/usr/bin/curl'
- '/usr/bin/wget'
resources:
max_cpu: '1.0'
max_memory: '2Gi'
max_pids: 128
max_file_size: '50Mi'
development-agent:
description: '개발 작업 에이전트 (제한적 쓰기)'
filesystem:
read:
- '/workspace'
write:
- '/workspace/src'
- '/workspace/tests'
- '/workspace/docs'
deny:
- '/workspace/.env'
- '/workspace/.git/hooks'
- '/workspace/node_modules/.cache'
network:
allow_outbound:
- 'registry.npmjs.org:443'
- 'api.openai.com:443'
deny_all_inbound: true
process:
allow_exec:
- '/usr/bin/git'
- '/usr/local/bin/node'
- '/usr/local/bin/npm'
- '/usr/bin/python3'
deny_exec:
- '/usr/bin/ssh'
- '/usr/bin/scp'
resources:
max_cpu: '2.0'
max_memory: '4Gi'
max_pids: 256
max_file_size: '100Mi'
audit:
log_all_file_writes: true
log_all_network_requests: true
alert_on_denied_access: true
Cursor의 플랫폼별 샌드박싱 구현
2026년 초 Cursor는 에이전트 샌드박싱을 전면 도입했다. 플랫폼별 구현은 다음과 같다.
| 플랫폼 | 격리 기술 | 특징 |
|---|---|---|
| macOS | Seatbelt (sandbox-exec) | 커널 수준 시스템 콜 차단 |
| Linux | Landlock + seccomp | 커널 보안 모듈 조합 |
| Windows | WSL2 내부 Linux 샌드박스 | WSL2 VM 경계 활용 |
Cursor의 샌드박스 에이전트는 다음과 같이 동작한다.
- 샌드박스 내에서 자유롭게 실행 (파일 읽기/쓰기, 빌드, 테스트)
- 샌드박스 경계를 넘는 요청 시 사용자에게 권한 요청 표시
- 인터넷 접근은 주로 권한 요청 대상
운영 체크리스트
샌드박싱 도입 전 체크리스트
- 에이전트가 접근해야 하는 파일/디렉터리 범위를 명확히 정의했는가
- .ssh, .aws, .gnupg 등 자격증명 디렉터리의 접근을 차단했는가
- 네트워크 접근 정책(아웃바운드 허용 목록)을 정의했는가
- 실행 가능한 바이너리 목록을 제한했는가
- CPU, 메모리, PID 수 등 리소스 상한을 설정했는가
운영 중 체크리스트
- 샌드박스 차단 로그를 수집하고 모니터링하고 있는가
- 에이전트의 파일 쓰기 작업을 감사(audit) 로깅하고 있는가
- 비정상적인 네트워크 요청에 대한 알림을 설정했는가
- 샌드박스 정책을 정기적으로 검토하고 업데이트하는가
- 에이전트 세션 종료 시 임시 데이터를 완전히 삭제하는가
보안 사고 대응 체크리스트
- 샌드박스 탈출 시도 탐지 메커니즘이 있는가
- 의심스러운 활동 발견 시 에이전트를 즉시 종료할 수 있는가
- 사고 발생 시 영향 범위를 파악할 수 있는 로그가 충분한가
- MicroVM/컨테이너의 포렌식 스냅샷을 저장하는 절차가 있는가
- 사고 후 정책 업데이트 프로세스가 정의되어 있는가
결론: 최소 권한 원칙의 현대적 적용
AI 코딩 에이전트의 샌드박싱은 선택이 아닌 필수다. 핵심 원칙을 정리하면 다음과 같다.
- Deny-first 정책: 모든 접근을 기본 차단하고 필요한 것만 명시적으로 허용
- OS 수준 강제: 앱 계층 제한은 우회 가능하므로 커널/하드웨어 수준 격리 적용
- 방어 심층: 단일 레이어 의존 대신 다층 보안 구성
- 일회용 환경: 세션 종료 시 환경을 폐기하여 시크릿 축적 방지
- 지속적 감사: 차단 로그 모니터링과 정책 정기 업데이트
로컬 개발에서는 Agent Safehouse로 시작하고, 프로덕션에서는 Firecracker MicroVM이나 gVisor로 전환하는 단계적 접근을 권장한다. 중요한 것은 지금 당장 시작하는 것이다.
참고 자료
- NVIDIA - Practical Security Guidance for Sandboxing Agentic Workflows - NVIDIA AI Red Team의 에이전트 워크플로우 샌드박싱 보안 가이드
- NVIDIA - How Code Execution Drives Key Risks in Agentic AI Systems - 에이전틱 AI 시스템의 코드 실행 리스크 분석
- Agent Safehouse - GitHub - macOS 네이티브 AI 에이전트 샌드박싱 도구
- Agent Safehouse - 공식 문서 - Agent Safehouse 아키텍처 및 정책 빌더
- Cursor - Agent Sandboxing - Cursor의 에이전트 샌드박싱 구현 설명
- Firecracker - GitHub - AWS의 서버리스 MicroVM 기술
- gVisor - 공식 사이트 - Google의 컨테이너 보안 플랫폼
- Northflank - How to Sandbox AI Agents in 2026 - MicroVM, gVisor 격리 전략 비교
- GKE - Agent Sandbox Documentation - Google Kubernetes Engine의 에이전트 샌드박스 설정 가이드
- Hacker News - Agent Safehouse Discussion - Agent Safehouse에 대한 커뮤니티 논의
- Pillar Security - Rules File Backdoor Attack - Cursor/Copilot 에이전트 무기화 취약점 발견
- Backslash Security - Cursor YOLO Mode Bypass - Cursor YOLO 모드 보안 우회 분석