엔비디아 Open Agent Safety Platform 공개: AI 에이전트의 실행 권한을 밖에서 통제합니다

AI 뉴스 · 에이전트 보안

AI 에이전트의 실행 권한을 모델 밖에서 통제합니다

NVIDIA는 9월 28일 Open Agent Safety Platform을 공개했습니다. OpenShell의 실행 경계와 BlueField-4 기반 Sentry의 독립 감시를 결합하는 참조 설계입니다. 모든 공격의 차단을 보장한다는 뜻은 아닙니다.

OpenShell 실행 경계오픈소스 런타임의 폭넓은 이용 가능 상태를 발표했습니다. 접근 정책을 실행 전에 검증하고 실행 중에도 집행합니다.

Sentry 독립 감시BlueField-4 DPU에서 동작하는 선택적 하드웨어 감시 계층입니다. 참조 설계와 전 고객 상용 배포는 구분합니다.

사람의 권한 승인Slack 통합은 활동·감사 이벤트 확인과 추가 권한 요청의 승인·거부를 지원한다고 공식 발표에서 설명했습니다.

이 글에서 다룰 내용

OpenShell의 접근 정책, Sentry의 독립 감시, 공식 다섯 원칙, Slack 권한 승인 사례, 도입 전 점검

AI에게 “중요한 파일은 건드리지 마세요”라고 말하면 충분할까요? 문장을 이해하는 것과 실제로 파일을 수정할 수 없도록 막는 것은 다른 문제입니다.

에이전트가 문서를 읽고 코드를 실행하고 외부 서비스를 호출하기 시작하면 답변의 정확성만으로 안전을 판단하기 어렵습니다. 어떤 자원에 접근하고 어디까지 행동할 수 있는지도 관리해야 합니다.

엔비디아는 2026년 9월 28일 Open Agent Safety Platform을 공개했습니다. 오픈 소프트웨어 플랫폼과 참조 시스템 설계로, AI 에이전트 보안의 통제 지점을 모델의 약속이 아닌 외부 실행 환경에 두는 접근입니다.

OpenShell은 CPU에서 실행되는 에이전트에 실행 경계를 두는 오픈소스 런타임입니다. 이번에 처음 등장한 기술은 아니며 엔비디아는 이번 발표에서 폭넓게 이용 가능한 상태인 ‘broadly available’이라고 명시했습니다.

핵심은 접근 정책을 실행 전에 검증하고 실행 중에도 집행하는 것입니다. 파일·네트워크·도구·프로세스·자격증명에 접근할 때, 허용된 실행 권한 안에서만 움직이도록 경계를 두는 셈입니다.

공식 기술 글은 OpenShell 0.1.0의 샌드박스 실행, 서비스 접근 통제, 자격증명 관리, 형식적 정책 분석을 설명합니다. 쉽게 말하면 작업 공간을 분리하고 연결할 서비스와 사용할 권한을 정하며 정책이 정해진 경계를 지키는지 논리적으로 살펴보는 구성입니다.

엔비디아는 Vera CPU에 최적화했으며 Arm·Intel 등 타사 컴퓨팅 플랫폼에도 확장할 수 있다고 설명합니다. 모든 장비에서 별도 준비 없이 동일하게 작동한다는 뜻은 아닙니다.

OpenShell이 소프트웨어 차원의 실행 경계를 담당한다면, Sentry는 여기에 더하는 선택적 하드웨어 보안 계층입니다. 블루필드, 즉 BlueField-4 DPU에서 독립적인 감시 장치인 out-of-band watchdog으로 동작합니다.

중요한 차이는 감시 위치입니다. 모델이나 에이전트가 접근할 수 없는 별도 신뢰 영역에서 감시와 집행을 수행하도록 설계했습니다.

DOCA는 요청·응답 검사와 신원·위임 권한 확인, 정책 집행을 지원합니다. 통신이 발생했는지만 보는 것이 아니라 누구의 권한으로 어떤 요청이 이뤄지는지도 통제에 연결하는 구조입니다.

엔비디아는 밀리초 단위 격리가 가능하다고 설명합니다. 이는 회사의 설명이며 독립 실험으로 모든 환경에서 검증됐거나 모든 공격을 차단한다는 의미는 아닙니다.

OpenShell의 일반 제공과 Sentry 참조 설계도 구분해야 합니다. 이번 발표만으로 Sentry가 모든 고객에게 상용 배포됐거나 가격과 도입 일정이 확정됐다고 볼 수는 없습니다.

공식 기술 글은 다섯 가지 원칙을 제시합니다. 검증 가능한 정책, 에이전트 밖의 집행, 모델 통신 경로 통제, 사고 과정 가시성에 맞춘 권한, 연구소·기업·하드웨어 제공자의 공동 책임입니다.

안전 규칙은 확인 가능한 형태여야 하고 그 규칙을 지키게 하는 장치는 에이전트 외부에 있어야 합니다. 모델과 통신하는 경로 역시 통제 대상에 포함됩니다.

여기에 에이전트의 판단 과정을 얼마나 살펴볼 수 있는지에 맞춰 권한을 부여하고 안전 책임을 한쪽에만 맡기지 않는다는 관점이 더해집니다. 새로운 국제표준의 확정이 아니라 플랫폼을 구성하는 설계 원칙으로 읽는 것이 정확합니다.

실무에서는 관리자가 통제 상황을 확인할 수 있어야 합니다. 공식 발표에서 Salesforce와 엔비디아는 Slack에서 OpenShell 에이전트 활동과 감사 이벤트를 보고 추가 권한 요청을 승인하거나 거부하는 통합을 설명했습니다.

핵심은 익숙한 업무 화면에서 활동과 권한 변경을 함께 다룬다는 점입니다. 처음부터 넓은 권한을 주는 대신, 필요한 추가 권한을 사람이 판단하는 흐름을 보여줍니다.

다만 이를 모든 기업이 즉시 적용할 수 있는 완성형 서비스로 확대해서는 안 됩니다. 발표에 없는 자동화율이나 비용 절감 수치도 단정할 수 없습니다.

다음은 발표 사실과 별개인 실무 권고입니다. 실제 업무에 연결하기 전 테스트 환경에서 읽기와 쓰기 권한을 구분하고 외부 통신 범위를 제한하며 추가 권한 승인 절차와 감사 로그를 점검하는 편이 좋습니다.

특히 허용된 작업이 성공하는지만 보지 말고 금지한 파일 수정이나 외부 접속이 실제로 거부되는지도 확인해야 합니다. “안전하게 일하라”는 프롬프트와 실행 권한 제한은 서로 대체할 수 없습니다.

이번 발표는 에이전트가 넘지 말아야 할 선을 외부에서 강제하는 구조에 초점을 맞췄습니다.

한 줄 요약: Open Agent Safety Platform은 AI를 믿고 맡기는 대신, 허용된 실행 권한 안에서 일하도록 외부 통제 장치를 두는 접근입니다.

공식 발표와 기술 글의 발행일은 2026년 9월 28일입니다. 기능·제공 범위와 성능 설명은 NVIDIA 발표 기준이며, 도입 전 점검 제안은 일반적인 실무 권고입니다.