코딩 에이전트 샌드박스는 에이전트가 생성한 명령어와 코드 변경이 파일, 프로세스, 네트워크 접근, 시크릿, 로그, 리뷰 아티팩트를 제어할 수 있는 범위가 정해진 작업 공간에서 실행되도록 합니다. 실용적인 목표는 임의로 생성된 코드가 무해한 척하는 것이 아닙니다. 목표는 에이전트를 일회용 개발 머신, 명확한 경계, 관찰 가능한 실행, 그리고 프로덕션에 반영되기 전 사람의 승인 절차를 갖춘 신뢰할 수 없는 기여자처럼 대우하는 것입니다.
코딩 에이전트 샌드박스가 격리해야 할 것
코딩 에이전트는 레포지토리를 검사하고, 파일을 편집하고, 테스트를 실행하고, 의존성을 설치하고, 패치를 반환할 수 있을 때 유용해집니다. 이러한 작업들은 환경을 위험하게 만드는 요소이기도 합니다. 프롬프트 인젝션을 통한 의존성 설치, 파괴적인 셸 명령어, 또는 실수로 노출된 시크릿은 잘못된 텍스트 응답보다 더 큰 피해를 초래할 수 있습니다.
코딩 에이전트가 접근할 수 있는 리소스를 중심으로 샌드박스를 설계하세요:
| 표면 | 제어할 내용 | 중요한 이유 |
|---|---|---|
| 레포지토리 체크아웃 | 브랜치, 커밋 SHA, 쓰기 범위, 서브모듈, 생성된 파일 | 에이전트가 잘못된 코드베이스를 변경하거나 리뷰 경로 외부에 변경 사항을 숨기는 것을 방지합니다. |
| 파일시스템 | 작업 공간 루트, 마운트된 파일, 무시된 경로, 출력 디렉터리 | 호스트 파일, 자격 증명, 캐시, 관련 없는 프로젝트에 대한 광범위한 접근을 방지합니다. |
| 셸 실행 | 허용된 명령어, 작업 디렉터리, 타임아웃, 출력 캡처, 승인 게이트 | 빌드 및 테스트에 충분한 권한을 제공하면서 위험도가 높은 작업을 제한합니다. |
| 패키지 설치 | 레지스트리 정책, lockfile, 고정된 버전, 캐시 전략, 설치 로그 | 에이전트가 새 의존성을 요청할 때 공급망 모호성을 줄입니다. |
| 네트워크 접근 | 기본 이그레스, 허용 목록, DNS 동작, API 대상, 패키지 미러 | 의도치 않은 데이터 이동을 방지하고 외부 호출을 검토 가능하게 만듭니다. |
| 시크릿 | 범위가 지정된 자격 증명, 단기 토큰, 마스킹, 기본 프로덕션 키 없음 | 에이전트가 필요하지 않은 자격 증명을 읽거나 유출하는 것을 방지합니다. |
| 아티팩트 | 테스트 보고서, 빌드 출력물, 스크린샷, 생성된 파일, 로그 | 에이전트의 요약에만 의존하지 않고 검토자에게 증거를 제공합니다. |
| 라이프사이클 | 일시 중지, 재개, 스냅샷, 초기화, 정리, 보존 정책 | 에이전트 실행을 장기간 지속되는 불명확한 머신이 아닌 반복 가능하고 일회용으로 만듭니다. |
이 표를 설계 체크리스트로 사용하세요. 샌드박스가 컨테이너, 가상 머신, 마이크로VM, 관리형 클라우드 샌드박스 또는 내부 러너 위에 구축되었는지 여부에 관계없이 적용됩니다. 정확한 격리 계층도 중요하지만, 그 계층을 둘러싼 운영 제어도 마찬가지로 중요합니다.
에이전트가 생성한 코드 실행을 위한 참조 워크플로우
가장 안전한 코딩 에이전트 워크플로우는 챗봇보다는 통제된 풀 리퀘스트 파이프라인에 더 가깝습니다.
- 작업을 위한 새 작업 공간을 만듭니다.
- 특정 브랜치 또는 커밋에서 대상 레포지토리를 체크아웃합니다.
- 에이전트에게 좁은 범위의 작업, 테스트 명령어, 파일 범위를 제공합니다.
- 에이전트가 파일을 검사하고 계획을 제안하도록 합니다.
- 위험도가 낮은 읽기 전용 명령어는 자동으로 실행합니다.
- 위험한 명령어에 대해서는 승인 또는 정책 확인을 요구합니다.
- 모든 명령어, 종료 코드, stdout, stderr, 파일 쓰기, 생성된 아티팩트를 캡처합니다.
- 샌드박스 내에서 테스트, 타입 검사, 린터, 빌드 또는 대상 스크립트를 실행합니다.
- 패치, diff, 테스트 출력, 아티팩트 번들을 내보냅니다.
- 스냅샷이 의도적으로 저장되지 않은 경우 리뷰 후 작업 공간을 초기화하거나 삭제합니다.
중요한 세부 사항은 샌드박스가 단순히 코드를 실행하는 장소일 뿐만 아니라 증거 기록자라는 점입니다. 검토자는 다음 질문에 답할 수 있어야 합니다: 어떤 레포지토리가 체크아웃되었는지, 무엇이 변경되었는지, 어떤 명령어가 실행되었는지, 무엇이 실패했는지, 무엇이 통과했는지, 어떤 파일이 생성되었는지, 어떤 외부 리소스에 접촉했는지.
간단한 에이전트의 경우, 각 작업 주변에 정책 확인을 두고 이를 작업 큐로 구현할 수 있습니다. 더 강력한 에이전트의 경우 동일한 경계를 유지하되 제어 평면을 더 명시적으로 만듭니다: 하나의 구성 요소는 에이전트가 무엇을 요청할 수 있는지 결정하고, 하나의 구성 요소는 승인된 작업을 실행하며, 하나의 구성 요소는 실행을 기록합니다.
사용자 작업
-> 에이전트가 파일 읽기, 편집, 명령어 제안
-> 정책 계층이 각 작업 분류
-> 샌드박스가 승인된 작업 실행
-> 로그, diff, 아티팩트 캡처
-> 병합 또는 배포 전 사람이 패치 검토
이러한 분리는 모델이 위험한 작업에 대한 계획자이자 최종 권한이 되는 것을 방지합니다.
명령어 실행 전 보안 체크포인트
생성된 명령어가 잘못되었거나, 지나치게 광범위하거나, 레포지토리 콘텐츠의 영향을 받을 수 있다는 가정에서 시작하세요. 코딩 에이전트는 테스트 픽스처, README, 이슈 본문, 패키지 스크립트 또는 웹 페이지에서 악성 명령어를 읽을 수 있습니다. 샌드박스는 이러한 실패를 가시화하고 격리되도록 만들어야 합니다.
셸 실행 전에 명령어 클래스를 정의하세요:
| 명령어 클래스 | 예시 | 기본 정책 |
|---|---|---|
| 읽기 전용 검사 | pwd, ls, git status, rg, cat package.json |
일반적으로 허용 및 로깅. |
| 로컬 검증 | npm test, pytest, go test, cargo test |
타임아웃 및 출력 캡처와 함께 허용. |
| 빌드 또는 생성 | npm run build, 코드 생성, 문서 생성 |
출력 경로가 예상되는 경우 허용. |
| 의존성 변경 | 패키지 매니저 설치, lockfile 업데이트 | 정책 확인 또는 승인 필요. |
| 네트워크 명령어 | URL 가져오기, API 호출, 추가 레포지토리 클론 | 대상 정책 및 로깅 필요. |
| 파괴적 명령어 | 삭제, 강제 초기화, 디스크 정리, 광범위한 chmod/chown | 차단 또는 명시적인 사람 승인 필요. |
| 시크릿 접근 | env 파일 읽기, 자격 증명 저장소, 배포 설정 | 작업별로 범위가 지정되지 않으면 차단. |
완벽한 정적 분석기가 필요하지는 않습니다. 작업 디렉터리 제한, 명시적 거부 패턴, 명령어 타임아웃, 출력 크기 제한, 의존성을 변경하거나 자격 증명에 접근하거나 외부 호스트에 접촉하는 명령어에 대한 승인 프롬프트와 같은 간단한 제어만으로도 도움이 됩니다.
파일시스템 경계도 마찬가지로 구체적이어야 합니다. 레포지토리와 에이전트가 필요한 임시 디렉터리만 마운트하세요. 운영자의 홈 디렉터리, SSH 키, 클라우드 설정, 패키지 매니저 자격 증명, 브라우저 프로필 또는 프로덕션 환경 파일은 마운트하지 마세요. 속도를 위해 캐시가 필요한 경우 읽기 전용 또는 작업별 범위의 캐시를 명확한 보존 정책과 함께 사용하는 것이 좋습니다.
패키지 설치 및 네트워크 접근 처리 방법
패키지 설치는 유용하면서도 위험하기 때문에 코딩 에이전트 샌드박싱에서 가장 어려운 부분 중 하나입니다. 에이전트는 빌드를 재현하고 테스트를 실행해야 하지만, 설치 스크립트는 코드를 실행하고, 전이적 의존성을 가져오고, 외부 인프라에 접촉할 수 있습니다.
패키지 작업에 대해 더 엄격한 정책을 사용하세요:
- 자유 형식 의존성 해결보다 lockfile 기반 설치를 선호하세요.
- 패키지 매니저 명령어, 레지스트리 URL, 패키지 이름, 버전, lockfile 변경 사항을 로깅하세요.
- 가능한 경우 승인된 레지스트리 또는 미러를 통해 의존성 다운로드를 라우팅하세요.
- 새 의존성 추가는 검토가 필요한 코드 변경으로 취급하세요.
- 프로젝트가 명시적으로 필요로 하지 않는 한, 위험도가 높은 워크플로우에 대해 설치 스크립트를 차단하세요.
- 의존성 캐시를 시크릿 및 관련 없는 레포지토리와 분리하여 유지하세요.
네트워크 이그레스도 동일한 처리가 필요합니다. 코딩 에이전트는 패키지 레지스트리, API 문서, 브라우저 확인 또는 통합 테스트를 위해 인터넷 접근이 필요할 수 있습니다. 그렇다고 해서 제한 없는 아웃바운드 접근이 필요하다는 의미는 아닙니다.
최소한 기본값을 정의하세요:
| 네트워크 질문 | 더 안전한 기본값 |
|---|---|
| 샌드박스가 인터넷에 접근할 수 있습니까? | 작업에서 필요로 하지 않는 한 아니요. |
| 임의의 DNS 이름을 확인할 수 있습니까? | DNS 및 대상 호스트 제한 또는 로깅. |
| 프로덕션 API를 호출할 수 있습니까? | 기본적으로 스테이징 엔드포인트 또는 모의 서비스 사용. |
| 패키지 의존성을 가져올 수 있습니까? | 승인된 레지스트리, 미러, lockfile 사용. |
| 파일이나 로그를 업로드할 수 있습니까? | 대상이 예상되고 검토되지 않는 한 차단. |
이러한 제어가 데이터 유출이나 의존성 손상이 절대 발생할 수 없다는 보장이라고 설명하지 마세요. 현실적인 주장은 더 좁습니다: 정책, 격리, 로깅, 검토가 폭발 반경을 줄이고 패치가 신뢰되기 전에 위험한 행동을 더 쉽게 감지할 수 있게 합니다.
사람의 검토를 위한 Diff, 아티팩트 및 로그
사람의 검토는 샌드박스가 긴 채팅 기록이 아닌 간결한 리뷰 패키지를 생성할 때 가장 효과적입니다.
모든 실행에 대해 다음을 캡처하세요:
- 체크아웃에 사용된 레포지토리 URL, 브랜치 및 커밋 SHA.
- 작업 프롬프트 또는 이슈 요약.
- 읽은 파일과 쓴 파일.
- 모든 명령어, 작업 디렉터리, 시작 시간, 종료 시간, 종료 코드, stdout, stderr.
- 의존성 설치 명령어 및 lockfile 변경 사항.
- 테스트, 린트, 타입 검사, 빌드 결과.
- 스크린샷, 보고서, 커버리지, 바이너리, 미리보기 URL과 같은 생성된 아티팩트.
- 표준 패치 또는 풀 리퀘스트 형식의 최종 diff.
검토자는 먼저 diff를 검사한 다음 로그와 아티팩트를 사용하여 특정 질문에 답해야 합니다. 테스트가 실제로 실행되었습니까? 에이전트가 요청된 범위 밖의 파일을 수정했습니까? 의존성을 추가했습니까? 생성된 파일을 다시 작성했습니까? 네트워크 서비스를 호출했습니까? 크거나 민감한 아티팩트를 남겼습니까?
프로덕션 팀의 경우 리뷰 게이트를 명시적으로 만드세요:
- 에이전트는 패치를 제안할 수 있습니다.
- 샌드박스는 검증을 실행할 수 있습니다.
- 시스템은 풀 리퀘스트를 열 수 있습니다.
- 사람 또는 승인된 정책이 병합, 배포 또는 더 넓은 권한 부여 여부를 결정해야 합니다.
이 경계는 인프라, 결제, 인증, 배포 또는 고객 데이터 경로를 포함하는 레포지토리에 특히 중요합니다.
Novita Agent Sandbox가 적합한 위치
Novita Agent Sandbox는 에이전트가 코드를 실행하고, 의존성을 설치하고, 파일에 접근하고, 브라우저 워크플로우를 사용하고, 세션 간 실행 상태를 유지할 수 있는 격리된 상태 저장 실행 환경을 위해 설계되었습니다. Agent Sandbox 개요는 격리된 작업 실행을 위한 샌드박스, 준비된 환경을 위한 템플릿, 구성된 상태를 재사용하기 위한 스냅샷이라는 세 가지 핵심 구성 요소를 설명합니다.
코딩 에이전트 워크플로우의 경우 이러한 기본 요소는 제어된 개발 작업 공간에 자연스럽게 매핑됩니다:
| 코딩 에이전트 요구 사항 | 샌드박스 패턴 |
|---|---|
| 알려진 환경에서 시작 | 예상되는 런타임 및 도구가 있는 템플릿 사용. |
| 호스트와 분리된 상태에서 명령어 및 테스트 실행 | 샌드박스별 파일시스템 및 런타임 환경 내에서 실행. |
| 준비된 설정 재사용 | 승인된 의존성 또는 프로젝트 도구 설치 후 스냅샷 저장. |
| 장기 실행 에이전트 작업 디버그 | 워크플로우에 연속성이 필요할 때 세션 간 상태 유지. |
| 리뷰 후 정리 | 보존 정책에 따라 샌드박스 초기화, 중지 또는 폐기. |
제품 사용과 보안 정책은 분리하여 유지하세요. Novita Agent Sandbox는 코드 실행 에이전트를 위한 격리된 실행 환경을 제공할 수 있지만, 애플리케이션은 여전히 레포지토리 접근, 명령어 정책, 시크릿 범위, 네트워크 규칙, 아티팩트 보존 및 사람의 승인 게이트를 정의해야 합니다. 이러한 선택은 위협 모델에 따라 달라지며 공개 프로덕션 사용 전에 엔지니어링 및 보안 담당자가 검토해야 합니다.
실습 예제를 원하는 개발자는 Novita 가이드인 Novita Sandbox로 원격 코드 실행 MCP 서버 구축하기를 읽을 수도 있습니다. 제품 문서는 Novita Agent Sandbox 문서 및 SDK 및 CLI 설치 가이드에서 시작하세요.
FAQ
코딩 에이전트 샌드박스만으로 생성된 코드를 안전하게 만들 수 있습니까?
아니요. 샌드박스는 하나의 제어 계층입니다. 병합 또는 배포 전에 여전히 범위가 지정된 레포지토리 접근, 명령어 정책, 의존성 제어, 네트워크 제한, 시크릿 처리, 로그, 아티팩트 검토 및 사람의 승인이 필요합니다.
코딩 에이전트에 인터넷 접근 권한이 있어야 합니까?
작업에서 필요로 하는 경우에만 가능합니다. 많은 코드 리뷰, 리팩터링 및 테스트 워크플로우는 의존성이 준비된 후 일반적인 인터넷 접근 없이 실행될 수 있습니다. 인터넷 접근이 필요한 경우 대상을 로깅하고 허용 목록에 있는 패키지 레지스트리, 문서 사이트, 스테이징 API 또는 모의 서비스를 선호하세요.
에이전트가 프로덕션 시크릿을 받아야 합니까?
기본적으로 코딩 에이전트에 프로덕션 시크릿을 제공하지 마세요. 특정 작업에 대해 범위가 지정된 단기 자격 증명을 사용하고, 스테이징 서비스를 선호하며, 로그를 마스킹하고, 검토된 이유가 없는 한 레포지토리 작업 공간 밖에 시크릿 접근을 유지하세요.
에이전트 패치를 신뢰하기 전에 무엇을 검토해야 합니까?
diff, 변경된 의존성, 생성된 파일, 명령어 로그, 테스트 결과, 네트워크 활동 및 모든 아티팩트를 검토하세요. 인증, 권한 부여, 배포, 결제, 인프라, 데이터 접근 및 패키지 관리 변경 사항에 특히 주의하세요.
샌드박스는 언제 초기화되어야 합니까?
의도적으로 스냅샷을 저장하지 않는 한 각 작업 후에 작업 공간을 초기화하거나 삭제하세요. 영구 상태는 장기 실행 워크플로우에 유용하지만, 소유권, 보존 및 정리 규칙이 있는 의도적인 선택이어야 합니다.
