OpenAI Agents SDK 샌드박싱과 엔터프라이즈 보안 배포 설계

호스트 프로세스에서 에이전트 코드를 떼어내야 했던 이유

Agents SDK 이전 버전에서는 에이전트가 실행하는 코드와 호스트 애플리케이션이 같은 프로세스를 공유했다. 모델이 만든 코드가 호스트 파일시스템이나 환경 변수에 접근할 수 있었고, 프롬프트 인젝션과 데이터 유출 공격이 파고들 수 있는 표면도 함께 열렸다.

OpenAI는 이 문제를 하네스(harness)와 컴퓨트 환경의 분리로 다뤘다. 2026년 4월 15일 발표된 업데이트에는 네이티브 샌드박스 실행, 서브에이전트 패턴, Codex 스타일 파일시스템 툴이 포함됐다. apply_patch와 셸 명령은 격리된 실행 환경에서 동작하고, Manifest가 로컬 파일과 출력 디렉토리, 클라우드 스토리지 마운트로 구성된 작업공간을 정의한다.

샌드박스 프로바이더는 Blaxel, Cloudflare, Daytona, E2B, Modal, Runloop, Vercel까지 7개다. 개발자가 컨테이너를 직접 구성하지 않고도 이 가운데 하나를 선택해 프로덕션 수준의 격리 환경을 마련할 수 있다. 코드 모드와 서브에이전트는 Python에서 먼저 출시됐으며 TypeScript 지원은 후속 릴리즈로 예정됐다.

Manifest를 경계로 나누는 실행 환경

샌드박스는 파일시스템과 셸만 격리하는 공간이 아니다. 설치된 패키지, 마운트된 데이터, 노출된 포트, 스냅샷, 외부 시스템 접근 제어까지 포함하는 Unix 유사 실행 환경이다.

⤢✕

파일 접근 범위는 Manifest에 명시한다. 에이전트가 사용할 파일과 디렉토리를 선언하고, 선언하지 않은 경로에는 접근할 수 없게 만든다. 태스크 수행에 불필요한 시스템 호출과 파일 접근도 기본적으로 차단해 최소 권한 원칙을 적용한다.

네트워크 요청 역시 허용된 외부 엔드포인트로 제한된다. 아웃바운드 연결은 기본적으로 막고 개발자가 허용 목록을 지정해 데이터 유출 시도를 통제한다. 모델이 생성한 코드는 호스트 프로세스가 아니라 격리된 컨테이너에서만 실행되며, 컨테이너 탈출 공격에 대한 방어는 각 프로바이더의 보안 레이어가 담당한다.

자격증명은 실행 환경과 더 엄격하게 분리된다. API 키나 비밀번호는 하네스에 남고 모델 생성 코드가 돌아가는 컴퓨트 환경에는 들어가지 않는다. 프롬프트 인젝션을 통해 비밀키를 읽어 가는 경로를 실행 구조에서 차단하는 방식이다.

전문 작업을 나누되 실패까지 분리한다

서브에이전트 패턴에서는 주 에이전트가 작업을 나눈 뒤 전문화된 에이전트에 위임한다. 이전에는 개발자가 오케스트레이션 루프와 메시지 버스를 직접 구현해야 했지만, 업데이트된 SDK는 컨텍스트 범위 설정과 메모리 격리, 실패 전파를 런타임 프리미티브로 다룬다.

⤢✕

주 에이전트를 루트로 두고 서브에이전트를 트리 형태로 배치할 수 있다. 각 서브에이전트는 독립된 샌드박스에서 실행되며, 자신에게 할당된 Manifest의 파일과 도구만 사용한다.

주 에이전트가 자연어로 태스크를 전달하면 SDK가 해당 작업을 서브에이전트에 넘긴다. 작업 결과가 돌아올 때는 SDK가 컨텍스트를 병합하므로 개발자가 별도 집계 로직을 구현할 필요가 없다.

실패도 작업 단위로 가둔다. 어느 한 서브에이전트가 실패하더라도 전체 에이전트 트리에 곧바로 영향을 주지 않으며, 주 에이전트가 해당 작업을 재시도하거나 다른 경로를 선택할 수 있다.

격리만으로 끝나지 않는 운영 통제

샌드박스는 코드 실행 경계를 만들지만, 엔터프라이즈 배포에는 그 경계에서 발생한 행위를 추적하고 출력과 권한을 관리하는 절차가 더 필요하다.

⤢✕

apply_patch가 실행될 때는 수정한 파일과 변경 내용이 로그에 남는다. 이 기록을 SIEM 시스템에 연동하면 에이전트가 코드와 파일에 가한 변경을 감사할 수 있다.

출력 수집 단계에는 개인식별정보(PII)를 감지하고 마스킹하는 필터가 필요하다. 에이전트가 처리 과정에서 민감 정보를 출력하더라도 하네스 레이어에서 이를 걸러내도록 구성한다.

API 키와 데이터베이스 비밀번호 같은 자격증명은 하네스에만 보관하고 샌드박스에는 주입하지 않는다. AWS Secrets Manager나 HashiCorp Vault 같은 외부 비밀 관리 시스템과 연동하는 방식이 권장된다.

Manifest는 단순한 작업공간 설정을 넘어 에이전트 인가 정책의 근거가 된다. 파일 접근 범위를 소스 코드로 관리하고 변경할 때 코드 리뷰를 거치도록 배포 프로세스에 포함해야 한다.

로컬 작업공간과 클라우드 스토리지 연결

Manifest에는 로컬 파일뿐 아니라 클라우드 스토리지도 마운트할 수 있다.

스토리지	마운트 방식	적합 사용 사례
AWS S3	`s3://bucket/path`	대용량 데이터 처리 에이전트
Google Cloud Storage	`gs://bucket/path`	GCP 기반 엔터프라이즈
Azure Blob Storage	`az://container/path`	Microsoft 생태계 통합
Cloudflare R2	`r2://bucket/path`	엣지 컴퓨팅 에이전트
로컬 파일	절대 경로	프로토타입 및 개발 환경

로컬 프로토타입을 프로덕션 클라우드 환경으로 옮길 때 에이전트 코드를 변경할 필요는 없다. Manifest의 스토리지 마운트 설정만 교체하면 같은 작업 구조를 유지할 수 있다.

Python 파일럿에서 프로덕션 확산까지

2026년 4월 기준 코드 모드와 서브에이전트는 Python에서 먼저 제공됐고, TypeScript 지원은 후속 릴리즈에서 제공될 예정이다. 하네스와 샌드박스의 기본 기능은 표준 API 가격 정책인 토큰과 툴 사용량 기준으로 일반 제공된다.

엔터프라이즈 팀이라면 Python으로 파일럿을 진행한 뒤 TypeScript 지원이 확정되면 전사 확산을 검토할 수 있다. 이때 프로바이더 선택만 볼 것이 아니라 하네스와 컴퓨트 환경의 분리, Manifest 접근 정책, 서브에이전트 실패 격리, 감사 로그와 비밀 관리가 하나의 배포 체계로 연결되는지 확인해야 한다. 7개 샌드박스 프로바이더를 지원하므로 기존 인프라에 맞는 통합 방식도 선택할 수 있다.