AI 코딩에서 샌드박스가 있어도 안전하다고 끝낼 수 없는 이유

AI coding agent에게 일을 맡기다 보면 어느 순간 질문의 성격이 달라진다.

처음에는 어떤 모델이 코드를 더 잘 만드는지가 중요하다. 그다음에는 긴 작업을 얼마나 안정적으로 이어가는지, 여러 파일을 함께 수정할 수 있는지, 필요한 tool을 적절하게 호출할 수 있는지를 보게 된다.

그런데 agent가 실제 개발 환경 안으로 깊게 들어오기 시작하면 다른 문제가 생긴다.

이 agent는 실제로 어디까지 갈 수 있는가?

파일을 읽고 수정하고, tool을 호출하고, command까지 실행할 수 있다면 모델의 능력이 커지는 만큼 권한의 범위도 함께 봐야 한다.

최근 공개된 OpenAI Codex의 sandbox escape 사례는 이 문제를 꽤 구체적으로 보여준다.

이번 사건에서 봐야 할 것은 버그 이름이 아니다

Accomplish AI의 보안 연구진은 OpenAI Codex sandbox에서 서로 다른 두 가지 탈출 경로를 발견했다고 공개했다.

연구진은 두 문제를 2026년 8월 12일 OpenAI에 보고했고, 두 문제 모두 8일 안에 수정됐다고 밝혔다. 공개 시점에는 이미 수정이 제공된 상태였다.

따라서 이 글의 목적은 현재 Codex가 위험하다고 말하는 것이 아니다.

오히려 반대다. 이미 수정된 사례를 통해 AI agent의 안전을 어디에서 보아야 하는가를 생각해볼 수 있다.

연구진은 첫 번째 문제를 Overpatch라고 불렀다. Codex CLI의 workspace-write 환경에서 patch를 처리하는 과정의 권한 범위와 관련된 문제였다.

두 번째 Heapjack은 Codex Desktop이 사용하는 Node 환경에서 발생했다. 신뢰된 JavaScript와 신뢰되지 않은 JavaScript가 같은 process의 memory를 공유하는 구조와 관련됐고, 연구진은 이 경로가 read-only sandbox mode에서도 sandbox 밖의 command 실행으로 이어질 수 있었다고 설명했다.

둘은 작동 방식이 다르다.

하지만 더 흥미로운 부분은 두 취약점의 이름이나 세부 공격 기법이 아니다. 결국 두 사례 모두 어디에서 권한을 제한하고, 무엇을 신뢰할 것인가라는 질문으로 이어진다.

샌드박스가 있다는 것과 경계가 안전한 것은 같은 말이 아니다

AI agent를 사용할 때 read-only, workspace-write 같은 표현을 보면 자연스럽게 하나의 안전한 경계가 만들어져 있다고 생각하기 쉽다.

하지만 이번 사례가 보여주는 것은 설정의 이름만 봐서는 충분하지 않다는 점이다.

중요한 것은 실제 실행 구조에서 그 제한이 어떻게 집행되는가다.

Agent가 어떤 행동을 요청했을 때 그것을 허용할지 판단하는 부분, 신뢰된 영역과 신뢰되지 않은 영역을 나누는 부분, tool이 agent에게 제공하는 권한의 범위가 서로 맞물린다.

여기서 하나라도 예상과 다르게 동작하면 화면에 표시된 권한 수준과 실제로 가능한 행동 사이에 차이가 생길 수 있다.

그래서 AI agent 보안은 단순히 ‘sandbox 기능이 있는가?’라는 체크박스로 끝내기 어렵다.

경계를 누가 집행하고 있는가?

이 질문이 더 중요하다.

모델을 믿는 문제와 권한을 제한하는 문제는 다르다

AI를 사용할 때 우리는 자주 모델의 행동에 초점을 맞춘다.

위험한 명령을 실행하지 않도록 지시하거나, 중요한 파일을 수정하지 말라고 prompt에 적고, 작업 범위를 명확하게 설명한다.

물론 이런 지시는 필요하다.

하지만 agent가 강해질수록 그것만으로 충분하다고 보기는 어렵다.

모델이 지시를 잘 따르는 것과 시스템이 실제로 허용되지 않은 행동을 막는 것은 서로 다른 문제이기 때문이다.

모델이 하지 않기를 기대하는 것과, 모델이 하려고 해도 할 수 없도록 만드는 것은 다르다.

AI coding agent가 단순한 코드 추천 도구를 넘어 파일과 tool, command를 직접 다루는 방향으로 이동한다면 이 차이는 점점 더 중요해진다.

Agent가 강해질수록 architecture를 보게 된다

이번 사건을 특정 제품의 보안 문제로만 보면 얻을 수 있는 것이 많지 않다.

취약점은 이미 수정됐다. 시간이 지나면 버전도 바뀌고 구현도 달라진다.

하지만 질문은 남는다.

AI에게 더 많은 일을 맡길수록 우리는 무엇을 기준으로 안전하다고 판단할 것인가?

앞으로 coding agent를 볼 때는 모델 성능과 context 길이, 작업 속도만 볼 것이 아니라 execution boundary, permission isolation, tool architecture, 그리고 update 상태까지 함께 봐야 할 이유가 생겼다.

특히 agent가 실제 업무 환경에 연결될수록 이 문제는 보안팀만의 관심사가 아니다. Agent에게 어떤 directory를 열어줄지, 어떤 tool을 연결할지, 어느 수준의 command 실행을 허용할지 결정하는 순간부터 이미 제품 설계와 workflow의 문제가 된다.

이는 AI를 덜 사용해야 한다는 이야기가 아니다.

오히려 반대에 가깝다.

AI에게 더 많은 일을 맡기려면, 그만큼 사람이 매번 감시하지 않아도 되는 구조를 함께 만들어야 한다.

더 강한 agent에는 더 명확한 경계가 필요하다

AI coding의 경쟁은 계속해서 agent에게 더 많은 능력을 주는 방향으로 움직이고 있다.

더 많은 파일을 읽고, 더 많은 tool을 사용하고, 더 긴 작업을 이어가며, 사람 대신 더 많은 단계를 처리할 수 있게 만드는 것이다.

그 방향 자체는 자연스럽다.

다만 능력의 범위가 넓어질수록 안전을 모델의 판단에만 맡길 수는 없다.

이번 Codex sandbox 사례가 보여주는 핵심도 여기에 있다.

좋은 agent는 많은 일을 할 수 있어야 하지만, 동시에 하지 말아야 할 일은 구조적으로 할 수 없어야 한다.

결국 AI agent 시대의 보안은 모델에게 무엇을 시킬 것인가뿐 아니라, 그 모델이 실제로 어디까지 갈 수 있도록 만들 것인가의 문제가 되고 있다.