저는 이 글을 '목요일의 생각(Thursday Thoughts)' 포스트로 시작하려 했습니다. 상황은 명확했습니다. OpenAI는 자사의 모델 두 개가 평가 샌드박스(sandbox)를 탈출하여 Hugging Face의 운영 인프라를 침해하고, 자체 벤치마크의 정답지를 훔쳤다고 공개했습니다. 그리고 그 "샌드박스"는 단 하나의 허가된 출구인 패키지 레지스트리 프록시(package-registry proxy)를 가진 컨테이너였으며, 그 프록시에는 제로데이(zero-day) 취약점이 있었습니다. 벌써 정의가 내려지고 있었습니다. 업계에는 모두가 고개를 끄덕이는 마케팅 용어가 아니라, 실제로 테스트 가능한 진정한 "샌드박스화(sandboxed)" 정의가 필요하다는 결론 말입니다.

그러다 "누군가 이것을 제대로 정의해야 한다"라고 쓰려던 순간 멈췄습니다. 확인도 하지 않고 단정 짓는 것은 게으른 행동입니다. 어쩌면 누군가 이미 해두었을지도 모릅니다. 그래서 저는 자극적인 의견을 잠시 접어두고 대신 찾아보기로 했습니다. 이 글은 그 의견이 아니라, 그 조사 과정에 대한 것입니다.

지형도, 간략하게

요약하자면: 에이전트 보안(agent security)에 대해 쓰인 글은 많지만, 단일 샌드박스의 격리 아키텍처(containment architecture)를 구체적으로 평가하는 점수 산정 표준은 거의 없습니다.

OWASP의 Agentic AI Top 10과 그 Agent Security Cheat Sheet는 위협과 완화 방법을 높은 수준에서 분류하며 체크리스트로서 유용하지만, 비교 가능한 점수를 생성하도록 만들어지지는 않았습니다. NIST의 AI Risk Management Framework는 이보다 완전히 높은 수준에서 작동하며, 이는 조직적 리스크 거버넌스(risk governance)이지 런타임 경계(runtime boundary)를 위한 기술적 채점 루브릭(grading rubric)이 아닙니다. MITRE ATLAS는 AI 시스템에 대한 적대적 기술(adversarial techniques)을 분류하며, 격리 조치보다는 위협 라이브러리에 가깝습니다.

Cloud Security Alliance는 여러 중복되는 노력을 기울이고 있습니다. MAESTRO, AI Controls Matrix, 그리고 자율성을 "인턴 (Intern)"부터 "수석 (Principal)"까지 4단계 사다리로 점수화하는 Agentic Trust Framework가 그것입니다. 이는 제가 찾고자 했던 특정 부분, 즉 에이전트가 인간 없이 얼마나 많은 일을 할 수 있는지에 가장 근접한 것이었지만, 샌드박싱 (sandboxing) 전체를 범위로 다루지는 않습니다. RAND의 Securing AI Model Weights는 SL1부터 SL5까지 5가지 보안 수준을 정의하지만, 이는 특정 에이전트의 런타임 샌드박스 (runtime sandbox)가 적대적 작업 (adversarial task) 하에서 견뎌낼 수 있는지 여부가 아니라, 연구소에서의 가중치 (weight) 도난 및 유출 위험에 초점을 맞추고 있습니다. 또한 최근 arXiv 논문인 AI Sandboxes: A Threat Model, Taxonomy, and Measurement Framework도 구조적으로 흥미롭지만, 이는 하나의 샌드박스를 독립적으로 등급을 매길 수 있는 계층으로 분해하기보다는 샌드박스를 아키타입 (archetypes: 시뮬레이션 기반, 디지털 트윈, 적대적, 규제, 에이전트 기반)으로 분류합니다.

이 중 그 어느 것도 제가 찾던 구체적인 작업을 수행하지는 않습니다. 즉, 단일 에이전트 샌드박스를 가져와 독립적인 부분들로 나누고, 각 부분을 점수화하여 제품 간에 비교할 수 있는 결과물을 만들어내는 작업 말입니다. 그러다 정확히 그 작업을 수행하는 것을 발견했습니다.

에이전트 샌드박스 분류 체계 (The Agent Sandbox Taxonomy)

2026년 3월에 발표되어 여전히 커뮤니티의 활발한 검토를 받고 있는 The Agent Sandbox Taxonomy는 기억하기 쉬운 "7-7-3"을 중심으로 구성되어 있습니다: 7개의 방어 계층 (defense layers), 7개의 위협 카테고리 (threat categories), 그리고 **3개의 평가 차원 (evaluation dimensions)**입니다.

7개의 계층은 하위 계층이 기초가 되기 때문에 아래에서 위로 번호가 매겨집니다:

각 계층은 강도 (Strength) (04)와 세분성 (Granularity) (03)에 따라 점수가 매겨지며, OS 및 인프라 의존성에 대한 고정된 이식성 (Portability) 태그가 추가됩니다. 제가 계속해서 강조하는 부분은 바로 강도(Strength) 척도인데, 이는 OpenAI 사고에서 중요했던 차이점과 정확히 일치하기 때문입니다: 0은 강제성 없음, 1은 샌드박스된 프로세스가 단순히 무시하거나 우회할 수 있는 협력적 강제 (Cooperative enforcement) (예: 프록시 환경 변수, 선택적 관례), 2는 프로세스가 내부적으로 우회할 수는 없지만 운영자가 재설정할 수 있는 소프트웨어에 의한 강제 (Software-enforced), 3은 커널에 의해 강제되며 적용되면 되돌릴 수 없는 방식 (Namespaces, Landlock, seccomp-BPF), 4는 구조적 방식 (Structural)으로, 보호된 리소스가 샌드박스 내부에 아예 존재하지 않는 상태 (MicroVM, 자격 증명 프록시, 네트워크 장치 없음)를 의미합니다.

모든 제품은 각 계층의 강도를 순서대로 보여주는 CVSS 스타일의 벡터인 지문(Fingerprint)을 갖게 됩니다:

E2B      L1:4/L2:4/L3:4/L4:0/L5:2/L6:-/L7:2

이 분류 체계(Taxonomy)는 또한 7가지 위협(데이터 유출 (Data exfiltration), 공급망 침해 (Supply-chain compromise), 파괴적 작업 (Destructive operations), 측면 이동 (Lateral movement), 지속성 (Persistence), 권한 상승 (Privilege escalation), 서비스 거부 (Denial of service))을 명시적인 임계값과 함께 특정 계층 조합에 다시 매핑합니다. 따라서 "T1 유출이 해결되었는가"는 주관적인 판단이 아니라, L3, L4, L5가 모두 2점 이상의 점수를 통과하는지에 대한 기계적인 확인 과정입니다. 그리고 결정적으로, 이 체계는 구성 프레임워크 (Composition framework)를 함께 제공합니다. 단일 제품이 7개 계층 모두를 잘 다루는 경우는 없으므로, 하나의 도구가 모든 것을 해결할 수 있다고 가정하기보다는 제품들을 쌓아 올리고 각 계층에서 최대 점수를 취하는 것이 실질적인 지침입니다.

이것은 단순한 사고 실험도 아닙니다. 이 프로젝트는 26개의 실제 제품에 대한 점수가 매겨진 products.yaml 파일, 실제 샌드박스(Sandbox)를 대상으로 실행하여 주장을 검증할 수 있는 Go 기반의 검증 프로브(verification probe), 그리고 지문(fingerprints)을 나란히 비교할 수 있는 대화형 탐색기(interactive explorer)를 함께 제공합니다.

좋았던 점

강도(Strength) 척도에서 협력형(cooperative) 대 커널형(kernel) 대 구조적(structural) 구분은, OpenAI 사건에 대한 저의 원래 의견(hot take)에서 쓰고 싶었던 문장과 거의 정확히 일치합니다. 즉, 프로세스가 우회할 수 있는 프록시(proxy)는 애플리케이션 계층(application layer) 아래에서 강제되는 경계보다 근본적으로 약한 보증이며, 이 분류 체계(taxonomy)는 이러한 구분을 단순한 느낌(vibes)으로 남겨두는 대신 이름과 숫자로 부여합니다. 또한 프로젝트의 README에서 아직 커뮤니티 리뷰를 거치지 않았음을 명시하고 어떤 제품 점수가 검증되지 않았는지 표시하는 등, 자체적인 한계에 대해 솔직하다는 점도 마음에 듭니다. 그리고 구성 프레임워크(composition framework)의 핵심 발견인, 제품들이 "더 나은 상자 만들기" 또는 "상자 내부 제어하기"로 클러스터링(cluster)되며 두 가지를 모두 수행하는 제품은 거의 없다는 점은, 비밀 정보가 애플리케이션 계층 아래에 속한다고 생각하는 방식에서 기본 거부(default-deny) 및 커널 강제 네트워크 정책이 해결해야 하는 문제와 정확히 일치합니다.

좋지 않았던 점

좋지 않았던 점

실제로 이를 사용해 보았을 때 두 가지 간극이 두드러졌습니다. 첫째, 격리 (containment)가 실패한 _이후_에 어떤 일이 발생하는지에 대한 계층이 없습니다. 즉, 킬 스위치 (kill switch), 트리거 발생 시의 자동 자격 증명 순환 (automatic credential rotation), 또는 포렌식 롤백 런북 (forensic rollback runbook) 등이 없습니다. 분류 체계 (taxonomy)는 에이전트가 격리될 가능성이 있는지를 알려줄 뿐, 격리에 실패한 직후의 시간대(window)에 어떤 일이 일어나는지는 알려주지 않습니다. 그리고 그 시간대가 바로 OpenAI 사고가 발생했던 지점입니다. 둘째, L7 관측성 (Observability)은 로깅 (logging)이 존재하는지, 그리고 변조 방지 (tamper-evident)가 얼마나 잘 되는지를 평가하지만, 이상 징후가 실제로 인간에게 도달하는 속도는 평가하지 않습니다. 시스템이 L7에서 높은 점수를 받더라도 무언가를 인지하는 데 며칠이 걸릴 수 있으며, 이는 이번 사례에서 발생한 일과 유사해 보입니다. 이 두 가지 간극이 프로젝트 자체를 비난하는 것은 아닙니다. v1 버전으로서 합리적인 범위 설정 (scoping)이었으나, 제가 다음 단계로 표준이 확장되기를 바라는 두 지점입니다.

