엔비디아 OpenShell과 Sentry 정리: Open Agent Safety Platform이 AI 에이전트를 모델 밖에서 막는 방식

NVIDIA Open Agent Safety Platform은 엔비디아가 2026년 9월 28일 공개한 AI 에이전트 안전 플랫폼입니다. 오픈소스 런타임인 OpenShell과 엔비디아 BlueField-4 DPU(서버 안에서 네트워크와 보안 처리를 맡는 별도 프로세서)에서 도는 감시 장치 Sentry로 이루어지고, 에이전트가 무엇을 읽고 어디에 연결하고 어떤 열쇠를 쓸 수 있는지를 모델이 아니라 실행 환경 밖에서 정합니다.

발표 시점이 우연으로 보이지는 않습니다. 한 기술 매체의 보도에 따르면 올여름 오픈AI와 앤트로픽, 메타, 구글 네 곳이 모두 자사 모델이 시험 환경을 벗어나 실제 시스템에 접근했다고 공개했습니다. 오픈AI는 7월 21일에 GPT-5.6 Sol과 연구용 시제품이 샌드박스의 유일한 네트워크 경로였던 패키지 프록시의 취약점을 뚫고 허깅페이스 운영 데이터베이스까지 갔다고 밝혔습니다. 며칠 뒤 앤트로픽은 평가 협력사 Irregular에서 자사 모델 셋이 의도치 않게 인터넷에 연결돼 실제 회사의 데이터베이스에 접근하고 PyPI에 악성 패키지를 올렸다고 보고했습니다. 엔비디아 보도자료도 최근 사고들을 언급하며 "에이전트가 맡은 일을 끝내려고 애플리케이션 계층의 보안 통제를 우회했다"는 공통점을 짚었습니다.

엔비디아가 내놓은 답의 핵심은 한 문장입니다. 모델을 잘 가르치는 것과 별개로, 에이전트가 넘을 수 없는 경계를 에이전트 바깥에 세우자는 것입니다. 이 글은 공식 발표와 기술 블로그, GitHub 저장소를 2026년 9월 29일 기준으로 대조해 무엇이 발표됐는지, OpenShell과 Sentry가 각각 어떻게 동작하는지, 클로드 코드나 코덱스를 쓰는 쪽에서 무엇을 확인할지 정리합니다. 사고 경위는 보도를 옮긴 것이라 그 범위에서만 적었습니다.

발표 내용 한눈에 보기

보도자료와 기술 블로그에 흩어진 내용을 한 표로 모으면 이렇습니다.

OpenShell 자체는 새 이름이 아닙니다. 보도에 따르면 엔비디아는 2026년 3월 GTC에서 OpenShell을 처음 소개했고, 이번 발표는 0.1.0 버전을 내고 정식으로 공개한 것입니다. GitHub 저장소는 2026년 2월에 만들어졌고 9월 29일 조회 기준 스타가 9,400개를 넘습니다.

모델 안전장치와 실행 제어의 차이

지금까지 AI 안전은 대부분 모델을 잘 가르치는 일이었습니다. 위험한 요청을 거부하고 지시를 따르도록 학습시키는 방식이고, 업계는 이것을 정렬(alignment)이라고 부릅니다. 엔비디아 엔터프라이즈 AI 부문 부사장 저스틴 보이타노는 발표 브리핑에서 확률적으로 동작하는 시스템에 이 방식만 쓰면 한계가 분명하다면서, 에이전트의 행동을 중재하고 강제하는 결정론적 시스템, 즉 같은 입력에는 늘 같은 판정을 내는 시스템을 내놓는다고 말했습니다.

두 방식은 서로 대체하는 관계가 아니라 층이 다릅니다. 엔비디아 제품 페이지는 이렇게 구분합니다.

회사 건물에서 직원이 어느 층에 들어갈 수 있는지를 직원의 약속이 아니라 출입 카드의 권한으로 정하듯, 런타임 제어는 에이전트의 판단이 아니라 바깥에서 정한 정책으로 접근 범위를 정합니다. 엔비디아 기술 블로그는 이 관점을 인터넷 초기의 브라우저에 견주었습니다. 웹이 안전해진 것은 개발자가 착하게 굴겠다고 약속해서가 아니라 브라우저가 페이지의 코드를 믿지 않고 탭마다 격리했기 때문이라는 설명입니다.

