AI 에이전트가 터미널 명령을 실행하고 프로젝트 파일을 수정하며 외부 API에 연결한다면, 자연어로 전달한 작업 지침만으로는 시스템 접근을 통제할 수 없다. AI 에이전트 샌드박스(Agent Sandbox)는 실제 프로그램이 실행되는 환경에 접근 제한을 적용해, 모델의 판단과 별개로 허용된 작업 범위를 설정하는 보안 구조다.

01. AI 에이전트 샌드박스의 정의

격리 실행환경(Sandbox)은 프로그램이 접근할 수 있는 자원과 수행할 수 있는 작업을 정책으로 제한하는 실행 영역이다. AI 에이전트 샌드박스는 이 원리를 코딩 에이전트, 웹 자동화 에이전트, 운영 자동화 에이전트처럼 실제 도구를 호출하는 시스템에 적용한다. 핵심 보호 대상은 모델의 텍스트 출력이 아니라, 모델의 판단을 받아 실행되는 프로세스와 그 프로세스의 시스템 접근이다.

에이전트가 “특정 폴더만 수정하라”는 지시를 받더라도, 해당 프로세스에 전체 사용자 계정의 파일 권한이 주어져 있다면 운영체제는 그 지시를 보안 규칙으로 해석하지 않는다. 반대로 파일 접근 정책이 특정 경로만 허용하도록 설정되어 있다면, 에이전트가 다른 파일을 열려고 시도하더라도 해당 접근을 제한할 수 있다. 이것이 자연어 지시와 시스템 수준 권한 통제의 차이다.

02. 실행환경과 신뢰 경계

일반적인 에이전트 샌드박스는 정책을 보관·승인하는 제어 영역(Control Plane), 제한된 프로그램이 실행되는 작업 영역(Workload), 접근 요청을 실제로 차단하거나 허용하는 정책 집행 지점(Policy Enforcement Point)으로 나눠 이해할 수 있다. 모든 제품이 동일한 프로세스 배치를 갖는 것은 아니며, 보안상 중요한 것은 권한이 높은 관리 구성요소가 에이전트의 임의 코드와 동일한 신뢰 경계에 놓이지 않는지 확인하는 것이다.

NVIDIA OpenShell은 이를 구현한 사례다. 공식 아키텍처 문서에는 Gateway가 정책과 상태를 관리하고, 신뢰된 Supervisor가 작업 영역 바깥에서 정책을 집행하며, 별도의 Sandbox 프로세스가 에이전트 자식 프로세스를 실행하는 신뢰 수준 분리가 제시돼 있다. 문서 버전에 따라 구성요소 설명과 배치가 달라질 수 있으므로 특정 제품의 구현을 모든 샌드박스의 표준 구조로 일반화해서는 안 된다.^[1]

03. 파일시스템 격리와 Landlock

파일시스템 격리(Filesystem Isolation)는 에이전트가 어떤 파일과 디렉터리를 읽거나 변경할 수 있는지 제한한다. 예를 들어 웹사이트 수정 작업에서는 작업 사본의 이미지 폴더에만 쓰기를 허용하고, 운영 서버 설정 파일이나 다른 고객 프로젝트는 접근 대상에서 제외할 수 있다.

Linux의 Landlock은 권한이 낮은 프로세스도 자신과 자식 프로세스에 추가 접근 제한을 적용할 수 있도록 하는 보안 모듈(LSM)이다. 파일 경로별 접근 규칙을 정의하고 제한된 작업을 실행할 수 있다. 기존 파일 소유권·접근제어 목록(ACL)과 별도로 작동하는 추가 제한이므로, Landlock에서 허용했다고 해서 운영체제의 다른 권한 검사가 생략되지는 않는다.^[2]

위 표는 개념 설명용 가상 정책이며 실제 Landlock 규칙 파일이나 OpenShell 기본 설정이 아니다. 실제 보호 수준은 마운트 구성, 파일 디스크립터 상속, 커널 지원 버전 등과 함께 검증해야 한다.

04. 프로세스 통제와 Seccomp

프로세스 통제(Process Restriction)는 에이전트가 실행하는 명령에 부여되는 사용자 권한과 커널 기능을 제한한다. 여기에는 비루트 사용자 실행, 권한 상승 차단, Linux Capability 축소, 시스템 호출 필터, 네임스페이스 분리 등이 포함될 수 있다.

시스템 호출 필터(Seccomp BPF)는 프로세스가 커널에 요청하는 시스템 호출을 필터링한다. 예를 들어 특정 관리·추적·마운트 관련 호출을 거부하도록 설정할 수 있다. 다만 Seccomp 자체는 완전한 샌드박스가 아니며, 인수 검사만으로 파일 경로나 네트워크 목적지의 모든 의미를 판단할 수도 없다. 파일·네트워크 통제와 별도의 권한 축소가 필요하다.^[3]

