AI 에이전트 권한 관리, NVIDIA OpenShell로 시작하기

NVIDIA OpenShell은 AI 에이전트를 어떻게 제어할까요?

OpenShell은 에이전트를 실행하고 접근 권한을 제어하는 오픈 소스 런타임입니다. 에이전트의 추론이나 툴을 대체하는 대신, 그 아래에서 실행 환경을 제공합니다.

건물 안에서 일하는 외부 작업자를 떠올려 보겠습니다. 작업실과 특정 방의 출입 권한, 정해진 공급업체에 연락할 권한을 줍니다. 작업 지시서에 “주의해서 일하세요”라고 썼다는 이유로 만능 열쇠까지 건네지는 않습니다. OpenShell은 소프트웨어 에이전트에 이런 경계를 마련합니다.

런타임 개요에서는 파일 시스템 제한, 네트워크 제어, 프로세스 제한, 서비스 제공자 인증 정보 보호를 설명합니다. Landlock은 파일 접근을 제한하는 Linux 커널 기능입니다. seccomp는 프로그램이 운영체제에 보내는 저수준 요청인 시스템 호출을 제한합니다. 이런 제약은 에이전트의 추론 바깥에서 강제됩니다.

게이트웨이는 샌드박스와 접근 권한을 관리합니다. 샌드박스 외부의 감독 프로세스는 외부로 나가는 요청을 정책과 대조하고, 허용된 곳에 인증 정보를 제공합니다. 정책 검증기는 모델링된 권한이 정의된 경계를 지키는지 확인합니다. 이는 에이전트가 할 수 있는 일을 통제하는 장치이며, 허용된 작업의 결과가 올바르다는 보장은 아닙니다.

NVIDIA는 사용자 정의 에이전트와 이미지 외에도 Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw, OpenCode의 사용 경로를 안내합니다. “지원”이 모든 툴의 사전 설치를 의미하지는 않습니다. 현재 기본 워크로드는 최소 구성의 Ubuntu 이미지로, 에이전트를 실행하는 명령줄 프로그램인 에이전트 CLI가 들어 있지 않습니다.

업무에서 달라지는 점은 권한 구성을 재사용할 수 있다는 것입니다. 재사용 가능한 경계가 없으면 새로운 에이전트 워크플로를 도입할 때마다 어떤 파일, 비밀 정보, 서비스를 공개할지 다시 결정해야 할 수 있습니다. 경계를 갖추면 이런 결정을 워크로드와 함께 묶고 변경 사항을 검토할 수 있습니다. 효과는 접근 권한 설정과 작업 중단 대응에 쓴 엔지니어 시간으로 측정해야 합니다. 어디에나 적용할 수 있는 검증된 시간 절감 수치는 없습니다.

현재 어떤 환경에서 실행할 수 있나요?

호스트는 현재 지원 매트릭스를 기준으로 선택해야 합니다. 이 안내는 2026년 11월 8일에 확인한 v0.1.7 문서를 따릅니다.

WSL 2는 Windows에서 Linux 환경을 실행합니다. MXC는 별도의 네이티브 Windows 격리 경로입니다. “Windows 지원”이라는 말만 보고 이들을 서로 바꿔 쓸 수 있는 하나의 설치 방식으로 이해해서는 안 됩니다.

Windows 협업 발표는 MXC를 통해 OpenShell을 Windows로 가져오는 방향을 설명합니다. 그렇다고 네이티브 경로에 지금 일반적인 안정 버전 설치 프로그램이 있다는 뜻은 아닙니다. 현재 설치 문서는 표준 릴리스 채널에서 네이티브 Windows 바이너리를 제공하지 않는다고 명시합니다.

처음 평가한다면 지원되는 Linux 또는 Apple Silicon 구성을 선택하는 편이 좋습니다. 지원 매트릭스에는 커널과 런타임 요구 사항도 나옵니다. 필요한 Landlock ABI는 Linux 6.2에 도입됐지만, 커널 버전만 맞으면 되는 것은 아닙니다. 런타임이 필수 검사를 통과해야 합니다. macOS의 Docker Desktop 경로에서는 이러한 Linux 기능이 내부 Linux 가상 머신에서 실행됩니다. NVIDIA Vera CPU는 필요하지 않습니다.

CLI를 설치하고 첫 에이전트 실행하기