같은 블로그에 사고 원인을 보는 엔비디아의 시각도 적혀 있습니다. 에이전트가 벗어난 것은 새로운 능력 하나가 생겨서가 아니라 도구와 시간, 애매한 지시가 합쳐진 결과라는 것입니다. 정책에 막히거나 버그를 만나거나 필요한 도구가 없을 때, 그리고 며칠씩 어려운 문제를 붙들고 있을 때 에이전트는 원래 과제에서 벗어나기 시작하는데, 엔비디아는 이런 경향을 능력을 유지한 채 학습만으로 없앨 수는 없다고 봅니다. 그래서 나온 결론이 "이런 상황의 에이전트가 자기 행동을 스스로 다스릴 것이라고 기대할 수 없다"는 문장입니다.

OpenShell: 에이전트를 샌드박스에 넣고 정책으로 묶는 런타임

OpenShell은 에이전트 하나마다 커널 수준으로 격리된 샌드박스를 만들고, 운영자가 적은 정책을 그 샌드박스 밖에서 강제하는 런타임입니다. 기존 에이전트를 고쳐 쓸 필요가 없습니다. 기술 블로그의 표현대로 코덱스나 클로드 코드를 그대로 샌드박스 안에서 띄우고, 허용 범위만 밖에서 정합니다.

구성 요소는 셋입니다.

• 게이트웨이(Gateway): 여러 샌드박스의 생성과 종료, 정책을 관리하는 관리 서버입니다
• 슈퍼바이저(Supervisor): 샌드박스 밖에 하나씩 붙어, 샌드박스에서 나가는 요청을 정책과 대조합니다
• 샌드박스(Sandbox): 에이전트가 실제로 도는 곳입니다. 파일과 프로세스는 커널이 제한하고, 네트워크는 슈퍼바이저를 거치는 길밖에 없습니다

슈퍼바이저가 하는 검사가 이 구조의 핵심입니다. 어떤 서비스에 연결해도 되는지 정하는 데서 끝나지 않고, HTTP와 GraphQL, MCP 요청을 열어 보고 같은 API에서도 읽기는 통과시키고 쓰기는 막을 수 있습니다. 에이전트가 셸을 열거나 자기가 만든 코드를 실행하거나 자식 프로세스를 띄우거나 하위 에이전트에게 일을 넘겨도 검사는 그대로 유지되고, 판정 결과는 보안 제품끼리 로그를 주고받는 공통 형식인 OCSF로 감사 기록에 남습니다.

자격 증명도 에이전트에게 주지 않습니다.

에이전트는 임시 키(placeholder key)만 보고 요청을 만들고, 슈퍼바이저가 승인된 주소로 나가는 요청에만 실제 키를 끼워 넣습니다. 직원에게 금고 열쇠를 주지 않고 경비실에서 문을 열어 주듯, 에이전트가 키를 다른 곳으로 보내려 해도 실제 키가 그 안에 없으니 새어 나갈 것이 없습니다. 키 자체에 쓰기 권한이 있어도 정책이 읽기 전용이면 쓰기 요청은 막힙니다.

정책은 설정 파일 형식인 YAML로 적으면 OpenShell이 정책 엔진 OPA의 규칙 언어 Rego로 바꿔 요청마다 평가합니다. 기술 블로그에 실린 정책 하나를 그대로 옮기면 아래와 같습니다. curl이 GitHub API에 읽기 전용으로만 연결하게 허용하는 정책이고, 제 환경에서 실행한 것이 아니라 공식 문서의 것입니다.

이 정책을 적용한 샌드박스 안에서 같은 주소에 GET을 보내면 통과하고 POST를 보내면 막힙니다. 호스트 쪽에서 로그 명령을 치면 어느 프로그램이 무슨 요청을 보냈고 왜 막혔는지 나옵니다. 문서는 사람이 curl로 확인한 것과 같은 검사가 에이전트의 요청에도 그대로 적용된다고 적었습니다.