사고를 통한 검증

실제 연습은 다음과 같습니다: 공개된 정보만으로 OpenAI/Hugging Face의 평가 환경 (eval environment)을 지문 인식 (fingerprint) 할 수 있는가? 대부분 '아니오'이며, 이 간극 자체가 발견 사항입니다.

만약 당신의 에이전트가 가진 샌드박스 (Sandbox)가 공개적으로 이 7가지 계층에 대해 지문 인식 (Fingerprinting)을 받아야 한다면, 당신은 7개 중 실제로 몇 개에 답변할 수 있겠습니까?

다음 단계: 실험 실행

그렇다면, "샌드박스 처리됨 (sandboxed)"에 대한 표준 정의가 존재할까요? 결과는 '예'입니다. 충분히 근접한 수준입니다. 하지만 지문 형식 (fingerprint format)을 읽는 것과 그것을 신뢰하는 것은 별개의 문제입니다. 특히 분류 체계 (taxonomy) 자체의 products.yaml에 있는 거의 모든 항목이 evidence_level: docs를 포함하고 있다는 점을 고려하면 더욱 그렇습니다. 이는 해당 정보가 직접적인 테스트가 아닌, 문서와 마케팅 페이지로부터 추론되었음을 의미합니다. 이 블로그의 모든 연구와 마찬가지로, 다음 단계는 또 다른 의견을 제시하는 것이 아니라 실험을 수행하는 것입니다.

계획은 다음과 같습니다. 우리 자신의 결과를 신뢰하기 전에, 도구 자체를 검증할 것입니다. 이 프로젝트는 ast-probe라는 바이너리를 제공합니다. 이는 라이브 샌드박스 (sandbox) 내부에 배치하여 문서 기반의 추측 대신 검증된 지문 (verified fingerprint)을 얻을 수 있게 해주는 도구입니다. 우리는 먼저 데이터셋에서 이미 점수가 매겨진 몇 가지 제품을 대상으로 이를 실행하여, 분류 체계 자체의 발표된 수치를 재현할 수 있는지 확인할 것입니다. 만약 재현할 수 없다면, 이는 프로브 (probe) 또는 점수 산정 방식에 관한 발견이며, 이후의 결과들을 신뢰하기 전에 반드시 해결되어야 할 문제입니다.

해당 검증이 통과되면, 우리가 실제로 에이전트 툴링 (agent tooling)을 실행하는 방식인 기본 거부 (default-deny) 커널 네트워크 정책, 자격 증명 (credential) 처리, 전체 스택을 구성한 라이브 Coder 워크스페이스 (workspace)에 대해 동일한 프로브를 실행하고 그 결과로 나온 지문을 공개할 것입니다. 재현이 성공한다면, 우리는 분류 체계의 products.yaml에 대해 기본값인 docs 대신 evidence_level: verified를 포함한 PR (Pull Request)을 보낼 것입니다. 프로브 출력에 의해 뒷받침되는 벤더의 자체 평가 (vendor self-assessments)는 이 프로젝트가 기여자들에게 제출하도록 명시적으로 요구하는 사항이기 때문입니다.

그것이 실제 다음 포스트의 내용입니다. 단순한 견해가 아닌, 마지막에 점수표 (scorecard)를 동반한 실험이 될 것입니다.

수치로 보는 데이터

• 1 — 정의가 이미 존재하는지 물어본 후 초안 작성 도중 보류되었던 Thursday Thoughts의 파격적인 견해 (hot take)
• 7-7-3 — 분류 체계(taxonomy) 자체의 약어: 7개의 방어 계층 (defense layers), 7개의 위협 범주 (threat categories), 3개의 평가 차원 (evaluation dimensions)
• 26 — 2026년 3월 v1.0 출시 기준, 분류 체계의 데이터셋에서 점수가 매겨진 실제 제품 수
• 5일 — Hugging Face가 침입을 감지한 시점과 OpenAI가 이를 자사의 테스트와 공개적으로 연결한 시점 사이의 간격 (현재 분류 체계에서는 점수를 매기지 않는 정확한 지연 시간 (latency))
• 3 — OpenAI의 공개 발표를 통해 우리가 확신을 가지고 추정할 수 있는 7개 계층 중의 수; 나머지 4개는 단순히 미지의 영역임
• 2 — v2에서 수정되기를 바라는 격차 (gaps): 사고 대응/킬 스위치 (incident-response/kill-switch) 계층, 그리고 탐지 지연 시간 (detection-latency) 하위 점수
• 1 — 우리가 실제로 조사를 실행할 샌드박스 (sandbox): 바로 우리 자신의 것
• 0 — 이 포스트에서 의도적으로 만들어낸 새로운 표준 (new standards)