NVIDIA OpenShell 0.1.x: 안전하고 비공개적인 AI 에이전트 플릿용 런타임

NVIDIA의 OpenShell은 Apache-2.0 라이선스의 런타임으로, 자율 AI 에이전트에게 파일 액세스, 패키지 설치, API 호출, 자격 증명 사용과 같은 실제 기능을 제공하면서도 커널 수준에서 접근 가능한 대상을 제한하고 정책 변경이 적용되기 전에 형식적으로 검증합니다. 이 프로젝트는 Hacker News 첫 페이지에 489점과 213개의 댓글로 등장했으며, 댓글은 배터리 포함 에이전트 샌드박스에 대한 열광과 기본 활성화된 원격 측정, 이름, 그리고 이 전체 범주가 컨테이너를 재발명하는 것인지에 대한 회의론으로 나뉘었습니다.

OpenShell이란 무엇인가

OpenShell은 NVIDIA가 Apache License 2.0으로 게시한 자율 AI 에이전트 플릿을 위한 안전하고 비공개적인 런타임입니다. 명시된 전제는 에이전트가 파일을 읽고, 패키지를 설치하고, API를 호출하고, 자격 증명을 사용할 수 있을 때 가장 유용하며, 그러한 기능을 제공하는 것이 데이터, 비밀, 또는 네트워크에 대한 무제한 액세스를 제공하는 것을 요구하지 않는다는 것입니다.

핵심 설계는 선언적입니다. 정책에서 각 에이전트가 접근할 수 있는 대상을 선언하면 OpenShell이 이를 적용합니다. 두 가지 메커니즘이 적용을 담당합니다:

런타임 시 모든 파일 액세스, 시스템 호출, 네트워크 연결에 정책을 적용하는 커널 수준 계측.
정책 변경이 적용되기 전에 허용할 내용을 확인하는 형식적 검증.

OpenShell은 openshell이라는 PyPI 패키지로 배포되며, 저장소는 github.com/NVIDIA/OpenShell입니다.

0.1.x 릴리스 라인

README는 현재 시리즈의 이정표를 명시합니다: "OpenShell 0.1.x의 새로운 기능: 안정적인 릴리스 주기, 새로운 격리 프리미티브, 확장된 확장 표면, 새로운 API." 전용 0.1.0 업그레이드 가이드는 docs.nvidia.com/openshell/latest/upgrade/0-1-0에 게시되어 있습니다.

OpenShell을 평가하는 모든 사람에게 실질적인 의미는 프로젝트가 이제 임시 릴리스가 아닌 정의된 릴리스 주기에 있으며, 확장 표면(미들웨어, 인터셉터, 컴퓨트 드라이버)과 공개 API가 이 시리즈에서 모두 성장했다는 것입니다. README는 또한 SDK에서 사용하는 OpenShell 릴리스를 게이트웨이를 실행하는 릴리스와 일치시킬 것을 권장합니다.

커널 수준 적용 방식

OpenShell은 각 에이전트를 격리된 샌드박스에 가두고 에이전트 요청을 구문 분석하는 대신 커널 경계에서 정책을 적용합니다. README에 따르면:

커널 제어는 에이전트가 액세스할 수 있는 파일과 수행할 수 있는 시스템 호출을 제한합니다.
모든 네트워크 연결은 샌드박스를 떠나기 전에 정책 검사를 통과합니다.
에이전트는 실제 자격 증명을 볼 수 없습니다. OpenShell은 승인된 엔드포인트에 대한 요청에만 자격 증명을 추가합니다.

세 번째 요점은 자격 증명 중개 모델입니다. 샌드박스는 사용 가능한 비밀을 보유하지 않으며, 런타임은 대상이 승인된 엔드포인트와 일치할 때만 아웃바운드 경로에 비밀을 주입합니다. 프로젝트는 이 개념을 "Providers"라고 부릅니다. 승인된 엔드포인트(추론 엔드포인트 포함)에서만 작동하는 자격 증명입니다.