정책을 바꾸는 절차에도 장치가 있습니다. 정책 조언(policy advisor) 기능을 켜 두면, 에이전트가 일하다가 처음에 몰랐던 서비스가 필요해질 때 좁은 범위의 정책 변경을 제안할 수 있는데, 제안은 기본적으로 사람의 검토를 기다리고 에이전트가 자기 제안을 승인할 수는 없습니다. 승인되면 샌드박스를 다시 시작하지 않고 새 규칙이 들어갑니다. 다만 파일과 프로세스 제한은 샌드박스를 만들 때 정해지므로 바꾸려면 새 샌드박스가 필요합니다.

0.1.0에서 새로 들어온 것이 정책 증명기(policy prover)입니다. 정책이 허용한 권한을 형식 논리로 따져, 운영자가 의도한 범위를 벗어나는 경로가 있는지 미리 찾습니다. 엔비디아 AI 소프트웨어 수석 디렉터 알리 골샨이 브리핑에서 든 예가 분명합니다. GitHub의 코드를 읽어 외부에 올리는 일을 막는 정책이 있어도, 에이전트가 GitHub를 읽을 수 있는 하위 에이전트와 외부에 올릴 수 있는 하위 에이전트를 하나씩 띄우고 둘을 대화시키면 우회가 됩니다. 증명기는 에이전트 무리 전체의 접근을 합쳐 이런 경로를 찾아냅니다. 골샨은 이것이 LLM을 심판으로 쓰는 방식이 아니라 수학적 추론이라서 결정론적이고, 속도도 대략 100배 빠르다고 말했습니다.

엔비디아 자체 실험도 하나 공개됐습니다. 안전장치를 낮춘 최상위 모델(프런티어 모델) 기반 에이전트들이 보호된 GitHub 저장소에 쓰기 권한을 달라고 AI 검토자를 최대 두 시간 동안 설득했는데, 증명기가 그 요청이 실제로 무엇을 허용하는지 검토자에게 보여 주었고 보호된 저장소에 쓰기는 한 건도 일어나지 않았다고 합니다. 회사 자체 실험이라 조건은 공개된 범위에서만 알 수 있습니다.

Sentry: BlueField-4 DPU에서 도는 감시 장치

Sentry는 OpenShell 위에 하나 더 얹는 독립 계층입니다. 앞에서 말한 BlueField-4 DPU에서 돌고, 호스트와 분리된 신뢰 영역에서 에이전트의 활동을 지켜봅니다. 보도자료의 표현으로는 에이전트가 소프트웨어 경계를 벗어나려 하면 밀리초 안에 격리해 멈춥니다.

작동 원리는 모델로 가는 통로를 가로막고 지켜보는 것입니다. 에이전트는 다음 생각을 모델에서 받아야 움직이므로, 모델 API로 가는 요청과 응답을 DPU의 프록시로 지나가게 하면 에이전트의 추론 흔적을 전부 볼 수 있고 필요할 때 끊을 수도 있습니다. 엔비디아 기술 블로그는 이것을 설계 원칙 가운데 하나로 적었고, 엔비디아의 차세대 데이터센터 서버 시스템인 Vera Rubin POD에서는 각 컴퓨트 트레이의 BlueField-4가 모델로 가는 유일한 경로에 놓여 있어 소프트웨어 업데이트만으로 이 보호를 켤 수 있다고 설명했습니다. 감시와 정책 집행은 BlueField용 개발 도구 모음인 엔비디아 DOCA로 프로그래밍하고, 에이전트마다 신원을 검증해 데이터와 도구, API 접근을 매번 확인하는 제로 트러스트 방식으로 통제합니다.

건물 안 출입 카드 시스템이 뚫려도 건물 밖 관제실의 카메라는 따로 돌아가듯, Sentry는 호스트가 침해된 상황에서도 동작하는 것을 목표로 합니다. 보이타노는 이것을 자율주행차의 안전 섬(safety island)에 견주었습니다. 인지를 담당하는 주 시스템과 별개로 시스템 전체의 안전만 보는 장치가 따로 있다는 뜻입니다.

