**AI 에이전트 샌드박싱 (AI agent sandboxing)**이란 자율적인 AI 에이전트를 격리되고 통제된 환경 내부에서 실행하는 것을 의미합니다. 기본적으로 네트워크가 차단되어 있고, 범위가 제한된 단기 자격 증명(short-lived credentials), 잠긴 파일 시스템(locked-down filesystem), 리소스 및 예산 제한(resource and budget caps), 그리고 일회용 인프라(disposable infrastructure)를 사용합니다. 에이전트가 실수하거나 탈취된 명령을 수행하는 것을 포함하여 무엇을 하든, 그 결과는 박스(box) 안에 머무릅니다. 이의 대안은 인간이 잘못된 동작을 알아차리고 제때 "거부"를 클릭할 것이라는 안전성에 도박을 거는 것인데, 에이전트는 어떤 인간이 검토할 수 있는 속도보다 더 빠르고, 더 자주, 그리고 더 불투명하게(opaquely) 행동합니다. 샌드박스는 안전 경계(safety boundary)를 개별 동작 프롬프트(per-action prompt)에서 환경(environment)으로 옮기며, 이는 에이전트가 잘못되었을 때도 유지됩니다. **AI 에이전트를 샌드박싱(sandbox AI agents)**하면, 최악의 상황도 통제된 상황이 됩니다.

이 모든 것은 LoopRails 프레임워크의 한 가지 질문으로 귀결됩니다: 인간이 현실적으로 이 실수를 제때 잡아낼 수 있는가? 정직한 답변이 "아니오"일 때, 당신은 결과를 게이트(gate)로 막는 대신 결과 자체를 방지(prevent)하게 되며, 샌드박스는 이를 방지하는 가장 신뢰할 수 있는 방법입니다.

AI 에이전트 샌드박싱의 목적

자율 에이전트는 자신의 다음 동작을 스스로 결정합니다. 에이전트는 읽고, 쓰고, 셸 명령(shell commands)을 실행하고, API를 호출하며, 돈을 쓰고, 네트워크와 통신합니다. 이 각각은 하나의 기능(capability)이며, 버그가 있는 계획, 환각(hallucination)을 일으킨 단계, 또는 에이전트가 읽은 콘텐츠에 명령을 몰래 끼워 넣은 공격자에 의해 어떤 기능이든 오용될 수 있습니다. 샌드박스는 이러한 기능들을 제한하여 오용이 외부로 탈출할 수 없도록 만듭니다.

당신은 에이전트의 행동을 제어하려고 하는 것이 아닙니다. 적대적인 입력(adversarial input) 하에서 LLM의 행동을 신뢰성 있게 제어하는 것은 불가능합니다. 왜냐하면 데이터와 명령어 사이에 명확한 경계가 없기 때문입니다. 할 수 있는 것은 잘못된 행동이 무해하도록 만드는 것입니다. 네트워크 외부 통신(network egress)이 없다면 데이터를 유출할 수 없습니다. 읽기 전용의 만료되는 자격 증명(read-only expiring credentials)을 사용한다면 공유 상태를 손상시킬 수 없습니다. 일회성 VM에서는 환경이 복구되기보다 재구축됩니다. 이것이 LoopRails의 Sandbox-First 패턴입니다: 에이전트를 신뢰하기 전에 격리된 환경에서 실행하는 것입니다. 이는 에이전트가 무엇을 하든 상관없이 작동하므로, 여러분이 가진 가장 영향력 있는 제어 수단입니다.

이를 YOLO Cliff 안티패턴과 비교해 봅시다. YOLO Cliff는 아무것도 담지 않은 완전한 자율성을 의미하며, 여기서 첫 번째 잘못된 행동은 피해가 발생하기 직전의 마지막 순간입니다. 샌드박스는 추락을 격리된 상태로 만듭니다.

왜 샌드박싱이 액션별 승인 프롬프트보다 우월한가

에이전트가 위험해지면 사람들은 '중요한 일을 하기 전에 나에게 물어봐'와 같은 인간의 검토 지점(human checkpoint)을 추가하는 경향이 있습니다. 이것은 감독처럼 느껴집니다. 하지만 샌드박스는 다음 세 가지 이유 때문에 이 과정 자체가 무용지물인 경우가 많습니다.

양과 속도. 에이전트는 사람이 검토하는 것보다 훨씬 빠르게 행동을 생성합니다. 수십 개의 프롬프트에 직면하면 사람들은 대충 승인(rubber-stamp)하게 되고, 그중 유해한 행동 하나가 잡음 속에 숨어버립니다. 샌드박스는 액션별 주의를 필요로 하지 않습니다. 모든 행동을 한 번에 제약합니다.

행동이 무해해 보인다. 'URL 가져오기' 또는 '스크립트 실행'은 에이전트가 해야 할 정확한 일입니다. 승인자는 정상적인 행동만 보고, 그 뒤에 숨겨진 명령어나 페이로드(payload)에 담긴 데이터를 보지 못합니다. 볼 수 없는 것은 잡을 수 없습니다. 외부 통신이 차단된 샌드박스는 누군가가 명령어를 알아차렸는지 여부와 관계없이 데이터 유출을 막습니다.

속도와 비가역성. 많은 유해한 행동은 실행되는 즉시 발생합니다. 사람이 프롬프트를 읽을 때쯤이면 돈은 이미 쓰였거나 데이터는 사라진 후입니다. 예방은 피해보다 먼저 작동하고, 검토는 그 후에 작동합니다.

이것이 LoopRails가 취하는 핵심적인 움직임입니다. 인간이 취약한 탐지기 역할을 수행하게 되는 프롬프트 단계에 안전 점검(safety check)을 두지 말고, 규칙이 강제되는 환경(environment)에 두십시오. 왜 "인간이 루프 안에 있는가(human in the loop)?"가 잘못된 질문이며, "인간이 제때 잡아낼 수 있는가?"가 올바른 질문인지에 대해서는 프레임워크를 참조하십시오. 샌드박스(sandbox)는 "아니요, 그래서 우리는 대신 이를 방지했습니다"라고 답할 수 있게 해주는 방법입니다.

좋은 샌드박스의 구성 요소

샌드박스는 단일 스위치가 아니라 제약 사항(constraints)의 스택입니다. **AI 에이전트를 샌드박싱 (sandbox AI agents)**하려면, 각각의 제약이 서로 다른 탈출 경로를 차단하므로 다음의 모든 요소를 포함해야 합니다.

기본적으로 네트워크 차단 (No network by default). 가장 가치 있는 단일 통제 수단입니다. 외부로 나가는 통로(egress)가 없으면 에이전트는 데이터를 어디로도 보낼 수 없고, 공격자의 서버에 접속하거나 알 수 없는 API를 호출할 수 없습니다. 작업별로 명시적인 허용 목록(allowlist)에 대해서만 네트워크를 개방하고, 그 외의 모든 것은 거부하십시오. 기본적으로 외부 통로를 거부(Default-deny egress)하면 (아래에서 설명할) 치명적인 삼각 관계(lethal trifecta) 중 네트워크 요소를 제거할 수 있습니다.

범위가 제한된 단기 자격 증명 (Scoped, short-lived credentials). 에이전트는 작업에 필요한 최소한의 권한(least privilege)만을 보유하며 그 이상은 갖지 않습니다. 쓰기 권한이 필요하지 않은 곳에는 읽기 전용 권한을 부여하고, 토큰의 범위를 좁히며, 상시 운영 환경(production) 접근 권한을 부여하지 않으며, 짧은 시간 내에 만료되는 자격 증명을 사용합니다. 에이전트가 가지지 않은 자격 증명은 오용될 수 없습니다. 만료된 자격 증명은 재사용(replay)될 수 없습니다. 이것이 경계(boundary)에서 강제되는 Authorized RAIL 및 역량 잠금 (Capability Lock) 패턴입니다.

파일 시스템 격리 (Filesystem isolation). 에이전트를 탈출할 수 없는 작업 공간(workspace)에 가두십시오. 홈 디렉토리, SSH 키, 다른 프로젝트 또는 호스트의 비밀 정보(secrets)에 접근할 수 없어야 합니다. 범위가 제한된 컨테이너(container)나 VM 파일 시스템을 사용하면, rm -rf와 같은 파괴적인 명령이나 과도한 "정리(cleanup)" 작업이 발생하더라도 사용자의 기기가 아닌 폐기 가능한 작업 공간만을 파괴하게 됩니다.

