NVIDIA OpenShell로 AI 에이전트에 런타임 제어 추가하기

AI 에이전트는 목표를 부여받으면 코드를 작성하고 도구를 사용하며, 새로운 정보가 들어올 때마다 작업을 이어갑니다. 덕분에 소프트웨어 장애를 조사하고, 실험을 실행하며, 며칠 혹은 몇 주에 걸쳐 비즈니스 핵심 작업과 연구를 수행하는 애플리케이션의 길이 열렸죠.

에이전트가 제대로 일하려면 워크스페이스, 컴퓨팅 자원, 데이터, 자격 증명, 외부 서비스에 접근할 수 있어야 합니다. 하지만 접근 범위가 넓어질수록 프로덕션 데이터 변경이나 기밀 정보 노출, 할당된 작업 범위를 벗어난 행동처럼 결과가 심각한 실패 모드도 함께 늘어납니다.

NVIDIA OpenShell 0.1.0은 에이전트가 어떤 시스템과 데이터에 접근할 수 있는지 정의하고 강제하는 오픈소스 런타임입니다. 샌드박스 실행, 통제된 서비스 접근, 자격 증명 관리, 형식적 정책 분석을 하나로 결합했는데요, 팀은 작업에 필요한 권한을 에이전트에 부여하고 OpenShell은 그 권한을 워크로드 바깥에서 강제합니다.

OpenShell은 Codex, Claude Code, Pi, Hermes와 앞으로 등장할 프레임워크를 지원하며, 사내 에이전트 플릿과 장기 연구부터 로보틱스와 엣지 시스템에 이르기까지 엔터프라이즈 애플리케이션, 프런티어 연구, 피지컬 AI 전반을 아우릅니다.

이 포스트에서는 NVIDIA OpenShell 0.1.0이 기존 AI 에이전트를 다시 작성하지 않고도 강제력 있는 런타임 제어를 어떻게 적용하는지 살펴봅니다. 이를 통해 팀은 API 작업을 제한하고, 자격 증명을 보호하며, 권한 변경을 에이전트 워크로드 바깥에서 검토할 수 있습니다.

OpenShell은 더 넓은 범위의 NVIDIA Open Agent Safety Platform에서 런타임 계층을 담당하며, 이 플랫폼은 애플리케이션, 런타임, 인프라 계층 전반으로 보호를 확장합니다.

기업들은 OpenShell을 어떻게 도입하고 있는가

OpenShell은 오픈소스이며 폭넓은 파트너 생태계에서 엔터프라이즈용으로 도입할 수 있고, 이 생태계가 제품의 방향을 함께 만들어 갑니다. 기업들은 칩 설계, 엔터프라이즈 자동화, 가속 컴퓨팅, 피지컬 AI 등 다양한 분야에서 OpenShell을 도입하고 있죠.

• Cadence는 ChipStack Autonomous RTL Design Engineer를 통해 칩 설계에 OpenShell을 활용합니다.
• Slack은 작업 자동화를 위한 온디맨드 에이전트 플랫폼을 OpenShell 위에 구축하고 있습니다.
• Gecko Robotics는 물리적 로봇의 의사결정을 담당하는 에이전트를 OpenShell로 통제합니다.

OpenShell의 기능

OpenShell 0.1.0은 샌드박스 운영, 정책 검증, 거버넌스 통합, 자격 증명 보호, 유연한 컴퓨팅을 지원합니다.

에이전트 바깥에서 권한을 강제하기

에이전트는 지시를 해석하고 도구를 선택하며 시간이 지남에 따라 접근 방식을 바꿔 나갑니다. OpenShell은 이러한 유연성을 그대로 유지하면서도 권한은 에이전트 워크로드 바깥에서 강제하죠.

OpenShell은 에이전트 플릿과 각 샌드박스를 저마다의 권한으로 관리하고, 여러 그룹에 걸친 거버넌스를 한 번에 적용할 수 있습니다. 이 제어는 다음 세 가지 구성 요소가 담당합니다.

• OpenShell Gateway: 다수 샌드박스의 라이프사이클과 정책을 관리합니다.
• OpenShell Supervisor: 각 샌드박스와 짝을 이루어 에이전트 워크로드 바깥에서 실행되며, 아웃바운드 요청을 정책에 따라 검사합니다.
• OpenShell Sandbox: 파일시스템과 프로세스에 대한 커널 수준 제어 아래 워크로드를 실행하며, 네트워크 경로는 Supervisor를 거치는 경로만 허용합니다.

OpenShell 샌드박스 런타임은 운영체제 커널 제어를 활용해 워크로드가 읽거나 변경할 수 있는 파일을 제한하고, 추가 시스템 권한을 획득하지 못하도록 막습니다. 네트워크 접근은 단순히 서비스 연결을 허용하는 수준을 넘어 더 세밀하게 지정할 수 있는데요, Supervisor가 설정된 HTTP, GraphQL, MCP(Model Context Protocol) 트래픽을 검사해 같은 API에서 데이터 조회는 허용하고 쓰기는 차단할 수 있습니다. 이 제어는 에이전트가 셸을 시작하거나, 생성한 코드를 실행하거나, 자식 프로세스를 띄우거나, 서브 에이전트에 작업 위임을 제안할 때도 그대로 유지됩니다. OpenShell은 정책 결정을 OCSF(Open Cybersecurity Schema Framework) 감사 로그로 기록하며, 검사 대상 요청을 차단할 때는 에이전트가 다음 행동을 판단할 수 있도록 설명이 담긴 오류를 반환할 수 있습니다.

정책 결정이 이루어지는 과정 살펴보기

이 예제에서는 curl과 인증이 필요 없는 GitHub REST API 엔드포인트를 사용하므로, API 키나 언어 모델 없이도 각 정책 결정을 눈으로 확인할 수 있습니다. 에이전트가 요청을 보낼 때도 같은 제어가 적용됩니다.

설치 가이드에 따라 OpenShell 0.1.0을 설치하고 시작한 뒤, 함께 제공되는 no-network.yaml과 github-readonly.yaml 정책 파일을 examples 디렉터리에 내려받습니다.

먼저 아웃바운드 네트워크 접근이 없는 샌드박스를 생성합니다.

openshell sandbox create --name policy-demo \
  --no-auto-providers \
  --policy examples/no-network.yaml

create 명령을 실행하면 샌드박스 안에 셸이 열립니다. 공개 엔드포인트를 읽어 보겠습니다.

curl -sS --max-time 10 https://api.github.com/zen

샌드박스에 아웃바운드 네트워크 권한이 없으므로 요청은 실패합니다. 호스트에서 두 번째 터미널을 열고 로그를 확인하면 어떤 프로그램이 요청을 보냈고 왜 차단됐는지 알 수 있죠.

openshell logs policy-demo --since 5m

다음으로 샌드박스 정책을 GitHub REST API 읽기 전용 접근을 허용하는 정책으로 교체합니다. 정책은 YAML로 작성되어 OPA/Rego로 컴파일되며, OpenShell이 아웃바운드 요청마다 이를 평가합니다.

network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

이 규칙은 /usr/bin/curl이 443 포트로 GitHub API에 접근하도록 허용합니다. protocol: rest 설정에 따라 OpenShell은 HTTP 요청을 검사해 읽기는 허용하고 쓰기는 차단하죠.

호스트 터미널에서 샌드박스를 재시작하지 않고 전체 교체 정책을 적용합니다.

openshell policy set policy-demo \
  --policy examples/github-readonly.yaml --wait

샌드박스 셸로 돌아가 두 요청을 모두 시도해 봅니다.

# Read: allowed
curl -sS --max-time 10 https://api.github.com/zen

# Write: blocked
curl -sS --max-time 10 -X POST https://api.github.com/zen

호스트 로그를 다시 확인하면 OpenShell이 POST를 차단했음을 알 수 있습니다. 이 명령을 실행하는 에이전트도 똑같은 제한을 받습니다.

자격 증명을 노출하지 않고 서비스에 접근하기

많은 에이전트가 작업을 완료하려면 모델 API나 사설 서비스가 필요합니다. OpenShell은 실제 자격 증명을 에이전트 워크로드 바깥에 둔 채 그 접근을 인가하죠.

한 서비스에 대한 인가가 다른 서비스에서도 그 자격 증명을 쓸 수 있다는 뜻은 아닙니다. 에이전트가 자격 증명의 승인된 엔드포인트가 아닌 곳으로 자리표시자를 보내면 OpenShell은 요청을 거부합니다.

요청을 받는 서비스는 여전히 실제 자격 증명에 부여된 권한을 강제하고, OpenShell은 에이전트가 그 자격 증명을 어떻게 사용할 수 있는지에 대한 별도의 제어를 더합니다. 예를 들어 자격 증명 자체에 쓰기 권한이 있더라도, 요청을 검사하는 읽기 전용 API 정책으로 쓰기 요청을 차단할 수 있죠.

제공자 프로필(provider profile)은 서비스의 자격 증명, 엔드포인트, 허용 프로그램을 정의합니다. github이라는 GitHub 제공자가 이미 설정되어 있다고 가정하고, 이를 새 샌드박스에 연결해 Codex를 실행해 보겠습니다.

openshell sandbox create \
  --provider github \
  -- codex

에이전트 실행 중에 네트워크 접근 조정하기

에이전트는 작업을 시작할 때는 몰랐던 서비스나 데이터 소스가 필요하다는 사실을 도중에 깨달을 수 있습니다. 정책이 요청을 차단하면 OpenShell은 거부 내역을 기록해 운영자나 AI 에이전트 승인자가 검토할 수 있게 하는데요, policy advisor를 활성화하면 에이전트가 범위를 좁게 한정한 네트워크 또는 파일 정책 변경을 제안할 수 있습니다. 제안은 기본적으로 사람의 검토를 기다리는 대기 상태로 남고, 에이전트는 자신의 요청을 스스로 승인할 수 없죠. 승인이 이루어지면 OpenShell이 실행 중인 샌드박스에 새 규칙을 로드하므로, 에이전트는 작업을 재시작하지 않고 다시 시도할 수 있습니다.

파일시스템과 프로세스 제한은 샌드박스가 시작될 때 확정되므로, 이 제어를 변경하려면 새 샌드박스가 필요합니다.

다음 명령으로 샌드박스에 policy advisor를 활성화합니다.

openshell settings set <sandbox-name> \
  --key agent_policy_proposals_enabled \
  --value true

정책이 부여하는 권한 검증하기

정책이 겉보기에는 엄격해 보여도 다른 경로가 열려 있을 수 있습니다. 한 도구를 통한 GitHub 쓰기를 차단하더라도, 허용된 다른 도구나 생성된 코드가 자격 증명으로 같은 쓰기를 수행할 수 있다면 소용이 없죠.

OpenShell 정책 증명기(policy prover)는 형식 논리를 사용해 제공자가 기여한 접근까지 포함하여 정책이 부여하는 권한을 검사합니다. 모델링된 권한이 운영자가 정의한 경계 안에 머무는지 증명하거나, 경계를 넘는 구체적인 행동을 식별할 수 있는데요, 결과가 정책 모델에서 도출되기 때문에 에이전트의 설명이 그 결과를 바꿀 수는 없습니다. 형식 기법 입문서에서 그 동작 원리를 단계별로 설명합니다.

장기 적대적 실험에서는 안전장치를 줄인 프런티어 에이전트들이 보호된 GitHub 리포지토리를 수정할 수 있는 권한을 얻기 위해 최대 두 시간 동안 AI 검토자를 설득하려 했습니다. OpenShell의 형식적 정책 분석은 에이전트가 검토자를 조종하려 하는 상황에서도 해당 권한이 무엇을 허용하는지에 대한 근거를 검토자에게 제공했죠. 검토와 런타임 제어를 결합한 결과 유용한 접근은 허용되었고, 이 테스트에서 보호된 리포지토리에 대한 쓰기는 한 건도 발생하지 않았습니다.

현재는 한 에이전트의 접근이 다른 에이전트의 접근과 결합될 수 있는 다중 에이전트 환경으로 정책 분석을 확장하는 작업이 진행 중이며, 에이전트들이 함께 구성하는 시스템 전체의 권한을 검사하는 것이 목표입니다. 지원되는 검사 항목은 증명기 문서를 참조하세요.

로컬에서 구축하고 공유 인프라에 배포하기

애플리케이션을 구축하고 권한을 정의하는 동안은 로컬 샌드박스로 시작하세요. 여러 사용자에게 서비스를 제공하려면 워크스페이스 및 접근 가이드를 따라 SDK로 샌드박스를 생성·관리하면 되는데요, 각 워크로드는 고유한 정책과 연결된 제공자를 갖습니다.

샌드박스 바깥의 신뢰할 수 있는 미들웨어는 아이덴티티 서비스를 연결하고 요청 경로에 애플리케이션 고유의 검사를 추가할 수 있습니다. 컴퓨팅 드라이버는 OpenShell을 Docker, Podman, MicroVM, Kubernetes에 연결하며, 현재 요구 사항은 지원 매트릭스에서 확인할 수 있습니다.

CNCF Slack의 #openshell-dev 채널에 참여해 질문하고 피드백을 공유하며 OpenShell 위에서 개발하는 다른 팀과 개발자들과 교류하세요. GitHub에서 코드를 살펴보고 기여할 수 있으며, 진행 중인 연구와 엔지니어링 작업은 OpenShell 개발 노트에서 확인할 수 있습니다. 기존 배포를 업그레이드하는 경우에는 0.1.0 마이그레이션 노트를 참고하세요.

이제 직접 구축할 준비가 되셨나요? 퀵스타트로 OpenShell에서 자신의 에이전트를 실행하고 접근 가능한 서비스를 설정해 보세요.