에이전트 샌드박스는
격리보다 운영에서 무너집니다

핵심 요약

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

샌드박스는 무엇을 막는가

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

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

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

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

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

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

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

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

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

2층: 금지 목록의 대부분이 우회됐습니다

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

저자들은 언어 모델에게 금지 목록을 우회할 명령을 제안하게 하고, 그것을 샌드박스에서 실제로 실행해 통과 여부를 검증하는 파이프라인을 만들었습니다. 제안만 받고 끝내지 않고 실행으로 확인했다는 점이 이 측정의 핵심입니다.

이 범위를 정확히 읽어야 합니다. 논문은 금지 목록이 막으려는 작업을 일곱 가지 유형으로 나눈 뒤, 각 유형마다 “그 작업을 막으려 한 목록” 중 우회를 하나 이상 놓친 비율을 셌습니다. 69.0%는 가장 잘 막힌 유형, 98.6%는 가장 못 막힌 유형입니다. 전체 목록의 69%가 뚫렸다는 뜻이 아니라, 어떤 작업을 막으려 하든 그 목록의 최소 열에 일곱은 빠진 경로가 있었다는 뜻입니다.

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

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

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

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

저자들은 이것을 범위 밖 행동이라 부르고, 프롬프트 인젝션이나 샌드박스 탈출과는 다른 종류의 문제로 분류합니다. 형식 정의는 “요청이 허가한 행동 집합에 들어 있지 않으면서 파일을 바꾸거나 민감한 위치를 읽은 행동”입니다.

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

측정 규모

검증을 통과한 시나리오 500개를, 에이전트 제품 4종(Claude Code · OpenHands · Codex CLI · Gemini CLI)과 기반 모델 6종에 걸쳐 약 7,500회 실행했습니다. 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 건은 명령 주입으로만 기술돼 있어 신뢰 경계와 직접 엮이지 않습니다. Claude Code의 두 건이 같은 자리를 가리킵니다 — 신뢰하지 않는 저장소를 여는 시점과 사용자의 신뢰 판단이 실제로 효력을 갖는 시점 사이의 틈입니다. 둘 다 격리를 뚫은 것이 아니라 격리와 신뢰 판단이 적용되기 전에 일어났습니다.

표의 네 건은 모두 수정 버전이 나와 있습니다. Claude Code 두 건은 자동 업데이트를 쓰는 사용자에게 이미 배포됐습니다. 수정 버전 1.0.111은 2025-09-10, 2.0.65는 2025-12-11에 나왔고, 2026-09-09 기준 최신은 2.1.263입니다(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가 낮게 나온 것을 “매번 묻기 때문”으로 읽을 수 없습니다. 제품마다 승인 외에도 구현이 다르고, 어느 요소가 차이를 만드는지는 이 측정으로 갈라지지 않습니다. 연관이지 인과가 아닙니다.
• 보안 업체가 낸 샌드박스 탈출 보고들은 확인하지 않았습니다. 검색 과정에서 2026년 여러 건이 보였지만, 1차 자료로 대조할 수 없어 이 글에 넣지 않았습니다.
• 세 논문 모두 사전 공개본(arXiv)입니다. 동료 심사를 거쳤는지 확인하지 못했습니다. 다만 셋 다 자료 출처(GitHub 수집 목록, 공개 저장소, NVD)를 밝히고 있어 값 자체는 추적 가능합니다.
• 자체 측정은 버전 고정 확인 하나뿐입니다. 금지 목록 우회나 범위 밖 행동은 저희가 재현하지 않았고, 논문이 보고한 값을 원문에서 확인만 했습니다.
• 금지 목록 편수에 논문 내부 불일치가 있습니다. 초록과 결론은 1,709개, 서론은 1,731개로 적혀 있습니다. 이 글은 둘이 일치하는 1,709를 썼습니다.

참고자료

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