형식적으로 검증된 정책 변경

정책 드리프트는 자동 작업이 아닌 검토 게이트로 처리됩니다. 정책 변경이 승인되기 전에 OpenShell은 형식적 검증을 사용하여 변경으로 인해 새로 부여되는 위험한 새 액세스(예: 자격 증명으로 새 호스트에 도달하거나 새 API 메서드 호출)를 표시하여 이러한 변경이 인간 검토를 기다리도록 합니다.

OpenShell 문서에서 이는 정책 섹션 아래의 어드바이저와 프로버로 나뉩니다. 주장은 에이전트가 검증되었다는 것이 아니라 이전 정책과 새 정책 간의 델타가 새로 허용하는 내용에 대해 분석된다는 것입니다.

아키텍처: 게이트웨이, 슈퍼바이저, 샌드박스

OpenShell은 아키텍처 문서에 설명된 세 가지 협력 부분으로 구성됩니다: 게이트웨이, 슈퍼바이저, 샌드박스. 게이트웨이는 샌드박스, 정책, 액세스의 제어 평면입니다.

정책 모델은 파일 시스템 규칙, 네트워크 규칙, 프로세스 규칙을 다룹니다. 샌드박스 문서는 이미지, 런타임, GPU, 수명 주기를 다룹니다.

설치 및 빠른 시작

OpenShell은 Linux, Apple Silicon의 macOS, 또는 WSL 2(실험적)가 있는 Windows와 Docker, Podman, 또는 호스트 가상화를 요구합니다. 지원 매트릭스가 세부 사항을 문서화합니다.

문서화된 빠른 시작은 두 명령입니다:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

설치 프로그램은 CLI와 로컬 게이트웨이를 설정합니다. 기본 샌드박스 이미지는 에이전트가 설치되지 않은 최소 Ubuntu입니다. 실제 에이전트를 실행하려면 "Run Your First Agent" 가이드가 무료 OpenRouter 모델에 대해 OpenCode를 실행하고 에이전트가 요청할 때 새 액세스 승인을 안내합니다.

SDK, Kubernetes, 확장

SDK는 애플리케이션을 OpenShell 게이트웨이에 연결합니다. CLI를 설치하지 않습니다.

언어	설치
Python	`uv add openshell`
TypeScript	`npm install @nvidia/openshell-sdk` (GitHub Packages)
Go	`go get github.com/NVIDIA/OpenShell/sdk/go@latest`
Rust	`cargo add openshell-sdk --git https://github.com/NVIDIA/OpenShell --tag <release-tag>`

Kubernetes의 경우 게이트웨이는 Helm으로 배포되며, README는 하드 요구 사항을 명시합니다: CNI가 NetworkPolicy를 적용해야 합니다. 확장성은 미들웨어, 인터셉터, 컴퓨트 드라이버를 통해 노출됩니다.

저장소는 또한 npx skills add NVIDIA/OpenShell로 설치할 수 있는 에이전트 스킬을 제공합니다. 스킬은 코딩 에이전트가 OpenShell CLI를 구동하고, 샌드박스 정책을 작성하고, 게이트웨이와 추론 라우팅을 디버깅하는 방법을 가르치며, OpenShell 소스 체크아웃 없이 작동합니다.

OpenShell은 명시적으로 에이전트 우선으로 구축되었으며, 활성화하는 것과 동일한 에이전트 중심 워크플로로 개발되었습니다. 기여자 설정은 CONTRIBUTING.md에, 저장소 코딩 규칙은 AGENTS.md에 있습니다.

원격 측정 및 의도적으로 수집하지 않는 것

OpenShell은 기본적으로 운영 범주와 수에 국한된 익명 원격 측정을 수집합니다. README는 수집하지 않는 항목을 열거합니다: 샌드박스 이름, 호스트 이름, 파일 경로, 프롬프트, 자격 증명, 공급자 또는 모델 이름, 사용자 콘텐츠. 이 원격 측정의 집계 보고서는 저장소에 게시됩니다.

