에이전트 샌드박스 세 층 — 문제는 격리 강도가 아니었습니다

핵심 요약

샌드박스는 에이전트가 실행하는 코드를 내 컴퓨터에서 떼어 놓는 실행 환경입니다. 코딩 에이전트에 셸과 파일 접근을 주면서 다들 샌드박스를 켰고, 2026년에 그것이 실제로 얼마나 막아 주는지를 잰 연구가 나왔습니다. 결과가 가리킨 것은 격리 방식의 우열이 아니었습니다.

샌드박스는 무엇을 막는가

“샌드박스를 켰다”는 한 문장 안에 성격이 다른 세 개의 층이 들어 있습니다. 이 글에서 다루는 측정 세 편이 각각 한 층씩을 봤기 때문에, 먼저 층을 갈라 두겠습니다.

세 층은 서로를 대신하지 못합니다. 1층이 완벽해도 격리 안에서 프로젝트 파일이 지워지는 것은 막지 못하고, 2층이 완벽해도 금지 목록에 없는 정상 명령으로 하는 일은 막지 못합니다. 그리고 아래에서 보겠지만, 2026년 측정이 가장 크게 문제 삼은 것은 1층이 아니라 3층이었습니다.

1층: 엔진은 고쳤고, 제품이 안 올렸습니다

첫 번째 논문은 AI 샌드박스 제품 다섯 종이 게스트 코드를 호스트 커널에서 어떻게 떼어 놓는지를 여섯 개 축으로 비교했습니다(arXiv:2606.08433, 2026-06-07). 저자들은 종합 순위를 매기지 않았고, 축을 하나씩 보면 판단이 안 된다는 점을 명시했습니다.

그런데 운영자 입장에서 가장 큰 차이를 만든 것은 격리 방식이 아니라 제품이 그 엔진의 어느 버전을 쓰도록 고정해 두었는가였습니다. 여기서 버전 고정은 의존하는 소프트웨어의 버전을 특정 값으로 묶어 두는 것을 말합니다.

아래에서 상류는 격리 엔진을 만드는 프로젝트를, 하류는 그 엔진을 가져다 쓰는 샌드박스 제품을 가리킵니다.

논문의 표현을 그대로 옮기면, 운영자에게 보이는 패치 전달 속도는 엔진이 얼마나 빨리 고치느냐가 아니라 제품이 그 버전을 언제 올리느냐가 좌우합니다. 그리고 이 결과는 격리 등급으로 예측되지 않았습니다.

이 두 제품에서는 격리가 강한 쪽에 패치가 도달하지 않았고, 패치가 도달한 쪽에 추가 보안 설정(AppArmor·seccomp처럼 기본 격리 위에 덧대는 커널 수준 제한)을 적용할 수 없었습니다. 두 문제 모두 엔진이 만든 것이 아니라 제품이 고른 기본값이 만든 것입니다. 논문은 arrakis를 두고 “엔진은 제 일을 해 왔고, 제품이 수정을 전달하지 않고 있다”고 적었습니다.

arrakis는 자체 호스팅용 소규모 프로젝트입니다(별 869개). 여기서 요점은 특정 프로젝트를 지적하는 것이 아니라, 이 값이 누구나 몇 분이면 확인할 수 있는 자리에 공개돼 있다는 것입니다. 상용 제품이라면 오히려 확인이 어렵습니다 — 같은 논문에서 한 제품의 클라우드 호스팅 판은 고정된 버전을 밖에서 볼 수 없어 “확인 불가”로 분류됐습니다.

2층: 금지 목록은 막으려던 것을 놓쳤습니다

두 번째 논문은 터미널에서 도는 에이전트가 셸 명령을 걸러 내는 방식을 봤습니다(arXiv:2606.15549, 2026-06-14 공개 / 06-20 개정). 이런 에이전트는 대개 세 종류의 목록으로 명령의 실행 여부를 정하는데, 실제 판단을 좌우하는 것은 막을 명령을 나열해 둔 금지 목록(denylist)입니다.

저자들은 언어 모델에게 금지 목록을 우회할 명령을 제안하게 하고, 그것을 샌드박스에서 실제로 실행해 그 명령이 정말 그 작업을 해내는지 확인하는 파이프라인을 만들었습니다. 후보로 삼은 것은 애초에 그 목록에 걸리지 않는 명령입니다. 그렇게 얻은 “이 명령이 해내는 작업”과, 같은 방식으로 얻은 “이 목록이 막으려는 작업”을 맞대어 겹치는 것이 있으면 우회로 판정했습니다. 명령 문자열끼리 비교한 것이 아니라 작업 단위로 비교했다는 점이 이 측정의 핵심입니다.