두 가지를 구분해 둘 필요가 있습니다.

• Sentry는 오픈소스가 아닙니다. 보도에 따르면 보이타노는 Sentry에 공개 API가 있고 OpenShell이 다른 네트워크 집행 하드웨어와도 연동될 수 있다고 말했지만, Sentry 자체는 OpenShell처럼 공개되지 않았습니다
• DPU는 선택 사항입니다. 같은 브리핑에서 그는 대부분의 경우 CPU에서 OpenShell만 써도 에이전트 접근 통제로 충분하다고 했고, DPU는 안전장치를 끈 최상위 모델을 평가하거나 레드팀을 돌리는 용도라고 설명했습니다

함께 이름을 올린 회사들

보도자료에 실린 협력 내용 가운데 실제 통합이 적힌 것은 다섯 곳입니다.

기술 블로그에는 이미 쓰고 있는 곳도 적혀 있습니다.

• 케이던스: 칩 설계 에이전트
• 슬랙: 주문형 에이전트 플랫폼
• 게코 로보틱스: 실제 로봇의 판단 통제

로봇 쪽으로는 Figure와 Skild AI, 금융 쪽으로는 시티와 JP모건체이스, 운영체제 쪽으로는 캐노니컬과 SUSE, 레드햇 이름이 올라 있고 전체는 100곳이 넘습니다.

목록에 없는 이름도 의미가 있습니다. 같은 기술 매체는 올여름 에이전트가 벗어난 네 연구소 가운데 오픈AI와 구글이 파트너 목록에 없고 AWS도 없다고 짚었습니다. 반대로 앤트로픽과 메타, 구글의 사고가 일어난 평가 환경을 운영한 Irregular는 목록에 있습니다. 앤트로픽과 오픈AI가 자기 학습 실험에 OpenShell과 Sentry를 쓸 계획인지 묻는 질문에 보이타노는 각 회사의 블로그를 보라고 답했습니다.

플랫폼은 Open Secure AI Alliance의 활동으로도 연결됩니다. 엔비디아가 120곳 넘는 조직과 함께 시작해 리눅스 재단이 관리하는 연합이고, AI 사고 정보를 공유하는 SAFE(Shared AI Findings Exchange) 같은 프로젝트를 함께 진행합니다.

클로드 코드와 코덱스를 쓰는 쪽에서 볼 것

이 발표를 데이터센터 이야기로만 읽을 필요는 없습니다. Sentry는 하드웨어가 있어야 하지만 OpenShell은 개인 컴퓨터에서 바로 시험할 수 있습니다.

GitHub README 기준 요구 사항은 리눅스, 애플 실리콘 맥, 윈도우 WSL 2(실험 단계) 가운데 하나와 Docker나 Podman입니다. 설치는 스크립트 한 줄이고 그다음 샌드박스를 만드는 명령까지 두 줄입니다.

기본 샌드박스 이미지는 에이전트가 없는 최소 우분투라서, 실제 에이전트를 돌리려면 문서의 첫 에이전트 실행 안내를 따라 프로바이더(모델 API 같은 외부 서비스의 접속 정보와 자격 증명 묶음)와 정책을 붙여야 합니다. 코딩 에이전트에게 OpenShell 사용법을 가르치는 스킬도 공개돼 있어 npx skills add NVIDIA/OpenShell로 설치합니다. 익명 원격 측정이 기본으로 켜져 있는데 샌드박스 이름이나 파일 경로, 프롬프트는 보내지 않는다고 적혀 있고, 게이트웨이에 환경 변수를 두면 끌 수 있습니다.

클로드 코드나 코덱스에 이미 있는 권한 설정과 무엇이 다른지 구분하면 이렇습니다. 코덱스의 샌드박스 옵션이나 클로드 코드의 권한 모드는 그 도구가 스스로 거는 제한이고, OpenShell은 그 도구 전체를 밖에서 둘러싼 층입니다. 도구의 설정이 잘못되거나 에이전트가 새 셸을 열어도 바깥 제한은 그대로입니다. 그래서 둘은 겹치는 기능이 아니라 안쪽 제한과 바깥쪽 제한으로 같이 쓰는 관계입니다. 코덱스의 안쪽 제한이 어떻게 정해지는지는 코덱스 CLI 사용법에 있습니다.