리소스 및 예산 제한 (Resource and budget caps). CPU, 메모리, 실행 시간 (runtime), API 비용 (API spend), 그리고 작업 속도 (action rate)를 제한하십시오. 이러한 제한은 통제 불능 상태가 재앙이 아닌, 작고 경계가 있는 사건으로 변하도록 만듭니다. 이것이 바로 폭발 반경 제한 (Blast-Radius Cap) 패턴입니다. 2012년 Knight Capital 사건—제어되지 않은 채 실행된 결함 있는 트레이딩 소프트웨어가 약 45분 만에 약 4억 4천만 달러를 손실했으며 이를 멈출 방법조차 없었던 사건—은 프로덕션 환경에서 제한 장치가 없는 에이전트가 어떤 모습인지를 보여주는 전형적인 사례입니다.

휘발성 및 폐기 가능한 환경 (Ephemeral, disposable environments). 샌드박스를 '애완동물(pets)'이 아닌 '가축(cattle)'처럼 취급하십시오. 즉, 작업마다 새로운 컨테이너나 VM (가상 머신)을 생성하여 실행한 뒤 즉시 파괴하는 방식입니다. 공격자가 지속적으로 머무를 수 있는 누적된 상태(accumulated state)가 존재하지 않으며, 잘못된 실행에 대한 복구 방식은

• 인코딩 (Encoding). 차단된 명령어를 Base64로 인코딩한 뒤, 실행 시점에 이를 디코딩하여 셸(shell)로 파이프(pipe) 연결함으로써 금지된 문자열이 그대로 나타나지 않게 합니다.
• 서브셸 (Subshells). 명령어를 중첩하거나 감싸서 외부 문자열이 차단된 패턴과 일치하지 않도록 만듭니다.
• 생성된 스크립트 (Generated scripts). 에이전트가 금지된 동작을 포함하는 스크립트를 작성한 다음, 필터로부터 한 단계 떨어진 상태에서 해당 스크립트를 실행합니다.
• 인용 및 분할 (Quoting and splitting). 명령어를 분해하거나 다시 인용(re-quoting)하여 단순한 문자열 매칭(string matching)을 무력화합니다.

이것이 바로 차단 목록 연극 (Denylist Theater) 안티 패턴(anti-pattern)입니다. 차단 목록(denylist)은 당신이 생각한 나쁜 것들을 나열할 뿐입니다. 공격자나 목표를 위해 논리적 근거를 찾아가는 에이전트는 당신이 생각하지 못한 단 하나의 예외만 있으면 됩니다. 샌드박스(sandbox)는 명령어가 얼마나 교묘하게 표현되었는지에 상관하지 않습니다. 네트워크 유출(network egress)이 불가능하고 쓰기 권한(write credential)이 없다면, 난독화된 데이터 유출(exfiltration) 명령은 일반적인 명령과 마찬가지로 실패합니다. 왜냐하면 실패하는 이유는 문자열(string) 때문이 아니라, 권한(capability)이 없기 때문입니다. 경계는 필터가 아니라 환경(environment)입니다. 차단 목록을 권한 제거(capability removal)로 대체하십시오. 차단 목록은 기껏해야 UX 측면의 속도 저하 요소(speed bump)로만 사용해야 하며, 결코 보안 계층(security layer)으로 사용해서는 안 됩니다. 플레이북(playbook)에서는 차단 목록에서 진정한 허용 목록(allowlist) 및 샌드박스 조합으로 전환하는 방법을 다룹니다.

샌드박싱과 치명적인 삼중주 (Sandboxing and the lethal trifecta)

샌드박싱 (Sandboxing)은 **치명적인 삼중주 (lethal trifecta)**를 해결하는 가장 깔끔한 방법입니다. 개인 데이터 접근 권한, 직접 작성하지 않은 신뢰할 수 없는 콘텐츠에 대한 노출, 그리고 외부 통신 채널이 결합된 에이전트는 프롬프트 인젝션 (Prompt Injection)을 통해 해당 데이터를 유출하도록 조종될 수 있습니다. 이때 악의적인 지침이 인간이 결코 읽지 않을 콘텐츠 속에 숨겨져 있기 때문에, 그 어떤 승인 프롬프트도 이를 안정적으로 잡아낼 수 없습니다. 이 삼중주 중 단 하나의 요소만 제거해도 공격은 무산됩니다. 네트워크가 없는 샌드박스는 외부 통신 요소를 완전히 제거합니다. 범위가 제한된 자격 증명 (Scoped credentials)은 개인 데이터 접근 요소를 제거합니다. 작동 메커니즘에 대해서는 치명적인 삼중주 (the lethal trifecta)와 프롬프트 인젝션 방지 (prompt injection prevention)를, 이것이 다른 통제 수단들과 어떻게 병행되는지에 대해서는 더 광범위한 가드레일 체크리스트 (the broader guardrails checklist)를 참조하세요.

