OpenShell: AI 에이전트를 위한 보안 경계 구축

셸 접근 권한을 가진 AI 에이전트는 챗봇이 절대 넘지 않는 경계를 가로지릅니다. 챗봇은 rm -rf /important/directory를 제안할 수 있습니다. 하지만 에이전트는 실제로 그것을 실행할 수 있습니다. 이는 보안 문제를 '이 프로그램을 신뢰할 수 있는가?'에서 '이 프로그램이 향후 10분 동안 신뢰할 수 없을 때 무슨 일이 발생하는가?'로 변화시킵니다.

NVIDIA의 OpenShell은 자율 AI 에이전트를 위한 런타임으로, 보안 경계를 에이전트 외부(outside)에 배치합니다. 에이전트는 샌드박스를 얻고, 이 샌드박스는 정책을 받습니다. 운영체제와 런타임이 그 정책을 강제합니다. 본 글에서는 OpenShell이 어떻게 작동하는지, 그 정책 모델은 어떤 모습인지, 그리고 엔지니어링 상의 트레이드오프는 어디에서 발생하는지를 살펴봅니다.

OpenShell은 현재 버전 0.1.1이며 알파(alpha)로 표시되어 있습니다. 이를 프로덕션 인증이라기보다는 새롭게 등장하는 런타임에 대한 아키텍처 투어라고 생각하시면 됩니다.

권한 문제 (The Authority Problem)

전통적인 소프트웨어는 비교적 안정적인 권한 모델을 가지고 있습니다. 컴파일러를 설치합니다. 이 컴파일러는 소스 트리를 읽을 수 있습니다. 테스트 스위트를 실행합니다. 테스트 러너는 테스트 프로세스가 접근할 수 있는 모든 것에 접근할 수 있습니다. 서버를 시작합니다. 서버는 부여받은 권한을 가집니다.

AI 에이전트는 세 가지 방식으로 이 모델을 깨뜨립니다:

1. 동적 도구 호출 (Dynamic tool invocation). 에이전트는 고정된 호출 그래프가 아닌 LLM 출력에 기반하여 런타임에 어떤 셸 명령어를 실행할지 결정합니다.
2. 영속적인 상태 (Persistent state). 에이전트는 사용자가 지켜보는 것을 멈춘 후에도 계속 실행되며, 여러 도구 호출을 거치면서 부작용(side effects)을 축적합니다.
3. 불투명한 추론 (Opaque reasoning). 단일 검토 또는 빌드 작업 동안 에이전트가 어떤 파일, 네트워크 엔드포인트 또는 프로세스를 건드릴지 쉽게 예측할 수 없습니다.

이는 폭발 반경 문제(blast radius problem)를 만듭니다. 만약 에이전트가 손상된다면 (프롬프트 주입, 모델 실패 또는 공급망 공격을 통해), 사용자가 알아차리기 전에 얼마나 많은 피해를 입힐 수 있을까요?

OpenShell의 아키텍처

OpenShell은 세 계층의 격리(containment) 모델을 구현합니다:

OpenShell의 아키텍처

OpenShell은 세 계층의 격리(containment) 모델을 구현합니다:

Layer 1: Sandbox runtime. 에이전트는 제한된 파일 시스템 접근, 네트워크 정책 및 프로세스 한계가 적용된 컨테이너화된 환경 내에서 실행됩니다. 이것이 가장 바깥쪽 경계입니다.

Layer 2: Policy engine. 에이전트가 실행하려는 모든 셸 명령어는 정책 평가기(policy evaluator)를 통과합니다. 이 정책은 명령어 구조, 인자 및 문맥에 따라 허용, 거부 또는 인간의 승인을 요구할 수 있습니다.

Layer 3: Blast-radius tracking. OpenShell은 에이전트가 어떤 파일을 읽고, 무엇을 쓰고, 어떤 네트워크 호출을 하고, 어떤 서브프로세스를 생성하는지 모니터링합니다. 이는 감사 추적(audit trail)을 생성하고 동적인 정책 조정을 가능하게 합니다.

핵심 아키텍처 결정 사항은 에이전트가 스스로 경계를 강제하지 않는다는 것입니다. 런타임 환경(runtime)이 그렇게 합니다. 에이전트는 셸 래퍼(shell wrapper)를 호출합니다. 이 래퍼가 정책을 확인합니다. 정책은 해당 명령어를 허용하거나, 차단하거나, 인간 운영자에게 에스컬레이션(escalate)시킵니다.

Policy Model

OpenShell 정책은 허용 및 거부되는 작업을 정의하는 선언적 YAML 파일입니다. 최소한의 정책은 다음과 같습니다:

version: 1
rules:
  - action: allow
...

정책 엔진은 순서대로 규칙을 평가합니다. 가장 먼저 일치하는 규칙이 승리합니다(first matching rule wins). 어떤 규칙도 일치하지 않으면 기본 동작은 거부입니다.

Scope Enforcement

scope 필드는 읽기 작업과 쓰기 또는 실행 작업을 구분합니다. OpenShell은 다음을 추적합니다:

• 읽기 전용 명령어: cat, git status, grep, ls
• 쓰기 명령어: echo >, git commit, npm install
• 실행 명령어: bash, python, 서브프로세스 생성

읽기 전용 범위(read-only scope)라는 것은 명령어가 파일을 수정하거나, 패키지를 설치하거나, 영구적인 프로세스를 시작할 수 없다는 의미입니다. 이는 seccomp-bpf 필터를 사용하여 시스템 호출(syscall) 수준에서 강제됩니다.

Path Restrictions

정책은 에이전트가 접근할 수 있는 디렉터리를 제한할 수 있습니다:

- action: allow
  command: cat
  path-prefix: /workspace/src
...

이는 에이전트가 워크스페이스에 읽기 전용 접근 권한을 가지고 있더라도 환경 파일, SSH 키 또는 자격 증명 저장소(credential stores)를 읽는 것을 방지합니다.

네트워크 경계 (Network Boundaries)

OpenShell은 아웃바운드(outbound) 네트워크 호출을 제한할 수 있습니다:

- action: allow
  network: egress
  destination: api.github.com
...

이를 통해 에어간(exfiltration) 시도를 차단하는 동시에, 에이전트가 리포지토리 메타데이터를 가져오거나 승인된 API를 호출할 수 있도록 허용합니다.

폭발 반경 추적 (Blast-Radius Tracking)

OpenShell은 에이전트 동작의 의존성 그래프(dependency graph)를 유지합니다. 에이전트가 파일을 읽으면, 해당 파일은 읽기 집합(read set)에 추가됩니다. 파일을 쓰면, 해당 파일은 쓰기 집합(write set)에 추가됩니다. 서브프로세스를 생성하면, 해당 프로세스는 실행 그래프(execution graph)에 추가됩니다.

이것이 폭발 반경 보고서(blast-radius report)를 생성합니다:

만약 에이전트가 손상된다면, 이 보고서는 정확히 무엇을 건드렸는지 보여줍니다. 이를 사용하여 다음 작업을 수행할 수 있습니다:

• 쓰기 집합에 대한 변경 사항 롤백 (Roll back changes to the write set)
• 세션 중 접근된 자격 증명 취소 (Revoke credentials accessed during the session)
• 에어간 시도를 위한 네트워크 호출 감사 (Audit network calls for exfiltration attempts)
• 실행되어서는 안 되는 서브프로세스 종료 (Kill subprocesses that should not be running)

LiveReview의 구현 (LiveReview's Implementation)

LiveReview는 OpenShell을 기반으로 구축된 폭발 반경 인식(blast-radius-aware) AI 코드 리뷰 도구입니다. 이는 풀 리퀘스트(pull request) 검토 중 런타임(runtime)을 사용하여 코드 분석 에이전트를 샌드박스화합니다.

작업 흐름 (The workflow):

1. 개발자가 풀 리퀘스트를 엽니다.
2. LiveReview는 OpenShell 샌드박스를 생성합니다.
3. 에이전트는 리포지토리를 클론하고, 디프(diff)를 읽고, 정적 분석 도구를 실행합니다.
4. 에이전트는 임시 파일에 리뷰 코멘트를 작성합니다.
5. OpenShell은 폭발 반경을 확인합니다. 에이전트가 소스 파일만 읽고 임시 디렉토리에만 썼다면, 검토는 승인됩니다.
6. 만약 에이전트가 소스 파일을 수정하거나, 패키지를 설치하거나, 외부 API를 호출하려고 시도했다면, 해당 동작은 차단되고 에스컬레이션(escalated)됩니다.

이 모델은 에이전트가 가끔 오작동할 수 있다고 가정합니다. 보안 경계는 오작동이 격리되도록 보장합니다.

성능 오버헤드 (Performance Overhead)

모든 셸 명령어는 정책 엔진(policy engine)을 통과합니다. 이로 인해 지연 시간(latency)이 추가됩니다:

• 정책 평가 (Policy evaluation): 명령어당 1-5 ms
• 시스템 호출 필터링 (Syscall filtering): 시스템 호출(syscall)당 0.1-0.5 ms
• 폭발 반경 로깅 (Blast-radius logging): 파일 작업당 0.5-2 ms

일반적인 코드 검토 과정에서 50개의 셸 명령어가 실행될 경우, 총 오버헤드는 75-350 ms입니다. 수백 개의 명령어를 실행하는 장시간 에이전트의 경우, 오버헤드가 1-2초에 달할 수 있습니다.

이러한 오버헤드는 정확성이 속도보다 중요한 코드 검토 및 CI(지속적 통합) 작업에는 허용 가능한 수준입니다. 하지만 지연 시간이 흐름을 끊는 상호 작용형 코딩 어시스턴트의 경우에는 덜 허용 가능합니다.

실패 모드 (Failure Modes)

OpenShell의 보안 모델은 알려진 취약점을 가지고 있습니다:

1. 셸 이스케이프를 통한 정책 우회 (Policy bypass via shell escapes). 만약 에이전트가 `sh -c

OpenShell 사용 시점

다음과 같은 경우 OpenShell을 사용해야 합니다:

• 코드 검토(code review), CI, 또는 인프라 자동화 과정에서 셸 명령어를 실행하는 AI 에이전트를 운영해야 할 때.
• 에이전트가 스스로 경계를 강제할 것이라고 신뢰할 수 없을 때.
• 규정 준수(compliance)나 사고 대응(incident response)을 위해 에이전트 행동에 대한 감사 추적(audit trail)이 필요할 때.
• 셸 명령어당 1~2ms의 지연 시간(latency)을 감수할 수 있을 때.

OpenShell 사용을 피해야 하는 경우:

• 에이전트가 셸 명령어를 실행하지 않을 때 (대신 함수 호출 샌드박스(function-call sandboxes)를 사용하세요).
• 보안보다 지연 시간(latency)이 더 중요할 때 (대화형 코딩 도우미).
• 측면 채널 공격(side-channel attacks)이나 리소스 고갈(resource exhaustion)에 대한 방어가 필요할 때 (MicroVM을 사용하세요).
• 에이전트가 완전히 신뢰할 수 없는 환경에서 실행될 때 (하드웨어 격리(hardware isolation)를 사용하세요).

기술적 평가 (Technical Verdict)

OpenShell은 실제 문제를 해결합니다. 셸 접근 권한을 가진 AI 에이전트는 에이전트의 통제 범위를 벗어난 격리 경계가 필요합니다. 정책 모델은 읽기(read), 쓰기(write), 실행(execute) 작업을 구별할 수 있을 만큼 표현력이 풍부합니다. 블라스트-반지름 추적(Blast-radius tracking)은 에이전트 행동에 대한 가시성을 제공합니다. 성능 오버헤드는 코드 검토 및 CI와 같은 배치 작업에는 허용 가능한 수준입니다.

이 아키텍처는 에이전트가 때때로 잘못 작동할 것이라고 가정하며, 그럴 경우 피해를 제한하는 데 중점을 둡니다. 이는 에이전트가 무인으로 실행되는 프로덕션 시스템에 적합한 가정입니다.

주요 격차(gaps)는 셸 이스케이프를 통한 정책 우회(policy bypass via shell escapes), 리소스 고갈, 측면 채널 누출입니다. 이는 어려운 문제입니다. OpenShell이 이를 해결하지는 못하지만, 악용하기 더 어렵게 만듭니다.

만약 프로덕션 환경에서 셸 명령을 실행하는 AI 에이전트를 구축하고 있다면, OpenShell은 평가해 볼 가치가 있습니다. 이것이 완벽한 보안 솔루션은 아니지만, 그러한 솔루션을 구축하기 위한 유용한 기본 요소(primitive)입니다.

소스 링크

• OpenShell: AI 에이전트를 둘러싼 보안 경계 구축 (Dev.to)
• LiveReview (GitHub)