안전한 AI 에이전트 개발 환경을 위한 샌드박스(sandbox)

RECOMMEND POSTS BEFORE THIS

• 하네스 엔지니어링(Harness Engineering)

0. 들어가면서

최근 회사에서 클로드 코드(Claude Code), 코덱스(Codex), 코파일럿(Copilot) 같은 AI 코딩 에이전트 사용을 지원해 줬다. 덕분에 토이 프로젝트에서 AI 에이전트를 여러모로 사용해 보고 있다. 새로운 지식을 배우고 사고를 넓히는 과정이 너무 즐거워 시간 가는 줄 모르겠다. 정말 머리에 새로운 지식을 집어넣는 것에 드는 비용이 매우 저렴해졌다. 토큰이라는 비용을 소모하고 있지만, 시간이라는 단위를 초 단위로 압축하고 있는 기분이 들어서 토큰 비용은 시간에 비해 매우 저렴해 보인다.

최근 팀에서 AI를 어떻게 사용할지, 안전하게 사용할 방법은 없을지 연구한 내용을 공유하는 시간을 갖고 있다. 지난주에는 충분한 권한만 부여하면 막강한 힘을 갖게 되는 AI 에이전트를 로컬 환경에서 안전하게 사용하는 방법을 공유받았다. 엔지니어 입장에서 샌드박스(sandbox) 환경에 대한 주제가 가장 흥미로웠다. 나도 로컬 환경에서 AI 에이전트를 안전하게 사용하고 싶었다.

이번 글에서는 AI 에이전트를 사용할 때 보안 문제가 발생할 가능성을 낮춰 주면서도, 더 편리하게 사용하기 위해 AI 에이전트에게 큰 권한을 줄 수 있는 샌드박스 환경 구축과 관련된 이야기를 정리했다.

1. Why do we need a sandbox environment?

샌드박스 환경은 소프트웨어 개발 및 보안에서 외부 시스템에 영향을 주지 않고 안전하게 코드, 프로그램, 데이터를 테스트하거나 실행할 수 있도록 격리된 공간이다. 실제 운영 환경과 분리되어 있어 악성 코드 분석, 기능 테스트, 디버깅 등을 안전하게 수행할 수 있는 ‘안전한 놀이터’ 역할을 한다. 주로 다음 용도로 사용된다.

• 신규 기능이나 코드를 실제 서비스 환경에 반영하기 전, 오류 여부를 확인할 수 있다.
• 의심스러운 파일이나 프로그램을 가상화된 공간에서 실행해 시스템 피해 없이 악성 코드 여부를 분석할 수 있다.

이런 샌드박스 환경은 왜 필요할까? AI 코딩 에이전트는 사용자의 권한을 그대로 상속받아 파일 생성, 셸 명령 실행, 네트워크 요청 등을 자율적으로 수행할 수 있다 보니 아무래도 보안 문제가 발생할 가능성이 커진다.

• AI 에이전트는 충분한 권한이 주어지면 PC의 로컬 시스템에 직접 접근할 수 있다. 파일을 수정하거나 삭제하는 셸 명령을 실행할 수 있다.
• AI 에이전트는 외부 데이터(웹 페이지의 숨겨진 흰색 텍스트, PDF의 숨겨진 레이어, 복제한 저장소의 주석 등)에 포함된 악의적인 지시를 읽고 그대로 실행하는 ‘간접 프롬프트 인젝션’ 공격에 매우 취약하다. 샌드박스가 없다면 에이전트가 민감한 디렉터리(e.g. ~/.aws, ~/.ssh)에 접근해 자격 증명을 읽고, 이를 일반적인 HTTP나 DNS 요청으로 위장해 외부 공격자 서버로 몰래 유출할 수 있다.
• AI 에이전트가 코드를 작성할 때 존재하지 않는 패키지 이름을 지어내기도 한다. 공격자가 이를 예측해 해당 이름으로 npm이나 PyPI 등에 악성 패키지를 미리 등록해 두면, 에이전트가 자율적으로 악성 코드를 다운로드하고 실행하게 된다. 샌드박스는 설령 악성 코드가 다운로드되어 실행되더라도 시스템 전체가 장악되는 것을 막는 방어막 역할을 한다.