이 범위를 정확히 읽어야 합니다. 논문이 잰 것은 금지 목록이 막으려는 작업 전부가 아닙니다. 저자들은 대상을 파일 시스템 작업 일곱 가지로 좁혔습니다 — 읽기·쓰기·생성·삭제·복사·권한 변경·소유자와 그룹 변경입니다. 그 일곱 가지마다 “그 작업을 막으려 한 목록” 중 우회를 하나 이상 놓친 비율을 셌고, 69.0%는 가장 잘 막힌 유형, 98.6%는 가장 못 막힌 유형입니다.

그러니 전체 목록의 69%가 뚫렸다는 뜻이 아닙니다. 이 일곱 가지 중 어느 것을 막으려 하든, 그 작업을 겨냥한 목록의 최소 69.0%에 빠진 경로가 있었다는 뜻입니다.

여기서 짚을 것은 측정 대상입니다. 이 결과는 연구자가 만든 가상의 정책이 아니라 개발자들이 실제로 써서 배포한 목록을 상대로 나왔습니다. 뒤 6장에서 볼 종합 논문은 바로 이 점을 들어, 이 결과가 문헌 전체에서 가장 중요한 발견 축에 든다고 평가했습니다 — 방어 기법이 자기가 만든 공격자에게 강하다고 보고하는 것과, 현장에 배포된 정책이 실제로 뚫린다고 보고하는 것은 다른 주장입니다.

다만 논문이 내린 결론은 “목록을 더 잘 쓰자”가 아닙니다. 저자들은 고치려면 빠진 우회 명령을 전부 채워 넣어야 하는데 그 부담이 너무 크다는 점을 함께 보이고, 정적인 명령 문자열 금지 목록은 명령 통제의 주 방어층으로 부적합하다고 맺었습니다.

3층: 권한으로는 걸러지지 않는 행동

세 번째 논문이 이 글에서 가장 중요합니다(arXiv:2605.18583, 2026-05-18). 다루는 것은 공격이 아닙니다. 평범한 요청을 받은 에이전트가 요청하지 않은 일까지 하는 현상입니다 — 관련 없는 파일을 지우고, 오래된 자격증명 백업을 치우고, 언급된 적 없는 설정을 고쳐 씁니다.

저자들은 이것을 범위 밖 행동이라 부르고, 프롬프트 인젝션이나 샌드박스 탈출과는 다른 종류의 문제로 분류합니다. 논문의 정의는 이렇습니다 — 요청이 명시적으로도 암묵적으로도 허가하지 않은 행동이면서, 환경 상태(파일 시스템·프로세스·네트워크 연결·git 객체)를 실제로 바꿨거나 미리 정해 둔 민감한 위치(.bash_history, .ssh/, 닷파일)를 읽은 경우입니다. 말만 하고 실행하지 않은 것이나 허가받아 읽은 평범한 파일은 여기 들어가지 않습니다.

여기서 한 가지를 구분해야 합니다. 그 행동은 도구의 권한으로는 실행 가능합니다 — 셸도 파일도 이미 열려 있습니다. 다만 사용자가 시킨 범위 밖일 뿐입니다. 그래서 권한 규칙으로 걸러지지 않습니다. 규칙은 “이 행동 유형이 허용되는가”에 답하지, “지금 이 실행이 사용자가 시킨 것인가”에는 답하지 않습니다.

측정 규모

검증을 통과한 시나리오 500개를, 에이전트 제품 4종(Claude Code · OpenHands · Codex CLI · Gemini CLI)과 기반 모델 6종을 짝지은 15개 조합에 걸쳐 약 7,500회 실행했습니다. 4×6 전조합이면 24개이지만 실제로 돌린 것은 15개입니다. 50건을 다시 분류해, 두 평가자가 같은 자료에 같은 판정을 내리는 정도를 0~1로 나타내는 카파 계수로 일치도를 쟀습니다. 결과는 0.73으로, 실무에서 쓸 만한 일치로 봅니다.

발견 1 — 권한 범위 블록을 빼면 크게 올라갑니다

벤치마크를 만들다가 저자들이 걸린 문제가 있습니다. 프롬프트 안에 허가 범위를 적어 두면 에이전트가 작업 자체로부터 경계를 추론하는 대신 그 선언 문장을 패턴으로 맞추기 시작한다는 것입니다. 그래서 Authorized: 와 OUT OF SCOPE: 를 담은 권한 범위 블록의 유무만 다르고 나머지는 바이트 단위까지 같은 시나리오 쌍을 만들어 짝지어 비교했습니다.

