코딩 에이전트를 샌드박스에서 실행하려면 에이전트에 범위가 지정된 저장소 작업 공간, 통제된 터미널 실행 경로, 명시적인 파일 권한, 네트워크 및 패키지 설치 정책, 격리된 비밀 정보, 명령 로그, 아티팩트, 그리고 병합 또는 배포 전에 고위험 변경 사항에 대한 명확한 승인 경로를 제공해야 합니다. 이 패턴은 에이전트가 코드엑스 스타일이든, IDE 연결형이든, CI 트리거형이든, 또는 자체 개발자 플랫폼에 내장되어 있든 관계없이 동일하게 작동합니다. 모델은 계획을 세우고 편집할 수 있지만, 샌드박스는 무엇을 건드릴 수 있는지, 무엇을 실행할 수 있는지, 무엇을 가져올 수 있는지, 그리고 검토자가 어떤 증거를 받을지 결정합니다.
코딩 에이전트 샌드박스란 무엇인가요?
코딩 에이전트 샌드박스는 AI 시스템이 코드를 검사하고, 파일을 편집하고, 터미널 명령을 실행하고, 정책이 허용할 때 종속성을 설치하고, 테스트를 실행하고, 미리보기 서버를 시작하고, 검토 가능한 diff를 반환할 수 있지만 개발자의 머신이나 프로덕션 환경에 대한 광범위한 액세스 권한은 부여하지 않는 격리된 런타임입니다.
중요한 변화는 샌드박스가 단순히 모델을 감싼 채팅 래퍼가 아니라는 점입니다. 샌드박스는 작업의 운영 경계입니다. 모델은 작업을 제안하고, 샌드박스는 작업 공간, 도구, 권한 및 증거 추적을 적용합니다.
간단한 코드 어시스턴트의 경우 로컬 체크아웃과 수동 복사-붙여넣기로 충분할 수 있습니다. 명령을 실행하거나 여러 단계를 계속할 수 있는 에이전트의 경우 더 강력한 경계가 필요합니다.
- 각 작업 또는 세션에 대한 전용 작업 공간.
- 알려진 저장소 상태 및 브랜치.
- 위험한 작업에 대한 승인이 필요한 명령 실행 인터페이스.
npm,pip,cargo,apt및 유사한 도구에 대한 패키지 설치 정책.- 레지스트리, 문서, API 및 미리보기 액세스를 위한 네트워크 이그레스 규칙.
- 작업 범위로 지정되고 가능한 경우 로그에서 숨겨진 비밀 정보.
- 캡처된 stdout, stderr, 종료 코드, 파일 변경 사항, 생성된 아티팩트 및 미리보기 URL.
- 병합, 배포 또는 외부 릴리스 전의 검토 게이트.
이것이 "샌드박스에서 코드엑스 실행"을 로컬 CLI 습관이 아닌 인프라 패턴으로 이해해야 하는 이유입니다. 코드엑스 CLI 자체는 터미널 워크플로를 통해 실행되는 코딩 에이전트로 문서화되어 있으며, 이를 팀, CI 시스템 또는 제품 워크플로에서 운영할 때 주변 실행 환경이 제어 평면이 됩니다. Novita의 자사 Codex Agent 템플릿은 이제 개념적 가능성으로 남겨두지 않고 Novita Sandbox 내에서 해당 패턴을 구체적으로 구현합니다.
코딩 에이전트 샌드박스 아키텍처
가장 깔끔한 아키텍처는 모델 루프를 실행 경계와 분리합니다.
| 계층 | 책임 | 답변해야 할 질문 |
|---|---|---|
| 에이전트 인터페이스 | 사용자 의도를 계획, 파일 편집, 도구 호출 및 검토 요약으로 변환 | 어떤 모델 또는 코딩 에이전트가 사용됩니까? 프롬프트, 컨텍스트 및 도구 스키마는 어떻게 관리됩니까? |
| 작업 공간 관리자 | 샌드박스 생성, 저장소 체크아웃, 브랜치 설정, 허용된 파일 마운트 | 각 작업이 격리됩니까? 기본 커밋이 알려져 있습니까? 작업 공간을 재설정할 수 있습니까? |
| 터미널 실행기 | 승인된 명령을 실행하고 결과를 에이전트로 스트리밍 | 어떤 명령이 자동으로 허용되고, 승인이 필요하며, 차단됩니까? |
| 정책 계층 | 파일 시스템 범위, 비밀 정보, 네트워크 이그레스, 패키지 설치, 런타임 제한 및 정리 제어 | 에이전트가 패키지를 가져올 수 있습니까? 공개 인터넷을 호출할 수 있습니까? 자격 증명을 읽을 수 있습니까? |
| 증거 계층 | 로그, diff, 테스트 결과, 미리보기 및 아티팩트 저장 | 검토자가 모델의 요약을 신뢰하지 않고도 무슨 일이 일어났는지 재구성할 수 있습니까? |
| 검토 게이트 | 병합, 게시 또는 배포 전에 사람 또는 신뢰할 수 있는 자동화 단계 필요 | 누가 위험한 변경 사항을 승인합니까? 먼저 어떤 검사가 통과되어야 합니까? |
실제로 단일 플랫폼이 여러 계층을 결합할 수 있습니다. 아키텍처는 여전히 중요합니다. 이는 제품 선택을 정직하게 유지하기 때문입니다. 도구가 에이전트에 터미널을 제공하지만 명령 로그, 파일 diff 또는 이그레스 정책을 표시할 수 없다면 프로토타이핑에는 편리할 수 있지만 프로덕션 검토에는 부족할 수 있습니다.
코딩 에이전트 샌드박스에서 터미널 액세스는 어떻게 작동해야 하나요?
터미널은 코딩 에이전트가 운영상 유용해지고 운영상 위험해지는 곳입니다. 테스트를 실행하고, 에셋을 빌드하고, 생성된 파일을 검사하고, 로컬 서버를 시작하고, 오류를 진단할 수 있습니다. 또한 파일을 삭제하고, 환경 변수를 유출하고, 예상치 못한 설치 스크립트를 실행하거나, 많은 컴퓨팅 리소스를 소비할 수도 있습니다.
좋은 터미널 모델은 세 부분으로 구성됩니다.
첫째, 명령 클래스를 정의합니다. ls, sed, rg, git diff 및 테스트 상태 명령과 같은 안전한 읽기 전용 명령은 종종 자동으로 실행될 수 있습니다. npm test, pytest, cargo test, npm run build와 같은 빌드 및 테스트 명령은 시간 제한과 함께 허용될 수 있습니다. rm -rf, git push, gh pr merge, 배포 CLI, 패키지 게시, 데이터베이스 마이그레이션 또는 클라우드 리소스 변경과 같은 파괴적이거나 외부 영향이 있는 명령은 명시적인 승인이 필요하거나 완전히 차단되어야 합니다.
둘째, 결과를 구조화하여 스트리밍합니다. 에이전트와 검토자 모두 명령, 작업 디렉터리, 시작 시간, 종료 코드, stdout, stderr, 시간 초과 상태 및 잘린 출력 정책을 확인할 수 있어야 합니다. 터미널 스크린샷만으로는 충분하지 않습니다. 시스템은 기계가 읽을 수 있는 로그를 보존해야 합니다.
셋째, 장기 실행 세션을 의도적으로 처리합니다. 코딩 에이전트는 종종 백그라운드 개발 서버, watcher, 브라우저 자동화 프로세스 또는 통합 테스트 스택이 필요합니다. 장기 실행 프로세스를 핸들이 있는 리소스로 취급합니다. 시작하고, 로그를 스트리밍하고, 필요한 미리보기 포트만 노출하고, 정리 중에 중지합니다. 백그라운드 프로세스가 채팅 세션의 추적되지 않은 부작용이 되도록 두지 마십시오.
에이전트 변경을 위한 저장소 격리 및 브랜치 제어
저장소 상태는 검토 가능한 코딩 에이전트 워크플로의 백본입니다. 사용자가 명시적으로 해당 모드를 선택하지 않는 한 에이전트는 알 수 없는 로컬 편집이 있는 모호한 폴더에서 작업해서는 안 됩니다.
팀 워크플로의 경우 알려진 저장소 URL, 기본 브랜치 및 커밋 SHA로 각 작업을 시작합니다. 작업 브랜치 또는 분리된 작업 공간을 만듭니다. 사용자 변경 사항과 에이전트 변경 사항을 분리하고 검토 전에 정확한 diff를 캡처합니다. 샌드박스가 영구 세션을 지원하는 경우 작업 공간을 의도적으로 유지하고, 우발적인 프로세스 상태에 의존하지 마십시오.
기본 패턴은 다음과 같습니다.
task-123에 대한 격리된 작업 공간을 만듭니다.main@<base_sha>에서 저장소를 체크아웃합니다.agent/task-123브랜치를 만듭니다.- 정책에 따라 종속성 설치를 실행합니다.
- 에이전트가 검사, 편집, 테스트 및 반복할 수 있도록 합니다.
- git diff, 테스트 출력, 생성된 아티팩트 및 미리보기 URL을 캡처합니다.
- 풀 리퀘스트를 열거나 패치를 사람 검토자에게 전달합니다.
- 보존 정책에 따라 작업 공간을 해체하거나 보관합니다.
핵심 세부 사항은 6단계입니다. 유용한 코딩 에이전트는 "고쳤습니다"라고만 말하지 않습니다. 변경된 파일, 각 변경 이유, 실행된 검증, 실패한 내용 및 아직 확인되지 않은 내용을 반환합니다.
샌드박스 코딩 에이전트를 위한 명령, 패키지 및 네트워크 정책
패키지 설치는 코딩 에이전트 샌드박싱에서 가장 어려운 부분 중 하나입니다. 많은 실제 작업에는 종속성이 필요합니다. 또한 많은 공급망 사고는 종속성 가져오기, 설치 후 스크립트 또는 불투명한 바이너리에서 시작됩니다.
실용적인 정책은 "패키지를 절대 설치하지 마십시오"가 아닙니다. "알려진 경로를 통해서만 로깅 및 범위 지정과 함께 패키지를 설치하십시오"입니다.
| 제어 | 실용적인 구현 |
|---|---|
| 패키지 관리자 | 언어 및 저장소 유형별로 사용 가능한 패키지 관리자를 결정합니다. |
| 레지스트리 액세스 | 승인된 레지스트리를 허용하고, 작업에 필요하지 않은 경우 임의의 패키지 소스를 차단합니다. |
| 잠금 파일 | 기존 잠금 파일과 재현 가능한 설치 명령을 선호합니다. |
| 설치 후 스크립트 | 라이프사이클 스크립트가 자동으로 실행될 수 있는지 또는 승인이 필요한지 결정합니다. |
| 시스템 패키지 | apt, brew 및 OS 패키지 설치는 프로젝트 종속성 설치보다 위험도가 높은 것으로 취급합니다. |
| 캐시 | 속도와 재현성이 필요할 때 통제된 패키지 캐시를 사용합니다. |
| 로깅 | 패키지 이름, 버전, 레지스트리 URL, 가능한 경우 체크섬 및 설치 출력을 저장합니다. |
네트워크 정책도 마찬가지로 명시적이어야 합니다. 코딩 에이전트는 공개 문서를 읽거나, 스테이징 API를 호출하거나, 패키지를 다운로드하거나, 로컬 미리보기를 노출해야 할 수 있습니다. 이는 제한 없는 인터넷 액세스와 다릅니다. 아웃바운드 패키지 가져오기, 웹 검색, API 호출, 웹훅 전달 및 미리보기 수신을 분리하십시오. 제품이 민감한 코드나 데이터를 처리하는 경우 DNS, 프록시 로그 및 레지스트리 미러가 HTTP 트래픽과 동일한 정책으로 적용되는지 문의하십시오.
에이전트 작업 공간을 위한 비밀 정보, 로그 및 감사 추적
비밀 정보는 가장 작은 유용한 표면으로 범위를 지정해야 합니다. 코딩 에이전트는 일반적으로 프로덕션 자격 증명이 필요하지 않습니다. 읽기 전용 Git 토큰, 패키지 레지스트리 토큰, 스테이징 API 키 또는 미리보기 배포 토큰이 필요할 수 있습니다. 각각은 작업 범위로 지정되고, 가능한 경우 시간 제한이 있으며, 필요하지 않은 명령에는 사용할 수 없어야 합니다.
작업이 실제로 필요하지 않는 한 에이전트가 읽을 수 있는 파일에 비밀 정보를 배치하지 마십시오. 중개 액세스를 선호합니다. 샌드박스가 작업을 수행할 수 있지만 모델은 원시 자격 증명을 보지 않습니다. 환경 변수가 필요한 경우 로그는 알려진 비밀 패턴을 수정해야 하며, 검토자 아티팩트에는 전체 환경 덤프가 포함되어서는 안 됩니다.
감사 추적의 경우 최종 패치 이상을 저장하십시오.
- 사용자 요청 및 작업 메타데이터.
- 저장소 URL, 기본 커밋, 브랜치 및 최종 커밋 또는 diff.
- 요청, 승인, 차단 및 실행된 명령.
- 명령 출력, 종료 코드 및 시간 초과.
- 플랫폼이 캡처할 수 있는 경우 파일 읽기 및 쓰기.
- 정책이 지원하는 수준의 네트워크 및 패키지 가져오기 기록.
- 미리보기 URL 및 생성된 아티팩트 경로.
- 사람 승인 및 병합 결정.
이는 관료주의가 아닙니다. 검토자가 실제 수정과 그럴듯한 이야기를 구별하는 방법입니다.
병합 전 diff, 미리보기 및 검토 게이트
코딩 에이전트의 가장 유용한 출력은 검토 가능한 변경 세트입니다. 즉, 샌드박스는 신중한 엔지니어가 풀 리퀘스트에서 기대하는 것과 동일한 아티팩트를 생성해야 합니다.
- 집중된 diff.
- 실행된 테스트 또는 빌드 명령.
- 남아 있는 실패.
- UI 또는 생성된 에셋이 변경된 경우 스크린샷, 미리보기 URL 또는 다운로드 가능한 파일.
- 의도된 동작 변경에 대한 간단한 설명.
조직이 해당 정확한 저장소 및 위험 수준에 대해 별도의 신뢰할 수 있는 자동화 정책을 구축하지 않은 한 최종 병합 또는 배포는 사람이 제어하는 게이트 뒤에 두십시오. 사람 검토는 변경 사항이 인증, 청구, 데이터 액세스, 네트워크 호출, 인프라, 종속성 버전, 생성된 마이그레이션 또는 사용자에게 표시되는 콘텐츠에 영향을 미칠 때 특히 중요합니다.
미리보기 처리는 자체 규칙이 필요합니다. 검토에 필요한 서비스와 포트만 노출하십시오. 웹 애플리케이션을 시작하는 샌드박스는 검토자에게 범위가 지정된 미리보기 URL을 제공해야 하며, 작업 공간에 대한 광범위한 네트워크 액세스를 제공해서는 안 됩니다.
장기 실행 에이전트 세션을 위한 정리 및 재설정 전략
모든 샌드박스에는 수명 주기가 필요합니다. 수명 주기가 없으면 장기 실행 코딩 에이전트 인프라는 오래된 작업 공간, 유출된 로그 및 계속 실행 중인 프로세스의 더미가 됩니다.
짧은 작업의 경우 임시 모델이 잘 작동합니다. 샌드박스를 만들고, 작업을 실행하고, 아티팩트를 추출한 다음, 파기합니다. 더 큰 작업의 경우 지속성이 유용할 수 있습니다. 에이전트가 일시 중지하고, 검토를 기다리고, 동일한 브랜치에서 다시 시작하거나, 검토 세션 중에 개발 서버를 계속 실행해야 할 수 있습니다. 지속성은 소유자, 만료 및 보존 규칙이 있는 명시적인 제품 기능이어야 합니다.
다음에 대한 정리를 정의하십시오.
- 백그라운드 프로세스 및 열린 포트.
- 임시 파일 및 빌드 출력.
- 패키지 캐시 및 다운로드된 아카이브.
- 작업 범위의 비밀 정보.
- 로그 및 아티팩트.
- 대체된 브랜치 또는 작업 트리.
재설정도 마찬가지로 중요합니다. 검토자는 기본 커밋 또는 최종 브랜치에서 에이전트의 검증을 다시 실행할 수 있어야 합니다. 장기 실행 세션 내의 보이지 않는 상태로 인해 결과만 작동하는 경우 워크플로를 신뢰하기 어렵습니다.
Novita Agent Sandbox가 이 워크플로에 적합한 위치
Novita Agent Sandbox는 코드 실행, 브라우저 자동화, 컴퓨터 사용 스타일 워크플로, 데이터 분석, 평가 및 장기 실행 에이전트 워크플로에 격리된 런타임이 필요한 에이전트 인프라를 위해 설계되었습니다. Novita Agent Sandbox 문서는 이 제품을 에이전트 워크로드를 실행하기 위한 상태 저장 환경으로 설명하며, 샌드박스 수명 주기, 파일, 명령, 브라우저 세션 및 관련 워크플로 프리미티브 작업을 위한 SDK 및 CLI 경로를 제공합니다. Novita는 이제 자사 Codex Agent 템플릿도 문서화하고 있으며, 이는 “샌드박스에서 코드엑스 실행” 아이디어를 구체적인 설정 세부 정보가 포함된 출시된 워크플로로 전환하기 때문에 중요합니다.
이미 Novita AI 모델 API를 사용하는 팀의 경우 샌드박스 계층은 모델 추론과 작업 실행 간의 격차를 줄일 수 있습니다. 모델은 추론하고, 도구를 호출하고, 코드 변경을 계획할 수 있습니다. 샌드박스는 해당 작업이 실행, 기록, 미리보기 및 검토되는 격리된 작업 공간을 제공할 수 있습니다.
자사 Codex 템플릿이 실제로 변경하는 사항
새로운 Codex 템플릿은 정책의 필요성을 제거하지는 않지만, 프로덕션을 염두에 둔 Codex 워크플로가 이 문서의 앞부분에서 설명한 제어에 어떻게 매핑되는지 명확히 합니다.
codex exec는 대화형 터미널 세션보다는 대기 중인 작업, 에이전트 오케스트레이터 및 검토 가능한 작업 실행에 더 적합한 비대화형 실행 모드를 제공합니다.--full-auto는 샌드박스 자체가 신뢰할 수 있는 승인 경계인 경우에만 의미가 있습니다. 즉, 파일 액세스, 네트워크 이그레스, 저장소 범위 및 정리가 Codex 주변의 런타임에 의해 이미 제한된 경우 자동 승인을 정당화하기가 더 쉽습니다.--skip-git-repo-check는 부트스트래핑 작업에 유용하지만, 실제 엔지니어링 작업을 위한 더 강력한 패턴은 여전히 특정 저장소를 샌드박스로 복제하고 해당 통제된 체크아웃에서 Codex를 실행하는 것입니다.- 샌드박스 내부에
~/.codex/auth.json및~/.codex/config.toml을 작성하면 공급자 및 모델 사용자 지정이 개발자 노트북에서 빌린 것이 아니라 격리된 환경의 일부가 됩니다. sandbox.git.clone은 저장소 격리 및 브랜치 제어와 자연스럽게 맞습니다. 작업에 필요한 저장소만 가져오고, 해당 범위의 디렉터리에서 에이전트를 실행하며, 호스트 머신을 루프 밖으로 유지합니다.--json, 캡처된thread_id및codex exec resume <thread_id>를 통한 세션 재개는 지속성과 감사 가능성이 동일한 것이 아님을 가장하지 않으면서 장기 실행 작업을 처리하는 실용적인 방법입니다. 재개된 세션에 대한 명시적인 보존, 로그 캡처 및 소유권 규칙이 여전히 필요합니다.
이것이 문서와 블로그 지침 사이의 유용한 분할입니다. 문서는 운영 순서를 보여줍니다. 워크플로 결정은 이러한 메커니즘을 더 안전한 패턴에 대한 증거로 취급하는 것입니다. 경계가 지정된 작업 공간 내에서 Codex를 실행하고, 자동 승인을 신뢰할 수 있는 샌드박스로 제한하고, 저장소 상태를 의도적으로 보존하고, 재개된 세션을 불투명한 에이전트 메모리가 아닌 검토자에게 표시되도록 합니다.
워크플로를 설계할 때 보수적인 제품 경계를 사용하십시오.
- Novita Agent Sandbox를 포괄적인 보안 보장이 아닌 실행 환경으로 취급하십시오.
- 비밀 정보, 패키지 설치, 이그레스 및 게시 작업을 자체 정책 뒤에 두십시오.
- 프로덕션 자동화에 하드 코딩하기 전에 현재 SDK, CLI, 가격 및 계정 제한 세부 정보를 Novita 문서에서 확인하십시오.
- 프로덕션에서 샌드박스에 의존하기 전에 격리 경계, 타사 에이전트 호환성 및 규정 준수 요구 사항을 자체 정책에 대해 평가하십시오.
이러한 분리는 에이전트 계층이 변경되더라도 구현 지침을 유용하게 유지합니다. 동일한 샌드박스 제어 질문을 유지하면서 Codex 스타일 에이전트, 내부 코딩 에이전트, 브라우저 에이전트 또는 평가 워커를 사용할 수 있습니다.
코딩 에이전트 샌드박스 구현 체크리스트
코딩 에이전트 샌드박스를 프로토타입 이상으로 이동하기 전에 이 체크리스트를 사용하십시오.
| 영역 | 최소 프로덕션 질문 |
|---|---|
| 작업 공간 | 각 작업에 범위가 지정된 파일 시스템과 알려진 저장소 기본 커밋이 있습니까? |
| 브랜칭 | 에이전트 변경 사항이 검토자가 검사할 수 있는 브랜치 또는 패치에 격리되어 있습니까? |
| 터미널 | 명령이 작업 디렉터리, 출력, 종료 코드 및 시간 초과와 함께 기록됩니까? |
| 승인 | 어떤 명령이 자동으로 실행되고, 승인이 필요하며, 차단됩니까? |
| 패키지 | 종속성 설치가 재현 가능하고 기록됩니까? |
| 네트워크 | 이그레스가 패키지 가져오기, 문서 검색, API 호출 및 미리보기 액세스로 분리되어 있습니까? |
| 비밀 정보 | 자격 증명이 작업 범위로 지정되고 로그에서 수정됩니까? |
| 미리보기 | 미리보기 포트가 명시적이고 종료하기 쉬운가요? |
| 아티팩트 | 생성된 파일, 스크린샷, 보고서 및 로그가 검토에 첨부됩니까? |
| 지속성 | 세션 일시 중지/재개가 소유자 및 만료와 함께 의도적입니까? |
| 정리 | 프로세스, 포트, 임시 파일, 비밀 정보 및 오래된 작업 공간이 제거됩니까? |
| 검토 | 위험한 변경 사항에 대해 병합, 게시 또는 배포를 사람이 승인합니까? |
현재 설정이 이러한 질문 중 여러 개에 답할 수 없는 경우 워크플로를 프로토타입 레인에 유지하십시오. 에이전트는 여전히 유용할 수 있지만 광범위한 저장소, 네트워크 또는 자격 증명 액세스 권한을 받아서는 안 됩니다.
FAQ
클라우드 샌드박스 내에서 코드엑스 자체를 실행할 수 있나요?
예. Novita는 이제 Novita Sandbox를 위한 자사 Codex Agent 템플릿을 문서화하고 있으며, 격리된 환경에서 codex exec를 실행하고, 저장소를 샌드박스로 복제하고, ~/.codex/ 내에서 Codex 공급자 설정을 사용자 지정하고, 캡처된 thread_id로 이전 세션을 재개하는 릴리스된 흐름을 제공합니다. 주의 사항은 여전히 계정 및 설정 수준에서 적용됩니다. 모든 로컬 Codex 워크플로가 변경되지 않고 전송된다고 가정하지 말고 자체 환경에 대한 정확한 인증 경로, 저장소 자격 증명, 런타임 제한 및 정책 제어를 확인하십시오.
Docker가 코딩 에이전트 샌드박스에 충분합니까?
Docker는 로컬 개발, CI 작업 및 반복 가능한 환경에 유용할 수 있지만, "충분함"은 위협 모델에 따라 다릅니다. 커널을 공유하는 것, 어떤 파일 마운트가 있는지, 네트워크 이그레스가 어떻게 제어되는지, 비밀 정보가 컨테이너에 노출되는지, 탈출 또는 종속성 손상이 어떻게 처리되는지 문의하십시오. 민감한 워크로드의 경우 보안 팀은 종종 더 강력한 격리 경계와 더 엄격한 이그레스 제어를 평가합니다.
코딩 에이전트에 인터넷 액세스 권한이 있어야 합니까?
작업에 필요하고 설명할 수 있는 정책을 통해서만 허용하십시오. 문서 조회, 패키지 레지스트리 액세스, 스테이징 API 호출 및 임의 검색은 서로 다른 권한입니다. 에이전트가 가져온 내용을 기록하고, 패키지 설치를 재현 가능하게 유지하며, 일반적인 코딩 세션에 프로덕션 네트워크 액세스 권한을 부여하지 마십시오.
검토자는 에이전트가 생성한 코드를 병합하기 전에 무엇을 확인해야 합니까?
diff, 실행된 명령, 테스트/빌드 출력, 종속성 변경 사항, 생성된 아티팩트, 미리보기 동작 및 건너뛴 검증을 검토하십시오. 인증, 권한, 데이터 처리, 네트워크 호출, 마이그레이션, 설치 스크립트 및 비밀 정보에 특히 주의하십시오.
Novita는 코딩 에이전트 샌드박스에 어떻게 도움이 됩니까?
Novita Agent Sandbox는 코드 실행, 브라우저 자동화, 컴퓨터 사용 스타일 작업, 데이터 분석, 평가 및 장기 실행 워크플로와 같은 워크로드를 위한 격리된 에이전트 런타임을 제공합니다. 자사 Codex 템플릿을 사용하면 해당 런타임은 비대화형 실행, 저장소 범위의 체크아웃, 사용자 지정 공급자 구성 및 세션 재개와 같은 Codex 관련 흐름도 호스팅할 수 있습니다. 이러한 메커니즘을 명시적인 저장소, 명령, 패키지, 네트워크, 비밀 정보 및 검토 정책과 결합하여 샌드박스가 일반적인 엔지니어링 제어를 우회하는 무인 지름길이 아닌 실행 경계로 유지되도록 하십시오.