단순히 에이전트의 시스템 프롬프트에 “파일을 삭제하지 마라”거나 “악의적인 행동을 하지 마라”라고 지시하는 것은 보안 통제 수단이 될 수 없다. 에이전트를 잠재적인 공격자로 간주하고, 애플리케이션 계층이 아닌 OS나 하드웨어 수준에서 물리적이고 강제적인 제한을 두는 샌드박스가 필수적이다.

보안을 위해 에이전트가 터미널 명령어를 실행할 때마다 사람의 승인을 요구하도록 설정할 수 있지만, 이는 개발 흐름을 방해한다. 사용자는 내용 확인 없이 기계적으로 승인 버튼만 누르게 되고, 개발 피로도도 높아진다. 샌드박스 환경을 구축하면 안전하게 격리된 환경에서 에이전트가 사용자 승인 없이 자유롭게 코드를 실행하도록 허용할 수 있다. 경계를 벗어나려는 시도만 차단할 수 있어서 작업 중단을 크게 줄이고 생산성과 보안을 동시에 확보할 수 있다.

2. How to build a sandbox environment?

샌드박스 환경은 어떻게 만들 수 있을까? 샌드박스를 구축할 수 있는 방법을 알아보자.

2.1. Embedded sandbox in AI agents

클로드 코드와 코덱스는 자체적으로 샌드박스 환경을 제공한다.

• 클로드 코드의 기본 샌드박스는 주로 Bash 도구에 적용되며, 세션 내에서 /sandbox 명령어를 입력해 활성화할 수 있다.
• 코덱스는 에이전트를 실행할 때 --sandbox 옵션을 지정해 샌드박스 환경을 적용할 수 있다.

클로드 코드와 코덱스는 모두 무거운 가상 머신(VM)이나 별도의 컨테이너를 띄우는 대신, 각 운영체제가 제공하는 보안 프리미티브를 활용해 하위 프로세스를 격리한다.

• macOS: 내장된 Seatbelt 프레임워크를 사용한다.
• Linux 및 WSL2: bubblewrap을 사용하여 파일 시스템과 프로세스를 격리한다. WSL1은 지원하지 않는다.

클로드 코드의 샌드박스는 실행하는 Bash 명령어뿐만 아니라, 그 명령어가 파생시키는 모든 자식 프로세스(e.g. npm, kubectl 등)에도 동일하게 강제 적용된다. 앱/OS 계층의 보안 울타리 역할을 하지만, 호스트 커널을 공유한다는 한계가 있다. 만약 완전히 신뢰할 수 없는 외부 코드를 실행해야 할 만큼 강력한 격리가 필요하다면, 앤트로픽에서 제공하는 공식 DevContainer(Docker 기반) 설정을 샌드박스와 결합해 사용하는 것이 권장된다.

클로드 코드는 샌드박스 환경을 구축할 때 두 가지 실행 모드를 지원한다.

• 자동 허용 모드(Auto-allow): 샌드박스의 안전한 경계 내에서 실행되는 명령어는 사용자의 승인 팝업 없이 자동으로 실행된다. 이를 통해 사용자의 승인 피로도를 대폭 줄여 준다.
• 일반 권한 모드(Regular permissions): 샌드박스로 격리되어 있더라도 모든 명령어에 대해 기존처럼 사용자의 승인을 요청한다.

클로드 코드 샌드박스 환경에서 네트워크 트래픽은 샌드박스 외부에서 도는 프록시 서버를 거치도록 강제되어 데이터 유출을 방지한다. 명시적으로 승인된 도메인만 접근할 수 있게 하거나 새로운 도메인에 대한 접근이 발생하면 OS 수준에서 차단되며, 사용자에게 연결을 허용할지 묻는 알림이 표시된다.

코덱스는 샌드박스 모드와 승인 정책을 조합해서 자율성과 보안의 수준을 결정할 수 있다. 코덱스의 샌드박스는 세 가지 모드를 지원한다.

