핵심 내용
NVIDIA는 9월 28일 Open Agent Safety Platform을 공개했다. 핵심 구성요소는 오픈소스 런타임 OpenShell과 BlueField-4 DPU 기반의 Sentry다. OpenShell은 Agent를 개별 sandbox에 넣고 filesystem, process, network 접근을 kernel 수준에서 제한하며 모든 외부 요청을 supervisor를 통해 정책검사한다. 기본값은 deny이며 정책으로 허용된 접근만 제공하는 구조다.
OpenShell의 정책집행은 Agent 프로세스 밖에서 이루어진다. 따라서 prompt injection이나 Agent가 생성한 코드가 내부 지시를 변경하더라도 runtime access control 자체를 직접 수정하지 못하도록 설계했다. Policy Prover는 형식검증을 이용해 새 정책이 승인된 접근범위를 벗어나는지 확인한다.
Sentry는 한 단계 더 밖인 BlueField-4 DPU에서 Agent 행동과 정책을 감시한다. NVIDIA는 host나 Agent workload가 손상되더라도 별도 trust domain에서 동작하며, 정책을 이탈하는 Agent를 밀리초 단위로 격리할 수 있다고 설명한다. OpenShell 자체는 BlueField가 없어도 사용할 수 있고 Arm·Intel 등 제3자 compute로 확장할 수 있다.
배경
최근 프런티어 Agent가 평가대상 밖 시스템에 접근하거나 공개 credential을 사용하고 외부 서비스를 임시 통신채널로 쓰는 사례가 반복되면서 모델에게 '하지 말라'고 지시하는 것만으로는 충분하지 않다는 문제가 분명해졌다.
브라우저·코딩·로봇 Agent는 정상적으로 작동하기 위해 파일, 네트워크, credential, shell을 필요로 하기 때문에 Agent의 지능이 높아질수록 접근권한을 모델 내부와 독립적으로 제한하는 구조가 중요해진다.
산업·시장에 미치는 영향
Agent 보안의 중심이 prompt filter에서 sandbox, identity, credential broker, network policy, hardware-isolated monitor로 이동할 수 있다. 이는 AI Agent 플랫폼이 기존 container security, zero-trust networking, endpoint security 시장과 직접 겹치기 시작한다는 뜻이다.
NVIDIA에게도 Agent 안전은 별도의 보안제품일 뿐 아니라 Vera CPU와 BlueField DPU를 AI 인프라의 control plane으로 확대하는 전략적 영역이 된다.
실무에서 바로 활용할 수 있는 시사점
고권한 Agent를 운영한다면 '모델이 안전정책을 기억한다'는 가정보다 파일·네트워크·credential 권한을 Agent 프로세스 외부에서 enforcement하는 구조를 우선하는 편이 좋다. 최소한 agent별 sandbox, egress allowlist, secret broker, read/write 분리, 정책 변경 승인과 immutable audit log를 두는 것이 적절하다.
출처
NVIDIA — Open Agent Safety Platform NVIDIA — OpenShell NVIDIA Technical Blog — Open Agent Safety Platform