샌드박싱이 등급(Grades) 및 RAIL에 매핑되는 방식

샌드박싱은 전부 아니면 전무 (all-or-nothing) 식의 방식이 아닙니다. 작업의 가치에 비례하여 적용합니다. LoopRails는 가역성 (reversibility), 폭발 반경 (blast radius), 그리고 위험도 (stakes)에 따라 모든 작업을 G0에서 G3까지 등급을 매기며, 등급이 높아질수록 샌드박스 요구 사항도 높아집니다. 대화형 등급 판정기 (interactive grader)를 사용하여 에이전트의 작업 등급을 설정해 보세요.

• G0 (사소함, trivial): 파일 읽기, 읽기 전용 쿼리 실행. 로깅 (Logging)만으로 충분하며, 샌드박스는 선택 사항입니다.
• G1 (낮음, low): 로컬 파일 수정, 테스트 실행. 범위가 제한된 워크스페이스 (Scoped workspace)와 가역성 (체크포인트/실행 취소)만으로 충분합니다.
• G2 (높음, high): git push, 예산 범위 내 지출, 공유 상태 수정. '샌드박스 우선 (Sandbox-First)' 원칙이 실질적인 요구 사항이 됩니다. 즉, 격리된 환경, 범위가 제한된 자격 증명, 예산 및 속도 제한 (rate caps)이 필요합니다.
• G3 (치명적, critical): 운영 환경(prod) 배포, 데이터 삭제, 외부 메시지 전송, 결제 실행. 예방을 최우선으로 합니다. 이 등급에서는 검토 (review)만으로는 함정에 빠질 수 있으므로, 상시 운영 자격 증명(standing production credentials)을 두지 않고, 기본 거부 방식의 외부 유출 차단 (default-deny egress), 그리고 엄격한 폭발 반경 제한 (hard blast-radius caps)을 포함한 샌드박스 적용이 필수적입니다. 인간이 제때 실수를 잡아낼 수 없다면, 이를 격리하거나 금지해야 합니다.

이러한 추세가 핵심입니다. 자율성(Autonomy)과 등급이 높아질수록, 샌드박스는 선택 사항이 아니라 필수적인 하중 지지 제어 장치(load-bearing control)가 됩니다. 이는 높은 자율성이 인간이 개입할 수 있는 시간과 맥락을 더 적게 남기기 때문입니다.

샌드박싱은 또한 모든 통제된 작업이 유지해야 하는 RAIL 속성을 강화합니다: Reversible (가역성), Authorized (권한 부여), Interruptible (중단 가능성), Logged (기록).

• Reversible (가역성): 일회용의 휘발성 환경(ephemeral environment)은 잘못된 실행을 파괴 후 재생성함으로써 복구 가능하게 만듭니다.
• Authorized (권한 부여): 범위가 제한된(scoped) 단기 자격 증명은 경계에서 최소 권한 원칙(least privilege)을 강제하여, 에이전트가 실제로 부여받은 권한만을 보유하도록 합니다.
• Interruptible (중단 가능성): 샌드박스는 종료(kill)할 수 있습니다. 폭주하는 에이전트와 협상할 필요 없이 컨테이너를 철거하고 자격 증명을 취소하십시오. 환경 자체가 킬 스위치(kill switch)의 집행 표면(enforcement surface)이 됩니다 (AI 킬 스위치 참조).
• Logged (기록): 송출 제어(egress control)와 격리된 환경은 에이전트가 무엇을 했고 무엇이 박스 외부로 나갔는지 기록할 수 있는 초크포인트(chokepoint, 병목 지점)를 제공합니다.

샌드박스 설정 체크리스트

실질적인 자율성을 가진 에이전트를 실행하기 전에, 다음 목록을 검토하십시오: