NVIDIA OpenShell, AI 에이전트에게 단호한 거절을 선언하다

AI 에이전트는 상당한 새로운 위험을 초래합니다. 개발자들은 일상적으로 Claude Code나 Codex와 같은 도구에 민감한 리포지토리, API, 자격 증명에 대한 광범위한 액세스 권한을 부여한 뒤 무인 상태로 실행되도록 방치합니다. 에이전트의 유용성은 중요한 리소스에 대한 액세스 권한과 직결되기 때문에, 이러한 편리함은 종종 보안을 희생하는 대가로 얻어집니다.

일반적인 컨테이너는 호스트 격리에는 효과적이지만, 미묘한 동작을 구분할 수는 없습니다. 예를 들어, GitHub 연결은 데이터를 읽는 것과 파괴적인 변경을 가하는 것 모두를 허용합니다. 컨테이너는 동일한 주소로 향하는 트래픽만 볼 뿐, 에이전트가 단순히 코드를 탐색하는 것인지 아니면 적극적으로 이슈를 생성하는 것인지 구분할 수 없습니다.

NVIDIA의 OpenShell은 이러한 격차를 해결하기 위한 새로운 오픈 소스 샌드박스입니다. Rust로 작성되었으며 Apache 2.0 라이선스를 따르는 OpenShell은 에이전트가 리소스에 접근할 수 '있는지' 여부뿐만 아니라, 접근했을 때 '무엇을' 할 수 있는지를 제어합니다. 중요한 점은 NVIDIA GPU가 필요 없으며 표준 하드웨어에서도 실행된다는 것입니다.

OpenShell의 정책 우선 설계는 파일 액세스, 시스템 호출, 네트워크 연결에 대한 세밀한 제어를 강제합니다. 기본적으로 모든 것을 거부(default-deny)하는 방식으로 작동하므로, 명시적으로 허용되지 않는 한 에이전트는 아무것도 할 수 없습니다. 이러한 세밀한 제어는 기본적인 컨테이너화 기술을 크게 뛰어넘는 발전입니다.

OpenShell은 세 가지 핵심 구성 요소를 매핑합니다. Gateway는 인터페이스 및 제어 평면 역할을 하며, Supervisor는 정책을 강제하고 자격 증명을 중개합니다. 그리고 Sandbox는 에이전트가 실행되는 제한된 환경을 제공합니다. 샌드박스의 유일한 외부 경로(egress path)는 Supervisor를 통과하도록 라우팅되어 모든 외부 상호 작용이 중재되도록 보장합니다.

기본 거부(Default-deny) 동작은 OpenShell 보안 모델의 핵심입니다. 커널 수준의 파일 시스템 및 프로세스 제한은 승인되지 않은 경로와 권한 상승을 처음부터 차단합니다. 에이전트로부터 발생하는 모든 네트워크 요청은 Supervisor를 통과해야 하며, Supervisor는 사전 정의된 정책에 따라 이를 검토합니다.

예를 들어, curl 바이너리가 GitHub API에 대해 읽기 전용 요청을 수행하도록 허용하는 정책이 있다고 가정해 봅시다. Supervisor는 이를 허용합니다. 그러나 동일한 curl 바이너리가 이슈를 생성하기 위해 승인되지 않은 POST 요청을 시도하면 Supervisor는 이를 거부합니다. 이러한 정책은 샌드박스를 재시작할 필요 없이 openshell policy update를 통해 실시간으로 업데이트되며, 모든 거부 사례는 기록되어 명확한 감사 추적을 제공합니다.

결정적으로, 에이전트는 자격 증명을 직접 처리하지 않습니다. Supervisor는 승인된 요청에 대해서만 토큰을 주입하여 프롬프트 인젝션을 통한 유출을 방지합니다. DNS 확인조차도 Supervisor를 통해 이루어지므로 에이전트의 가시성과 제어권이 제한됩니다. 이 설계는 에이전트가 손상되더라도 유출할 키가 없음을 보장합니다.

OpenShell의 가장 독창적인 기능은 자격 증명 마스킹(credential masking)입니다. 에이전트는 민감한 API 키나 토큰을 직접 보유하지 않습니다. 대신 Supervisor가 이러한 비밀 정보를 유지하며, 확립된 정책에 부합하는 승인된 아웃바운드 요청에만 이를 주입합니다. 이 설계는 에이전트가 유출할 자격 증명이 존재하지 않기 때문에 프롬프트 인젝션에 대한 공격 표면을 크게 줄여줍니다.

