AI 에이전트 샌드박스 격리 검토는 생성된 코드가 실제 시스템이나 데이터에 대해 실행되기 전에 실행 경계, 파일 시스템 노출, 프로세스 및 리소스 제어, 네트워크 및 DNS 정책, 패키지 가져오기 동작, 비밀 처리, 로그, 아티팩트 캡처, 초기화 의미, 인간 승인 지점, 그리고 인시던트 대응 가정을 검증해야 합니다.
AI 에이전트 격리 검토가 중요한 이유
전통적인 샌드박스 검토는 종종 한 가지 질문으로 시작합니다: 이 시스템이 호스트를 노출하지 않고 신뢰할 수 없는 코드를 실행할 수 있는가? AI 에이전트 검토도 그 질문이 필요하지만, 에이전트는 단일 스크립트를 실행하는 것 이상을 수행하기 때문에 더 광범위한 체크리스트가 필요합니다. 에이전트는 저장소를 복제하고, 패키지를 설치하고, 사이트를 탐색하고, 파일을 쓰고, API를 호출하고, GUI 세션을 열고, 실패한 명령을 재시도하고, 모델 출력을 셸 액션으로 변환할 수 있습니다.
이는 위험 모델을 변화시킵니다. 코딩 에이전트는 터미널에 접근할 수 있는 주니어 엔지니어처럼 행동할 수 있습니다. 데이터 분석 에이전트는 파일을 업로드하고, 패키지를 가져오고, 차트를 내보내는 노트북 사용자처럼 행동할 수 있습니다. 브라우저 에이전트는 쿠키, 다운로드, 스크린샷, 양식 작성 액션을 가진 사용자처럼 행동할 수 있습니다. 강화 학습 또는 평가 에이전트는 동일한 작업을 수천 번 실행할 수 있으며, 이는 소규모의 이그레스, 리소스 또는 로깅 격차가 대규모로 문제가 되게 만듭니다.
아래 체크리스트를 사용하여 샌드박스를 민감한 저장소, 고객 데이터, 내부 API, 권한 있는 자격 증명 또는 프로덕션 배포 시스템에 연결하기 전에 경계를 검토하십시오.
실행 경계 보안
에이전트 워크로드를 호스트 및 다른 테넌트로부터 분리하는 경계부터 시작하십시오. 검토는 보안 엔지니어가 에이전트가 적대적인 코드를 실행할 경우 무엇이 실패하는지 설명할 수 있을 정도로 명확해야 합니다.
확인 사항:
- 사용되는 격리 계층은 무엇인가: 컨테이너, microVM, 전체 VM, gVisor와 같은 시스템 콜 중재, Kubernetes 샌드박싱 또는 다른 모델?
- 각 샌드박스는 자체 커널 경계를 가지는가, 아니면 호스트 커널을 공유하는가?
- CPU, 메모리, 파일 시스템, 프로세스 테이블, 네트워크 스택 및 장치 접근이 다른 워크로드와 분리되어 있는가?
- 샌드박스가 컨테이너 런타임 소켓, 호스트 프로세스 네임스페이스, 호스트 경로, 클라우드 메타데이터 서비스 또는 권한 있는 장치에 접근할 수 있는가?
- 브라우저 세션, GUI 데스크탑, VNC 스트림 및 코드 인터프리터는 동일한 경계 내에 어떻게 배치되는가?
- 문서화된 호스트 이스케이프 가정은 무엇인가: 차단, 위험 감소 또는 더 강력한 보장?
일반적인 "안전한 샌드박스"라는 문구를 전체 답변으로 받아들이지 마십시오. 구체적인 격리 메커니즘, 경계 내부에 무엇이 있는지, 외부에 무엇이 있는지, 그리고 여전히 보완 제어가 필요한 가정이 무엇인지 물어보십시오.
파일 시스템 및 마운트 보안
에이전트 파일 시스템은 별도의 검토가 필요합니다. 에이전트는 정상 작업의 일부로 파일을 생성, 편집 및 유출하는 경우가 많기 때문입니다. 위험한 부분은 읽기/쓰기 접근만이 아닙니다. 작업 간 우발적인 데이터 이월과 사용자가 공유하려 하지 않은 프로젝트 파일에 대한 암시적 접근도 위험합니다.
확인 사항:
- 기본 파일 시스템은 비어 있는가, 템플릿 기반인가, 아니면 프로젝트 파일로 미리 로드되어 있는가?
- 에이전트가 쓸 수 있는 경로와 읽기 전용인 경로는 무엇인가?
- 호스트 디렉토리, 저장소 마운트, SSH 키, 패키지 캐시, 브라우저 프로필 또는 클라우드 구성 파일이 샌드박스에 마운트되어 있는가?
- 에이전트가 심볼릭 링크나 바인드 마운트를 통해 의도하지 않은 경로로 이동할 수 있는가?
- 파일 접근은 샌드박스별, 사용자별, 프로젝트별 또는 조직별로 범위가 지정되어 있는가?
- 업로드된 파일은 삭제, 보존, 스냅샷 생성 또는 이후 세션에서 사용 가능하게 되는가?
- 생성된 파일과 diff는 샌드박스를 떠나기 전에 검토 가능한가?
코딩 에이전트의 경우 가장 안전한 패턴은 일반적으로 좁은 프로젝트 작업 공간, 명시적인 아티팩트 내보내기, 그리고 개발자 홈 디렉토리나 공유 자격 증명 저장소에 대한 주변 접근이 없는 것입니다.
프로세스 및 리소스 제어
에이전트는 실수로 포크 폭탄을 일으키거나, 빌드를 중단시키거나, 디스크를 채우거나, 백그라운드 서버를 실행하거나, 값비싼 명령을 계속 재시도할 수 있습니다. 리소스 제어는 이러한 실패를 제한된 실패로 전환합니다.
확인 사항:
- CPU, 메모리, 디스크, 파일 디스크립터, 프로세스 수 및 런타임 제한이 적용되는가?
- 명령 및 세션에 대한 최대 벽시계 시간이 있는가?
- 명령이 완료된 후에도 백그라운드 프로세스가 유지될 수 있는가?
- 샌드박스가 중지되거나 재설정될 때 자식 프로세스가 종료되는가?
- 에이전트가 수신 포트를 열 수 있는가, 그리고 가능하다면 해당 포트가 명시적인 미리보기 메커니즘을 통해서만 노출되는가?
- 대용량 stdout/stderr 로그는 잘리거나, 스트리밍되거나, 저장되는가?
- 할당량 실패는 호출자에게 표시되는가, 아니면 자동으로 재시도되는가?
프로덕션 에이전트 워크플로의 경우 제한은 API 계약의 일부여야 하며, 단순한 과금 개념이 아니어야 합니다. 보안 팀은 에이전트가 제한에 도달했을 때 어떤 일이 발생하는지와 실패가 부분적인 상태를 남기는지 알아야 합니다.
네트워크 및 이그레스 제어
네트워크 정책은 많은 샌드박스 검토가 너무 모호해지는 부분입니다. 일부 에이전트 워크로드는 인터넷 접근이 필요합니다. 다른 워크로드는 기본적으로 접근 권한이 없어야 합니다. 올바른 답변은 샌드박스가 테스트를 실행하는지, 공개 페이지를 탐색하는지, 패키지를 가져오는지, 내부 API를 호출하는지, 아니면 민감한 데이터를 처리하는지에 따라 다릅니다.
확인 사항:
- 아웃바운드 인터넷 접근이 기본적으로 활성화되어 있는가?
- 네트워크 접근을 샌드박스별, 템플릿별 또는 프로젝트별로 비활성화할 수 있는가?
- 도메인, IP 범위, 포트 또는 프로토콜에 대한 이그레스 허용 목록을 사용할 수 있는가?
- 클라우드 메타데이터 엔드포인트에 대한 접근이 차단되어 있는가?
- 샌드박스가 프라이빗 VPC, 내부 서비스, 데이터베이스 또는 배포 시스템에 도달할 수 있는가?
- 브라우저 트래픽, CLI 트래픽, 패키지 관리자 트래픽 및 직접 소켓 연결이 동일한 정책에 의해 관리되는가?
- 아웃바운드 요청이 타임스탬프, 대상, 프로세스 또는 명령 컨텍스트 및 응답 상태와 함께 기록되는가?
에이전트 이그레스를 빌드 시스템 이그레스처럼 취급하십시오. 에이전트가 패키지를 설치하거나, 아티팩트를 업로드하거나, 웹훅을 호출하거나, 임의의 사이트를 탐색할 수 있다면, 검토는 악성 코드와 프롬프트 인젝션 기반 동작을 모두 다루어야 합니다.
DNS 및 패키지 접근 위험
DNS와 패키지 관리자는 인프라 배관처럼 느껴지기 때문에 간과하기 쉽습니다. 에이전트의 경우 이는 실행 표면의 일부입니다. 생성된 스크립트는 DNS 쿼리에 데이터를 인코딩하거나, 타이포스쿼팅된 패키지를 가져오거나, 검토되지 않은 URL에서 스크립트를 가져올 수 있습니다.
확인 사항:
- DNS 트래픽은 HTTP 및 HTTPS와 동일한 이그레스 정책을 따르는가?
- DNS 쿼리가 기록, 필터링 또는 제어된 리졸버를 통해 강제 전달되는가?
- 패키지 관리자가 기본적으로 공개 레지스트리에 도달할 수 있는가?
- 패키지 레지스트리가 허용 목록에 추가, 프록시, 캐시 또는 고정되어 있는가?
- 설치된 패키지 이름, 버전, URL, 해시 및 잠금 파일 변경 사항이 캡처되는가?
- 에이전트가 설치 스크립트, 포스트인스톨 훅 또는 임의의 패키지 빌드 단계를 실행할 수 있는가?
- 새 종속성이 템플릿이나 프로덕션 워크플로에 유지되기 전에 검토 게이트가 있는가?
패키지 접근이 필요한 경우, 고정된 버전, 잠금 파일, 레지스트리 허용 목록 및 검토자가 다운로드 및 실행된 내용을 재구성할 수 있는 로그를 선호하십시오.
비밀 처리
비밀은 일반적으로 샌드박스 경계를 무의미하게 만드는 가장 빠른 방법입니다. 에이전트가 광범위한 토큰을 보게 되면 호스트를 이스케이프하지 않고도 데이터를 유출할 수 있습니다.
확인 사항:
- 비밀은 작업이 명시적으로 필요로 할 때만 주입되는가?
- 비밀은 샌드박스, 작업, 저장소, 환경 및 수명에 따라 범위가 지정되는가?
- 환경 변수, 파일, 셸 히스토리, 프로세스 목록, 로그, 스크린샷 또는 브라우저 저장소에서 비밀을 읽을 수 있는가?
- 로그 및 아티팩트는 저장 또는 내보내기 전에 수정되는가?
- 장기 자격 증명 대신 단기 토큰이 사용되는가?
- 에이전트가 호스트에서 사용자 수준의 SSH 키, Git 자격 증명, 클라우드 자격 증명, 브라우저 쿠키 또는 API 키에 접근할 수 있는가?
- 비밀 접근이 감사 로그에 표시되는가?
실용적인 규칙: 사람이 신뢰할 수 없는 빌드 작업에 자격 증명을 붙여넣지 않을 것이라면, 더 좁은 범위와 더 강력한 로깅 없이 자율 에이전트에게 제공하지 마십시오.
로그 및 감사 추적
보안 팀은 성공 또는 실패 이상의 정보가 필요합니다. 어떤 코드가 실행되었는지, 어떤 파일이 변경되었는지, 어떤 네트워크 호출이 발생했는지, 그리고 어떤 출력이 생성되었는지 알아야 합니다.
확인 사항:
- 명령 호출이 인수, 작업 디렉토리, 종료 코드, 시작 시간 및 지속 시간과 함께 기록되는가?
- 파일 읽기, 쓰기, 삭제, 업로드, 다운로드 및 권한 변경이 기록되는가?
- 패키지 설치 및 외부 가져오기가 기록되는가?
- 브라우저 액션, 스크린샷, 다운로드 및 양식 제출이 관련된 경우 캡처되는가?
- API 호출, 도구 호출 및 모델-도구 전환이 동일한 세션과 연결되는가?
- 로그가 샌드박스 내부에서 변조에 강한가?
- 보존 기간은 얼마이며, 누가 로그에 접근할 수 있는가?
규제 또는 엔터프라이즈 워크플로의 경우 감사 추적은 디버깅과 사후 인시던트 재구성을 모두 지원해야 합니다. 부분적인 터미널 기록은 일반적으로 충분하지 않습니다.
아티팩트 캡처 및 검토
에이전트는 유용한 출력을 생성합니다: diff, 테스트 결과, 보고서, 스크린샷, 생성된 파일, 미리보기 URL 및 데이터셋. 아티팩트 처리는 필요한 것보다 더 많은 상태를 노출하지 않으면서 해당 출력을 검토 가능하게 만들어야 합니다.
확인 사항:
- 어떤 아티팩트가 자동으로 내보내지며, 어떤 것이 명시적 선택을 필요로 하는가?
- 검토자는 생성된 파일이 커밋, 업로드 또는 다른 서비스로 전송되기 전에 검사할 수 있는가?
- 아티팩트는 비밀, 악성코드, 안전하지 않은 파일 형식 또는 예상치 못한 크기에 대해 스캔되는가?
- 브라우저 다운로드는 소스 코드 diff 및 테스트 출력과 별도로 저장되는가?
- 아티팩트는 이를 생성한 정확한 명령, 에이전트 단계 및 샌드박스 세션에 다시 연결될 수 있는가?
- 아티팩트는 샌드박스 삭제 후에도 보존되며, 삭제할 수 있는가?
목표는 로그, 스크린샷, 아카이브 또는 생성된 번들을 통한 두 번째 데이터 유출 채널을 피하면서 유용한 증거를 보존하는 것입니다.
수명 주기 및 초기화 제어
에이전트 세션은 단기, 장기 실행, 일시 중지, 재개, 스냅샷 생성 또는 템플릿에서 복제될 수 있습니다. 각 수명 주기 모드는 경계를 변경합니다.
확인 사항:
- 각 샌드박스는 새로 생성되는가, 상태에서 재개되는가, 아니면 템플릿에서 복제되는가?
- 일시 중지, 재개, 스냅샷, 템플릿 생성 및 삭제 시 어떤 데이터가 유지되는가?
- 임시 파일, 패키지 캐시, 셸 히스토리, 브라우저 쿠키 및 로컬 데이터베이스는 재설정 시 지워지는가?
- 손상된 세션이 재사용 가능한 템플릿을 오염시킬 수 있는가?
- 최대 세션 수명이 있는가?
- 중지된 샌드박스는 실제로 종료되는가, 아니면 백그라운드 작업이 계속될 수 있는가?
- 동일한 작업을 깨끗한 환경에서 재현할 수 있는가?
재설정 가능성은 평가 및 강화 학습 워크로드에도 중요합니다. 각 시도가 약간 다른 상태에서 시작된다면 보안 결과와 모델 동작을 신뢰하기가 더 어려워집니다.
인간 승인 제어
인간 승인은 단지 UX 기능이 아닙니다. 이는 신뢰 경계를 넘는 행동에 대한 제어 평면입니다.
확인 사항:
- 어떤 행동이 자율적으로 실행될 수 있으며, 어떤 행동이 승인을 필요로 하는가?
- 승인 프롬프트는 명령, 파일, 대상, 자격 증명 범위 및 예상 효과를 표시할 수 있을 만큼 구체적인가?
- 정책은 패키지 설치, 외부 네트워크 접근, 저장소 쓰기, 배포 명령 또는 비밀 접근에 대해 승인을 요구할 수 있는가?
- 승인은 사용자, 타임스탬프, 행동 및 결과 명령과 함께 기록되는가?
- 승인은 광범위한 미래 권한을 부여하는 대신 시간 제한 및 작업 제한이 될 수 있는가?
- 비상 경로가 있으며, 이는 감사되는가?
파일 삭제, 프로덕션 브랜치에 쓰기, 배포 API 호출, 고객 데이터 접근 및 샌드박스 템플릿 변경과 같은 되돌릴 수 없거나 영향이 큰 행동에 대해 인간 승인을 사용하십시오.
인시던트 대응 가정
경계가 실패하거나 워크플로가 예기치 않게 동작할 때 어떻게 되는지 묻지 않고는 샌드박스 검토가 완료되지 않습니다. 이는 위험한 행동이 모델 출력, 프롬프트 인젝션, 종속성 손상 또는 일반적인 소프트웨어 버그로 인해 발생할 수 있기 때문에 에이전트 시스템에서 특히 중요합니다.
확인 사항:
- 샌드박스가 데이터를 유출하거나 적대적인 코드를 실행한 것으로 의심될 때 트라이지를 담당하는 사람은 누구인가?
- 샌드박스를 프로젝트 또는 조직별로 종료, 격리 또는 차단할 수 있는가?
- 네트워크 이그레스를 신속하게 비활성화할 수 있는가?
- 로그 및 아티팩트가 조사를 위해 보존되는가?
- 영향을 받은 템플릿, 패키지 캐시 및 스냅샷이 무효화되는가?
- 자격 증명이 자동으로 또는 문서화된 런북을 통해 교체되는가?
- 샌드박스 차단 문제와 에이전트 정책 문제 사이에 명확한 구분이 있는가?
검토는 서면 위협 모델과 짧은 런북으로 끝나야 합니다. 최종 결정이 "비민감 워크로드에만 승인"이더라도 그 경계는 유용합니다.
Novita Agent Sandbox 작동 방식
Novita Agent Sandbox는 AI 생성 코드, 브라우저 워크플로, 컴퓨터 사용, 평가, 강화 학습 환경 및 장기 실행 작업을 위해 설계되었습니다. 제품 페이지는 격리된 샌드박스, 서브밀리초 시작, 영구 세션, VNC 기반 라이브 세션 보기, 사용량 기반 가격, 템플릿 및 격리된 파일 시스템 지원을 설명합니다. Novita Agent Sandbox 퀵스타트는 SDK 기반 샌드박스 생성, 명령 실행, 파일 목록 보기 및 샌드박스 종료를 보여줍니다.
이러한 기능은 이 체크리스트의 많은 워크플로를 지원할 수 있지만, 평가 기준과 제품 주장은 분리되어야 합니다. 팀이 Novita Agent Sandbox 또는 다른 에이전트 런타임을 검토할 때, 사용하려는 라이브 구성을 위의 제어 항목(경계, 파일, 프로세스 제한, 네트워크, DNS, 패키지 가져오기, 비밀, 로그, 아티팩트, 수명 주기, 승인 및 인시던트 대응)에 매핑하십시오.
이미 Novita AI 모델 API를 사용하는 엔지니어링 팀의 경우, 모델 추론을 샌드박스 실행과 결합하면 에이전트 워크로드의 플랫폼 분산을 줄일 수 있습니다. 보안에 민감한 프로덕션 사용의 경우, 샌드박스를 프라이빗 저장소, 민감한 데이터셋, 내부 서비스 또는 배포 자격 증명에 연결하기 전에 여전히 워크로드별 검토를 실행하십시오.
결론
검토가 다음 세 가지 질문에 명확히 답할 수 있을 때만 AI 에이전트 샌드박스를 승인하십시오: 무엇이 격리되었는가, 경계를 벗어날 수 있는 것은 무엇인가, 그리고 문제가 발생했을 때 어떤 증거가 남는가. 이러한 답변이 모호하다면, 누락된 제어가 문서화되고 테스트될 때까지 샌드박스를 비민감 워크로드로 제한하십시오.
FAQ
보안 팀이 AI 에이전트 샌드박스 검토에서 가장 먼저 확인해야 할 것은 무엇인가요?
실행 경계, 파일 시스템 노출 및 네트워크 기본값부터 시작하십시오. 이 세 가지 제어는 승인 및 아티팩트 내보내기와 같은 워크플로별 세부 사항을 살펴보기 전에 적대적인 코드가 호스트, 민감한 파일 또는 외부 대상에 도달할 수 있는지 여부를 결정합니다.
자율 코딩 에이전트에게 컨테이너 전용 샌드박스로 충분한가요?
워크로드와 도달할 수 있는 데이터에 따라 다릅니다. 컨테이너는 엄격한 마운트, 엄격한 이그레스 정책, 단기 자격 증명 및 강력한 로깅을 사용하는 낮은 민감도 작업에 허용될 수 있지만, 보안 팀은 "컨테이너"라는 단어만으로 결정하는 것이 아니라 문서화된 제어를 기반으로 결정해야 합니다.
DNS 및 패키지 접근을 일반 이그레스와 별도로 검토해야 하는 이유는 무엇인가요?
에이전트는 정상 운영의 일부로 종속성을 설치하고 외부 호스트를 확인하는 경우가 많기 때문입니다. DNS 쿼리와 패키지 가져오기는 기록, 필터링 또는 제한되지 않으면 데이터 유출 경로이자 공급망 위험이 될 수 있습니다.
추천 문서:
