샌드박스 코드가 공격자가 통제하는 도메인을 해석하거나 DNS를 아웃바운드 데이터 채널로 사용할 수 있다면 DNS 유출 위험이 중요해집니다. 따라서 팀은 민감한 워크플로를 AI 에이전트 샌드박스에 맡기기 전에 DNS 정책, 로깅, 패키지 가져오기 경로, 사고 증거를 평가해야 합니다.
샌드박스 위협 모델에서 DNS가 중요한 이유
AI 에이전트 샌드박스는 유용한 자율성을 위해 설계되었습니다. 코딩 에이전트는 모든 명령을 사람이 승인하지 않고도 테스트 실행, 패키지 설치, API 호출, 브라우저 실행, 파일 검사, 아티팩트 생성을 수행할 수 있습니다. 이러한 유연성 때문에 네트워크 동작은 CPU, 메모리, 파일 시스템, 프로세스 격리와 별도로 자체 검토가 필요합니다.
DNS는 HTTP 이그레스보다 덜 주목받는 경향이 있습니다. 인프라 파이프라인처럼 보이기 때문입니다. 애플리케이션이 API, 레지스트리, 웹 페이지, 업데이트 엔드포인트에 도달하려면 이름 해석이 필요합니다. 그러나 DNS는 여전히 아웃바운드 통신입니다. 임의 도메인을 해석할 수 있는 샌드박스는 쿼리 이름을 통해 정보를 노출하거나, 공격자가 통제하는 인프라에 접촉하거나, DNS 트래픽이 웹 요청과 동일한 수준으로 기록되지 않으면 사각지대를 만들 수 있습니다.
이것은 AI 에이전트를 위해 만들어진 이론적 범주가 아닙니다. MITRE ATT&CK은 DNS를 공격자가 명령 및 제어 통신에 사용할 수 있는 애플리케이션 계층 프로토콜로 문서화하고 있으며, 기본 애플리케이션 프로토콜이 아닌 채널을 통해 데이터가 유출되는 것을 대체 프로토콜을 통한 유출로 별도로 문서화합니다. 샌드박스 평가자에게 주는 교훈은 분명합니다. HTTP POST가 아니라는 이유로 DNS를 무해하게 취급하지 말라는 것입니다.
AI 에이전트의 경우 위험은 명백한 실수 하나가 아니라 작은 권한의 연쇄에서 발생하는 경우가 많습니다.
| 샌드박스 기능 | 팀이 허용하는 이유 | DNS 관련 질문 |
|---|---|---|
| 패키지 설치 | 에이전트가 누락된 의존성을 설치하도록 허용 | 어떤 레지스트리와 해석 경로가 허용되나요? |
| 웹 접근 | 브라우저 에이전트가 공개 컨텍스트를 수집하도록 허용 | 코드가 모든 도메인을 해석할 수 있나요, 아니면 승인된 도메인만 해석할 수 있나요? |
| API 호출 | 에이전트가 앱 백엔드와 통합하도록 허용 | 내부 도메인과 메타데이터 엔드포인트가 차단되나요? |
| 빌드 도구 | 코딩 에이전트가 실제 테스트를 실행하도록 허용 | 설치 후 스크립트가 예기치 않은 조회를 트리거할 수 있나요? |
| 장기 실행 세션 | 에이전트가 다단계 작업을 계속하도록 허용 | DNS 로그가 전체 세션 수명 주기에 걸쳐 보존되나요? |
목표는 모든 네트워크 호출을 금지하는 것이 아닙니다. 많은 에이전트 워크로드에는 통제된 네트워크 접근이 필요합니다. 목표는 어떤 경로가 존재하고, 어떤 경로가 차단되며, 작업이 예기치 않게 동작할 때 어떤 증거를 확보할 수 있는지 아는 것입니다.
에이전트 워크플로에서 DNS 해석이 나타나는 위치
보안 검토는 종종 샌드박스에 인터넷 접근 권한이 있는지 묻습니다. 그 질문은 너무 광범위합니다. 더 나은 검토는 코드, 도구, 패키지 관리자, 브라우저가 이름 해석을 트리거할 수 있는 모든 위치를 매핑하는 것에서 시작합니다.
일반적인 DNS 경로는 다음과 같습니다.
- Python, JavaScript, 셸 스크립트, SDK, 테스트 스위트의 직접 코드 요청.
- 페이지, 하위 리소스, 글꼴, 이미지, 분석 스크립트, 리디렉션을 로드하는 브라우저 자동화.
- npm, pip, uv, pnpm, apt, cargo 또는 언어별 플러그인 설치 프로그램과 같은 패키지 관리자.
- 바이너리, 템플릿, 브라우저 드라이버, 모델 파일 또는 테스트 픽스처를 가져오는 빌드 도구.
- 타사 API 또는 웹훅 엔드포인트를 호출하는 에이전트 도구.
- 표시된 에이전트 단계가 반환된 후에도 계속 실행되는 백그라운드 작업.
이 매핑에는 의도된 트래픽과 우발적 트래픽이 모두 포함되어야 합니다. 개발자는 에이전트에게 단위 테스트 실행만 요청할 수 있지만, 테스트 명령이 패키지를 설치하고, 패키지 관리자가 레지스트리 도메인을 해석하고, 수명 주기 스크립트가 별도 호스트에 접촉할 수 있습니다. 브라우저 작업이 하나의 공개 사이트로 제한될 수 있지만, 포함된 리소스는 많은 추가 도메인을 해석합니다.
샌드박스 제공자에게 가장 강력한 답변은 단순히 “네트워크 접근이 가능합니다” 또는 "네트워크 접근이 격리되어 있습니다"가 아닙니다. 유용한 답변은 해석 경로를 설명합니다.
- 샌드박스 DNS가 제공자 통제 해석기, 고객 통제 해석기, VPC 해석기 또는 공용 해석기를 사용합니까?
- 고객이 도메인, IP 범위, 포트 또는 프로토콜을 제한할 수 있습니까?
- DNS 요청이 샌드박스별, 세션별, 명령별로 기록됩니까, 아니면 집계 네트워크 계층에서만 기록됩니까?
- 거부된 조회가 기록됩니까, 아니면 허용된 조회만 기록됩니까?
- 고객이 패키지 가져오기 DNS와 런타임 DNS를 분리할 수 있습니까?
이러한 세부 정보를 확인할 수 없다면 샌드박스가 안전하지 않다는 증거가 아니라 평가 항목으로 취급하십시오. 실질적 위험은 워크로드의 민감도, 샌드박스 내부에 있는 비밀, 아웃바운드 정책, 포렌식 증거의 품질에 따라 달라집니다.
아웃바운드 정책 평가 방법
아웃바운드 정책은 DNS가 일상적인 파이프라인이 될지, 검토되지 않은 탈출 경로가 될지를 결정하는 제어 표면입니다. 성숙한 정책은 세 가지 질문에 답해야 합니다. 무엇이 허용되는지, 왜 허용되는지, 예외가 어떻게 승인되는지입니다.
기본 태세부터 시작하십시오. 신뢰할 수 없는 AI 생성 코드에 사용되는 샌드박스는 개발자 노트북과 동일한 광범위한 네트워크 접근 권한을 상속해서는 안 됩니다. 기본값이 개방형 이그레스라면 제품이 고위험 워크로드에 대해 접근 범위를 좁힐 수 있는지 물어보십시오. 기본값이 제한된 이그레스라면 개발자가 작업에 필요한 정확한 도메인을 어떻게 활성화하는지 물어보십시오.
그런 다음 DNS 정책을 HTTP 정책과 분리하십시오. 일부 시스템은 HTTP 허용 목록을 적용하지만 이름 해석은 광범위하게 남겨 둡니다. 이로 인해 불일치가 발생할 수 있습니다. 승인되지 않은 호스트에 대한 요청은 HTTP 계층에서 실패할 수 있지만, DNS 쿼리는 여전히 환경을 떠나고 쿼리된 이름에 메타데이터를 포함할 수 있습니다. 더 엄격한 설계는 해석과 연결 시도를 함께 평가합니다.
보안 검토에는 다음과 같은 정책 매트릭스를 사용하십시오.
| 평가 영역 | 무엇을 물어볼까 | 더 강력한 증거 |
|---|---|---|
| 기본 이그레스 | 아웃바운드 네트워크 접근이 개방, 거부 또는 템플릿별로 범위가 지정됩니까? | 문서화된 기본 정책 및 샌드박스 수준 테스트 결과 |
| DNS 해석기 경로 | 어떤 해석기가 샌드박스 DNS를 처리합니까? | 아키텍처 다이어그램 또는 구성 증명 |
| 도메인 허용 목록 | 팀이 승인된 레지스트리와 API만 허용할 수 있습니까? | 구성 예시 및 거부 로그 예시 |
| IP 및 사설 네트워크 차단 | 내부 범위와 메타데이터 서비스가 기본적으로 차단됩니까? | 문서화된 거부 규칙 및 테스트 증거 |
| 프로토콜 제어 | DNS, HTTP, HTTPS, 원시 소켓이 별도로 제어됩니까? | 마케팅 문구가 아닌 정책 모델 |
| 예외 워크플로 | 누가 도메인을 추가하거나 정책을 완화할 수 있습니까? | 역할 기반 승인 및 감사 기록 |
대부분의 팀에게 첫 번째 실질적 목표는 완벽한 제로 이그레스 환경이 아닙니다. 승인된 패키지 레지스트리, 승인된 API 도메인, 명시적으로 라우팅되지 않는 한 내부 네트워크에 대한 접근 금지, 허용 및 거부 시도 모두에 대한 로그를 갖춘 문서화된 최소 이그레스 프로필입니다.
패키지 가져오기 및 의존성 기반 DNS
패키지 설치는 샌드박스 이그레스를 과소평가하기 가장 쉬운 경로 중 하나입니다. 에이전트가 생성한 코드는 누락된 의존성 때문에 실패하는 경우가 많으며, 가장 빠른 개발자 경험은 에이전트가 필요한 것을 설치하도록 하는 것입니다. 이러한 편의성은 두 번째 공급망 문제를 만듭니다. 패키지 이름, 레지스트리 리디렉션, 설치 스크립트, 바이너리 다운로드가 원래 프롬프트에서 언급되지 않은 DNS 및 네트워크 활동을 트리거할 수 있습니다.
OWASP의 LLM 애플리케이션 지침은 과도한 에이전시와 공급망 노출과 관련된 위험을 지적합니다. 에이전트 샌드박스에서 이러한 위험은 패키지 설치에서 만납니다. 모델은 명령을 선택하도록 허용될 수 있습니다. 명령은 패키지 관리자를 호출할 수 있습니다. 패키지 관리자는 레지스트리에서 코드를 가져올 수 있습니다. 가져온 패키지는 설치 후크를 실행할 수 있습니다. 각 단계는 DNS 조회와 아웃바운드 연결을 생성할 수 있습니다.
방어적 평가는 공격 메커니즘이 아닌 거버넌스에 초점을 맞춰야 합니다.
- 반복 가능한 에이전트 작업에는 고정된 의존성 파일을 선호하십시오.
- 일반적인 에코시스템에는 승인된 레지스트리 또는 풀스루 캐시를 사용하십시오.
- 가능한 경우 패키지 이름, 버전, 레지스트리 URL, 해석된 도메인, 아티팩트 해시를 기록하십시오.
- 패키지 설치 권한을 일반 런타임 인터넷 접근과 분리하십시오.
- 민감한 작업 영역에서는 허용 목록 외부의 패키지를 설치하기 전에 승인을 요구하십시오.
- 모든 실행에서 에이전트가 광범위한 네트워크 접근이 필요하지 않도록 일반적인 스택에 대한 사전 빌드 샌드박스 템플릿을 고려하십시오.
중요한 구분은 "패키지 가져오기"가 하나의 제어가 아니라는 점입니다. 여기에는 DNS 해석, 레지스트리 인증, 아티팩트 다운로드, 설치 시 코드 실행, 캐시 동작이 포함됩니다. 좋은 샌드박스 검토는 전체 경로에 대해 질문합니다.
비밀 및 데이터 노출 가정
DNS 유출은 유출할 의미 있는 데이터가 있을 때만 중요합니다. 따라서 비밀 배치와 데이터 범위 지정은 DNS 검토의 일부입니다.
AI 에이전트 샌드박스는 입증되지 않는 한 신뢰할 수 없는 빌드 작업자로 취급해야 합니다. 샌드박스가 호스트에서 격리되어 있다는 이유만으로 장기 사용 프로덕션 자격 증명, 광범위한 클라우드 토큰, 고객 데이터 또는 내부 소스 코드를 샌드박스에 넣지 마십시오. 격리는 폭발 반경을 줄여주지만 모든 명령을 안전하게 만들지는 않습니다.
고위험 워크플로를 설계할 때 다음 가정을 사용하십시오.
- 에이전트가 실행한 코드가 읽을 수 있는 모든 파일은 로그, 출력, 네트워크 요청 또는 오류 메시지에 포함될 수 있습니다.
- 프로세스에 보이는 모든 환경 변수는 해당 프로세스에 의해 복사될 수 있습니다.
- 샌드박스에 허용된 모든 아웃바운드 채널은 DNS를 포함하여 동일한 데이터 손실 검토를 받아야 합니다.
- 브라우저 또는 문서 워크플로의 프롬프트 주입 지침은 도구 사용에 영향을 미치려고 시도할 수 있습니다.
- 장기 실행 세션은 수명 주기 로그와 토큰 만료의 가치를 증가시킵니다.
실질적 통제에는 단기 자격 증명, 최소 권한 API 키, 범위가 지정된 서비스 계정, 작업별 비밀, 편집된 로그, 공개 데이터 연구 작업과 민감한 코드 실행 작업의 명시적 분리가 포함됩니다.
로그, 감사 추적 및 사고 증거
DNS 통제는 팀이 이를 검증할 수 있을 때만 유용합니다. 샌드박스 작업이 의심스러울 때 보안 팀은 빠르게 증거를 확보해야 합니다. 무엇이 실행되었는지, 무엇이 해석되었는지, 무엇이 연결되었는지, 어떤 파일이 변경되었는지, 어떤 출력이 반환되었는지입니다.
최소한 플랫폼이 특정 샌드박스 세션에 대해 다음 이벤트를 재구성할 수 있는지 물어보십시오.
- 샌드박스 생성 시간, 템플릿, 리소스 구성, 소유자.
- 에이전트 또는 사용자가 실행한 명령.
- 제품이 파일 작업을 노출하는 경우 읽기, 쓰기, 업로드 또는 다운로드된 파일.
- 패키지 설치 및 레지스트리 가져오기.
- 타임스탬프, 쿼리된 이름, 결과, 샌드박스/세션 식별자를 포함한 DNS 쿼리.
- 대상 호스트, IP, 포트, 프로토콜, 허용/거부 결과 및 가능한 경우 볼륨을 포함한 아웃바운드 연결 시도.
- 도구 호출, 브라우저 탐색 이벤트 및 백그라운드 프로세스.
- 로그에 비밀 값을 노출하지 않는 비밀 주입 이벤트.
- 세션 종료, 일시 중지, 재개, 스냅샷 및 정리 이벤트.
성공 트래픽 로그만 요청하지 마십시오. 거부된 이벤트는 정책이 작동했는지 평가하는 데 더 유용한 경우가 많습니다. 샌드박스가 승인되지 않은 도메인을 해석하려고 시도하고 정책이 이를 차단하면, 그 거부된 조회는 기능하는 통제와 조용한 실패를 구분하는 증거입니다.
보존도 중요합니다. 7일 로그 창은 디버깅에는 충분할 수 있지만 사고 대응에는 약합니다. 규제 대상 또는 고객 민감 워크로드가 있는 팀은 샌드박스 원격 분석 보존을 더 넓은 보안 로깅 정책에 맞춰야 합니다.
Novita 에이전트 샌드박스 평가 노트
Novita 에이전트 샌드박스는 격리된 코드 실행, 브라우저 자동화, 컴퓨터 사용 스타일 작업, 장기 실행 세션, 평가 또는 강화 학습 워크로드가 필요한 AI 에이전트 워크플로를 위해 설계되었습니다. Novita 에이전트 샌드박스 개요는 현재 제품 동작에 대한 올바른 시작점이며, 에이전트 샌드박스 제품 페이지는 더 넓은 플랫폼 적합성을 설명합니다.
Novita 또는 다른 샌드박스 제공자를 DNS 민감 워크로드에 대해 평가할 때 두 가지 유형의 진술을 분리하십시오.
- 제품 적합성: 샌드박스가 코드 실행, 브라우저 자동화 또는 장기 실행 작업과 같이 필요한 에이전트 워크플로를 지원하는지 여부.
- 보안 통제 증거: 정확한 DNS, 이그레스, 패키지 가져오기, 비밀, 로그 통제가 내부 정책을 충족하는지 여부.
이러한 분리는 과잉 주장을 방지합니다. 샌드박스가 에이전트 실행에 강력한 적합성을 가질 수 있지만 여전히 DNS 정책, 해석기 경로, 허용 목록, 감사 보존 및 사고 워크플로에 대한 특정 고객 검토가 필요할 수 있습니다. 보안 팀은 민감한 워크로드를 승인하기 전에 이러한 통제 세부 정보에 대한 최신 문서 또는 제품 확인을 요청해야 합니다.
이미 Novita AI 모델을 사용하는 팀의 경우 플랫폼 적합성은 모델 API와 에이전트 실행 인프라를 함께 평가할 수 있다는 점입니다. 이는 운영 분산을 줄일 수 있지만 위협 모델의 필요성을 없애지는 않습니다. 샌드박스를 통제된 실행 환경으로 취급하고, 각 에이전트 클래스에 필요한 네트워크 접근을 정의하고, 통제 증거가 내부에 배치된 데이터의 위험과 일치하는지 검증하십시오.
보안 검토 체크리스트
민감한 코드, 자격 증명, 고객 데이터 또는 내부 시스템에 접촉할 수 있는 AI 에이전트 샌드박스 워크로드를 승인하기 전에 이 체크리스트를 사용하십시오.
| 검토 질문 | 중요한 이유 |
|---|---|
| 샌드박스가 기본적으로 무엇을 해석할 수 있습니까? | HTTP가 차단된 경우에도 DNS는 아웃바운드 신호가 될 수 있습니다. |
| DNS를 도메인, 템플릿, 작업 영역 또는 VPC 정책별로 제한할 수 있습니까? | 민감한 워크로드는 공개 연구 작업보다 더 좁은 기본값이 필요합니다. |
| DNS 쿼리가 샌드박스 세션별로 기록됩니까? | 사고 대응에는 집계 해석기 지표가 아닌 귀속이 필요합니다. |
| 거부된 DNS 및 연결 시도가 기록됩니까? | 거부된 이벤트는 정책이 예기치 않은 동작을 차단했음을 증명합니다. |
| 패키지 레지스트리가 허용 목록 또는 프록시로 처리됩니까? | 패키지 관리자는 의존성 기반 DNS 및 다운로드를 트리거할 수 있습니다. |
| 패키지 설치를 런타임 네트워크 접근과 분리할 수 있습니까? | 빌드 시간과 런타임 위험은 다릅니다. |
| 내부 IP 범위와 메타데이터 엔드포인트가 차단됩니까? | 에이전트가 우연히 인프라 제어 평면을 발견하거나 접촉해서는 안 됩니다. |
| 비밀은 어떻게 주입, 범위 지정, 교체 및 편집됩니까? | 장기 사용 비밀이 샌드박스 코드에 제공되면 DNS 검토는 불완전합니다. |
| 브라우저 하위 리소스가 로그에 표시됩니까? | 브라우저 에이전트는 최상위 URL보다 더 많은 도메인을 해석할 수 있습니다. |
| 일시 중지, 재개, 스냅샷 또는 정리 후 어떤 증거가 제공됩니까? | 장기 실행 세션에는 수명 주기 인식 원격 분석이 필요합니다. |
| 누가 이그레스 정책을 완화할 수 있습니까? | 예외 변경은 감사 가능해야 합니다. |
| 의심스러운 세션은 어떻게 보존됩니까? | 정리로 인해 유일한 유용한 사고 증거가 지워져서는 안 됩니다. |
여러 답변을 알 수 없다면 제공자 또는 내부 플랫폼 팀이 통제 경로를 문서화할 때까지 워크로드를 샌드박스에 넣지 마십시오. 워크로드가 공개 데이터만 처리하고 비밀을 사용하지 않는 경우 초기 프로토타입 단계에서는 동일한 격차가 허용될 수 있지만, 프로덕션 사용 전에 여전히 추적되어야 합니다.
결론
프로덕션 에이전트 샌드박스의 경우 DNS를 각주가 아닌 이그레스의 일부로 검토하십시오. 최소 방어 가능한 구성은 범위가 지정된 아웃바운드 정책, 명시적인 패키지 가져오기 거버넌스, 단기 비밀, 세션별 DNS 및 연결 로그, 증거 보존을 위한 테스트된 사고 워크플로입니다.
데이터가 비민감하고 에이전트에 의미 있는 비밀이 없는 경우에만 저위험 프로토타입에 더 광범위한 네트워크 접근을 사용하십시오. 민감한 코드베이스, 고객 데이터, 내부 API 또는 규제 대상 워크로드의 경우 에이전트에 자율 실행을 부여하기 전에 최소 이그레스 프로필과 현재 제공자 증거를 요구하십시오.
FAQ
샌드박스가 HTTP를 차단하면 DNS 유출이 여전히 관련이 있나요?
네. HTTP 통제와 DNS 통제는 서로 다른 계층입니다. 샌드박스가 아웃바운드 웹 요청을 차단하면서도 DNS 쿼리를 허용할 수 있습니다. 보안 팀은 해석 정책과 연결 정책을 모두 검증해야 합니다.
AI 에이전트 샌드박스에 인터넷 접근이 없어야 하나요?
항상 그런 것은 아닙니다. 많은 유용한 에이전트 작업에는 패키지 레지스트리, 공개 문서, API 또는 브라우저 접근이 필요합니다. 더 안전한 목표는 최소한의 설명 가능한 이그레스입니다. 작업에 필요한 것은 허용하고, 필요하지 않은 것은 거부하며, 허용 및 거부 활동을 모두 기록하는 것입니다.
패키지 설치는 일반 네트워크 접근과 동일한가요?
아니요. 패키지 설치는 레지스트리, 의존성 해석, 아티팩트 다운로드, 때로는 설치 시 스크립트를 포함하기 때문에 별도 정책이 필요합니다. 팀은 승인된 캐시를 통한 패키지 가져오기는 허용하면서 임의 런타임 이그레스를 거부할 수 있습니다.
DNS 위험에 가장 중요한 로그는 무엇인가요?
가장 유용한 로그는 DNS 쿼리를 특정 샌드박스, 명령, 시간, 사용자 또는 에이전트 워크플로, 정책 결정에 연결합니다. 거부된 조회 로그는 통제가 실제로 작동했는지 보여주기 때문에 특히 중요합니다.
샌드박스 제공자가 데이터 유출이 없음을 보장할 수 있나요?
절대적 보장에는 주의하십시오. 제공자는 격리, 네트워크 통제, 로깅, 구성 옵션을 제공할 수 있지만, 최종 위험은 워크로드 설계, 비밀, 데이터 배치, 아웃바운드 정책, 운영 모니터링에 따라 달라집니다.