정책 변경 사항이 적용되기 전에 OpenShell은 Z3 solver를 사용하여 공식 검증자 역할을 수행합니다. 이 수학적 엔진은 제안된 정책 수정을 평가하여 새로 부여된 액세스 권한의 전체 범위를 계산합니다. 이러한 사전 검사는 의도치 않은 와일드카드나 지나치게 광범위한 권한과 같은 위험한 규칙을 노출하여 배포되지 않도록 방지합니다.

대안이 존재하지만(Docker는 기본적인 격리를 제공하고, Anthropic의 sandbox runtime은 더 가벼운 설정을 제공하며, E2B나 Daytona와 같은 호스팅 솔루션은 관리형 실행을 제공함), OpenShell은 독자적인 영역을 구축합니다. OpenShell은 Docker, Podman, Kubernetes와 같은 컨테이너 런타임 위에서 실행되는 자체 호스팅형 정책 기반 에이전트 제어를 강조합니다. 기본 아키텍처와 오픈 소스 기여에 관심이 있는 분들은 NVIDIA/OpenShell on GitHub에서 프로젝트를 확인할 수 있습니다.

OpenShell은 단순히 "에이전트가 접근할 수 있는가?"라는 질문에서 "에이전트가 그것으로 무엇을 할 수 있도록 허용되는가?"라는 질문으로의 전환을 의미합니다. NVIDIA의 텔레메트리 보고서에 따르면, 올여름 2주 동안 OpenShell은 550,000개 이상의 샌드박스를 생성하고 420만 건의 에이전트 작업을 차단하여 에이전트 경계를 강화하는 데 적극적인 역할을 수행했음을 보여줍니다.

OpenShell은 보안 포스 필드가 아닌 유용한 가드레일을 제공합니다. Cisco, CrowdStrike, Google Cloud, Microsoft Security와 같은 생태계의 큰 관심에도 불구하고 프로젝트 버전이 0.1.5로 "초기 프리뷰" 단계라는 점에서 초기 단계임이 분명합니다. 텔레메트리는 기본적으로 활성화되어 이벤트를 익명으로 집계하지만, 환경 변수를 통해 비활성화할 수 있습니다.

Mac 사용자는 OpenShell 샌드박스가 Docker Desktop의 가상 머신 내에서 실행되는 Linux 기반임을 유의해야 합니다. 이를 위해서는 기본적으로 꺼져 있는 경우가 많은 Landlock 및 호스트 네트워킹과 같은 커널 기능이 활성화되어 있어야 합니다. NVIDIA의 doctor 명령어가 정상으로 표시될 수 있지만 테스트를 권장합니다.

NVIDIA의 내부 텔레메트리 보고서는 2주 동안 550,000건 이상의 샌드박스 생성과 420만 건의 에이전트 작업 차단이라는 놀라운 활동을 보여줍니다. 이 수치는 OpenShell이 차단하는 에이전트의 권한 남용 규모를 강조합니다. 그러나 NVIDIA는 같은 기간 동안 샌드박스 생성의 약 12%가 실패했다고 보고했으며, 이는 독립적인 감사가 아닌 회사 텔레메트리 수치입니다.

Claude Code와 같은 도구를 사용한 간단한 로컬 코딩의 경우, 기본적인 컨테이너나 Anthropic Sandbox Runtime만으로도 설정이 충분할 수 있습니다. 하지만 실제 자격 증명을 처리하거나 장기간 실행되는 감독되지 않는 작업을 수행하는 에이전트의 경우, OpenShell의 요청별 규칙과 자격 증명 마스킹은 매우 유용합니다. 샌드박싱은 위험을 완화하지만 모든 잠재적 취약점을 제거할 수는 없으므로 신중한 정책 설계가 여전히 중요합니다.

NVIDIA OpenShell이란 무엇인가요?

OpenShell은 에이전트 외부에서 적용되는 정책을 통해 AI 에이전트의 파일, 프로세스 및 네트워크 액세스를 제한하기 위한 오픈 소스 런타임입니다.

OpenShell은 NVIDIA GPU가 필요한가요?

아니요. 영상에서는 Mac에서 실행되는 모습을 보여주며, OpenShell은 NVIDIA GPU 하드웨어에 의존하지 않습니다.

OpenShell은 Docker와 어떻게 다른가요?

Docker는 컨테이너를 격리하는 반면, OpenShell은 특정 프로세스가 특정 네트워크 엔드포인트 및 작업에 액세스할 수 있는지에 대한 규칙을 포함하여 세밀한 제어 기능을 추가합니다.

OpenShell은 모든 AI 에이전트 보안 위험을 방지하나요?

아니요. 에이전트가 액세스할 수 있는 범위를 제한하지만 완벽한 보안 보장은 아닙니다. 구성, 격리 경계 및 소프트웨어 성숙도가 여전히 중요합니다.