엔비디아 OpenShell과 Sentry 이해하기: AI 에이전트의 권한을 정하는 법

OpenShell은 AI 에이전트가 접근할 파일과 네트워크를 정책으로 제한하는 실행 환경입니다. 설치 없이 권한표를 만드는 예제로 시작해 Sentry의 역할과 정책 증명기의 지원 범위를 알아봅니다.

홍승협(준이아빠)게시 2026.09.29수정 2026.10.04약 30분

지금까지 50명 넘게 읽었어요, 61%가 끝까지 읽었어요

#AI #자동화 #API

엔비디아 OpenShell과 Sentry 이해하기: AI 에이전트의 권한을 정하는 법 대표 이미지

첫 단계: 요약 작업에 필요한 권한 적어 보기
모델의 판단과 실행 환경의 제어
OpenShell의 구성 그림 읽기
정책 증명기가 확인하는 것
Sentry가 추가로 맡는 일
파트너 발표에서 확인할 내용
코덱스와 클로드 코드를 쓰고 있다면
발표 당시의 8컷 만화
Sources
3줄 요약

세 줄로 먼저 읽기

OpenShell은 에이전트를 격리하고 파일과 네트워크 접근을 정책으로 제한하는 실행 환경입니다.
정책 증명기는 지원하는 규칙의 권한 범위를 비교하며, 여러 에이전트의 우회 경로까지 모두 증명하는 기능은 개발 중입니다.
Sentry는 별도 하드웨어에서 감시하는 구성이고, 처음에는 설치 없이 필요한 파일 권한부터 적어 볼 수 있습니다.

이번 방문에서 한 편은 바로 볼 수 있습니다.

NVIDIA Open Agent Safety Platform은 엔비디아가 2026년 9월 28일 공개한 AI 에이전트 안전 플랫폼입니다. 에이전트는 AI가 파일 읽기나 명령 실행 같은 도구를 사용해 일을 진행하는 프로그램입니다. 이 플랫폼은 에이전트에게 일을 맡길 때 접근 가능한 파일과 서비스의 범위를 정하고 검사합니다.

구성은 OpenShell과 Sentry입니다. OpenShell은 프로그램이 돌아가는 실행 환경인 런타임이고, Sentry는 별도 하드웨어에서 활동을 감시하는 구성입니다. 처음부터 둘 다 설치할 필요는 없습니다. 이 글에서는 폴더 권한을 정하는 짧은 예제로 개념을 익힌 뒤, 구조와 선택 실습을 살펴봅니다. 설명은 2026년 10월 4일 공개 문서를 기준으로 합니다.

첫 단계: 요약 작업에 필요한 권한 적어 보기

메모 앱을 열고 요약 작업 권한이라는 메모를 만듭니다. 가상 업무는 “/work/demo의 문서를 읽고 요약을 /work/result에 저장한다”입니다. /work/demo처럼 슬래시로 구분한 문자열은 폴더 위치를 나타내는 경로입니다. 이 예에서는 원문을 바꾸거나 인터넷으로 보낼 필요가 없습니다.

아래 네 행동에 허용과 거부를 먼저 적어 보세요. 메모로 판단하는 연습이며 실제 컴퓨터의 권한을 바꾸지는 않습니다. 설치와 서비스 사용료 없이 진행할 수 있고, 5분 정도를 잡으면 됩니다.

행동	이 과제에서 정할 권한	이유
`/work/demo/회의.txt` 읽기	허용	요약할 원문이 필요함
`/work/demo/회의.txt` 덮어쓰기	거부	원문 수정은 맡기지 않음
`/work/result/요약.txt` 쓰기	허용	결과를 저장해야 함
외부 웹사이트에 원문 보내기	거부	이번 과제에 필요하지 않음

표와 답이 다르면 “이 행동이 요약 파일을 만드는 데 꼭 필요한가요?”를 다시 확인합니다. 특히 읽기와 쓰기는 같은 폴더에서도 다른 권한입니다. 메모를 저장하고 닫았다가 다시 열어 네 판단과 이유가 남았는지 확인합니다.

다음에는 조건 하나를 바꿉니다. “결과를 파일로 저장하지 말고 화면에만 표시한다”면 /work/result 쓰기도 거부할 수 있습니다. 바꾼 이유를 메모 아래에 적습니다. 여기까지 하면 에이전트에게 필요한 권한을 작업별로 구분하는 연습을 마친 것입니다.

모델의 판단과 실행 환경의 제어

AI에게 “원문을 바꾸지 마세요”라고 요청하는 것과 운영체제가 그 파일에 쓰지 못하게 하는 것은 역할이 다릅니다. 전자는 모델이 무엇을 시도할지 안내하고, 후자는 요청이 잘못되더라도 실행 가능한 범위를 제한합니다. 모델 학습과 실행 제어를 함께 사용할 수 있습니다.

직원의 약속과 사무실 출입 권한을 함께 두는 경우를 떠올리면 이해하기 쉽습니다. 다만 실행 제어도 설정 오류나 소프트웨어 취약점까지 없앤다는 뜻은 아닙니다. 허용할 권한을 정하고 실제 동작을 확인해야 합니다. 엔비디아는 장시간 도구를 사용하는 에이전트를 모델의 판단에만 맡기기 어렵다는 문제의식에서 이 플랫폼을 설명합니다.

구성	맡는 일	필요한 환경
OpenShell	파일, 프로세스와 네트워크 접근을 정책으로 제한	지원 운영체제와 컨테이너 실행 환경
Sentry	호스트와 분리된 하드웨어에서 감시와 제어	BlueField-4 DPU 등을 사용하는 참조 구성

프로세스는 실행 중인 프로그램이고, 컨테이너는 프로그램과 실행에 필요한 구성 요소를 묶어 분리된 환경에서 돌리는 방식입니다. 호스트는 에이전트 실행 환경을 제공하는 컴퓨터입니다. DPU는 서버에서 네트워크와 보안 처리를 맡는 별도 프로세서입니다. 일반 노트북에서 OpenShell을 알아보는 데 DPU 구매가 필요한 것은 아닙니다.

OpenShell의 구성 그림 읽기

그림 위쪽의 게이트웨이는 샌드박스의 생성과 종료, 정책을 관리하는 서버입니다. 샌드박스는 프로그램이 허용된 자원 안에서 실행되도록 격리한 환경입니다. 각 에이전트는 이 안에서 파일이나 도구를 사용합니다. API는 프로그램이 외부 서비스에 요청을 보내는 연결 방식입니다. 아래쪽은 모델 API, 데이터, 외부 도구 서버이며 초록색 화살표는 정책이 허용한 연결을 뜻합니다. 그림에 화살표가 있다고 모든 연결이 기본 허용되는 것은 아닙니다.

샌드박스 바깥의 슈퍼바이저는 나가는 요청을 정책과 대조합니다. 정책은 “이 프로그램이 이 주소에 읽기 요청을 보낼 수 있다”처럼 허용 조건을 적은 규칙입니다. 통신 규칙인 프로토콜과 설정에 따라 HTTP, GraphQL, MCP 요청을 검사합니다. 각각 웹 통신, 데이터 질의, AI와 외부 도구 연결에 쓰는 방식이며 처음에는 세 이름을 외우기보다 어떤 요청을 허용할지에 집중하면 됩니다. 모든 암호화 통신의 의미를 설정 없이 알아내는 기능으로 이해하면 안 됩니다. 판정은 보안 도구가 함께 읽을 수 있는 OCSF 형식의 기록으로 남깁니다.

실제 API 키를 대신 넣어 주는 방식

API 키는 서비스를 이용할 권한을 나타내는 인증 정보입니다. 그림 왼쪽의 에이전트는 대체 문자열인 placeholder key로 요청을 만듭니다. 가운데 프록시가 정책과 연결 설정을 검사하고, 허용된 서비스에 보낼 때 실제 키를 넣습니다.

이 보호는 OpenShell에 연결해 관리하는 자격 증명에 적용됩니다. 실제 키를 별도 파일에 넣어 에이전트에게 읽게 하면 그 파일까지 자동으로 보호되는 것은 아닙니다. 또 키를 감춘다고 원문이나 고객 정보의 전송까지 모두 막히지는 않습니다. 허용된 목적지에 보낼 자료도 따로 정해야 합니다.

읽기 전용 네트워크 규칙의 예

아래는 공식 기술 문서의 정책 일부입니다. 설정 파일인 YAML의 들여쓰기로 항목의 관계를 나타냅니다. 이 조각만 저장해서 전체 샌드박스 정책으로 적용하는 예제는 아닙니다.

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

host는 접속 주소, port는 연결 번호, binaries는 요청을 보내는 실행 파일을 지정합니다. 이 예에서는 /usr/bin/curl이라는 통신 프로그램이 GitHub API를 읽기 전용으로 이용하게 합니다. 공식 예제의 GET 요청은 통과하고 POST 요청은 차단됩니다. GET과 POST는 HTTP 요청의 종류이며, 다른 API에서도 GET이면 무조건 민감 정보가 전달되지 않는다는 뜻은 아닙니다.

실제 시험에서는 “응답이 실패했다”만으로 OpenShell이 막았다고 판단하지 않습니다. 서비스 자체의 인증 오류일 수도 있습니다. 호스트 쪽 OpenShell 로그에서 요청과 거부 이유를 대조해야 합니다. 전체 설정과 실행 순서는 공식 런타임 제어 예제에 있습니다.

새 서비스가 필요한 경우 정책 조언 기능이 변경을 제안할 수 있습니다. 기본적으로 사람이 검토하며 에이전트가 자기 제안을 승인할 수 없습니다. 네트워크 규칙은 승인 후 실행 중 반영할 수 있지만 파일과 프로세스 제한을 바꾸려면 새 샌드박스가 필요합니다.

정책 증명기가 확인하는 것

정책 증명기(policy prover)는 후보 정책의 권한이 기준 정책 안에 있는지 논리 규칙으로 비교하는 도구입니다. 예를 들어 기준이 /usr와 /etc 읽기를 허용하고 후보가 /usr 읽기만 허용한다면 후보의 권한이 더 좁습니다.

현재 문서의 지원 범위는 파일, 프로세스와 일부 네트워크 규칙 등입니다. 런타임이 검사하는 규칙과 증명기가 증명할 수 있는 규칙은 다릅니다. GraphQL과 MCP 규칙은 증명기에서 지원하지 않는 것으로 설명돼 있습니다. 여러 에이전트의 권한을 합쳤을 때 생기는 우회 경로까지 분석하는 기능도 공식 기술 블로그에서 개발 중이라고 밝힙니다.

엔비디아는 보호된 GitHub 저장소에 쓰기 권한을 얻으려는 에이전트의 시도를 최대 두 시간 시험했고 쓰기가 일어나지 않았다고 보고했습니다. 이는 회사가 공개한 특정 실험의 결과이며 모든 공격을 막거나 모든 운영 환경을 보호한다는 보증은 아닙니다.

선택 실습: 설치된 증명기로 두 파일 비교하기

이 부분은 터미널에서 명령을 실행해 본 분을 위한 선택 실습입니다. openshell-prover가 이미 설치돼 있다면 모델 API나 게이트웨이에 연결하지 않고 로컬 파일만 비교할 수 있습니다. 없다면 앞의 권한표 연습까지만 하고 공식 정책 증명기 문서를 참고합니다.

새 연습 폴더에 다음 두 파일을 일반 텍스트로 저장합니다. 워드 문서 형식이나 .yaml.txt 이름으로 저장하지 않도록 확장자를 확인합니다. 예제의 /usr 등은 비교할 경로를 적은 것이며 해당 폴더에 직접 파일을 쓰라는 지시가 아닙니다. 첫 파일 이름은 boundary.yaml이며 비교 기준입니다.

version: 1
filesystem_policy:
  read_only:
    - /usr
    - /etc

둘째 파일은 candidate.yaml이며 검사할 후보입니다.

version: 1
filesystem_policy:
  read_only:
    - /usr

두 파일이 있는 폴더에서 터미널을 열고 다음 명령을 입력합니다.

openshell-prover check candidate.yaml --boundary boundary.yaml

공식 예제의 예상 결과는 result: within_boundary입니다. 비교한 범위에서 후보 권한이 기준 안에 있다는 뜻입니다. 이 명령은 정책을 실행 환경에 적용하거나 승인하지 않습니다.

두 번째에는 후보 파일을 다음처럼 바꾸고 같은 명령을 다시 실행합니다.

version: 1
filesystem_policy:
  read_only:
    - /usr
  read_write:
    - /tmp

예상 결과는 exceeds_boundary입니다. 기준에 없는 /tmp 쓰기가 추가됐기 때문입니다. 이때 명령이 종료 코드 1로 끝나는 것은 예제에서 의도한 권한 초과 결과입니다. 후보 파일에서 read_write와 그 아래 /tmp 줄을 지우고 저장한 뒤 같은 명령을 실행하면 처음 상태로 비교를 반복할 수 있습니다. 명령이 예상과 달리 끝나지 않으면 Ctrl+C로 중단하고 파일 내용과 버전을 확인합니다.

결과 또는 문제	해석과 다음 행동
`within_boundary`	지원하는 규칙의 비교 통과이며 실제 차단 성공과 구분
`exceeds_boundary`	기준 밖의 권한이 있음. 출력의 경로와 동작 확인
`unsupported` 또는 `inconclusive`	지원하지 않거나 결론을 못 냄. 통과로 처리하지 않음
`error`	파일 형식과 오류 메시지를 확인
`command not found`	실행 파일이 설치됐는지 확인하고 이 선택 실습 중단
파일을 찾을 수 없음	터미널의 현재 폴더와 두 파일 이름 확인

검사 결과와 사용한 두 파일을 같은 폴더에 보관합니다. within_boundary여도 그 정책이 해당 업무에 꼭 필요한 최소 권한인지, 실제 실행 환경이 올바르게 제한하는지는 별도로 확인해야 합니다.

Sentry가 추가로 맡는 일

Sentry는 BlueField-4 같은 별도 하드웨어에서 감시하는 참조 구성입니다. 에이전트가 실행되는 호스트가 침해된 상황에서도 감시를 유지하는 것이 목표입니다. 엔비디아는 밀리초 단위 격리를 설명하지만, 이를 개인 컴퓨터에서 확인한 성능값으로 받아들이지는 않습니다.

모델로 향하는 요청과 응답이 감시 장치를 거치도록 구성하면 추가 모델 호출을 차단할 수 있습니다. 그렇다고 외부 모델이 공개하지 않는 내부 추론을 전부 읽는 것은 아닙니다. 이미 실행 중인 도구의 제어도 필요하고, 이미 보낸 자료나 완료한 외부 작업이 호출 차단만으로 취소되지는 않습니다.

Vera Rubin POD 참조 구성에는 BlueField-4가 포함되며 엔비디아는 소프트웨어 업데이트로 보호를 활성화하는 방식을 설명합니다. 일반 PC에 소프트웨어 하나를 설치하면 같은 하드웨어 구성이 생긴다는 뜻은 아닙니다. OpenShell의 Apache 2.0 공개 저장소와 Sentry 참조 구성은 구분해서 살펴봅니다.

파트너 발표에서 확인할 내용

엔비디아 발표에는 100곳이 넘는 회사가 참여하며, 다음과 같은 연동 방향이 소개됐습니다.

회사	발표된 연동 내용
앤트로픽	Claude Managed Agents의 샌드박스 접근 제어
SpaceXAI	Cursor와 Grok에 플랫폼 적용
세일즈포스	Slack에서 활동과 감사 이벤트 확인, 권한 요청 검토
SAP	Joule Studio 런타임에 OpenShell 통합
Scale AI	에이전트 인프라 계층에 플랫폼 기술 반영

파트너 로고는 내 계정에 해당 기능이 이미 제공된다는 표시가 아닙니다. 쓰려는 서비스의 지원 버전과 실제 제공 범위를 확인해야 합니다. 발표 명단에 없는 회사에 대해서도 명단만으로 보안 수준이나 도입 계획을 판단할 수는 없습니다.

코덱스와 클로드 코드를 쓰고 있다면

기존 도구의 샌드박스에도 운영체제 수준의 격리 기능이 있을 수 있습니다. 이를 모두 “에이전트가 스스로 지키는 약속”으로 보는 것은 부정확합니다. OpenShell은 여러 에이전트의 실행 환경과 정책을 별도로 관리하는 역할을 더합니다. 기존 제한과 겹치는 부분, 추가되는 관리 기능을 나누어 비교하면 됩니다.

OpenShell의 현재 README는 리눅스와 애플 실리콘 맥을 안내하고, 윈도우 WSL 2는 실험 지원으로 표시합니다. 컨테이너 실행에는 Docker나 Podman 같은 환경이 필요합니다. 기본 샌드박스는 에이전트가 없는 최소 우분투이므로 샌드박스 생성만으로 AI가 일을 시작하지는 않습니다. 실제 사용에는 에이전트, 모델 접속 설정, 정책이 더 필요하며 모델 이용 비용은 별도입니다.

처음 도입한다면 가짜 문서로 앞의 네 행동을 시험하고, 허용된 읽기와 결과 저장은 되는지, 원문 덮어쓰기와 외부 전송은 막히는지 로그와 대조합니다. 예상과 다르면 권한을 넓히기 전에 어떤 프로그램과 요청이 실패했는지 확인합니다. 회사에 적용할 때는 정책 파일과 OpenShell 버전, 확인 결과를 함께 남깁니다.

익명 운영 통계 전송은 기본으로 켜집니다. README는 프롬프트, 자격 증명, 샌드박스 이름과 호스트 파일 경로를 보내지 않는다고 설명합니다. 끄려면 클라이언트 터미널에만 변수를 넣는 것이 아니라 게이트웨이의 OPENSHELL_TELEMETRY_ENABLED=false 설정이나 해당 배포 설정을 적용해야 합니다.

출시 발표는 0.1.0 기준이고 현재 증명기 문서는 v0.1.2로 표시됩니다. 설치와 업그레이드는 공식 저장소의 해당 버전 안내를 따릅니다. 폴더 권한을 구분하는 것이 이번 목표라면 설치 전에 마친 메모 연습으로도 충분합니다.

발표 당시의 8컷 만화

기존 만화는 격리와 외부 검사 장치의 관계를 보여줍니다. 다만 2컷의 “지금까지는 모델 쪽 안전장치만”이라는 대사는 부정확합니다. 기존에도 운영체제 격리가 있었습니다. 4컷은 설계 목표이며 무결점 보증이 아니고, 7컷의 브라우저 비유도 실제 격리 구조를 단순화한 설명입니다. 현재 기능과 한계는 위 본문을 기준으로 읽습니다.

발표 당시 만화와 대사 보기

그림은 DGX Spark에서 Qwen-Image-2.1로 그렸고, 대사는 글과 대조해 따로 얹었습니다.

만화 대사 전문

(2026년 9월 28일, 엔비디아 발표) 민준: 맡겨 두면 가끔 엉뚱한 데까지 건드려서요. / 준이아빠: 그래서 밖에서 막는 장치가 나왔어요.
(학습이 아니라 실행 환경에서 막는다) 준이아빠: 잘 가르치는 것과 못 들어가게 하는 것은 층이 달라요. / 민준: 지금까지는 모델 쪽 안전장치만 있었던 거네요.
(에이전트를 상자에 넣고 통로만 연다) 준이아빠: 에이전트를 격리된 환경에서 돌리고 허용한 통로만 열어 줘요. / 민준: 파일과 네트워크도 허용한 범위 안에서만 쓰는 거군요.
(검사하는 쪽에 에이전트가 닿지 못한다) 준이아빠: 검사 장치를 에이전트 밖에 두는 게 핵심이에요. / 민준: 안에 있으면 스스로 끌 수도 있으니까요.
(대체가 아니라 층이 다르다) 민준: 그럼 모델 쪽 안전장치는 필요 없어지나요? / 준이아빠: 아니요. 둘은 서로 다른 층이라 같이 둬요.
(에이전트가 벗어나기 쉬운 조건) 준이아빠: 도구가 많고 시간이 길고 지시가 애매할 때 벗어나기 시작해요. / 민준: 며칠씩 붙들고 있을 때가 딱 그렇네요.
(브라우저가 탭을 나눈 것과 같다) 준이아빠: 브라우저가 안전해진 것도 페이지를 믿어서가 아니라 탭마다 격리해서였어요. / 민준: 믿는 대신 격리하는 거군요.
(지금 할 수 있는 것) 민준: 지금은 제가 허용 범위를 직접 적어 두는 게 먼저겠어요. / 준이아빠: 맞아요. 폴더와 도구부터 정해요.

Sources

3줄 요약

OpenShell은 에이전트를 격리하고 파일과 네트워크 접근을 정책으로 제한하는 실행 환경입니다.
정책 증명기는 지원하는 규칙의 권한 범위를 비교하며, 여러 에이전트의 우회 경로까지 모두 증명하는 기능은 개발 중입니다.
Sentry는 별도 하드웨어에서 감시하는 구성이고, 처음에는 설치 없이 필요한 파일 권한부터 적어 볼 수 있습니다.

제대로 이해했는지 한 문제로 확인해 볼까요?

답을 고르면 바로 풀이가 나와요.

정책 증명기의 within_boundary 결과로 알 수 있는 것은 무엇인가요?

이 글이 도움이 되었나요?

이 글 다음 배우기AI 에이전트 중급: 원리와 설계중급 코스 · 12편

도구에 상관없이 통하는 에이전트 원리와 설계 규칙을 정리했습니다

코스 전체 보기 →

이어서 읽기 좋은 글허깅페이스 사용 전 확인할 것: 모델 카드와 엔비디아 인수 발표 →

허깅페이스는 모델과 데이터 및 실행 데모를 공유하는 플랫폼입니다. 모델 카드에서 게시자와 이용 조건을 읽는 방법, 엔비디아의 인수 합의 발표와 실제 제품 조건을 구분하는 기준을 설명합니다.