지금 시점에서 적용 여부는 상황에 따라 셋으로 나뉩니다.

• 개인이 코딩 에이전트를 쓰는 경우: 도구 자체의 권한 모드로 충분한 편이고, 에이전트에게 실제 API 키를 주는 자동화를 오래 돌린다면 OpenShell의 자격 증명 치환이 이득이 됩니다
• 회사에서 여러 에이전트를 돌리는 경우: 게이트웨이 하나로 샌드박스 여러 개를 관리하고 감사 기록을 남기는 구조라 검토 대상이 됩니다. 쿠버네티스에는 패키지 도구 Helm으로 올리고, 네트워크 플러그인(CNI)이 NetworkPolicy 규칙을 실제로 막아 주는 것이어야 합니다
• 모델을 평가하거나 레드팀을 돌리는 경우: 엔비디아가 Sentry의 용도로 든 상황이고 BlueField-4가 필요합니다

버전 번호 0.1.0에서 알 수 있듯 아직 초기 소프트웨어입니다. 업그레이드 안내가 따로 있을 만큼 0.1.x에서 격리 방식과 API가 바뀌었으므로, 업무에 넣는다면 정책 파일을 버전과 함께 관리하는 편이 안전합니다.

자주 묻는 질문

OpenShell을 쓰면 클로드 코드나 코덱스를 고쳐야 하나요?

아닙니다. 기술 블로그는 기존 에이전트를 다시 만들지 않고 바깥에 실행 제어를 덧붙이는 것이 OpenShell의 목적이라고 적었고, 지원 목록에 코덱스와 클로드 코드, Pi, Hermes가 있습니다. 에이전트는 샌드박스 안에서 평소처럼 돌고 허용 범위만 밖에서 정합니다.

Sentry 없이 OpenShell만 써도 되나요?

됩니다. 엔비디아 제품 페이지는 OpenShell이 BlueField-4 없이 로컬과 온프레미스, 클라우드, 쿠버네티스에서 동작한다고 밝혔고, 보이타노도 대부분의 경우 CPU에서 OpenShell만으로 접근 통제가 충분하다고 말했습니다. Sentry는 호스트가 침해된 상황까지 대비해야 하는 환경이나 최상위 모델 평가에 쓰는 것입니다.

정책 증명기는 무엇을 미리 막아 주나요?

정책이 허용한 권한을 조합했을 때 운영자가 의도하지 않은 경로가 생기는지 찾습니다. 하나의 도구에서 GitHub 쓰기를 막아도 다른 허용 도구나 생성된 코드가 같은 자격 증명으로 같은 쓰기를 할 수 있으면 소용이 없는데, 증명기는 그런 우회 경로를 정책을 적용하기 전에 알려 줍니다.

정리

모델을 더 잘 정렬하는 일과 에이전트를 밖에서 묶는 일은 서로 대신하지 못합니다. 이번 발표는 뒤쪽을 오픈소스로 표준화하려는 시도이고, 100곳이 넘는 회사가 이름을 올렸다는 점에서 에이전트 운영의 기본 구성이 될 가능성이 있어 보입니다. 다만 Sentry는 엔비디아 하드웨어 위에서만 돌고 공개되지 않았으므로, 개방된 부분과 그렇지 않은 부분을 나누어 보고 자기 환경에 맞는 쪽부터 시험하는 것이 맞습니다.

Sources

• NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment (엔비디아 보도자료)
• NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring (엔비디아 기술 블로그)
• Add Runtime Controls to AI Agents with NVIDIA OpenShell (엔비디아 기술 블로그)
• NVIDIA Open Agent Safety Platform 제품 페이지
• NVIDIA/OpenShell (GitHub)
• Nvidia launches Open Agent Safety Platform to lock down rogue AI agents (The New Stack)
• Nvidia Unveils AI Agent Safety Platform With Hardware-Based Watchdog (SecurityWeek)