코딩 에이전트가 셸과 브라우저를 사용합니다. 컨테이너 하나를 띄우면 안전한 실행 환경이 되는가요?

컨테이너는 격리 수단 중 하나지만 파일·네트워크·자격 증명·커널·자원 제한의 전체 안전성을 자동 보장하지 않습니다. 어떤 비신뢰 코드를 실행하고 무엇을 보호해야 하는지 위협 모델을 정한 뒤 격리 경계를 설계하겠습니다. 에이전트가 만든 코드뿐 아니라 저장소의 빌드 스크립트와 의존성 설치도 코드를 실행한다는 점을 포함해야 합니다.

호스트와 비밀값의 접근을 줄입니다

작업에 필요한 저장소만 제한적으로 마운트하고 홈 디렉터리·SSH 키·클라우드 자격 증명·컨테이너 관리 소켓을 노출하지 않습니다. 권한 상승 가능한 실행 옵션과 불필요한 시스템 capability를 제거하고, 위험 수준에 따라 더 강한 VM·microVM 경계를 검토합니다. 읽기 전용 마운트라도 그 파일을 네트워크로 전송할 수 있으면 기밀성은 보호되지 않으므로 파일과 통신 정책을 함께 봅니다.

네트워크는 필요한 패키지 저장소·테스트 API 등으로 제한하고 내부 metadata endpoint와 관리망 접근을 막습니다. 허용된 도메인도 사용자별 경로와 업로드 기능으로 유출 통로가 될 수 있어 목적지 이름만으로 충분하지 않을 수 있습니다. 비밀값이 꼭 필요한 테스트는 짧은 수명·최소 범위 자격을 실행기에만 주고 로그·모델 문맥·산출물에서 제거합니다.

자원과 수명을 제한합니다

CPU·메모리·디스크·프로세스 수·실행 시간을 제한해야 무한 루프나 대량 출력이 host를 고갈시키지 않습니다. 에이전트의 대화 deadline과 실행 프로세스의 종료는 별개이므로 자식 프로세스까지 종료·회수하는 구조를 둡니다. 작업별 파일 시스템과 캐시를 분리해 이전 과제의 정답·비밀·변경이 다음 과제로 새지 않게 합니다. 공유 캐시를 쓰면 신뢰할 수 있는 패키지와 사용자 데이터를 구분해야 합니다.

테스트에서는 허용 파일 읽기와 금지 경로, 외부 전송, 권한 상승 시도, 프로세스 잔존, 디스크 포화를 격리된 범위에서 확인합니다. sandbox 안의 작업이 성공해도 실제 운영 데이터 변경이나 게시 권한을 얻은 것은 아닙니다. 검증 산출물을 검토한 뒤 별도 승인된 경로로 반영합니다. 좋은 sandbox는 '아무 일도 못 하는 환경'이 아니라 필요한 실험은 가능하고 잘못된 행동의 영향을 제한하는 환경입니다.

실행 사례로 확인합니다

작업이 끝난 뒤 산출물을 host로 복사할 때도 경계를 유지합니다. 생성된 실행 파일·스크립트·압축파일이 있다고 자동 실행하거나 임의 경로로 풀지 않고 허용 파일과 크기·경로를 검사합니다. 평가 환경에서는 정답 파일과 채점기를 에이전트가 수정할 수 없는 별도 영역에 두어 결과 조작을 막습니다. 공유 패키지 캐시를 제공한다면 쓰기 권한과 출처 검증을 제한하고, 한 작업이 오염시킨 항목을 다른 작업이 신뢰해 실행하지 않게 합니다. 격리는 실행 중뿐 아니라 입력 반입·결과 반출·캐시 재사용의 전체 수명에서 검증해야 합니다. 필요한 기능만 열어 놓고 허용한 행동이 실제로 가능한지도 정상 테스트로 확인하겠습니다.