에이전트 보안은 왜 프로세스 바깥에 있어야 할까? NVIDIA OpenShell 아키텍처 해부
NVIDIA GTC Berlin 2026에서 발표된 AI 에이전트 보안 런타임 OpenShell의 구조와 동작 원리를 정리한다. 샌드박스 외부의 Supervisor, 정형 검증 기반 Policy Prover, 하드웨어 격리의 역할을 살펴본다.
NVIDIA가 공개한 GTC Berlin 2026 키노트 하이라이트 영상과 OpenShell 레퍼런스 아키텍처 기술 문서는 자율적으로 도구를 호출하고 코드를 실행하는 AI 에이전트를 어떤 경계 안에서 통제할 것인가를 다룬다. Jensen Huang CEO는 현대 AI 팩토리가 단순 모델 추론을 넘어 모델(Model), 샌드박스(Sandbox), 하네스(Harness), 지식(Knowledge), 도구(Tools)의 다섯 요소로 구성된 에이전트 전체를 실행한다며, 이를 안전하게 격리하는 오픈소스 런타임 NVIDIA OpenShell을 핵심 인프라로 제시했다.
결론부터 말하면, 자율 에이전트의 보안 정책은 프롬프트나 에이전트 프로세스 내부가 아니라 에이전트가 우회할 수 없는 프로세스 바깥(커널 및 외부 감독자 계층)에서 강제되어야 한다. 다만 이 글은 NVIDIA가 공개한 발표 영상과 아키텍처 문서를 바탕으로 구성 요소를 정리한 것이며, 실제 클러스터 환경에서 측정한 샌드박스 오버헤드나 차단 지연을 직접 벤치마킹한 결과는 아니다.
프롬프트 가드레일만으로는 에이전트를 막을 수 없는 이유
대화형 챗봇과 달리 코딩·운영 에이전트는 직접 셸 명령을 내리고 파일을 수정하며 외부 네트워크와 통신한다. 에이전트에게 주어진 목표를 달성하라고 지시하면, 모델은 때때로 의도하지 않은 우회 경로를 찾거나 허용되지 않은 시스템 호출을 시도할 수 있다.
따라서 에이전트 워크로드는 기본적으로 신뢰할 수 없는 대상(untrusted workload)으로 취급해야 한다. 에이전트가 돌아가는 동일한 프로세스 공간 안에 보안 규칙이나 API 키(credential)를 두면, 프롬프트 인젝션이나 에이전트가 스스로 생성한 코드에 의해 자격 증명이 유출되거나 정책이 무력화될 위험이 있다. OpenShell 공식 개요
NVIDIA OpenShell의 4가지 핵심 구성 요소
Apache 2.0 오픈소스 라이선스로 공개된 OpenShell은 에이전트의 실행 공간과 정책 결정·자격 증명 주입 공간을 엄격히 분리한다. 영상(01:26 부근)의 다이어그램과 기술 문서에 나타난 네 가지 핵심 컴포넌트의 역할은 다음과 같다.
| 구성 요소 | 배치 위치 | 핵심 역할 및 통제 방식 |
Sandbox | 비신뢰 영역 (에이전트 내부) | 에이전트와 하네스( Harness)가 실행되는 격리 환경. 직접적인 외부 네트워크 접근 권한이 없으며, 커널 수준에서 파일 시스템과 시스템 콜(syscall)을 제한 |
Supervisor | 신뢰 영역 (샌드박스 외부) | 샌드박스 바깥에서 에이전트의 모든 외부 요청을 검사. 실행 바이너리, 목적지, HTTP 메서드, 경로 단위로 정책을 대조하고 허용된 요청에만 자격 증명을 대신 주입 |
Policy Prover | 제어 평면 / CI 파이프라인 | 정형 검증(formal verification) 엔진을 사용해 선언적 YAML 정책이 조직의 허용 한도(ceiling)를 넘지 않는지, 권한 조합으로 인한 의도치 않은 접근 확장이 없는지 사전 검증 |
Gateway | 제어 평면 (Control Plane) | 사용자 인증, 샌드박스 수명주기 관리, 각 Supervisor로의 정책 및 자격 증명 배포 담당 |
여기서 가장 중요한 설계 원칙은 에이전트가 실제 자격 증명(API 키, 토큰)을 직접 볼 수 없다는 점이다. 에이전트가 외부 API를 호출하려 할 때, 요청은 단일 보안 채널을 통해 샌드박스 바깥의 Supervisor로 전달된다. Supervisor가 정책을 확인한 뒤 안전하다고 판단될 때만 자격 증명을 붙여 외부로 내보내고, 모든 허용(allow)과 거부(deny) 이력을 감사 로그로 남긴다.
소프트웨어 런타임과 하드웨어 격리(Sentry)의 구분
발표 내용을 볼 때는 누구나 무료로 설치해 쓸 수 있는 오픈소스 소프트웨어 계층과, NVIDIA의 데이터센터 하드웨어가 필요한 계층을 구분해서 이해해야 한다.
OpenShell(오픈소스 런타임): Apache 2.0 라이선스로 제공되는 커널 격리 기반 런타임이다. Codex, Claude Code 등 다양한 에이전트 하네스를 지원하며 일반적인 Linux(x86 및 Arm) 환경에서도 독립적으로 실행할 수 있다.
NVIDIA Sentry&BlueField-4 DPU(하드웨어 격리): 호스트 OS와도 분리된 실리콘 수준(in-silicon)의 감시 계층이다. 에이전트가 정책을 위반하거나 비정상 행동을 보일 때BlueField-4 DPU에서 밀리초(ms) 단위로 에이전트를 즉시 격리(quarantine)한다. 이는 해당 하드웨어가 장착된 인프라에서만 동작한다.
즉, 일반 개발 팀이나 온프레미스 서버에서도 OpenShell 런타임과 Policy Prover의 이점은 그대로 활용할 수 있으며, 대규모 멀티테넌트 AI 팩토리에서는 DPU 기반의 하드웨어 격리까지 결합하는 구조다. OpenShell 레퍼런스 아키텍처 발표문
자율 에이전트 실행 환경을 설계할 때 확인할 점
사내 인프라나 로컬 머신에서 파일 수정·외부 API 호출 권한을 가진 에이전트를 운영할 때는 다음 기준을 먼저 점검할 만하다.
- 기본 거부(Deny-by-default) 네트워크 정책: 에이전트 샌드박스에 모든 외부 인터넷 접근을 열어두지 않고, 선언된 호스트와 HTTP 메서드(예:
GET만 허용하고POST/DELETE는 차단)만 통과시키는지 확인한다.
- 자격 증명(Credential)의 샌드박스 외부 분리:
.env파일이나 환경 변수로 API 키를 에이전트 컨테이너 내부에 직접 주입하지 않고, 외부 프록시나Supervisor계층에서 요청 시점에 주입하는 구조인지 확인한다.
- 권한 변경에 대한 정적·정형 검증: 에이전트에게 새로운 도구나 네트워크 경로를 열어줄 때, 기존 권한과 결합해 우회 경로가 생기지 않는지 CI 단계에서 정책 검증(
Policy Prover등)을 거치는지 점검한다.
결국 에이전트의 능력이 강력해질수록 “모델이 얼마나 똑똑한가”만큼이나 “모델이 실수하거나 오염되었을 때 시스템이 어디서 물리적으로 제동을 거는가”가 엔터프라이즈 도입의 핵심 기준이 된다.
참고 자료
발표 내용과 아키텍처 구성은 October 29, 2026 공개 자료 확인 기준이다.