특히 서비스 거부(DoS) 위험을 줄이려면 파일·프로세스 접근 정책과 별도로 CPU·메모리·프로세스 수·실행 시간 등의 자원 상한을 설정해야 한다.

05. 네트워크 격리와 정책 프록시

네트워크 격리(Network Isolation)는 에이전트가 연결할 수 있는 목적지와 포트, 필요하면 HTTP 요청의 경로·메서드까지 제한하는 방식이다. 일반적인 설계에서는 에이전트의 직접 외부 연결을 막고 정책 프록시(Policy Proxy)를 통해 승인된 요청만 내보낸다.

실제 구현에서는 DNS 조회와 연결 대상의 불일치, 사설 주소나 클라우드 메타데이터 주소 접근, 프록시 우회, TLS 암호화로 인한 요청 내용 검사 한계 등을 고려해야 한다. OpenShell의 보안 정책 문서는 목적지·포트·실행 바이너리·선택적인 애플리케이션 계층(L7) 규칙을 사용한다고 설명한다.^[4]

06. 인증정보 격리와 권한 갱신

인증정보 격리(Credential Isolation)는 에이전트가 외부 API를 호출하더라도 API 키나 서비스 토큰을 무제한으로 읽거나 재사용하지 못하게 만드는 설계다. 한 방식은 비밀정보를 관리 영역에 보관하고, 승인된 목적지로 나가는 요청에 필요한 인증정보만 프록시가 주입하는 것이다.

그러나 “원본 키를 볼 수 없다”와 “해당 키로 수행 가능한 작업을 오용할 수 없다”는 다른 문제다. 승인된 API가 삭제나 결제 등 민감한 작업을 허용한다면 요청별 권한, 최소 범위 토큰, 사람의 승인, 사용량 제한을 추가로 설계해야 한다.

정적 정책(Static Policy)은 샌드박스 시작 시 적용하는 파일·프로세스 제한처럼 실행 중 확대하기 어려운 통제다. 동적 정책(Dynamic Policy)은 실행 중 네트워크 허용 목록이나 연결 대상을 변경할 수 있는 통제다. OpenShell은 이 둘을 구분하며, 네트워크 정책의 변경은 검증 절차를 거쳐 적용하고 정적 통제 변경에는 작업 영역 재생성이 필요하다고 설명한다.^[4]

07. Sandbox·Container·VM의 차이

샌드박스·컨테이너·가상머신은 같은 수준의 개념이 아니다. 샌드박스는 접근을 제한한다는 보안 목적과 정책을 뜻하고, 컨테이너와 가상머신은 주로 프로그램을 실행하고 자원을 분리하는 기반 기술을 뜻한다. 따라서 컨테이너 안에 샌드박스 정책을 적용하거나 가상머신 안에 여러 샌드박스를 배치할 수 있다.

컨테이너나 VM을 사용했다는 사실만으로 작업 권한이 최소화되지는 않는다. 반대로 파일 접근 제한만 적용한 샌드박스가 커널 취약점이나 네트워크 우회까지 모두 막아 주는 것도 아니다.

08. 위협 모델과 기술적 한계

샌드박스의 주요 목표는 허용되지 않은 자원 접근과 피해 확산을 제한하는 것이다. 그러나 에이전트가 정상 권한으로 접근할 수 있는 파일을 잘못 수정하거나, 승인된 API로 잘못된 요청을 보내는 문제는 샌드박스만으로 해결되지 않는다.

이 때문에 심층 방어(Defense in Depth)가 필요하다. 샌드박스와 함께 코드 검토, 테스트, 배포 승인, 백업·복구, 접근 감사, 최소 범위 인증정보를 결합해야 실제 업무에서의 피해를 줄일 수 있다.

09. 구현 시 검증해야 할 보안 조건

AI 에이전트 샌드박스의 보호 범위를 평가할 때는 “샌드박스 사용 여부”보다 실제 보안 경계와 우회 가능성을 확인하는 편이 정확하다. 다음 항목은 특정 제품의 권장 설정이 아니라 일반적인 기술 검증 질문이다.

OpenShell과 같은 구현체를 평가할 때는 공식 보안 문서의 실제 집행 위치, 지원하는 런타임과 커널 버전, 기본 정책, 정책 변경 실패 시 동작을 함께 확인해야 한다. 제품 아키텍처가 개정될 수 있으므로 일반 원리와 특정 버전의 구현을 구분하는 것이 중요하다.