BoxAgnts Runtime (3) — WebAssembly: AI 에이전트를 위한 더 나은 샌드박스

AI 에이전트(AI agents)는 점점 더 텍스트 생성을 넘어 확장되고 있습니다. 현대적인 에이전트 시스템은 코드를 실행하고, 파일을 조작하며, 웹을 탐색하고, API를 호출하며, 인프라를 관리하고, 분산된 작업을 조정할 수 있습니다. 에이전트가 실제 환경과 상호작용하기 시작하면, 실행 안전성(execution safety)은 프롬프트의 문제에서 시스템 수준의 문제로 전환됩니다.

대부분의 현재 구현 방식은 Python 서브프로세스(subprocesses), 쉘 명령(shell commands), 그리고 컨테이너 격리(container isolation)에 의존합니다. 이러한 방식들은 인간이 제어하는 소프트웨어를 위해 설계된 것으로, LLM(Large Language Model) 기반의 확률적 실행 시스템(probabilistic execution systems)에는 적합하지 않습니다.

WebAssembly(WASM)가 가장 강력한 후보로 떠오르고 있습니다. 이는 단순히 유행이기 때문이 아니라, WebAssembly의 실행 의미론(execution semantics)이 AI 인프라의 보안 요구 사항과 놀라울 정도로 잘 일치하기 때문입니다.

전통적인 에이전트 실행의 문제점

대부분의 에이전트 런타임(runtimes)은 결국 다음과 같은 익숙한 아키텍처로 수렴합니다:

LLM → 도구 호출 (Tool Call) → Python 런타임 (Python Runtime) → 쉘 (Shell) / 파일 시스템 (Filesystem) / 네트워크 (Network)

전통적인 도구 실행은 지속적인 문제들을 야기합니다: 제한 없는 호스트 상호작용, 의존성 충돌, 환경적 불일치, 취약한 격리 경계, 어려운 리소스 거버넌스(resource governance). 실행 결정이 LLM으로부터 비롯될 때 상황은 더욱 악화됩니다. LLM은 프롬프트 조작(prompt manipulation)에 민감하며, 실행 경로가 확률적이고, 외부 컨텍스트가 동작을 변경할 수 있기 때문입니다.

BoxAgnts는 이러한 아키텍처를 완전히 버립니다. boxagnts/wasm-tools/src/wasm_tool.rs를 보면 각 도구는 독립적인 WASM 모듈입니다:

pub struct WasmTool {
    name: String,
    wasm_file: String,      // WASM 바이너리 경로
...

이것은

컨테이너(Containers)는 파일 시스템 분리, 프로세스 네임스페이스(process namespaces), 네트워크 격리(network isolation), 그리고 재현 가능한 배포(reproducible deployment)를 제공합니다. 하지만 컨테이너 내부에서도 에이전트가 도구를 오용하거나, 의도하지 않은 리소스에 접근하고, 데이터를 유출하며, 위험한 작업을 재귀적으로 호출할 수 있는 등 여전히 상대적으로 넓은 실행 표면(execution surfaces)을 노출합니다.

컨테이너는 "이 프로세스가 어떤 환경 내부에서 실행되는가?"라는 질문에 답합니다.

AI 런타임(runtime)은 "이 에이전트가 정확히 어떤 작업들을 수행하도록 허용되는가?"라는 질문에 답해야 합니다.

BoxAgnts의 WASM 샌드박스(sandbox)는 두 번째 질문에 답하도록 설계되었습니다. 이는 OS 레벨의 프로세스 격리(process isolation)에 의존하지 않습니다. 대신 프로세스보다 세밀하고(finer-grained) 컨테이너보다 가벼운(lighter) Wasmtime 가상 머신(virtual machine) 계층에서 경계를 구축합니다.

WebAssembly의 보안 모델

기본적으로 WASM 모듈은 다음과 같은 제약을 가집니다:

• 임의의 메모리에 접근할 수 없음
• 파일 시스템에 접근할 수 없음
• 네트워크 연결을 열 수 없음
• 프로세스를 생성(spawn)할 수 없음
• 호스트 시스템과 직접 상호작용할 수 없음

외부 세계와의 모든 상호작용은 반드시 런타임에 의해 명시적으로 허용되어야 합니다.

이 "기본 거부(default-deny)" 모델은 AI 에이전트의 보안 요구 사항과 자연스럽게 일치합니다. BoxAgnts의 RunOption 구조체(struct)는 이러한 철학을 코드로 구현한 것입니다:

// boxagnts/wasm-sandbox/src/run.rs
pub struct RunOption {
    pub work_dir: Option<String>,
...

모든 것은 명시적으로 허용됩니다. work_dir이 설정되지 않았나요? WASM 모듈은 어떤 파일도 볼 수 없습니다. allowed_outbound_hosts가 없나요? 모든 네트워크 요청이 차단됩니다. wasm_timeout이 없나요? 장시간 실행되는 작업은 종료됩니다.

기능 주입(Capability Injection): 진정한 핵심 기능

현대적인 WASM 런타임의 가장 중요한 속성은 이식성(portability)이 아니라, 바로 **기능 주입(capability injection)**입니다.

런타임은 파일 시스템 접근, 네트워크 접근, 환경 변수(environment variables), 지속성 저장소(persistent storage) 등을 다음과 같이 세밀한 제어와 함께 선택적으로 제공할 수 있습니다:

read:/workspace/docs
write:/workspace/tmp
fetch:https://api.example.com

BoxAgnts의 각 WASM 도구는 고유하고 독립적인 권한 세트(capability set)를 가집니다. WasmTool::execute에서 ToolContext에 의해 제공되는 설정은 RunOption으로 정확하게 매핑됩니다:

let work_dir = ctx.get_work_dir().await;           // 작업 디렉토리만 노출
let allowed_outbound_hosts = ctx.get_allowed_outbound_hosts();  // 네트워크 허용 목록 (allowlist)
let cache_dir = ctx.get_app_cache_dir().await;      // 캐시 디렉토리

모듈은 부여받은 권한을 초과할 수 없습니다. 이는 전통적인 서브프로세스(subprocess) 실행과는 근본적으로 다릅니다. 서브프로세스는 부모로부터 권한을 상속받지만, WASM 모듈은 제로(zero) 상태에서 시작합니다.

결정론적 실행 (Deterministic Execution)

현대적인 에이전트들은 종종 종속성(dependencies)을 동적으로 설치하고, 런타임 상태(runtime state)를 수정하며, 임시 코드를 생성합니다. 이는 재현성(reproducibility)을 거의 불가능하게 만듭니다.

WebAssembly 모듈은 자급자족적(self-contained)이며, 플랫폼 독립적이고, 런타임 제약이 있으며, 명시적으로 권한을 부여받습니다. 이는 동일한 WASM 도구가 로컬 개발 환경, 클라우드 서버, 엣지 디바이스, 심지어 브라우저에 이르기까지 어디에서나 동일하게 동작함을 의미합니다.

BoxAgnts는 app/extensions/tools/ 경로에 7개의 내장 WASM 도구를 포함하여 제공합니다:

file-read-component.wasm     ← 파일 읽기 (대용량 파일을 위한 페이지네이션 지원)
file-write-component.wasm    ← 파일 쓰기
file-edit-component.wasm     ← 정확한 문자열 치환 편집
...

각 도구는 한 번 컴파일되면 어디서든 실행되며 일관되게 동작합니다. 이는 AI 인프라의 감사(auditing), 디버깅(debugging), 재생(replay) 및 거버넌스(governance)에 있어 매우 중요합니다.

WASI: 실행 형식에서 실용적인 런타임으로

WASM 자체는 단순한 바이너리 형식일 뿐입니다. WASI (WebAssembly System Interface)는 이를 실용적인 런타임으로 확장하여 파일 시스템, 네트워킹, 시계, 난수 생성, 스트림 및 환경 변수에 대한 표준화된 인터페이스를 도입합니다.

더 중요한 점은, WASI가 **권한 지향 원칙 (capability-oriented principles)**을 중심으로 설계되었다는 것입니다. 리소스는 기본적으로 전역적으로 접근할 수 없으며, 반드시 명시적으로 제공되어야 합니다. BoxAgnts의 WASM 런타임은 RunCommon 설정을 통해 WASI 지원을 활성화합니다:

// boxagnts/wasm-sandbox/src/run.rs
run_common.common.wasi.cli = Some(true);
run_common.common.wasi.http = Some(true);
...

HTTP는 기본적으로 활성화되어 있지 않으며, 명시적인 wasi.http = Some(true) 설정이 필요합니다. 활성화된 상태에서도 외부 연결(outbound connections)은 allowed_outbound_hosts 및 block_networks에 의해 제한됩니다.

전통적인 운영 체제(Operating Systems)는 신뢰할 수 있는 인간 사용자를 중심으로 발전해 왔습니다. 하지만 AI 에이전트는 인간 사용자가 아닙니다. 대규모 언어 모델(LLMs)은 민감한 파일, 권한이 부여된 API, 그리고 프로덕션 인프라를 신뢰성 있게 구분할 수 없습니다. AI 시스템은 전통적인 소프트웨어보다 더 엄격하고 세밀한 실행 경계(execution boundaries)를 필요로 합니다.

리소스 거버넌스 (Resource Governance)

현대의 에이전트는 재귀 루프(recursive loops), 과도한 작업, 과도한 메모리 사용, 폭주하는 API 트래픽 등 놀라울 정도로 불안정한 워크로드를 생성할 수 있습니다. BoxAgnts는 WASM 런타임을 통해 다층적인 리소스 거버넌스를 제공합니다:

wasm_timeout        → 장기 실행(long-running execution) 방지
wasm_max_memory_size → 메모리 팽창(memory bloat) 방지
wasm_max_wasm_stack → 스택 오버플로(stack overflow) 방지
...

wasm_fuel은 특히 우아한 설계입니다. 각 WASM 명령어는 1 단위의 연료(fuel)를 소비하며, 연료가 고갈되면 실행이 트랩(trapped)되어 종료됩니다. 이는 블록체인의 가스(gas) 메커니즘과 동일한 원리로 작동하며, 무한 루프와 서비스 거부(DoS) 공격을 효과적으로 방지합니다.

멀티 에이전트 격리 (Multi-Agent Isolation)

BoxAgnts의 관리형 에이전트(Managed Agent) 모드는 병렬로 실행되는 여러 개의 실행기(Executors)를 지원합니다. 각 실행기는 독립적인 메모리, 독립적인 기능(capabilities), 독립적인 생명주기(lifecycles)를 가진 자체 WASM 샌드박스 내에서 실행됩니다.

이러한 격리는 사후 고려 사항이 아니라, RunOption 생성 시점에 아키텍처에 내장되어 있습니다. 운영 체제의 프로세스 격리(process isolation)와 마찬가지로, 하나의 실행기가 충돌하거나 권한을 위반하더라도 다른 실행기로 연쇄 반응이 일어나지 않습니다.

결론

WebAssembly가 AI 에이전트를 위한 더 나은 샌드박스인 이유는 단순히 그것이 "새롭기" 때문이 아니라, 기본적으로 권한이 없는 제로 권한(zero permissions), 명시적인 기능 주입(capability injection), 엄격한 리소스 제한, 결정론적 동작(deterministic behavior)을 갖춘 보안 모델(security model) 때문입니다.

BoxAgnts의 아키텍처 설계 방식은 이 경로의 실현 가능성을 입증합니다: 모든 도구는 통합된 Tool 트레이트(trait)를 통해 등록되며, 모든 WASM 도구는 통합된 RunOption 제약 조건 하에서 실행되고, 모든 런타임 리스크는 샌드박스 경계에서 차단됩니다.

리소스

• BoxAgnts: https://github.com/guyoung/boxagnts