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

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

플랫폼은 OpenShell과 Sentry 두 가지로 이뤄집니다. OpenShell은 에이전트 프로그램이 돌아가는 실행 환경(런타임)이고, Sentry는 별도 하드웨어에서 에이전트의 활동을 감시하는 구성입니다. 이 글의 설명은 2026년 10월 4일 공개 문서 기준입니다.

OpenShell과 Sentry가 맡는 일

항목	OpenShell실행 환경	Sentry하드웨어 감시
하는 일	파일, 프로세스, 네트워크 접근 제한	호스트와 분리된 하드웨어에서 감시와 제어
필요한 환경	지원 운영체제와 컨테이너 실행 환경	BlueField-4 DPU를 쓰는 참조 구성
공개 방식	Apache 2.0 공개 저장소	참조 구성
일반 노트북에서 사용	제공	제공하지 않음

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

모델에게 하는 부탁과 실행 환경의 제한

AI에게 "원문을 바꾸지 마세요"라고 요청하는 것과 운영체제가 그 파일에 쓰지 못하게 막는 것은 하는 일이 다릅니다. 요청은 모델이 무엇을 시도할지를 이끌고, 실행 환경의 제한은 모델이 잘못 시도하더라도 실제로 할 수 있는 범위를 묶어 둡니다. 엔비디아는 오랫동안 도구를 쓰며 일하는 에이전트를 모델의 판단에만 맡기기 어렵다는 점을 이 플랫폼을 만든 이유로 듭니다. 두 방식은 함께 씁니다.

회의록 폴더의 문서를 읽고 요약을 결과 폴더에 저장하는 에이전트를 예로 들면, 정책에 적을 권한은 네 줄입니다.

회의록 요약 에이전트에 줄 권한

행동	허용 여부
/work/demo/회의.txt 읽기	제공
/work/demo/회의.txt 덮어쓰기	제공하지 않음
/work/result/요약.txt 쓰기	제공
외부 웹사이트로 원문 보내기	제공하지 않음

실행 환경의 제한도 설정 실수나 소프트웨어 취약점까지 막아 주지는 못합니다. 그래서 정책을 적은 뒤에는 허용한 동작만 실제로 되는지 실행 로그로 맞춰 봅니다.

OpenShell의 구성

아래는 엔비디아 기술 블로그에 실린 OpenShell 구성도입니다.

그림 위쪽의 게이트웨이는 샌드박스를 만들고 끄며 정책을 관리하는 서버입니다. 샌드박스는 프로그램이 허용된 자원 안에서만 돌아가도록 격리한 환경이고, 에이전트는 각자의 샌드박스 안에서 파일과 도구를 씁니다. 아래쪽은 모델 API, 데이터, 외부 도구 서버입니다. API는 프로그램이 외부 서비스에 요청을 보내는 연결 방식입니다. 초록 화살표는 정책이 허용한 연결만 그린 것입니다.

샌드박스 바깥의 슈퍼바이저는 밖으로 나가는 요청을 정책과 대조합니다. 정책은 "이 프로그램이 이 주소에 읽기 요청을 보낼 수 있다"처럼 허용 조건을 적은 규칙입니다. 슈퍼바이저는 설정에 따라 HTTP(웹 통신), GraphQL(데이터 질의), MCP(AI와 외부 도구의 연결) 요청을 검사하며, 암호화된 통신의 내용은 그에 맞는 설정을 해야 검사합니다. 판정 결과는 보안 도구가 함께 읽는 OCSF 형식의 기록으로 남습니다.

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

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

이 보호는 OpenShell에 등록해 관리하는 자격 증명에만 적용됩니다. 실제 키를 별도 파일에 넣고 에이전트에게 읽게 하면 그 키는 보호 대상에서 빠집니다. 키를 감춰도 원문이나 고객 정보는 허용된 목적지로 나갈 수 있으므로, 목적지마다 보낼 자료도 정책으로 정합니다.

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

아래는 공식 기술 문서에 실린 정책의 일부입니다. YAML은 들여쓰기로 항목 사이의 관계를 나타내는 설정 파일 형식이고, 이 조각은 전체 샌드박스 정책 가운데 네트워크 규칙 하나입니다.

host는 접속 주소, port는 연결 번호, binaries는 요청을 보낼 수 있는 실행 파일입니다. 이 규칙은 /usr/bin/curl이라는 통신 프로그램이 GitHub API를 읽기 전용으로 쓰게 합니다.

github-api-readonly 규칙의 판정

요청	공식 예제의 판정
curl의 GET 요청(읽기)	제공
curl의 POST 요청(쓰기)	제공하지 않음

시험 중에 응답이 실패했다면 OpenShell이 막은 것인지 서비스 쪽 인증 오류인지부터 가려야 합니다. 호스트의 OpenShell 로그에 요청과 거부 이유가 남습니다. 전체 설정과 실행 순서는 공식 런타임 제어 예제에 있습니다.

새 서비스에 접속해야 하면 정책 조언 기능이 규칙 변경을 제안합니다. 제안은 기본적으로 사람이 검토하고, 에이전트는 자기 제안을 승인할 수 없습니다. 네트워크 규칙은 승인 뒤 실행 중에도 반영할 수 있지만, 파일과 프로세스 제한을 바꾸려면 샌드박스를 새로 만들어야 합니다.

정책 증명기가 확인하는 것

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

런타임이 실행 중에 검사하는 규칙과 증명기가 미리 증명하는 규칙은 범위가 다릅니다.

규칙 종류별 런타임 검사와 증명기 지원

규칙	런타임 검사실행 중 차단	정책 증명기실행 전 비교
파일 규칙	제공	제공
프로세스 규칙	제공	제공
네트워크 규칙	제공	일부
GraphQL, MCP 규칙	제공	제공하지 않음
여러 에이전트 권한을 합친 우회 경로	–	개발 중

엔비디아는 보호된 GitHub 저장소에 쓰기 권한을 얻으려는 에이전트를 최대 두 시간 동안 시험했고, 그동안 쓰기가 일어나지 않았다고 보고했습니다.

설치된 증명기로 두 정책 비교하기

openshell-prover가 설치돼 있으면 모델 API나 게이트웨이에 연결하지 않고 로컬 파일 두 개만으로 비교할 수 있습니다. 공식 정책 증명기 문서에 실린 예제 순서입니다.

1. 빈 폴더에 비교 기준이 될 boundary.yaml을 일반 텍스트로 저장합니다. 파일 이름이 boundary.yaml.txt처럼 저장되지 않았는지 봅니다.

1. 같은 폴더에 검사할 후보 candidate.yaml을 저장합니다.

1. 두 파일이 있는 폴더에서 터미널을 열고 다음 명령을 입력합니다. 결과에 result: within_boundary가 나오면 후보 권한이 기준 안에 있다는 뜻입니다.

1. 후보 파일에 /tmp 쓰기를 더하고 같은 명령을 다시 입력합니다. 기준에 없는 권한이 생겼으므로 exceeds_boundary가 나오고 명령은 종료 코드 1로 끝납니다. 이 판정이 예제에서 의도한 결과입니다.

터미널, openshell-prover

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

result: within_boundary

candidate.yaml에 read_write /tmp 추가

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

result: exceeds_boundary

기준에 없는 /tmp 쓰기가 들어가 초과로 판정됩니다

예제 안의 /usr, /etc, /tmp는 비교할 경로를 적은 글자이고, 명령은 그 폴더에 아무것도 쓰지 않습니다. 이 명령은 정책을 실행 환경에 적용하거나 승인하지도 않습니다. 결과마다 다음에 할 일은 이렇습니다.

증명기 결과별 다음 행동

결과	다음 행동
within_boundary	비교 통과 실제 차단은 로그로 따로 봄
exceeds_boundary	출력에 나온 경로와 동작 축소
unsupported, inconclusive	통과로 처리하지 않음
error	파일 형식과 오류 메시지 점검
command not found	openshell-prover 먼저 설치
파일을 찾을 수 없음	터미널의 현재 폴더와 파일 이름 점검

Sentry가 추가로 맡는 일

Sentry는 BlueField-4 같은 별도 하드웨어에서 에이전트를 감시하는 참조 구성입니다. 에이전트가 돌아가는 호스트가 침해돼도 감시가 이어지게 하는 것이 목표이고, 엔비디아는 밀리초 단위로 격리한다고 설명합니다.

Sentry가 모델 호출을 감시하는 흐름

1. 11. 에이전트 실행호스트 컴퓨터에서
   도구와 모델을 씀
2. 22. 모델 요청 통과요청과 응답이
   BlueField-4를 거침
3. 33. 호출 차단정책에 어긋나면
   다음 모델 호출을 막음
4. 44. 따로 처리할 것실행 중인 도구 제어
   이미 보낸 자료는 그대로

외부 모델이 공개하지 않는 내부 추론은 Sentry도 읽지 못합니다. 모델 호출을 막아도 이미 실행 중인 도구는 따로 제어해야 하고, 이미 보낸 자료나 끝난 외부 작업은 되돌아오지 않습니다.

Vera Rubin POD 참조 구성에는 BlueField-4가 들어 있고, 엔비디아는 소프트웨어 업데이트로 이 보호를 켜는 방식을 설명합니다. 이 업데이트는 BlueField-4가 있는 구성에 해당하며, 일반 PC에 설치하는 OpenShell 공개 저장소와는 별개입니다.

파트너 발표에서 볼 내용

엔비디아 발표에는 100곳이 넘는 회사가 참여했고, 그 가운데 다섯 곳의 연동 계획은 이렇습니다.

발표는 연동 방향을 밝힌 것이어서, 내 계정에서 지금 쓸 수 있는지는 각 서비스의 지원 버전과 제공 범위를 따로 봐야 합니다.

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

코덱스(Codex)나 클로드 코드(Claude Code) 같은 코딩 에이전트에도 운영체제 수준에서 파일 접근을 막는 샌드박스 기능이 들어간 경우가 있습니다. OpenShell이 더하는 것은 여러 에이전트의 실행 환경과 정책을 도구 바깥에서 한곳에 모아 관리하는 기능입니다. 지금 쓰는 도구의 제한과 겹치는 부분, 새로 생기는 관리 기능을 나눠 보면 도입할지 판단하기 쉽습니다.

OpenShell을 직접 돌려 보려면 아래 다섯 가지를 차례로 갖춥니다.

OpenShell을 쓰기 전에 갖출 것

1. 11. 운영체제리눅스, 애플 실리콘 맥
   윈도우 WSL 2는 실험 지원
2. 22. 컨테이너 실행 환경Docker나 Podman
3. 33. 샌드박스 생성기본은 최소 우분투
   에이전트는 들어 있지 않음
4. 44. 에이전트와 모델에이전트 설치, 모델 접속 설정
   모델 이용료는 별도
5. 55. 정책 작성파일, 프로세스, 네트워크의
   허용 범위 정하기

처음 적용할 때는 실제 업무 폴더 대신 사본 폴더를 연결하고 앞에서 정한 네 행동을 시험합니다. 원문 읽기와 결과 저장은 되고 원문 덮어쓰기와 외부 전송은 막히는지 로그와 맞춰 봅니다. 예상과 다르게 막혔다면 권한을 넓히기 전에 어떤 프로그램의 어떤 요청이 실패했는지부터 찾습니다. 회사에 적용할 때는 정책 파일과 OpenShell 버전, 시험 결과를 함께 남깁니다.

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

출시 발표는 0.1.0 기준이고 증명기 문서는 v0.1.2로 표시돼 있습니다. 설치와 업그레이드는 공식 저장소의 버전별 안내를 따릅니다. 에이전트를 처음 다룬다면 설치보다 먼저, 맡길 작업마다 읽기와 쓰기, 외부 전송을 어디까지 열지 정하는 일부터 합니다.

Sources

• NVIDIA Open Agent Safety Platform 발표
• OpenShell의 런타임 제어
• 하드웨어 감시 참조 구성
• OpenShell 공식 저장소
• 정책 증명기의 지원 범위와 예제

3줄 요약

1. OpenShell은 엔비디아가 2026년 9월 28일 공개한 실행 환경으로 AI 에이전트를 샌드박스에 격리하고 파일과 프로세스, 네트워크 접근을 정책으로 제한합니다.

2. 정책 증명기는 후보 정책의 권한이 기준 정책 안에 있는지 비교해 within_boundary나 exceeds_boundary로 답하며 GraphQL과 MCP 규칙은 지원하지 않습니다.

3. Sentry는 BlueField-4 같은 별도 하드웨어에서 에이전트를 감시하는 참조 구성이고 OpenShell은 이 하드웨어 없이 리눅스나 애플 실리콘 맥에서 돌아갑니다.