오픈AI가 코딩 에이전트 'Codex'를 엔터프라이즈 환경에서 안전하게 배포하기 위한 기술적 제어 체계를 상세히 공개했다. 저장소 검토, 명령어 실행, 개발 도구 상호작용 등 이전에는 인간이 직접 수행하던 작업을 에이전트가 자동으로 처리하면서 보안 우려가 커지자, OpenAI는 이를 관리할 수 있는 구체적인 기술 통제 방안을 제시한 것이다.

멀티레이어 통제 구조

OpenAI가 내부 배포에 적용한 Codex 제어 방식은 세 가지 원칙을 중심으로 설계됐다. 첫째, 에이전트가 명확한 기술적 경계 내에서 작동할 것. 둘째, 저위험 일상 작업은 마찰 없이 빠르게 진행할 것. 셋째, 고위험 행동은 명시적 검토 대상으로 만들 것이다.

이를 구현하기 위해 샌드박싱과 승인 정책을 결합했다. 샌드박스는 Codex가 파일을 쓸 수 있는 범위, 네트워크 접근 가능 여부, 보호해야 할 경로를 정의하는 기술적 실행 경계다. 승인 정책은 샌드박스 밖의 작업이 필요할 때 사용자 승인을 요구하는 시점을 결정한다.

특히 주목할 점은 '자동 검토 모드(Auto-review)' 도입이다. OpenAI는 저위험 요청을 자동 승인하는 별도의 AI 에이전트를 운영해, 개발자가 일상적 작업마다 중단되지 않도록 설계했다. Codex가 계획된 행동과 최근 문맥을 자동 승인 에이전트에 전달하면, 이 에이전트가 낮은 위험도의 요청은 자동으로 승인하고 높은 위험도나 의도하지 않은 결과를 초래할 가능성이 있는 행동은 사용자 개입을 요청한다.

네트워크·인증·명령어 세분화

네트워크 정책도 제한적이다. OpenAI는 Codex에 무제한적인 아웃바운드 접근을 허용하지 않는다. 대신 '허용 목록'을 유지해 예상된 목적지만 통신하게 하고, 알려지지 않은 도메인에 접근할 때는 사용자 승인을 요구한다. 이렇게 하면 일반적인 개발 워크플로우(예: 패키지 저장소 접근)는 빠르게 진행되지만, 임의의 외부 시스템에 접근하려는 시도는 차단된다.

인증 관리도 중층적이다. CLI와 MCP(Model Control Protocol) OAuth 자격증명을 OS 보안 키링에 저장하고, 로그인을 ChatGPT를 통해서만 강제하며, 접근을 엔터프라이즈 워크스페이스로 고정한다. 이를 통해 Codex 활동이 ChatGPT의 엔터프라이즈 컴플라이언스 로그 플랫폼에서 추적 가능해진다.

명령어 레벨에서도 세분화된 통제가 작동한다. ls, grep 같은 일상적이고 안전한 셸 명령어는 샌드박스 밖에서도 승인 없이 실행되지만, 시스템 설정 변경이나 권한 상승 시도 같은 위험한 명령어는 차단되거나 승인 필수로 설정된다. OpenAI는 이러한 규칙을 클라우드 관리 정책, macOS 관리형 환경 설정, 로컬 요구사항 파일의 조합으로 적용한다. 이렇게 하면 관리자가 강제하는 기본 규칙은 유지하면서도 팀·사용자 그룹·환경별로 서로 다른 설정을 테스트할 수 있다.

에이전트 원시 텔레메트리와 감시

통제만으로는 충분하지 않다. 에이전트가 배포된 후, 보안팀은 에이전트가 무엇을 했고 왜 했는지를 알아야 한다. 기존 보안 로그는 "프로세스가 시작됐다", "파일이 변경됐다", "네트워크 연결 시도가 있었다" 같은 **행위(what)**만 기록한다. 하지만 보안팀은 여전히 Codex가 왜 그렇게 했는지, 사용자의 의도가 무엇인지를 따로 파악해야 한다.

이를 해결하기 위해 OpenAI는 **에이전트 인식형 로그(agent-native telemetry)**를 도입했다. Codex는 OpenTelemetry 표준을 지원해 사용자 프롬프트, 도구 승인 결정, 도구 실행 결과, MCP 서버 사용, 네트워크 정책 허용·차단 사건 등을 기록한다. 엔터프라이즈와 교육용 고객은 OpenAI 컴플라이언스 플랫폼을 통해서도 이 활동 로그에 접근할 수 있다.

OpenAI 보안팀은 이 로그를 AI 기반 보안 분류 에이전트와 함께 운영한다. 엔드포인트 보안 도구가 "Codex가 비정상적인 행동을 했다"고 알리면, Codex 로그가 그 의도와 문맥을 설명해준다. AI 분류 에이전트는 원본 요청, 도구 활동, 승인 결정, 도구 결과, 네트워크 정책 결정을 종합적으로 검토해 보안팀에 분석 결과를 제시한다. 이렇게 하면 정상 행동과 양성 오류, 그리고 진정한 보안 위협을 구분하기 쉬워진다.

OpenAI는 이 같은 로그를 운영 관점에서도 활용한다. 내부 채택 추이, 가장 많이 사용되는 도구와 MCP 서버, 네트워크 샌드박스가 요청을 차단하거나 승인 대기 중인 빈도, 배포 과정에서 여전히 조정이 필요한 부분 등을 파악한다. 이 OpenTelemetry 로그는 SIEM(Security Information and Event Management)과 컴플라이언스 로깅 시스템으로 중앙화할 수 있다.

한국 시장의 과제

한국의 대형 IT·금융 기업들도 AI 에이전트 도입 시 동일한 보안 과제에 직면할 것이다. 특히 금융감독위원회의 AI 위험 관리 지침과 개인정보보호위원회의 자동 의사결정 규제가 강화되는 상황에서, 에이전트의 행동을 추적·감시·통제할 수 있는 기술 체계는 필수가 된다. OpenAI의 공개 방식은 한국 기업들이 자체 정책을 수립할 때 참고할 수 있는 국제 표준이 될 것으로 보인다.

미해결 과제

다만 남은 질문이 있다. 자동 승인 에이전트 자체의 의사결정이 오류를 범할 경우, 그 책임은 누가 질 것인가? OpenAI의 문서는 저위험 판단 기준을 명시하지 않았다. 또한 Codex의 행동 로그가 법적 증거로 인정받을 조건도 아직 불명확하다. 이런 점들은 향후 에이전트 규제 프레임이 정립될 때 함께 논의될 필요가 있다.