코딩 에이전트는 개발자 PC에서 실행될 때 강력합니다. 파일을 읽고, 테스트를 실행하고, 브랜치를 만들고, 패키지를 설치하고, 코드를 수정할 수 있습니다. 문제는 그 권한이 보통 “개발자 본인 권한”이라는 점입니다. 에이전트가 할 수 있는 일은 개발자가 할 수 있는 일과 거의 같습니다.
OpenAI는 2026년 5월 13일 “Building a safe, effective sandbox to enable Codex on Windows”라는 엔지니어링 글을 공개했습니다. 글의 출발점은 명확합니다. Windows용 Codex에 sandbox 구현이 없던 시기에는 사용자가 두 가지 나쁜 선택지 중 하나를 골라야 했습니다. 거의 모든 명령을 승인하거나, Full Access mode로 모든 명령을 제한 없이 허용하는 방식입니다.
이 글은 Windows 내부 구현 이야기이지만, 실제로는 모든 로컬 코딩 에이전트 운영에 적용되는 보안 가이드에 가깝습니다. 핵심 질문은 “에이전트가 빠르게 일하게 하면서도 어디까지 막을 것인가”입니다.
OpenAI 글은 Codex의 기본 모드를 이렇게 설명합니다. 파일은 넓게 읽을 수 있지만, 쓰기는 workspace 안으로 제한합니다. 네트워크 접근은 사용자가 명시적으로 원할 때만 허용합니다. 이런 제약을 자동으로 강제하려면 운영체제가 실제로 제한을 집행하는 sandbox가 필요합니다.
여기서 중요한 표현은 “실제로 집행”입니다. 프롬프트에 “workspace 밖은 수정하지 마”라고 적는 것은 sandbox가 아닙니다. wrapper script에서 조심하라고 안내하는 것도 충분하지 않습니다. 하위 프로세스까지 제약이 전파되어야 합니다. 에이전트가 npm, git, python, shell, build tool을 실행하더라도 같은 경계 안에 있어야 합니다.
좋은 sandbox는 최소한 네 가지 조건을 만족해야 합니다.
.git, 설정, agent memory 같은 영역은 별도로 보호됩니다.이 기준은 macOS, Linux, Windows 모두에 적용됩니다. 구현 도구만 다릅니다.
OpenAI는 AppContainer, Windows Sandbox, Mandatory Integrity Control(MIC)을 검토했지만 최종 요구사항에는 맞지 않았다고 설명합니다. 이 비교는 다른 팀이 자체 에이전트 실행기를 만들 때도 참고할 만합니다.
AppContainer는 강한 OS 경계를 제공하지만, 미리 필요한 capability를 아는 앱에 더 적합합니다. Codex 같은 코딩 에이전트는 shell, Git, Python, package manager, build tool 등 열린 개발 워크플로우를 다룹니다. 너무 좁은 sandbox는 생산성을 깎습니다.
Windows Sandbox는 disposable lightweight VM입니다. 보안 경계는 강하지만, 사용자의 실제 checkout, toolchain, credential, 로컬 설정 위에서 직접 작업해야 하는 Codex 요구에는 맞지 않았습니다. 매번 별도 데스크톱과 host-guest bridging을 관리해야 한다면 개발 경험이 나빠집니다.
MIC integrity labeling은 낮은 무결성 프로세스가 높은 무결성 객체에 쓰지 못하게 하는 방식입니다. 하지만 workspace를 low integrity로 relabel하면 Codex만 쓰는 공간이 아니라 low-integrity process 일반이 쓸 수 있는 공간이 됩니다. 실제 host filesystem의 trust model이 바뀌는 셈이라 위험합니다.
이 비교에서 얻을 교훈은 하나입니다. 강한 격리와 개발자 경험은 항상 충돌합니다. 에이전트 sandbox는 “보안상 가장 강한 박스”가 아니라 “실제 개발 흐름을 망치지 않으면서 위험한 행동을 막는 경계”여야 합니다.
OpenAI의 첫 prototype은 synthetic SID와 write-restricted token을 사용했습니다. sandbox-write라는 합성 SID를 만들고, 현재 작업 디렉터리와 추가 writable_roots에는 write/execute/delete 권한을 주며, .git, .codex, .agents 같은 read-only within writable 위치에는 write를 명시적으로 거부하는 방식입니다.
이 접근은 파일 쓰기 제한에는 꽤 명확합니다. 문제는 네트워크였습니다. 관리자 권한 없이 Windows Firewall 같은 강한 도구를 쓰기 어렵기 때문에, 첫 prototype은 proxy 환경변수를 죽은 endpoint로 보내고, Git SSH 명령을 실패시키고, PATH 앞에 denybin을 두는 식으로 일반적인 네트워크 도구를 막았습니다.
하지만 OpenAI는 이것을 advisory라고 평가했습니다. 프로세스가 환경변수를 무시하거나 직접 socket을 열면 우회할 수 있기 때문입니다. 이 대목이 중요합니다. 파일 write 제약과 네트워크 제약은 난이도가 다릅니다. “패키지 설치를 막았다”고 생각했지만, 다른 바이너리가 직접 네트워크를 열 수 있다면 exfiltration 위험은 남습니다.
실무 운영에서는 다음처럼 분리해서 봐야 합니다.
자체 sandbox를 만들지 않더라도 운영 정책은 세울 수 있습니다. 가장 먼저 해야 할 일은 권한 모드를 업무별로 나누는 것입니다.
읽기 전용 분석 작업은 넓게 허용해도 됩니다. 예를 들어 “이 버그 원인 찾아줘”, “테스트 실패 로그 분석해줘”, “영향 파일 목록 뽑아줘”는 read와 test 중심입니다. 이때도 secret 파일은 제외해야 합니다.
수정 작업은 workspace 내부 write만 허용합니다. 에이전트가 프로젝트 밖 설정 파일, 글로벌 패키지, 홈 디렉터리 dotfile을 건드리려 하면 멈춰야 합니다. 개발자가 직접 승인해도 로그가 남아야 합니다.
네트워크 작업은 의도별로 나눕니다. npm install, pip install, git fetch는 흔하지만 supply chain 위험이 있습니다. curl로 외부 endpoint에 데이터를 보내는 행위는 더 위험합니다. package install과 outbound request를 같은 “인터넷 접근”으로 묶으면 안 됩니다.
마지막으로 .git 보호가 중요합니다. 에이전트가 working tree를 수정하는 것은 괜찮지만, git internals를 직접 수정하거나 history를 재작성하는 명령은 별도 승인으로 둬야 합니다. 자동 커밋까지 맡길 경우 commit message, diff summary, 테스트 결과를 먼저 요구해야 합니다.
.git, agent 설정, credential 관련 디렉터리는 workspace 안에 있어도 read-only 또는 승인 대상으로 둡니다.로컬 코딩 에이전트 보안의 목표는 에이전트를 못 믿는 것이 아닙니다. 에이전트가 잘못된 명령을 실행해도 피해가 제한되도록 만드는 것입니다. 다음에 코딩 에이전트 권한을 설정할 때는 “이 명령을 실행해도 되는가”보다 먼저 물어야 합니다. “실행하면 어디까지 영향을 줄 수 있는가?”