Skip to content
Published on

AI 코딩 에이전트 샌드박싱: 안전한 코드 실행 격리와 보안 운영 가이드

Authors
  • Name
    Twitter

AI Coding Agent Sandbox Security

왜 지금 샌드박싱이 필수인가

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 컨테이너gVisorFirecracker MicroVM
격리 수준프로세스 수준네임스페이스/cgroup사용자 공간 커널하드웨어 가상화
커널 공유호스트 커널 공유호스트 커널 공유사용자 공간 커널전용 게스트 커널
시작 시간즉시 (ms 이하)초 단위초 단위125ms 이하
메모리 오버헤드최소낮음중간VM당 5MB
보안 강도중간낮음-중간높음최고
호스트 OSmacOS 전용Linux/macOS/WindowsLinux 전용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는 에이전트 샌드박싱을 전면 도입했다. 플랫폼별 구현은 다음과 같다.

플랫폼격리 기술특징
macOSSeatbelt (sandbox-exec)커널 수준 시스템 콜 차단
LinuxLandlock + seccomp커널 보안 모듈 조합
WindowsWSL2 내부 Linux 샌드박스WSL2 VM 경계 활용

Cursor의 샌드박스 에이전트는 다음과 같이 동작한다.

  1. 샌드박스 내에서 자유롭게 실행 (파일 읽기/쓰기, 빌드, 테스트)
  2. 샌드박스 경계를 넘는 요청 시 사용자에게 권한 요청 표시
  3. 인터넷 접근은 주로 권한 요청 대상

운영 체크리스트

샌드박싱 도입 전 체크리스트

  • 에이전트가 접근해야 하는 파일/디렉터리 범위를 명확히 정의했는가
  • .ssh, .aws, .gnupg 등 자격증명 디렉터리의 접근을 차단했는가
  • 네트워크 접근 정책(아웃바운드 허용 목록)을 정의했는가
  • 실행 가능한 바이너리 목록을 제한했는가
  • CPU, 메모리, PID 수 등 리소스 상한을 설정했는가

운영 중 체크리스트

  • 샌드박스 차단 로그를 수집하고 모니터링하고 있는가
  • 에이전트의 파일 쓰기 작업을 감사(audit) 로깅하고 있는가
  • 비정상적인 네트워크 요청에 대한 알림을 설정했는가
  • 샌드박스 정책을 정기적으로 검토하고 업데이트하는가
  • 에이전트 세션 종료 시 임시 데이터를 완전히 삭제하는가

보안 사고 대응 체크리스트

  • 샌드박스 탈출 시도 탐지 메커니즘이 있는가
  • 의심스러운 활동 발견 시 에이전트를 즉시 종료할 수 있는가
  • 사고 발생 시 영향 범위를 파악할 수 있는 로그가 충분한가
  • MicroVM/컨테이너의 포렌식 스냅샷을 저장하는 절차가 있는가
  • 사고 후 정책 업데이트 프로세스가 정의되어 있는가

결론: 최소 권한 원칙의 현대적 적용

AI 코딩 에이전트의 샌드박싱은 선택이 아닌 필수다. 핵심 원칙을 정리하면 다음과 같다.

  1. Deny-first 정책: 모든 접근을 기본 차단하고 필요한 것만 명시적으로 허용
  2. OS 수준 강제: 앱 계층 제한은 우회 가능하므로 커널/하드웨어 수준 격리 적용
  3. 방어 심층: 단일 레이어 의존 대신 다층 보안 구성
  4. 일회용 환경: 세션 종료 시 환경을 폐기하여 시크릿 축적 방지
  5. 지속적 감사: 차단 로그 모니터링과 정책 정기 업데이트

로컬 개발에서는 Agent Safehouse로 시작하고, 프로덕션에서는 Firecracker MicroVM이나 gVisor로 전환하는 단계적 접근을 권장한다. 중요한 것은 지금 당장 시작하는 것이다.


참고 자료