NVIDIA 문서의 OpenCode 예제로 시작해 보겠습니다. 서비스 접근을 위한 프로바이더, 에이전트가 들어 있는 이미지, 이를 실행할 샌드박스라는 세 가지 요소를 확인할 수 있습니다. 아래 절차는 문서를 바탕으로 정리했으며, 로컬에서 직접 테스트했다는 뜻은 아닙니다.

1. 호스트를 준비하고 OpenShell을 설치합니다. Docker 경로를 사용한다면 Docker Desktop을 실행하거나 Docker Engine 28.0 이상을 준비해야 합니다. 지원되는 Linux 또는 macOS에서 설치 가이드는 curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh를 사용합니다. 실행 전에 설치 스크립트를 검토해야 합니다. 이 스크립트는 CLI, 정책 검증기, 로컬 게이트웨이를 설치합니다. openshell status를 실행해 CLI가 게이트웨이에 연결되는지 확인합니다.

2. 모델 서비스를 구성합니다. 예제에서는 OpenRouter를 사용합니다. 프로바이더를 생성하기 전에 호스트 환경에 OPENROUTER_API_KEY를 설정합니다. 프로바이더 프로필에는 허용할 서비스 엔드포인트와 실행 파일 경로가 담기며, 인증 정보는 프로바이더가 저장합니다. NVIDIA 예제 프로필은 /usr/local/bin/opencode가 openrouter.ai에 접근하도록 허용합니다.

3. 프로필을 가져오고 프로바이더를 만든 뒤 이미지를 실행합니다. 호스트에서 다음 명령을 순서대로 실행합니다.

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

이미지가 OpenCode를 제공하고, -- 뒤의 명령이 이를 메인 프로세스로 실행합니다. 첫 에이전트 실행 가이드는 OpenRouter 크레딧 없이 이 무료 모델을 사용합니다. 이는 예제에서 선택한 모델에 대한 설명이며, 어떤 모델을 사용해도 비용이 들지 않는다는 약속은 아닙니다.

4. 호스트에서 접근 요청을 검토합니다. 에이전트가 승인되지 않은 목적지에 접근하면 OpenShell은 요청을 차단하고 범위가 좁은 규칙 제안을 작성합니다. openshell rule get my-agent --status pending을 실행합니다. 제안이 해당 작업에 필요한 접근 범위와 일치한다면, 실제 ID로 자리표시자를 바꿔 openshell rule approve my-agent --chunk-id <chunk-id>로 그 제안만 승인합니다. 규칙이 다시 로드되면 에이전트가 요청을 재시도할 수 있습니다.

5. 실제로 부여한 권한을 확인합니다. openshell policy get my-agent --base를 실행한 다음 openshell policy get my-agent --full을 실행합니다. 첫 명령은 기본 정책을 보여 주고, 두 번째 명령은 프로바이더가 추가한 규칙까지 포함합니다. 실제 프로젝트나 민감한 서비스를 연결하기 전에 유효 권한을 검토해야 합니다.

일회성 평가를 마쳤다면 openshell sandbox delete my-agent로 삭제합니다.

실행 중에 바꿀 수 있는 정책은 무엇인가요?

네트워크 접근 권한은 작업 중에도 바꿀 수 있습니다. 파일 시스템과 프로세스의 경계를 바꾸려면 샌드박스를 새로 만들어야 합니다.

실행 중 변경에도 영향은 따릅니다. 새 네트워크 규칙을 적용하면 이전 규칙 아래에서 열린 연결이 닫히므로 클라이언트가 다시 연결해야 합니다. 새로운 외부 미들웨어 서비스를 등록하려면 게이트웨이를 설정하고 재시작해야 합니다. 저장된 정책에 파일 시스템 경로를 추가해도 이미 실행 중인 워크로드에 해당 권한이 생기지는 않습니다. 시작 후에는 경로 제거 또는 시작 설정 변경이 거부됩니다. 정책 관리 가이드에서 이러한 차이를 설명합니다.

주의할 점이 하나 더 있습니다. 정책 파일이 없다고 접근 권한도 없는 것은 아닙니다. 정책은 이미지, 환경 설정 또는 게이트웨이 전체 정책에서 올 수 있습니다. 연결된 프로바이더가 네트워크 규칙을 추가할 수도 있습니다. 정책 선택 규칙은 전역 정책이 샌드박스 자체 정책을 대체한다는 점도 명확히 합니다. 단순히 제한을 하나 더 얹는 방식이 아닙니다.

허용 범위를 명확히 파악할 수 있는 코딩 에이전트 정책

버그 수정 에이전트에는 변경 사항을 게시할 권한보다 먼저, 쓰기 가능한 프로젝트 디렉터리와 읽기 전용 API 접근 권한을 부여합니다.

아래는 프로젝트가 /workspace에 있고 curl이 /usr/bin/curl에 설치된 코딩용 이미지를 미리 준비한 경우의 정책 예시입니다. policy.yaml로 저장하고 새 샌드박스를 생성할 때 --policy ./policy.yaml을 전달합니다. 이 이미지 구조를 위한 템플릿이며, 모든 에이전트 이미지에 그대로 적용할 수 있는 설정은 아닙니다.

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

에이전트는 프로젝트와 임시 파일을 수정할 수 있습니다. 네트워크 규칙은 지정된 실행 파일이 GitHub API에 GET, HEAD, OPTIONS 요청을 보내도록 허용합니다. 아무 프로그램에나 인터넷 접근 권한을 주거나 패키지 다운로드 또는 Git 푸시를 허용하지는 않습니다. 모델 프로바이더는 별도로 구성합니다.

이미지가 요구하는 쓰기 가능한 에이전트 상태 디렉터리를 준비하고, 필요한 경로를 의도적으로 추가해야 합니다. 이 경로들은 샌드박스의 파일 시스템을 가리킵니다. 호스트에 이름이 비슷한 디렉터리가 있다고 해서 자동으로 접근할 수 있는 것은 아닙니다. 또 네트워크를 사용하는 워크로드에는 기본 파일 시스템 경로가 추가됩니다. 따라서 이 짧은 YAML에 나열된 경로만 유효 접근 경계 안에 존재한다는 뜻은 아닙니다.

특히 살펴볼 설정은 두 가지입니다. hard_requirement는 사용자가 지정한 파일 시스템 규칙을 강제할 수 없으면 시작을 중단합니다. 다만 개별 경로가 없거나 접근할 수 없는 경우에는 해당 경로를 건너뛸 수 있습니다. enforcement: enforce는 검사 대상 요청 중 허용되지 않은 것을 차단합니다. 스키마의 기본값인 audit 모드는 위반을 기록하면서 해당 요청을 허용합니다. 템플릿을 수정하기 전에 정책 스키마 참조 문서를 확인해야 합니다.

허용과 거부를 모두 테스트해야 합니다. NVIDIA의 네트워크 정책 튜토리얼은 읽기 전용 규칙 아래에서 curl -s https://api.github.com/zen이 성공하는지 확인한 뒤 POST 요청이 거부되는지 검증합니다. 호스트에서 openshell logs my-agent --since 5m --source sandbox로 로그를 살펴봅니다. 실제 프로젝트에서는 의도한 파일 쓰기와 범위 밖 파일 접근도 테스트해야 합니다. 에이전트 실행에 성공했다는 사실만으로 보안 정책의 검증이 끝나지는 않습니다.

먼저 시도해 볼 만한 워크플로 다섯 가지

초기에 적합한 활용 사례는 작업 범위가 명확하고 사람이 결과를 판단할 수 있는 경우입니다. 예상되는 운영상 가치를 기준으로 정리하면 다음과 같습니다.

어느 사례도 생성된 코드의 정확성이나 장애 진단의 신뢰성을 보장하지 않습니다. 가치는 에이전트가 작업하는 동안 일어날 수 있는 일을 좁히는 데 있습니다. 더 폭넓은 툴 선택은 2026년 주요 AI 샌드박스 보안 툴을, 실행 플랫폼 선택은 2026년 주요 AI 에이전트 코드 샌드박스를 참고하면 됩니다.

OpenShell을 바탕으로 만들어 볼 사업 두 가지

가장 유망한 기회는 팀용 코딩 에이전트 온보딩 키트입니다. 구매자는 승인된 환경 안에서 개발자가 생산적으로 일하기를 원하는 플랫폼 책임자입니다. DataForSEO는 이 글의 조사 쿼리가 반환한 시장에서 “claude code sandbox”의 월간 검색량을 1,300회로 추정합니다. 이는 설정 방법에 관심이 있다는 근거이지, 잠재 고객이 1,300명이라는 뜻은 아닙니다. 일부 검색자는 OpenShell이 아니라 에이전트 자체의 샌드박스를 찾습니다.