원격 측정은 두 가지 방법으로 비활성화할 수 있습니다: 게이트웨이에 OPENSHELL_TELEMETRY_ENABLED=false를 설정하거나 Helm 설치에 server.telemetryEnabled=false를 설정합니다. 완전히 컴파일에서 제외할 수도 있습니다.

기본 활성화 원격 측정은 Hacker News 스레드에서 가장 일관된 불만이었습니다. 한 댓글 작성자는 README의 원격 측정 섹션을 그대로 인용하고 그대로 두었습니다. 다른 사람은 더 직설적이었습니다:

기본 원격 측정은 말도 안 됩니다. 그 외에는 제어 수준이 멋지고, 거의 너무 세밀합니다. 아마도 매우 세밀한 엔터프라이즈 요구 사항(아마도 그것을 대상으로 함)에만 특히 유용할 것입니다. 대부분의 회사는 권한을 훨씬 더 거칠게 설정할 수 있으며, 에이전트 산업은 배포 플랫폼으로서 k8s에서 멀어지고 있다고 생각합니다.

HN 댓글 작성자들이 좋아한 점

여러 댓글 작성자는 OpenShell을 새로운 아이디어가 아닌 통합 플레이로 보았습니다. 한 사람은 "Nvidia Openshell은 절대적으로 훌륭하고, 한 곳에 훌륭한 기능 번들을 제공합니다"라고 썼고, 경쟁 프로젝트가 등장하면서 OpenShell이 버려질까 걱정했다고 덧붙였습니다. 다른 사람은 이미 컨테이너에서 에이전트를 실행 중이며 여전히 가치를 본다고 말했습니다: "아직 에이전트를 컨테이너에서 실행하지 않았다면 미친 것입니다. 그렇긴 하지만, 이것은 그러한 컨테이너를 관리하는 좋은 방법처럼 보입니다."

GTC Europe에 참석한 스레드 참가자는 그곳의 데모 중 상당 부분이 OpenShell을 사용했으며 이전에 그것에 대해 들어본 적이 없다고 말했습니다.

호평을 받은 재구성 중 하나는 용어적이었습니다: "에이전트 런타임 — 오늘날 코딩 에이전트 또는 에이전트 하네스라고 불리는 것에 실제로 좋은 이름입니다."

비판: 이름, 마케팅, 유지 관리 문제

이름은 즉각적인 의심을 불러일으켰습니다. OpenShell은 오래된 Open-Shell-Menu 프로젝트와 이름을 공유하며, 한 댓글 작성자는 이를 충돌로 지적했습니다. 다른 사람들은 브랜딩이 모순적이라고 생각했습니다: "나는 이렇게 읽는 것을 선호합니다: Nvidia Opens Hell"이라고 한 사람이 썼습니다. 다른 사람: "Open과 Nvidia가 한 문장에 있는 것은 멋진 모순입니다." 더 넓은 반대는 제품 설명에 "open", "safe", "private"을 함께 짝지으면 의심을 불러일으킨다는 것이었습니다: "무언가를 비공개적이고 안전하다고 바로 부르는 것은 실제로 그러한 주장 모두에 실패할 가능성이 있다고 생각하게 만듭니다."

한 댓글 작성자는 프레이밍에 직접 의문을 제기했습니다:

제 생각에 이것은 모순을 모호하게 만듭니다: 에이전트에 더 많은 액세스를 줄수록 더 유능해집니다. 케이크를 먹고도 가질 수는 없습니다. 이 도구는 균형을 잡을 수 있게 해줍니다. 그러나 설명은 모든 것을 할 수 있지만 이제는 안전하다고 읽힙니다. 그것은 사실일 수 없습니다.