• read-only(기본값): 파일 읽기만 가능하며 파일 수정이나 명령어 실행은 불가능하다.
• workspace-write: 지정된 워크스페이스 내에서만 읽기/쓰기 및 명령 실행이 허용되며, 네트워크 접근은 차단된다.
• danger-full-access: 시스템의 모든 곳에 쓰기를 허용하는 매우 위험한 모드다.

에이전트가 특정 행동을 하기 전에 사용자에게 권한을 물어볼지 결정하는 승인 정책도 세 가지 존재한다.

• untrusted(기본값): 모든 작업에 대해 사용자의 승인이 필요하다.
• on-request: 워크스페이스를 벗어나는 등 샌드박스 밖의 작업에 대해서만 승인을 요청한다.
• never: 사용자의 승인 없이 작업을 실행하지만, 샌드박스의 물리적 제한은 그대로 유지된다.

코덱스 샌드박스 환경에서 네트워크 연결은 기본적으로 차단되어 있다. 에이전트가 의도치 않게 외부로 데이터를 유출하거나 악의적인 통신을 하는 것을 막기 위해 네트워크 연결을 엄격하게 통제한다. 샌드박스 내부에서 실행되는 명령어는 사용자의 명시적인 승인이 없으면 외부 네트워크로 아웃바운드 통신을 할 수 없다. config.toml 설정 파일을 통해 재사용 가능한 네트워크 권한 프로파일을 구성할 수 있다.

코덱스는 클로드 코드와 마찬가지로 운영체제 플랫폼에 따라 네이티브 기능을 활용해 에이전트를 격리한다. Seatbelt 프레임워크와 bubblewrap을 사용하므로 호스트 커널을 공유한다는 보안 한계점도 동일하게 존재한다.

2.2. Other methods for creating a sandbox environment

위에서 살펴본 샌드박스 환경 구축 방법은 무거운 가상화 없이 운영체제가 제공하는 보안 프리미티브를 사용해 앱 계층에서 프로세스를 격리하는 방법이다. 내장 샌드박스 환경 외에도 어떤 방법이 있을까? 크게 나누면 다음 기술을 활용할 수 있다.

• 컨테이너(container) 환경
• 유저스페이스(userspace) 커널 환경
• 마이크로VM(micro VM) 환경
• 일반 가상 머신(VM, virtual machine) 환경

컨테이너 환경은 운영체제(OS) 및 프로세스 수준에서 격리가 가능하다. 리눅스의 네임스페이스와 cgroup을 사용하지만 호스트 시스템의 커널을 공유한다. 시작 속도가 빠르고 리소스 오버헤드가 낮아 가볍게 실행할 수 있다. 개발자들에게 친숙한 방식이라 기존 CI/CD 파이프라인이나 로컬 개발 환경에 쉽게 통합할 수 있다. 호스트 커널을 공유한다는 근본적인 한계 때문에 커널의 취약점을 악용한 컨테이너 탈출(container escape) 공격에 취약하다. seccomp(Secure Computing Mode) 등으로 시스템 콜을 제한하더라도, 완전히 신뢰할 수 없는 외부 AI 코드를 실행하기 위한 완벽한 보안 경계로 삼기에는 부족하다.

컨테이너 기반 샌드박스 환경을 구축할 때는 다음과 같은 기술을 사용할 수 있다.

• Docker
• Podman

유저스페이스 커널 기반의 샌드박스 기술은 하드웨어 가상화(hypervisor)를 사용하지 않고도 기존 컨테이너의 보안 취약점을 극복하기 위해 개발됐다. 대표적으로 구글(Google)에서 개발한 gVisor라는 유저스페이스 커널 기술이 AI 에이전트를 위한 샌드박스 기술로 많이 사용되는 것으로 보인다. 일반 컨테이너 안에서 실행되는 애플리케이션은 운영체제(호스트 커널)에 직접 시스템 콜(system call)을 보내 하드웨어 자원을 요청한다. 이 구조에서는 커널 취약점이 악용되면 컨테이너 탈출 공격이 발생할 수 있다.