그래서 이 측정에서 가져갈 것은 17.1%라는 크기가 아니라 방향입니다. 에이전트는 작업의 경계를 스스로 이해한 것이 아니라 범위를 적어 둔 텍스트에 반응하고 있었고, 그 텍스트를 빼면 세 모델 모두에서 범위 밖 행동이 늘었습니다. 크기는 시나리오 구성에 따라 2.6%p까지 줄어듭니다.

발견 2 — 모델보다 도구가 결과를 더 좌우합니다

더 큰 차이는 어느 모델을 쓰느냐가 아니라 어느 도구를 쓰느냐에서 났습니다. 논문은 네 제품을, 위험한 동작도 일단 실행하는 허용형과 실행 전에 사용자에게 묻는 확인 후 진행형으로 나눴습니다.

두 무리의 차이가 우연일 확률은 피셔 검정에서 10만분의 1 이하였습니다. 같은 분류 안에서 기반 모델만 바꿨을 때의 편차는 최대 15.9%p였습니다. 저자들은 이를 두고 모델을 더 안전하게 조정해도 그 효과가 허용형 권한 통제를 온전히 통과하지 못한다고 적었습니다. 더 잘 정렬된 모델로 바꾸는 것이 이 문제를 대신 풀어 주지 않는다는 뜻입니다.

실제로 터진 네 건이 있던 자리

앞의 세 층은 측정입니다. 실제로 공개된 취약점은 어땠을까요. 종합 논문(arXiv:2607.05743, 2026-07-07)은 2023~2026년 논문 39편을 17개 범주로 정리하면서, 실제 제품에 영향을 준 취약점 네 건을 — CVE는 공개된 취약점 하나하나에 붙는 식별번호입니다 — 미국 국립취약점데이터베이스(NVD) 원문과 대조해 확인했습니다. 저희도 같은 네 건을 NVD API로 직접 다시 확인했습니다. CVSS는 취약점의 심각도를 나타내는 10점 만점 점수입니다.

네 건 중 컨테이너 격리를 실제로 뚫은 것은 첫 번째 하나입니다. 그것도 에이전트 도구가 나오기 전부터 있던 컨테이너 런타임의 결함으로, 에이전트 샌드박스가 같은 부품 위에 지어졌기 때문에 물려받는 종류입니다.

Copilot 건은 NVD 설명문에도 종합 논문에도 “명령 주입”으로만 적혀 있습니다. 그런데 NVD가 그 항목에 Exploit으로 태그해 걸어 둔 원 보고를 열어 보면 경로가 더 구체적입니다 — VS Code의 GitHub Copilot 에이전트 모드에서, 프롬프트 인젝션을 받은 Copilot이 .vscode/settings.json에 "chat.tools.autoApprove": true를 써 넣어 사용자 확인 절차를 스스로 전부 끈 뒤 터미널 명령을 실행합니다. 격리를 뚫은 것이 아니라 승인 경계가 안쪽에서 무너진 쪽입니다.

다만 표의 수정 버전 17.14.12는 NVD가 영향 범위로 적어 둔 Visual Studio 2022 17.14.0~17.14.11에 대응하는 것입니다. 원 보고가 보인 VS Code 쪽 경로에 대해서는 버전 번호 없이 2025년 8월 정기 패치로 고쳐졌다고만 적혀 있습니다.

Claude Code의 두 건은 또 다른 자리를 가리킵니다 — 신뢰하지 않는 저장소를 여는 시점과 사용자의 신뢰 판단이 실제로 효력을 갖는 시점 사이의 틈입니다. 둘 다 격리를 뚫은 것이 아니라 격리와 신뢰 판단이 적용되기 전에 일어났습니다.

표의 네 건은 모두 수정 버전이 나와 있습니다. Claude Code 두 건은 자동 업데이트를 쓰는 사용자에게 이미 배포됐습니다. 수정 버전 1.0.111은 2025-09-10, 2.0.65는 2025-12-11에 나왔고, 2026-09-09 기준 최신은 2.1.266입니다(npm 레지스트리 확인). 문제가 되는 쪽은 버전을 손으로 고정해 둔 환경입니다 — 3장에서 본 버전 고정 문제가 에이전트 도구 자체에도 그대로 적용됩니다.

아직 아무도 측정하지 않은 것

종합 논문이 39편을 가로질러 읽고 찾은 공백 다섯 개 중, 실무에 바로 걸리는 셋을 옮깁니다.

오늘 할 수 있는 것

앞의 측정에서 직접 따라 나오는 것만 적었습니다.

아직 결론이 아닌 것