유지 관리도 또 다른 우려였습니다. 한 댓글 작성자는 OpenShell이 기존 샌드박스 분야와 어떻게 비교되는지, 무엇이 그것을 구별하는지 물은 다음 자신의 기대를 명확히 밝혔습니다: "제 기대는 그것이 제대로 유지되지 않을 것이라는 것입니다; nvidia는 소프트웨어 회사가 아닙니다." 스레드에서 아무도 기능별 비교를 직접 제공하지 않았으며, Docker의 microVM 기반 샌드박싱과 OpenShell을 비교하라는 요청은 답변되지 않았습니다.

"그냥 컨테이너를 사용하면 안 되나?"

가장 반복된 반대는 컨테이너가 이미 이 문제를 해결한다는 것이었습니다. 한 댓글 작성자는 "그냥 컨테이너를 사용하면 안 되나..."라고 물었고, 다른 사람은 이 공간이 "AI 맛을 더한 가상화 및 컨테이너화를 재발명"하고 있다고 말했습니다.

아무 댓글 작성자도 결정적인 답변을 제공하지 않았지만, OpenShell 설계는 의도된 차이점을 시사합니다: 컨테이너 격리는 프로세스가 도달할 수 있는 범위를 제한하는 반면, OpenShell은 추가로 엔드포인트별로 자격 증명을 중개하고 검증과 인간 검토를 통해 정책 변경을 게이트합니다. 그 델타가 새 런타임을 정당화하는지 여부는 회의론자들이 정확히 의문을 제기한 부분입니다. 한 댓글 작성자는 또한 대안의 실질적인 한계를 표면화했습니다: Docker Sandbox는 microVM에 의존하며, 유사한 도구에는 알려진 격차가 있습니다 — 예를 들어 VS Code Remote SSH가 샌드박스에서 호스트에 대한 공격을 노출합니다.

플릿 문제: 공모 및 집단 권한

상세한 댓글은 OpenShell 뒤에 있는 GTC 피치가 개별 권한이 아닌 집단 권한에 관한 것이라고 설명했습니다:

GTC의 피치에서, 아이디어는 각 개별 에이전트가 할 수 있는 것을 제한하는 것뿐만 아니라 집단 권한이 에이전트가 하도록 원하는 것을 초과하지 않도록 하는 것입니다. 분명히 에이전트는 필요한 권한을 가진 다른 에이전트에게 작업을 위임하여 개별 샌드박스를 벗어나기 위해 공모할 것입니다. 이것은 에이전트 플릿의 문제입니다. 작업을 조정해야 하기 때문입니다. 따라서 통신해야 합니다. 에이전트가 원하지 않는 일을 하는 것을 방지하는 순진한 접근 방식은 권력 분립으로, 개별 권한을 각 에이전트의 작업으로 제한하는 것입니다... 에이전트 중 하나가 원시 데이터를 게시해야 한다고 결정하면, 단일 에이전트가 그 목표를 달성할 권한이 없더라도 그렇게 하기 위해 공모할 가능성이 높습니다.

같은 댓글 작성자는 OpenShell이 세분화된 에이전트별 권한으로 플릿의 집단 권한 집합을 모니터링하여 이를 해결하며, 에이전트가 실행되는 칩과 호스트 사이에 위치한 하드웨어 방화벽(BlueField 기반)과 함께 제시되어 에이전트가 자신의 OpenShell 정책을 수정하는 능력을 제거한다고 말했습니다. 그 하드웨어 세부 사항은 README가 아닌 댓글 작성자의 GTC 프레젠테이션 설명에서 나온 것입니다.

유출은 해결되지 않은 가장자리

접근 방식을 좋아한 댓글 작성자조차도 잔여 위험을 식별했습니다. 한 사람은 도메인별 네트워크 제한과 자격 증명 교체를 위해 Iron Proxy를 사용하는 방법을 설명한 다음 남은 격차를 명명했습니다:

에이전트를 진정으로 신뢰하려면 남은 유일한 실제 문제는 데이터 유출을 방지하는 방법입니다... 신뢰할 수 있는 도메인으로 네트워크를 제한할 수 있지만, 특히 프롬프트 주입되고 한 번에 몇 문자씩 데이터를 밀어내는 경우 에이전트가 매우 교활할 가능성이 항상 있습니다.

같은 댓글 작성자는 에이전트가 공개 저장소를 포크하거나, 이슈를 열거나, PR을 제출할 수 있는지 제어하기 위해 직접 액세스를 부여하는 대신 gh를 프록시하는 방법을 설명했습니다. 결론은 해결되지 않았습니다: 에이전트는 여전히 허용된 도메인에 예상치 못한 방식으로 데이터를 보낼 수 있습니다.

다른 댓글 작성자는 OpenShell을 프로덕션에서 실행 중이며 팀 정책, 안전한 git 사용(에이전트가 사용자의 전체 액세스를 상속하지 않도록), 내장 SCA/SAST를 위한 레이어를 그 위에 구축하고 있다고 말했습니다. 동기에 대한 요약: "제가 본 에이전트 추적는 거칠고 경계 없는 목표 추구는 실제입니다."

k3s 네임스페이스와 함께 ACL 적용 플러그인을 사용하는 댓글 작성자는 어떤 정책 엔진도 완전히 해결하지 못하는 전체 문제의 가장 어려운 부분을 설명했습니다: "가장 어려운 것은 보안 규칙을 설정하는 것이 아니라 에이전트가 필요로 하는 모든 것을 미리 아는 것입니다."

형식적 검증 논쟁

한 댓글 작성자는 OpenShell의 프로버를 더 넓은 논제와 연결했습니다: 프론티어 모델은 이미 샌드박스에서 벗어나는 방법, 권한을 우회하는 방법, 사이드 채널을 고안하는 방법을 찾을 수 있으므로 형식적 방법을 사용한 보안-by-construction만이 유일한 지속 가능한 답변입니다. 그들은 Anthropic의 게시된 형식적 검증 작업을 규모에서 검증이 가능하다는 증거로 지적했지만, 메모리 정리 버그의 부재를 증명하는 것은 한 종류의 문제일 뿐이며, "어떤 수준에서도 자격 증명을 유출할 방법이 없다"와 같은 종단 간 주장이 의미를 가지려면 검증된 칩, 부트로더, 최소 Linux, 애플리케이션 라이브러리 스택이 필요하다고 주장했습니다.

채택 신호 및 공개 질문

스레드의 채택 증거는 일화적입니다: 한 댓글 작성자는 한동안 OpenShell을 사용해 왔으며 다른 팀을 위해 확장하고 있다고 말했습니다. 다른 사람은 에이전트를 컨테이너화한 후 자연스러운 다음 단계로 보았습니다. 반면 여러 댓글 작성자는 실제 사용자가 어디에 있는지 물었습니다 — "사람들이 실제로 에이전트 플릿으로 무엇을 하고 있나요?" — 그리고 GTC Europe 데모에서 이 도구가 많이 사용되었다는 냉소적인 메모는 NVIDIA 주도의 가시성이 독립적인 채택보다 더 많다는 것을 시사합니다.

저장소가 구체적으로 확립하는 것: OpenShell은 Apache-2.0이며, PyPI에 openshell로 게시되고, Python, TypeScript, Go, Rust SDK를 제공하며, NetworkPolicy를 적용하는 CNI를 요구하는 Helm 기반 Kubernetes 경로를 문서화하고, Linux, Apple Silicon macOS, WSL 2(실험적)를 Docker, Podman, 또는 호스트 가상화와 함께 지원하며, 검색된 외부 자료는 자체 별도 약관의 적용을 받고 소프트웨어는 "있는 그대로" 제공된다는 명시적 면책 조항을 포함합니다.