하지만 gVisor는 Go 언어로 작성된 ‘Sentry’라는 유저스페이스 커널을 컨테이너와 호스트 커널 사이에 배치해 보안 수준을 높였다. 애플리케이션은 자신이 실제 리눅스 커널과 통신한다고 생각하지만, 실제로는 Sentry 프로세스가 모든 시스템 콜을 중간에서 가로채 필터링하고 에뮬레이션해 대신 처리한다. 결과적으로 컨테이너 내부의 코드가 호스트 커널에 직접 접근하는 것을 원천 차단한다.

마이크로VM은 하드웨어 가상화 수준에서 격리가 가능하다. 일반 VM과 마찬가지로 각각 독립된 게스트 커널을 갖는다. 일반 VM의 강력한 보안성과 컨테이너의 빠른 속도를 하나로 결합한 기술이다. AWS 람다(lambda)나 파게이트(fargate)에서 사용하는 Firecracker의 경우 불필요한 장치 모델을 모두 제거한 최소한의 설계 덕분에 125ms 이하의 초고속 부팅이 가능하다. 인스턴스당 메모리 오버헤드도 5MiB 미만으로 적다. 컨테이너 환경에 비해 초기 네트워크 브리지 구성, 루트 파일 시스템 마운트 등 설정과 운영의 복잡도가 높다는 점이 단점이다.

마이크로VM을 활용한 샌드박스 환경을 구축할 때는 다음과 같은 기술을 사용할 수 있다.

• Firecracker
• Kata Containers
• Docker Sandboxes

일반 가상 머신은 하드웨어 가상화 수준에서 완벽한 격리가 가능하다. 호스트 커널과 물리적으로 분리된 완전히 독립적인 게스트 커널을 부팅한다. 가장 강력한 보안을 제공한다. 에이전트의 악성 코드나 프롬프트 인젝션 공격이 성공해 게스트 운영체제가 장악되더라도 호스트 시스템에는 닿을 수 없다. 다만, 수많은 범용 하드웨어 장치를 모두 에뮬레이션해야 하므로 매우 무겁다. 부팅하는 데 수 초에서 수십 초가 걸리며, 메모리 및 스토리지 오버헤드가 크다. 에이전트가 코드를 실행할 때마다 즉각적으로 격리 환경을 띄우고 폐기해야 하는 AI 워크플로에는 효율성이 너무 떨어진다.

가상 머신을 활용한 샌드박스 환경을 구축할 때는 다음과 같은 기술을 사용할 수 있다.

• QEMU
• Parallels
• Lima

컨테이너, gVisor, 마이크로VM(VM)의 격리 수준을 시각화하면 아래 그림처럼 표현할 수 있다. 마이크로VM(VM)은 하드웨어 가상화를 통해 프로세스의 시스템 콜이 호스트 커널까지 도달하지 못하게 한다.

https://read.engineerscodex.com/p/every-dev-should-know-about-ai-sandboxes

위에서 살펴본 샌드박스 기술들의 격리 수준과 실행 속도를 비교해 보면 다음과 같다.

https://read.engineerscodex.com/p/every-dev-should-know-about-ai-sandboxes

REFERENCE

• https://docs.tosspayments.com/resources/glossary/sandbox
• https://cursor.com/ko/blog/agent-sandboxing
• https://code.claude.com/docs/en/sandboxing
• https://developers.openai.com/codex/concepts/sandboxing
• https://wikidocs.net/329827
• https://www.ikangai.com/the-complete-guide-to-sandboxing-autonomous-agents-tools-frameworks-and-safety-essentials/
• https://www.youngju.dev/blog/ai-platform/2026-03-14-ai-coding-agent-sandbox-security-isolation
• https://tilnote.io/pages/695e28bdc601484077a3e323
• https://firecracker-microvm.github.io/
• https://www.luiscardoso.dev/blog/sandboxes-for-ai
• https://read.engineerscodex.com/p/every-dev-should-know-about-ai-sandboxes