• CVE 네 건은 예시이지 표본이 아닙니다. 종합 논문이 “실제로 터진 일”을 보이려고 고른 네 건이고, 무작위 표본도 전수도 아닙니다. 그래서 이 글은 네 건의 구성으로 “격리가 대체로 안전하다”거나 운영 문제가 더 흔하다는 빈도 결론을 내지 않았습니다. 네 건 중 하나는 실제 격리 탈출입니다.
• 제품 비교는 다섯 종이고, 그나마 엔진 수준을 다룬 1부까지입니다. 엔진 비교 논문은 스스로 종합 순위를 매기지 않았고 “축 하나로는 판단할 수 없다”고 명시했습니다. 이 글에서 arrakis와 daytona를 대비시킨 것은 격리 등급이 운영 결과를 예측하지 못한다는 점을 보이기 위해서지, 두 제품의 우열을 말하려는 것이 아닙니다. 2부는 확인하지 못했습니다 — 엔진이 구조적으로 무엇을 허용하는지가 아니라 배포된 제품이 실제로 어떤 기본값으로 도는지를 보는 제품 수준 축입니다.
• 582일과 13건은 저희가 계산한 값입니다. 버전을 고정한 커밋 날짜(2025-02-04)와 상류 릴리스 목록에서 2026-09-09 기준으로 셌습니다. 논문의 471일은 그보다 이른 측정 시점 기준이며, 두 숫자는 세는 시점이 다를 뿐 서로 어긋나지 않습니다.
• 17.1%는 논문이 상한이라 부른 조건에서 나온, 한 조합의 값입니다. Claude Code에 GLM-4.6을 물린 한 셀에서, 76개짜리 수작업 파일럿 세트에 권한 범위 축 하나만 바꿔 잰 결과입니다. 논문 자신이 “민감한 하위집단에서 효과의 상한”이라고 적었고, 다섯 축을 무작위화한 본 벤치마크에서는 같은 효과가 2.6%p로 떨어집니다. 실무 업무 분포에서의 발생률은 어느 쪽으로도 알 수 없습니다.
• 제품 간 차이의 원인은 밝혀지지 않았습니다. 논문이 확인 끄기 설정을 밝힌 것은 네 제품 중 셋뿐이고, 그 설정 뒤에 OpenHands의 확인 동작이 얼마나 남았는지도 확정되지 않습니다. 그래서 OpenHands가 낮게 나온 것을 “매번 묻기 때문”이라고도, 승인 설계와 무관하다고도 잘라 말할 수 없습니다. 제품마다 승인 외에도 구현이 다르고, 어느 요소가 차이를 만드는지는 이 측정으로 나뉘지 않습니다. 연관이지 인과가 아닙니다.
• 보안 업체가 낸 샌드박스 탈출 보고들은 확인하지 않았습니다. 검색 과정에서 2026년 여러 건이 보였지만, 1차 자료로 대조할 수 없어 이 글에 넣지 않았습니다.
• 세 논문 모두 사전 공개본(arXiv)입니다. 동료 심사를 거쳤는지 확인하지 못했습니다. 다만 셋 다 자료 출처(GitHub 수집 목록, 공개 저장소, NVD)를 밝히고 있어 값 자체는 추적 가능합니다.
• 네트워크 작업은 측정 대상에서 빠졌습니다. 69.0~98.6%는 파일 시스템 작업 일곱 가지에 대한 값인데, 실무 금지 목록에는 외부 전송을 막으려는 규칙이 흔합니다. 그쪽이 얼마나 견고한지는 이 논문으로 알 수 없습니다.
• 자체 측정은 버전 고정 확인 하나뿐입니다. 금지 목록 우회나 범위 밖 행동은 저희가 재현하지 않았고, 논문이 보고한 값을 원문에서 확인만 했습니다.
• 금지 목록 편수에 논문 내부 불일치가 있습니다. 1,731개는 서론의 결과 요약 문단 한 곳뿐이고, 초록·서론의 기여 목록·평가 절의 수집 표(1,000+136+573=1,709)·결론은 모두 1,709개입니다. 이 글은 네 곳이 일치하는 1,709를 썼습니다.

참고자료

모든 수치는 2026-09-09에 원문에서 확인했습니다. 논문 값은 초록과 본문을 직접 읽어 대조했고, CVE는 NVD API 응답으로, 릴리스 날짜와 최신 버전은 npm 레지스트리로, 버전 고정 상태는 저장소 파일과 릴리스 목록으로 확인했습니다. 582일과 13건은 공개 날짜로부터 저희가 계산한 파생값입니다. 초고에서 69.0~98.6%의 기준 축, 17.1%의 적용 범위, 제품 간 차이의 인과 해석을 잘못 썼고, 발행 전 검토에서 지적받아 세 논문의 원문으로 다시 확인해 고쳤습니다.