AI 코드 실행을 위한 샌드박스는 격리 경계만큼 안전합니다. 하지만 격리 경계는 답의 일부일 뿐입니다. 더 나은 질문은: 샌드박스가 실제로 무엇을 격리하며, 무엇이 여전히 빠져나올 수 있는가? 입니다. 대부분의 샌드박스는 일부 항목(프로세스 수준의 코드 실행, 호스트에 대한 임의 파일 시스템 쓰기)을 잘 차단하지만, 다른 항목(아웃바운드 네트워크, 패키지 설치, 환경 변수의 시크릿)은 기본적으로 열려 있습니다. 이러한 격차를 이해하는 것이 샌드박스가 위험 모델에 적합한지 평가하는 방법입니다.
코드 실행 샌드박스에서 “보안”의 의미
코드 실행 샌드박스의 보안은 이진 속성이 아닙니다. 이는 특정 위험 범주를 각각 다루는 일련의 제어 장치입니다. 누군가 “이 샌드박스가 안전한가요?”라고 물을 때, 보통 여러 가지 별개의 질문을 동시에 하는 것입니다:
- 호스트 격리: 샌드박스 내부에서 실행되는 코드가 호스트 시스템으로 빠져나갈 수 있습니까?
- 테넌트 격리: 한 사용자의 코드가 다른 사용자의 세션에 영향을 줄 수 있습니까?
- 이그레스 제어: 샌드박스 내부의 코드가 인터넷, 내부 서비스 또는 메타데이터 엔드포인트에 도달할 수 있습니까?
- 시크릿 범위 지정: 자격 증명이 필요한 것보다 더 넓은 샌드박스 영역에 접근 가능합니까?
- 공급망 위험: 패키지 설치로 예상치 못한 악성 코드가 도입될 수 있습니까?
- 감사 가능성: 에이전트가 실제로 무엇을 했는지 사후에 재구성할 수 있습니까?
샌드박스는 호스트 격리에는 강력하지만 이그레스에는 약할 수 있습니다. 이그레스에는 강력하지만 시크릿에는 약할 수 있습니다. “보안 수준”을 평가하려면 각 차원을 개별적으로 확인해야 하며, “컨테이너화” 또는 “마이크로VM 기반”과 같은 단일 레이블을 전체 답변으로 받아들여서는 안 됩니다.
격리 계층 비교
AI 코드 실행 샌드박스에는 세 가지 주요 격리 모델이 사용됩니다. 각 모델은 서로 다른 경계를 제공합니다.
프로세스 격리
프로세스 격리는 OS 수준의 기본 요소(Linux 네임스페이스, cgroups, seccomp 필터, AppArmor 또는 SELinux 프로필)를 사용하여 프로세스가 접근할 수 있는 것을 제한합니다. 샌드박스는 호스트 OS에서 프로세스로 실행되며 호스트 커널을 공유합니다.
방지하는 것: 더 넓은 파일 시스템, 샌드박스 외부의 다른 프로세스, seccomp 정책에 의해 명시적으로 차단된 시스템 콜에 대한 접근.
방지하지 않는 것: 공유 취약점을 통해 권한을 상승시키는 커널 익스플로잇. seccomp 우회 또는 커널 취약점은 호스트 경계를 넘을 수 있습니다.
적합한 경우: 짧은 실행 시간, 낮은 위험, 신뢰할 수 있는 코드에서 VM 경계보다 시작 속도와 이식성이 더 중요한 경우. 외부 사용자의 임의 에이전트 생성 코드를 실행하는 경우에는 권장되지 않습니다.
컨테이너 격리 (Docker/네임스페이스)
컨테이너 격리는 프로세스 격리를 확장하여 더 구조화된 이미지 모델, 네트워크 네임스페이스, 볼륨 마운트를 제공합니다. 대부분의 Docker 기반 샌드박스 구현은 최소 이미지와 제한된 seccomp 프로필을 사용하여 컨테이너 내부에서 코드를 실행합니다.
방지하는 것: 호스트에 대한 직접 파일 시스템 접근, 인접 컨테이너에 대한 대부분의 네트워크 접근(올바르게 구성된 경우), 호스트 프로세스에 대한 쉬운 접근.
방지하지 않는 것: 커널 수준 익스플로잇은 여전히 적용됩니다 — 컨테이너는 호스트 커널을 공유합니다. 잘못 구성된 볼륨 마운트, 지나치게 넓은 seccomp 프로필, --privileged 모드, 노출된 Docker 소켓은 모두 의도된 경계를 무효화할 수 있습니다.
적합한 경우: 많은 프로덕션 배포에서 seccomp 프로필이 타이트하고, 이미지가 최소화되며, 이그레스가 제한되고, 권한 있는 접근이 부여되지 않은 경우 컨테이너를 AI 코드 실행에 효과적으로 사용합니다. 위험 모델은 마이크로VM과 다르지만 신중한 구성으로 관리할 수 있습니다.
마이크로VM 격리 (Firecracker/gVisor)
마이크로VM 격리는 각 샌드박스를 자체 게스트 커널을 가진 경량 가상 머신에서 실행하며, KVM 하이퍼바이저 경계로 호스트와 격리합니다. Firecracker가 가장 일반적인 구현이고, gVisor(자체 사용자 공간 커널 사용)는 다른 트레이드오프를 제공합니다.
방지하는 것: 게스트 커널 익스플로잇은 호스트 커널이나 다른 게스트로 전파되지 않습니다. 호스트 공격 표면은 최소로 설계된 VMM(가상 머신 모니터)으로 축소됩니다.
방지하지 않는 것: VMM 자체의 취약점(드물지만 불가능하지는 않음). 네트워크, 패키지, 시크릿 제어는 여전히 VM 경계 외부에 있습니다 — 마이크로VM 격리는 이러한 항목을 처리하지 않습니다.
적합한 경우: 신뢰할 수 없거나 에이전트가 생성한 코드를 외부 사용자로부터 실행하는 경우, 폭발 반경이 중요한 멀티 테넌트 환경, 임의 셸 명령이나 패키지 설치 스크립트를 실행할 수 있는 워크로드.
| 격리 모델 | 호스트 커널 공유 | 테넌트 분리 | 시작 오버헤드 | 호스트 이스케이프 위험 |
|---|---|---|---|---|
| 프로세스 | 예 | 약함 | 가장 낮음 | 가장 높음 |
| 컨테이너 | 예 | 보통 | 낮음 | 중간 (구성에 따라 다름) |
| 마이크로VM | 아니오 | 강함 | 보통 | 낮음 |
각 경계를 여전히 빠져나갈 수 있는 것
격리 모델은 런타임 코드 실행을 다룹니다. 다른 경로를 통해 샌드박스에 들어오거나 나가는 것을 자동으로 처리하지는 않습니다.
아웃바운드 네트워크: 세 가지 격리 모델 모두 아웃바운드 네트워크 접근은 정책 구성에 맡깁니다. 기본적으로 열린 이그레스는 샌드박스 내부의 코드가 공용 인터넷, 클라우드 메타데이터 엔드포인트(AWS 및 GCP의 169.254.169.254), 동일 네트워크의 내부 서비스, 임의 외부 API에 도달할 수 있음을 의미합니다. 이는 격리 모델과 관계없이 데이터 유출 경로, 시크릿 검색 경로, 명령 및 제어 경로입니다.
패키지 설치: apt install, pip install, 또는 npm install은 외부 레지스트리에서 코드를 가져와 실행합니다. 샌드박스가 패키지 설치를 허용하고 이그레스가 열려 있으면, 패키지 이름 충돌, 타입스쿼팅 공격, 또는 의존성 혼동 공격을 통해 샌드박스의 모든 권한으로 실행되는 악성 코드가 도입될 수 있습니다. 격리 경계는 폭발 반경을 제한하지만 설치를 막지는 않습니다.
공유 상태: 멀티 테넌트 배포에서 공유 캐시, 공유 패키지 레지스트리, 공유 템플릿 이미지, 공유 파일 시스템 마운트는 격리 경계를 우회하는 테넌트 간 채널을 만듭니다.
환경 변수의 시크릿: 에이전트 프로세스에 표시되는 환경 변수는 에이전트가 실행하는 모든 코드에서 읽을 수 있습니다. 데이터베이스 자격 증명이나 API 키가 환경에 있으면 샌드박스와 그것이 실행하거나 설치하는 모든 것에 접근 가능합니다.
이그레스 및 네트워크 제어
이그레스는 대부분의 샌드박스에서 가장 큰 격차가 있는 부분입니다. 열린 아웃바운드 인터넷 접근은 편리하기 때문에 일반적입니다 — 에이전트가 패키지를 설치하고, API를 호출하고, 리소스를 가져와야 하기 때문입니다. 그러나 이는 위험도 생성합니다:
클라우드 메타데이터 엔드포인트: 호스팅된 클라우드 인프라에서 169.254.169.254 (및 IPv6 등가 주소)는 IAM 자격 증명을 포함한 인스턴스 메타데이터를 제공합니다. 이그레스가 열린 샌드박스 내부의 코드는 이 엔드포인트에 도달하여 기본 호스트의 자격 증명을 검색할 수 있습니다.
DNS 기반 유출: HTTP가 차단되더라도 아웃바운드 DNS 쿼리는 도메인 조회에 데이터를 인코딩하여 데이터를 유출하는 데 사용될 수 있습니다. DNS 차단은 외부 서버에 대한 TCP/UDP 53을 차단하는 것만으로는 부족하며, 리졸버 수준에서 필터링이 필요합니다.
내부 서비스: 샌드박스가 프라이빗 네트워크 세그먼트에서 실행되는 경우, 열린 이그레스는 에이전트 코드에서 도달할 의도가 없는 내부 데이터베이스, 관리자 패널, API에 접근을 허용할 수 있습니다.
평가할 제어 사항:
| 제어 | 방지하는 것 | 확인할 사항 |
|---|---|---|
| 기본 거부 이그레스 | 목록에 없는 대상으로의 아웃바운드 연결 | TCP/UDP뿐만 아니라 DNS도 차단하는가? |
| 허용 목록 기반 이그레스 | 승인되지 않은 도메인으로의 연결 | 허용 목록이 고객이 구성 가능한가? |
| 메타데이터 엔드포인트 차단 | 169.254.169.254를 통한 클라우드 자격 증명 검색 |
IPv6 메타데이터도 차단되는가? |
| 이그레스 프록시 | 모든 아웃바운드 트래픽의 로깅 및 검사 | 프록시 로그에 접근 가능한가? |
| DNS 필터링 | DNS 기반 유출 및 내부 이름 확인 | 샌드박스 내부에서 어떤 리졸버가 사용되는가? |
보편적으로 올바른 이그레스 정책은 없습니다. 일부 에이전트 워크로드는 유용성을 위해 광범위한 인터넷 접근이 진정으로 필요합니다. 중요한 점은 정책이 의도적이고 감사 가능해야 하며, 구성된 적이 없어서 기본적으로 열려 있어서는 안 된다는 것입니다.
시크릿 처리
AI 에이전트 샌드박스의 시크릿은 모든 소프트웨어 시스템의 시크릿과 동일한 원칙을 따르지만, 한 가지 추가 제약이 있습니다: 에이전트가 개발자의 의도 없이 환경을 읽거나, 기록하거나, 전송하는 코드를 실행할 수 있다는 점입니다.
범위 지정: 현재 작업에 실제로 필요한 자격 증명만 마운트하십시오. 코딩 작업을 실행하는 샌드박스는 프로덕션 데이터베이스 자격 증명이 필요하지 않습니다. 모델 출력을 평가하는 샌드박스는 청구 서비스의 API 키가 필요하지 않습니다.
수명: 단기 자격 증명은 장기 자격 증명보다 훨씬 안전합니다. 샌드박스 내부에서 자격 증명이 유출되면, 짧은 TTL은 노출 기간을 제한합니다. 많은 클라우드 IAM 시스템은 몇 분 또는 몇 시간 후에 만료되는 단기 토큰을 지원합니다.
주입 방법: 환경 변수는 가장 일반적인 주입 방법이며 프로세스의 모든 코드가 가장 접근하기 쉽습니다. 파일 시스템 마운트를 통해 주입되거나, 에이전트가 탐색할 필요가 없는 경로에 마운트되거나, 필요한 특정 도구가 실행될 때만 동적으로 가져오는 시크릿은 포괄적인 환경 변수 설정보다 더 제한적입니다.
편집(Redaction) : 시크릿은 stdout, stderr, 도구 응답 페이로드, 모델에 표시되는 컨텍스트, 감사 로그에서 편집되어야 합니다. 환경을 출력하거나, env를 호출하거나, 실패하는 API 호출에 토큰을 전달하는 에이전트는 이후 저장되거나 운영자에게 표시될 수 있는 로그로 자격 증명을 유출할 수 있습니다.
리소스 제한 및 서비스 거부 위험
리소스 제한이 없는 샌드박스는 CPU, 메모리, 디스크 또는 네트워크 대역폭을 소진시키는 에이전트 워크로드에 취약합니다 — 실행 불능 코드, 무한 루프, 설치된 패키지의 메모리 누수, 또는 인접 워크로드를 방해하려는 의도적인 시도를 통해 발생합니다.
확인해야 할 리소스 제어:
- CPU 제한: 세션당 조절 또는 하드 제한은 한 세션이 호스트 용량을 독점하는 것을 방지합니다.
- 메모리 제한: OOM 종료 정책은 호스트 프로세스가 아닌 샌드박스 세션을 종료해야 합니다.
- 디스크 할당량: 세션당 쓰기 제한은 세션이 공유 저장소를 가득 채우는 것을 방지합니다.
- 실행 시간 초과: 벽시계 제한을 초과하는 세션은 계속 실행되지 않고 정리되어 종료되어야 합니다.
- 네트워크 속도 제한: 아웃바운드 대역폭 제한은 이그레스 정책이 대상을 허용하더라도 유출을 제한할 수 있습니다.
- 동시 프로세스 제한: 공격적으로 포크를 생성하거나 백그라운드 프로세스를 생성하는 에이전트는 프로세스 테이블 슬롯을 소진시킬 수 있습니다.
리소스 제한 위반도 기록할 가치가 있습니다. 가벼워야 하는 작업 중에 지속적으로 CPU 조절 또는 OOM 종료에 도달하는 세션은 조사할 가치가 있는 신호입니다.
감사 가시성
격리 제어는 문제가 발생했을 때 폭발 반경을 줄입니다. 감사 로그는 문제가 발생했음을 발견하고 무슨 일이 일어났는지 재구성하는 방법입니다.
특히 AI 에이전트 샌드박스의 경우 유용한 감사 범위는 다음과 같습니다:
- 프로세스 실행: 전체 인수 목록, UID, 부모 프로세스와 함께 실행되는 모든 명령. 인수 목록이 없으면 로그의
curl과python은 의미가 없습니다. - 파일 시스템 접근: 민감한 경로에 대한 읽기 및 쓰기. 대부분의 위협 모델에서 읽기보다 쓰기와 삭제가 더 높은 우선순위입니다.
- 아웃바운드 네트워크: 대상, 프로토콜, DNS 쿼리, 전송된 바이트. DNS 쿼리 로깅은 종종 누락되지만 중요합니다.
- 패키지 설치: 패키지 관리자, 패키지 이름, 버전, 소스 레지스트리, 해시.
- 세션 수명 주기: 생성, 일시 중지, 재개, 종료, 정리 이벤트와 이유 코드.
- 리소스 제한 이벤트: OOM 종료, CPU 조절, 시간 초과 종료.
수집 메커니즘은 범위만큼 중요합니다. 샌드박스 프로세스 내부에서 생성된 로그는 충분히 권한이 있는 에이전트에 의해 억제되거나 수정될 수 있습니다. 커널 수준 수집(auditd, eBPF 또는 하이퍼바이저 계측을 통해)은 에이전트가 쓰기 접근 권한이 없는 애플리케이션 계층 아래에서 생성됩니다.
모든 샌드박스 제공자 또는 프로젝트에 물어봐야 할 질문
관리형 샌드박스 서비스 또는 오픈 소스 샌드박스 프레임워크를 평가할 때 이 체크리스트를 사용하십시오:
격리
- 각 에이전트 세션이 자체 격리 환경을 얻습니까, 아니면 세션이 공유 실행 환경에 그룹화됩니까?
- 어떤 격리 모델이 사용됩니까: 프로세스, 컨테이너 또는 마이크로VM?
- 게스트 커널이 호스트와 공유됩니까?
네트워크 및 이그레스
- 이그레스가 기본적으로 열려 있습니까, 아니면 기본적으로 거부됩니까?
- 이그레스 정책을 테넌트별 또는 세션별로 구성할 수 있습니까?
- 클라우드 메타데이터 엔드포인트(
169.254.169.254)가 차단됩니까? - 샌드박스 내부에서 DNS는 어떻게 처리됩니까?
패키지 설치
- 패키지 설치가 기본적으로 허용됩니까?
- 설치를 승인된 레지스트리로 제한할 수 있습니까?
- 설치 이벤트가 소스 및 해시와 함께 기록됩니까?
시크릿
- 자격 증명이 샌드박스에 어떻게 주입됩니까?
- 자격 증명을 필요로 하는 특정 도구 또는 작업으로 범위를 지정할 수 있습니까?
- 시크릿이 로그 및 모델에 표시되는 출력에서 편집됩니까?
리소스 제한
- CPU, 메모리, 디스크, 시간 초과 제한이 적용됩니까?
- 제한에 도달하면 어떻게 됩니까 — 조절, 종료 또는 경고?
감사 로그
- 로그가 커널/하이퍼바이저 수준에서 생성됩니까, 아니면 샌드박스 프로세스 내부에서 생성됩니까?
- 기본적으로 어떤 이벤트 범주가 기록됩니까?
- 로그를 외부 SIEM 또는 로그 집계 시스템으로 내보낼 수 있습니까?
- 로그 보존 정책은 무엇입니까?
테넌시
- 다른 테넌트의 워크로드가 서로 격리됩니까?
- 크로스 테넌트 채널을 생성하는 공유 캐시, 이미지 또는 마운트가 있습니까?
Novita Agent Sandbox의 위치
Novita Agent Sandbox는 코드, 파일, 프로세스 및 장기 실행 세션을 위한 격리된 실행 환경이 필요한 에이전트 워크로드를 위해 설계되었습니다. 코딩 에이전트, 평가 파이프라인, 데이터 분석 에이전트, 브라우저 기반 에이전트 워크플로우를 구축하는 팀을 대상으로 합니다.
이 샌드박스는 일시 중지, 재개, 유휴 세션 자동 일시 중지를 포함한 세션 수명 주기 제어를 지원합니다. API를 통해 접근 가능한 리소스 메트릭 및 세션 수준 실행 로그를 제공합니다. 이미 Novita 모델 API를 사용하는 팀의 경우, 모델이 계획을 세우고 도구를 호출하며 샌드박스가 격리된 환경에서 런타임 실행을 처리하는 에이전트 아키텍처의 실행 계층 역할을 할 수 있습니다.
보안에 민감한 사용 사례에 대해 Novita Agent Sandbox를 평가할 때는 아키텍처 결정을 내리기 전에 제품 문서에서 현재 격리 모델, 이그레스 정책 기본값, 로그 범위 및 시크릿 처리를 확인하십시오. 보안 요구 사항은 워크로드에 따라 크게 다릅니다 — 내부 평가 파이프라인에 적합한 것이 사용자 제공 코드를 처리하는 멀티 테넌트 제품에는 충분하지 않을 수 있습니다.
모든 샌드박스와 마찬가지로 보안 태세는 플랫폼의 기본값과 애플리케이션 수준 제어(자격 증명 범위 지정 방법, 에이전트가 요청할 수 있는 항목, 인간 승인이 필요한 도구 호출, 감사 로그 모니터링 방법)에 따라 달라집니다.
한계 및 어떤 샌드박스도 제거하지 않는 것
어떤 샌드박스도 모든 위험을 제거하지 않습니다. 경계 외부에 남아 있는 것을 이해하는 것은 경계가 제공하는 것을 이해하는 것만큼 중요합니다.
애플리케이션 계층 신뢰 결정: 샌드박스는 런타임 실행을 제어합니다. 에이전트가 무엇을 요청할 수 있는지 결정하지 않습니다. 애플리케이션이 에이전트가 자격 증명을 요청하거나, 임의 셸 명령을 실행하거나, API를 호출하도록 허용하는 경우, 샌드박스는 폭발 반경을 줄이지만 해당 작업을 방지하지는 않습니다.
프롬프트 인젝션: 신뢰할 수 없는 콘텐츠(웹 페이지, 사용자 업로드 파일, 외부 API 응답)를 처리하는 에이전트는 해당 콘텐츠를 통해 조작되어 수행해서는 안 되는 작업을 취할 수 있습니다. 이는 샌드박스 문제가 아니라 애플리케이션 설계 문제입니다. 샌드박스는 해당 작업이 도달하는 위치를 제한할 수 있지만, 결정 논리는 애플리케이션에 있습니다.
제로데이 취약점: 모든 격리 모델에는 알려진 취약점과 알려지지 않은 취약점이 있습니다. 마이크로VM 격리는 현재 프로덕션 사용에서 가장 강력한 경계를 제공하지만, VMM 취약점은 존재합니다. 하나의 경계를 신뢰하는 것보다 여러 제어를 결합하는 심층 방어가 단일 격리 모델보다 더 강력한 태세입니다.
모델 출력을 통한 사회 공학: 에이전트는 인간 운영자가 안전하지 않은 작업을 수행하도록 설득하는 출력을 생성할 수 있습니다. 샌드박스는 인간의 결정을 감사하지 않습니다.
규정 준수 및 규제 위험: 격리 제어는 기술적 위험을 다룹니다. 규제 요구 사항(GDPR, HIPAA, SOC 2, ISO 27001)은 샌드박스가 인프라 수준에서 제공하는 것 이상의 데이터 처리, 보존, 문서화 및 감사 요구 사항을 다룹니다.
코드 실행 샌드박스의 보안은 제품을 선택하여 획득하는 속성이 아니라 평가하고 구성해야 하는 일련의 제어 장치로 이해하는 것이 가장 좋습니다. 위의 평가 질문은 구축하든 구매하든 모든 샌드박스 결정(자체 인프라 포함)에 적용됩니다.
FAQ
샌드박스 AI 코드 실행 환경이 서버에서 코드를 실행하는 것과 비교하여 얼마나 안전한가요?
잘 구성된 샌드박스는 신뢰할 수 없는 코드를 서버에서 직접 실행하는 것과 비교하여 폭발 반경을 크게 줄입니다. 파일 시스템 접근, 프로세스 범위, 네트워크 접근을 제한합니다. 그러나 차이는 구성에 따라 다릅니다. 광범위한 환경 변수 주입이 있는 열린 이그레스 컨테이너는 네트워크 제어가 있는 강화된 서버보다 덜 안전할 수 있습니다. 격리 모델은 출발점일 뿐 보장이 아닙니다.
마이크로VM 격리가 샌드박스가 완전히 안전하다는 것을 의미하나요?
아니요. 마이크로VM 격리(Firecracker, KVM 기반)는 공유 커널 컨테이너가 제공하지 않는 강력한 호스트 경계를 제공합니다. 그러나 이그레스, 시크릿, 패키지 설치 또는 감사 범위를 제어하지는 않습니다. 이그레스가 열려 있고 로그 수집이 없는 마이크로VM은 격리 계층이 강력하더라도 “완전히 안전”하지 않습니다.
AI 생성 코드가 샌드박스를 탈출할 수 있나요?
격리 모델과 구성에 따라 다릅니다. 컨테이너 탈출은 커널 또는 잘못된 구성을 악용해야 합니다. 마이크로VM 탈출은 VMM을 악용해야 합니다. 둘 다 가능하지만 흔하지 않습니다. 더 실용적인 위험은 허용된 네트워크 경로를 통한 데이터 유출, 환경에서 시크릿 읽기, 또는 제한되지 않은 패키지 관리자를 통한 악성 패키지 설치입니다.
대부분의 AI 코드 샌드박스에서 가장 큰 보안 위험은 무엇인가요?
열린 아웃바운드 이그레스는 가장 일반적으로 간과되는 위험입니다. 많은 샌드박스가 패키지를 설치하고 API를 호출해야 하는 에이전트에게 편리하기 때문에 기본적으로 제한 없는 아웃바운드 인터넷 접근을 허용합니다. 이는 격리 경계가 아무리 강력하더라도 존재하는 데이터 유출, 클라우드 메타데이터 엔드포인트를 통한 자격 증명 도난, 명령 및 제어 통신을 위한 경로를 만듭니다.
관리형 샌드박스를 사용해야 하나요, 아니면 직접 구축해야 하나요?
관리형 샌드박스는 마이크로VM 또는 컨테이너 수명 주기, 호스트 용량, 이미지 관리의 운영 복잡성을 처리합니다. 직접 구축하면 전체 정책 스택에 대한 더 많은 제어권을 얻을 수 있습니다. 어느 쪽이든 동일한 평가 질문이 적용됩니다: 이그레스 정책, 시크릿 처리, 로그 범위, 리소스 제한, 감사 내보내기. 구축 대 구매 결정은 보안 평가와 별개입니다.
에이전트 샌드박스 보안을 전통적인 코드 실행 보안과 다르게 만드는 것은 무엇인가요?
전통적인 코드 실행 보안은 실행될 코드를 대략적으로 알고 있다고 가정합니다. AI 에이전트는 이를 변경합니다: 단일 프롬프트로 인해 세션이 각 단계에 대한 명시적인 개발자 승인 없이 패키지를 설치하고, 파일을 쓰고, 셸 명령을 실행하고, 외부 API를 호출하고, 하위 프로세스를 생성할 수 있습니다. 이로 인해 감사 범위(모든 작업을 예측할 수 없음), 이그레스 제어(에이전트가 예상치 못한 대상에 도달할 수 있음), 시크릿 범위 지정(에이전트가 환경의 모든 것에 접근할 수 있음)이 더 중요해집니다.
