BoxAgnts Runtime (4) — 루트 권한이 아닌 권한 기반 보안 (Capability Security)

현대의 AI 에이전트들은 셸 명령 실행, 리포지토리(repository) 수정, 로컬 파일 접근, 클라우드 인프라 운영, 개발 환경 관리 등 운영 권한을 빠르게 확보하고 있습니다.

문제는 대부분의 AI 인프라가 여전히 **신뢰할 수 있는 인간 운영자(trusted human operators)**를 위해 설계된 보안 모델에 의존하고 있다는 점입니다. 그 가정은 더 이상 유효하지 않습니다.

LLM(Large Language Models)은 신뢰할 수 있는 실행 권한 주체가 아닙니다. LLM은 프롬프트 인젝션 (prompt injection), 적대적 컨텍스트 (adversarial context), 신뢰할 수 없는 문서, 조작된 도구 출력, 그리고 추론 불안정성에 노출된 확률적 시스템입니다. 그럼에도 불구하고 많은 AI 에이전트들은 여전히 루트 (root) 권한과 맞먹는 특권으로 실행되고 있습니다.

이것은 도구의 문제가 아니라, 보안 아키텍처 (security architecture)의 문제입니다.

대부분의 AI 에이전트 내부에 숨겨진 가정

BoxAgnts의 쿼리 루프 (query loop)는 LLM이 어떻게 런타임 컨트롤러 (runtime controllers)가 되는지를 명확하게 보여줍니다. 즉, 모델이 어떤 도구를 호출할지, 어떤 인자를 전달할지, 어떤 리소스에 접근할지를 결정합니다. boxagnts/query/src/query.rs 코드를 보면 다음과 같습니다:

// 매 턴마다 모델이 생성한 콘텐츠를 파싱합니다.
// 만약 tool_use 블록이 포함되어 있다면, 시스템은 해당 도구를 실행합니다.
for tool_use_block in tool_uses {
...

핵심적인 문제는 런타임이 일반적으로 모델에게 지나치게 광범위한 암묵적 권한—제한 없는 파일 시스템, 제한 없는 네트워크, 제한 없는 셸—을 부여한다는 점입니다. LLM은 운영 리스크 (operational risk), 권한 상승 (privilege escalation), 운영 환경의 안전성 (production safety), 또는 조직적 경계를 이해하지 못합니다. 단지 그럴듯한 연속성을 예측할 뿐입니다.

프롬프트 인젝션이 광범위한 권한을 더 위험하게 만든다

악의적인 지침은 웹페이지, 마크다운 (Markdown) 파일, 소스 코드, 이메일, PDF, 그리고 API 응답에 포함될 수 있습니다. 모델은 프롬프트만으로는 "신뢰할 수 있는 지침"과 "악의적인 지침"을 안정적으로 구분할 수 없습니다.

따라서 핵심 질문은 "모델이 가끔 안전하게 행동할 수 있는가?"가 아닙니다. 핵심은 제한 없는 권한이 모든 추론 실패를 증폭시킨다는 것입니다. 목표는 모델을 신뢰할 수 있게 만드는 것이 아니라, 안전하지 않은 행동을 격리 가능한 상태로 만드는 것입니다. 이를 위해서는 권한 경계 (capability boundaries)가 필요합니다.

BoxAgnts의 에이전트 도구 설계(boxagnts/tools/src/agent/mod.rs)는 이 원칙을 구현하고 있습니다. 에이전트는 특정 도구 세트만 허용하는 tools 제한을 설정할 수 있고, max_turns 하드 캡(hard caps)을 설정할 수 있으며, 격리된 Git 워크트리(worktree)에서 실행되도록 isolation: "worktree"를 선택할 수 있습니다. 이들은 모두 권한 제약(capability constraints)의 사례입니다.

#[derive(Debug, Deserialize)]
struct AgentInput {
    description: String,
...

전통적인 접근 제어는 충분하지 않습니다

RBAC(역할 기반 접근 제어), ACL(액세스 제어 목록), IAM(ID 및 액세스 관리) — 이러한 ID 기반 보안 모델은 안정적인 ID, 예측 가능한 워크플로, 그리고 인간 운영자를 가정합니다. 하지만 AI 에이전트는 이 세 가지를 모두 위반합니다. 즉, 워크플로를 동적으로 생성하고, 확률적으로 도구를 호출하며, 여러 에이전트 간에 협업합니다.

BoxAgnts의 PermissionMode 설정은 더 유연한 접근 방식을 제공합니다:

pub enum PermissionMode {
    BypassPermissions,   // 권한 확인 건너뛰기 (프로덕션 환경에서는 권장되지 않음)
    Default,             // 표준 권한 확인
...

하지만 이 모델조차 충분히 세밀하지 않습니다. 실제로 필요한 것은 "에이전트는 /workspace/project를 읽을 수 있고, /workspace/tmp에 쓸 수 있으며, ~/.ssh에 접근할 수 없고, 프로덕션 비밀 정보(production secrets)에 접근할 수 없다"와 같은 정밀한 기술입니다.

권한 기반 보안 (Capability Security): "당신은 누구인가?"에서 "당신은 무엇을 할 수 있는가?"로

권한 기반 보안(Capability Security)의 핵심 아이디어는 간단합니다. 에이전트에게 루트(root) 비밀번호를 주지 말고, 정밀한 권한 목록을 주는 것입니다.

BoxAgnts의 WASM 실행 모델은 이 아이디어를 공학적으로 구현한 것입니다. RunOption에서 모든 권한은 명시적으로 선언됩니다:

work_dir            → 파일 시스템 권한 (Filesystem capability): 지정된 디렉토리만 노출
allowed_outbound_hosts → 네트워크 권한 (Network capability): 허용 목록(allowlist) 방식의 외부 연결
env_vars            → 환경 권한 (Environment capability): 환경 변수를 선택적으로 전달
...

네트워크 수준의 권한 제어는 특히 세밀합니다. boxagnts/wasm-sandbox/src/extension/net.rs를 살펴보십시오:

// 외부 연결 확인
pub async fn socket_addr_check(
    addr: SocketAddr,
...

모델은 이러한 제약 사항을 무시할 수 없습니다—LLM이 프롬프트 내에서 어떻게 "추론(reasoning)"하든 상관없이, WASM 샌드박스(sandbox)의 TCP 바인딩(bind)은 항상 false를 반환합니다. 이것이 권한 기반 보안(capability security)의 핵심적인 장점입니다. 즉, 보안은 모델의 의도에 의존하는 것이 아니라, 런타임 강제(runtime enforcement)에 의존합니다.

권한 기반 보안 (Capability Security) vs. 인간 중심 보안 (Human-Centered Security)

전통적인 운영 체제는 신뢰할 수 있는 인간 사용자를 중심으로 발전해 왔습니다. 인간은 맥락적 이해, 조직적 인식, 장기적 추론 및 책임감을 갖추고 있습니다. 하지만 LLM은 이 중 어느 것도 갖추고 있지 않습니다. LLM은 특정 파일이 민감한지, 명령어가 위험한지, 혹은 API 호출이 정책을 위반하는지를 일관되게 평가할 수 없습니다.

이것이 바로 권한 기반 보안이 RBAC(역할 기반 액세스 제어)보다 AI에 더 적합한 이유입니다. 권한 기반 보안은 모델의 판단에 대한 의존성을 끊어냅니다. 이는 에이전트가 올바른 결정을 내리기를 기대하는 것이 아니라, 런타임이 가능한 결정의 범위를 제한하도록 보장하는 것입니다. 보안은 모델 정렬(model alignment)에 의존해서는 안 되며, 런타임 보장(runtime guarantees)에 의존해야 합니다.

BoxAgnts의 ToolContext에는 이러한 설계 의도가 반영된 모든 요소가 포함되어 있습니다:

pub struct ToolContext {
    pub permission_mode: PermissionMode,
    pub session_id: Option<String>,
...

모든 도구 실행에는 이 컨텍스트가 수반됩니다. allowed_outbound_hosts와 block_url은 단순한 권장 사항이 아니라, WASM 런타임으로 전달되는 엄격한 제약 사항(hard constraints)이라는 점에 유의하십시오.

멀티 에이전트 시스템에서의 권한 경계 (Capability Boundaries)

BoxAgnts의 관리형 에이전트(Managed Agent) 모드에서 매니저(Manager)는 여러 실행기(Executor)에게 작업을 분배합니다. 각 실행기는 서로 다른 권한 세트, 서로 다른 모델, 서로 다른 도구 액세스 권한을 가질 수 있습니다.

boxagnts/query/src/managed_orchestrator.rs에서 시스템 프롬프트는 이러한 계층 구조를 명시적으로 정의합니다:

당신은 계획 및 추론 계층을 담당하는 MANAGER입니다.
당신은 파일/bash 도구를 직접 사용할 수 없습니다—반드시 실행기 에이전트(executor agents)에게 위임해야 합니다.
각 실행기는 {executor_model} 모델을 사용하며, 최대 {max_turns}회까지 실행할 수 있습니다.
...

이러한 계층 구조 자체가 권한 기반 보안 (Capability Security)입니다. Manager의 권한은 "위임 (delegation)"이며, Executor의 권한은 "실행 (execution)"입니다. Manager는 단순히 쉘 도구 (shell tools)를 가지고 있지 않기 때문에, 실수로 위험한 쉘 명령어를 실행하는 일이 발생하지 않습니다.

권한 그래프 (Capability Graphs): 미래의 런타임 기본 요소 (Runtime Primitive)

AI 시스템의 복잡성이 증가함에 따라, 권한 그 자체가 오케스트레이션 가능한 리소스가 될 수 있습니다. 미래의 런타임은 권한 위임 (capability delegation), 임시 권한 (temporary permissions), 권한 취소 (capability revocation), 실행 추적 (execution tracing), 권한 상속 (capability inheritance), 그리고 리소스 계정 (resource accounting)을 관리하게 될 것입니다.

BoxAgnts의 현재 아키텍처는 이미 이러한 확장을 위한 여지를 남겨두고 있습니다. 모든 도구 실행의 컨텍스트 전달자인 ToolContext는 현재 에이전트의 권한 세트뿐만 아니라 상속 체인 (inheritance chains), 위임 관계 (delegation relationships), 그리고 감사 로그 (audit logs)까지 담는 "권한 컨텍스트 (capability context)"로 자연스럽게 확장될 수 있습니다.

결론

AI 에이전트는 대화형 시스템에서 실행형 시스템으로 진화하고 있습니다. 이러한 변화는 보안 요구 사항을 근본적으로 변화시킵니다. LLM은 본질적으로 적대적 지시 (adversarial instructions), 신뢰할 수 없는 컨텍스트 (untrusted context), 그리고 확률적 실행 경로 (probabilistic execution paths)에 노출되어 있습니다. LLM이 광범위한 암묵적 권한 (implicit permissions)을 가지고 실행되는 한, 이들은 구조적으로 안전하지 않은 (structurally unsafe) 상태로 남게 됩니다.

해결책은 더 나은 프롬프트가 아니라, 런타임에서 강제되는 권한 격리 (capability isolation)입니다. BoxAgnts의 사례는 권한 기반 런타임이 제한된 실행 (constrained execution), 명시적 권한 (explicit permissions), 결정론적 경계 (deterministic boundaries), 그리고 통제 가능한 인프라 (governable infrastructure)를 제공한다는 것을 보여줍니다.

AI 에이전트는 루트 권한 (root access)이 아니라 권한 (capabilities)을 부여받아야 합니다.

리소스

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