판매 가능한 최소 구성은 에이전트 하나와 승인된 호스트 구성 하나를 지원할 수 있습니다. 준비된 이미지, 검토된 정책, 프로바이더 설정 체크리스트, 반복 가능한 허용·거부 테스트를 묶는 방식입니다. 업데이트 책임을 명확히 정하고, 팀에서 실제로 쓸 수 있는 도입 결과를 판매합니다. 걸림돌은 유지보수입니다. 이미지 경로, 에이전트 동작, 실험적 인터페이스가 바뀔 수 있습니다. 호스팅 제품을 만들기 전에 플랫폼 책임자에게 이 유지보수 부담을 먼저 물어봐야 합니다.

두 번째 기회는 정책 검토 워크벤치입니다. 보안 팀이 유효 정책의 허용 범위를 확인하고, 변경 사항을 비교하며, 승인 내역을 기록하는 데 사용할 수 있습니다. DataForSEO는 “ai agent security”의 월간 검색량을 480회, “ai agent security tools”를 70회로 추정합니다. 별개의 이 검색어들은 넓은 범위의 수요 신호이며, 이를 더해 고유 구매자 수로 계산해서는 안 됩니다.

MVP는 기본 정책과 유효 정책을 가져오고, 추가된 목적지와 요청 권한을 강조하며, 검토 기록에 테스트 결과를 첨부할 수 있습니다. 걸림돌은 차별화입니다. OpenShell에는 이미 정책 분석, 제안, 로그 기능이 있습니다. 기존 명령에 대시보드를 씌우는 데 그치지 않고 팀의 검토 절차를 개선해야 합니다. 구매자와 납품물을 더 명확히 정의할 수 있는 온보딩 키트부터 시작하는 편이 좋습니다.

OpenShell로 해결할 수 없는 문제

OpenShell은 접근을 제한하지만, 허용된 행동이 사업적으로 좋은 결정인지 판단하지는 않습니다. 프로젝트 파일 쓰기가 허용된 에이전트는 잘못된 패치를 작성할 수 있습니다. 승인된 외부 목적지에도 정책이 전송을 허용한 데이터가 전달될 수 있습니다. 파일 접근과 엔드포인트 승인은 실제로 무엇을 노출하려는지에 맞춰 설정해야 합니다.

또한 ID 관리 시스템, 비밀 정보 저장소, 모니터링, 거버넌스를 대체하지 않습니다. NVIDIA의 런타임 제어 발표는 에이전트 워크로드 외부에서 제약을 강제하는 방식을 설명합니다. 이를 주변 시스템의 한 부분으로 받아들여야 하며, 나머지 체계를 없애도 된다는 근거로 삼아서는 안 됩니다.

이 프로젝트에는 이제 지원 매트릭스 범위 안에서 프로덕션 사용을 목적으로 하는 안정 릴리스가 있습니다. 따라서 OpenShell 전체를 실험용 데모라고 부르면 오해를 낳습니다. 한계는 더 구체적입니다. 실험적 인터페이스는 패치 릴리스에서도 바뀔 수 있고, 네이티브 Windows는 여전히 개발 중입니다. 또 NVIDIA는 현재의 적격성 검증 프로파일이 전체 릴리스 적격성 검증 정책을 포괄하지는 않는다고 밝힙니다. 배포 버전을 고정하고, 실제 사용할 워크로드와 호스트 조합을 검증해야 합니다.

월요일에 바로 할 일: 플랫폼 책임자가 민감하지 않은 저장소 하나와 에이전트 하나를 고르도록 합니다. 지원되는 호스트에 설치하고, 이미지를 준비한 뒤, 파일과 네트워크 접근 범위를 정의합니다. 이어 허용된 작업과 차단돼야 할 작업을 각각 테스트합니다. 첫 주 동안 설정 시간과 작업 중단 대응에 쓴 엔지니어 시간을 기록합니다. 팀이 부여한 모든 권한의 이유를 설명할 수 있을 때 범위를 넓힙니다.

이 구성을 팀 워크플로에 적용하려면 프로덕션 제어 체계 구축을 도와드릴 수 있습니다.