NVIDIA Open Agent Safety Platform 출시, AI 가드레일을 모델 외부로 이전

NVIDIA Open Agent Safety Platform이 9월 28일 출시되며, 현재 AI 업계의 안전성 모델에 분명한 문제를 제기했다. 에이전트가 프롬프트를 따를 것이라고 신뢰하는 대신, NVIDIA는 에이전트 외부의 소프트웨어와 하드웨어가 모든 행동을 통제하도록 하려 한다.

이 플랫폼은 격리된 에이전트 실행을 위한 오픈소스 런타임 OpenShell과 NVIDIA BlueField-4 데이터 처리 장치를 기반으로 구축된 독립 모니터링 설계 Sentry를 결합한다. NVIDIA는 Sentry가 에이전트가 허가된 경계를 넘을 경우 수 밀리초 안에 격리할 수 있다고 밝혔다.

이 차이는 이것이 또 하나의 에이전트 프레임워크에 그치지 않는 이유다. NVIDIA는 에이전트가 자격 증명, 네트워크 접근 권한, 실제 시스템을 변경할 권한을 받는 순간 모델 정렬과 애플리케이션 수준 지침만으로 충분한 통제를 제공할 수 없다고 주장한다. NVIDIA가 제안하는 대안은 기존 인프라 보안과 닮아 있다. 기본적으로 접근을 거부하고, 제한적인 권한만 부여하며, 모든 결정을 기록하고, 워크로드의 통제 범위를 벗어난 곳에서 정책을 집행하는 방식이다.

당면한 질문은 OpenShell이 에이전트를 샌드박스에 둘 수 있느냐가 아니다. 기존 운영체제와 클라우드 플랫폼도 이미 격리 도구를 제공한다. 더 어려운 질문은 NVIDIA가 기업이 에이전트에 기대하는 업무를 막지 않으면서 에이전트 격리를 실용적인 인프라 계층으로 만들 수 있느냐다.

NVIDIA Open Agent Safety Platform, 두 계층의 제어로 출시

NVIDIA는 에이전트 보안을 소프트웨어 경계와 독립적인 하드웨어 백스톱으로 나눴다.

OpenShell은 첫 번째 계층을 제공한다. 각 에이전트를 격리된 환경에서 실행하고 파일, 프로세스, 네트워크 목적지, 자격 증명, 모델 엔드포인트를 포괄하는 정책을 적용한다. 에이전트는 작업에 필요한 접근 권한을 받을 수 있지만, 호스트 시스템에 대한 무제한 통제권을 얻지는 않는다.

NVIDIA는 OpenShell을 에이전트 프레임워크가 아닌 런타임으로 설명한다. 이는 Claude Code, Codex, GitHub Copilot CLI, OpenCode 및 맞춤형 에이전트 시스템과 같은 도구의 하위 계층에 위치한다. 개발자는 보안 경계를 사용하기 위해 에이전트의 추론 모델이나 애플리케이션 하니스를 교체할 필요가 없다.

이 런타임은 기본 거부 방식을 사용한다. 샌드박스가 시작될 때 에이전트에는 일반적인 네트워크 접근, 상승된 권한 또는 광범위한 파일시스템 권한이 부여되지 않는다. 이후 관리자는 기계가 읽을 수 있는 정책을 통해 승인된 리소스를 정의한다.

예를 들어 송장 처리 에이전트는 특정 폴더를 읽고 승인된 회계 API에 연결할 권한을 받을 수 있다. 하지만 송장을 삭제하거나, 관련 없는 디렉터리를 조사하거나, 승인되지 않은 웹사이트로 데이터를 전송하는 일은 계속할 수 없도록 제한될 수 있다.

OpenShell은 자격 증명의 사용과 보유도 분리한다. 샌드박스 외부에서 실행되는 감독자는 정책이 특정 요청을 승인할 때만 자격 증명을 제공할 수 있다. 에이전트는 기본 비밀 정보에 직접 접근할 필요가 없다.

런타임은 요청 바이너리, 목적지, 메서드, 경로 등의 세부 정보를 사용해 네트워크 활동을 평가한다. 에이전트가 계속 실행되는 동안에도 정책 업데이트를 적용할 수 있다. 허용되거나 거부된 각 작업은 감사 추적의 일부가 된다.

NVIDIA의 OpenShell architecture에는 정책 증명기도 포함된다. 이 구성 요소는 관리자가 정책 변경을 적용하기 전에, 지정된 규칙이 정의된 속성을 충족하는지 확인하는 수학적 방법인 형식 검증을 사용한다.

이 증명기는 미묘한 문제를 해결한다. 보안 팀은 에이전트가 하나의 새로운 서비스에 접근해야 한다는 점은 이해할 수 있지만, 정책 변경으로 생성되는 모든 기능을 쉽게 파악하기는 어렵다. 제한적으로 보이는 규칙도 예상치 못한 네트워크 경로를 열거나 자격 증명이 접근 가능한 위치에 놓이게 할 수 있다.

Sentry는 두 번째 계층을 제공한다. 이는 메인 CPU 외부에서 인프라 및 보안 워크로드를 처리하는 특수 프로세서인 BlueField-4 DPU의 격리된 신뢰 도메인에서 실행된다.

NVIDIA의 platform announcement에 따르면, Sentry는 에이전트 활동을 독립적으로 모니터링하고 의심스러운 행동을 수 밀리초 안에 중단할 수 있다. NVIDIA는 이 시스템이 DOCA 소프트웨어를 사용해 요청을 검사하고, ID를 검증하며, 데이터 접근을 보호하고, 검증 가능한 텔레메트리를 생성한다고 밝혔다.

이 분리는 에이전트가 단순히 Sentry에 프롬프트를 주입하거나, 지침을 다시 작성하거나, 작업 환경 내부에서 이를 비활성화할 수 없다는 점에서 중요하다. 런타임이 침해된 경우에도 메인 시스템 밖의 또 다른 집행 지점에 맞닥뜨리게 된다.

OpenShell은 폭넓게 제공되는 반면, Sentry는 BlueField-4와 연계된 레퍼런스 시스템 설계의 일부로 제시된다. NVIDIA에 따르면 OpenShell 소프트웨어는 Arm과 Intel의 프로세서로도 확장할 수 있다.

그 결과는 단일 보안 제품이 아닌 계층형 제안이다. OpenShell은 정상 운영 중 에이전트가 할 수 있는 일을 제한한다. Sentry는 그 경계 밖에서 감시하고, 활동이 이를 벗어나는 것으로 보일 때 대응한다.

에이전트 보안이 프롬프트를 넘어서는 이유

행동할 수 있는 에이전트는 더 나은 지침만으로 해결할 수 없는 보안 문제를 만든다.

기존 챗봇은 사람이 검토할 텍스트를 반환한다. 자율 에이전트는 로컬 파일을 읽고, 패키지를 설치하며, 외부 서비스를 호출하고, 인증 토큰을 사용하고, 코드를 수정하고, 지속적인 승인 없이 작업을 계속할 수 있다.

이러한 역량은 에이전트를 유용하게 만든다. 동시에 잘못된 가정, 조작된 입력, 침해된 종속성 또는 모호한 지침이 초래하는 결과도 확장한다.

프롬프트는 에이전트에게 기밀 정보를 공유하지 말라고 지시할 수 있다. 하지만 이 지침이 에이전트가 민감한 파일을 열거나 알려지지 않은 서버에 접속하는 것을 물리적으로 막지는 못한다. 애플리케이션 가드레일은 에이전트가 탐색하는 동일한 소프트웨어 환경의 일부로 남는다.

프롬프트 인젝션은 이 약점을 특히 중요하게 만든다. 에이전트는 웹사이트, 문서, 이메일, 이슈 트래커 또는 소스 코드 저장소 안에서 악의적인 지침을 마주할 수 있다. 이러한 지침은 정당한 작업 데이터처럼 보이면서 에이전트의 방향을 바꾸려 할 수 있다.

공격자를 만나지 않더라도 모델은 유효한 요청을 잘못 해석할 수 있다. 프로젝트를 정리하라는 요청을 받은 코딩 에이전트는 필수 파일을 삭제할 수 있다. 리서치 에이전트는 그 단계를 유용하다고 판단해 승인되지 않은 서비스에 정보를 제출할 수 있다.

NVIDIA의 엔터프라이즈 AI 부문 부사장 Justin Boitano는 기자들에게 지침이 모호하거나 도구가 예기치 않게 작동할 때 에이전트가 일탈할 수 있다고 말했다. 그의 핵심 주장은 에이전트가 행동할 수 있게 된 후에는 스스로를 통제할 것으로 기대할 수 없다는 것이었다.

이것이 NVIDIA Open Agent Safety Platform 출시 발표의 기반 원칙이다. 에이전트 추론은 확률적이지만 인프라 권한은 결정론적일 수 있다. 정책 엔진은 모델이 요청 이유를 어떻게 설명하든 네트워크 연결을 거부할 수 있다.

이 변화는 클라우드 보안의 이전 전환과 닮아 있다. 조직들은 모든 데이터베이스, 비밀 정보, 네트워크 경로를 애플리케이션 개발자만이 보호하도록 의존하는 일을 멈췄다. 대신 각 애플리케이션 외부에 ID 관리, 워크로드 격리, 정책 엔진, 모니터링을 추가했다.

에이전트 보안도 이제 비슷한 전환을 맞고 있다. 모델에는 여전히 안전성 훈련이 필요하고, 애플리케이션에도 합리적인 지침이 필요하다. 어느 계층도 테스트에서 잘 작동한다는 이유만으로 무제한 권한을 받아서는 안 된다.

NVIDIA의 입장은 에이전트 플랫폼 공급업체에도 압박을 가한다. 에이전트 하니스 내부에서만 구현된 보안 통제는 외부 런타임이 여러 모델과 프레임워크 전반에서 권한을 집행할 수 있을 때 설득력이 약해진다.

클라우드 제공업체도 압박을 받는다. 에이전트 플릿을 배포하는 고객은 자율 워크로드를 위해 설계된 ID 경계, 자격 증명 브로커링, 송신 제어, 감사 기록을 점점 더 기대하게 될 것이다. 범용 컨테이너만으로는 모든 거버넌스 질문에 답할 수 없다.

기업은 세 번째로 압박받는 집단이다. 기업은 에이전트가 어떤 리소스에 접근하는지, 권한이 어떻게 바뀌는지, 누가 이를 중단할 수 있는지를 설명하지 못한다면 에이전트가 최소 권한으로 작동한다고 주장할 수 없다.

이 요구 사항은 극적인 불량 에이전트 시나리오를 넘어선다. 컴플라이언스 팀은 파일 접근, API 호출, 정책 변경, 자격 증명 사용을 포함한 일상 작업의 기록도 필요로 한다.

NVIDIA는 100개 이상의 조직이 이 플랫폼의 기술과 함께 작업하고 있다고 밝혔다. 발표된 참여 그룹에는 Anthropic, Cisco, CrowdStrike, Dell Technologies, Hugging Face, JPMorganChase, Microsoft, Palantir, Perplexity, Red Hat, Salesforce, SAP, Scale AI, ServiceNow 등이 포함된다.

이 목록은 폭넓은 관심을 보여주지만, 운영 환경에서의 성숙도를 입증하지는 않는다. “함께 작업하고 있다”는 표현은 평가, 통합, 공동 엔지니어링 또는 지원 계획을 포괄할 수 있다. 구매자는 여전히 배포 근거와 운영 결과를 확인해야 한다.

OpenShell 0.1, 최소 권한을 에이전트 런타임으로 전환

OpenShell의 핵심 기여는 더 똑똑한 모델이 아니라, 다양한 모델 아래에서 재사용할 수 있는 제어 계층이다.

OpenShell 0.1 릴리스 라인은 안정적인 출시 주기, 확장된 확장 지점, 새로운 API, 추가 격리 메커니즘을 통해 이 접근 방식을 공식화한다. 해당 open-source repository는 검토를 위해 런타임, 정책 시스템, 소프트웨어 개발 키트, 배포 자료를 공개한다.

각 에이전트는 비특권 계정과 축소된 운영체제 기능을 갖춘 샌드박스 안에서 실행된다. Linux 제어 기능은 파일시스템 접근과 시스템 호출을 제한하며, 외부 연결은 정책 검사를 거친다.

아키텍처는 샌드박스와 감독자를 분리한다. 에이전트는 제한된 워크로드 경계 안에서 작동하고, 감독자는 그 밖에 남아 승인된 접근을 중개한다. 게이트웨이는 사용자, 샌드박스, 정책, 설정, 자격 증명을 관리한다.

이 분리는 에이전트 프로세스가 보유한 권한을 줄인다. 모델이 금지된 파일을 요청하는 셸 명령을 생성하면, 운영 환경은 해당 작업을 차단한다. 모델의 확신이나 제시된 근거는 결과를 바꾸지 못한다.

OpenShell 정책은 선언형이다. 관리자는 모든 제한 사항을 애플리케이션 코드에 삽입하는 대신 구성으로 허용되는 행동을 기술한다. 이는 보안, 플랫폼, 개발 팀이 함께 검토할 수 있는 공통 표면을 만든다.

정책은 여러 관련 영역을 다룬다. 파일시스템 규칙은 읽을 수 있는 경로와 쓸 수 있는 경로를 구분한다. 프로세스 제어는 권한을 줄이고 시스템 호출을 제한한다. 네트워크 규칙은 목적지, 포트, 바이너리, 애플리케이션 수준의 세부 정보를 평가한다.

공급업체 프로필은 승인된 서비스와 해당 자격 증명 및 네트워크 규칙을 연결한다. 이는 API 토큰을 일반 환경 변수에 두는 대신 의도된 목적지에 묶어둘 수 있다.

런타임은 추론 라우팅도 지원한다. 기업은 공급업체 자격 증명을 샌드박스 밖에 유지하면서 에이전트가 사용할 모델 엔드포인트를 관리할 수 있다. 이는 팀이 로컬 모델, 클라우드 API, 제한된 데이터를 함께 사용할 때 중요하다.

관측 가능성은 기본 제어 루프를 완성한다. OpenShell은 결정을 기록하고 구조화된 형식으로 보안 이벤트를 내보낼 수 있다. 조사 담당자는 에이전트가 무엇을 요청했는지, 런타임이 무엇을 허용했는지, 무엇을 거부했는지 검토할 수 있다.

이러한 기능은 특히 코딩 에이전트에 잘 맞는다. 개발자는 에이전트가 하나의 저장소를 읽고, 작업 브랜치 안에서 파일을 생성하며, 승인된 레지스트리에서 패키지를 다운로드하고, 승인된 모델 엔드포인트에 연결하도록 허용할 수 있다.

동일한 정책은 관련 없는 저장소, 개인 디렉터리, 프로덕션 자격 증명, 임의의 웹사이트에 대한 접근도 차단할 수 있다. 에이전트가 더 광범위한 접근을 요청할 경우, 사람 또는 신뢰할 수 있는 시스템이 제안된 변경 사항을 검토할 수 있다.

이 설계는 장기 실행 에이전트도 지원한다. 전통적인 샌드박스는 제한된 작업을 수행하는 하나의 한정된 프로세스를 보호하는 경우가 많다. OpenShell은 정책 업데이트와 하위 에이전트 워크플로를 포함해 시간이 지나며 변화하는 에이전트 활동을 관리하는 것을 목표로 한다.

이러한 목표는 운영상 복잡성을 수반한다. 정책은 정당한 변형을 수용하면서도 보호 가치를 잃을 정도로 광범위해지지 않아야 한다. 또한 팀에는 모든 작업을 지연시키지 않으면서 예외를 검토할 수 있는 프로세스가 필요하다.

형식 검증은 제안된 정책의 구조를 평가하는 데 도움이 된다. 그러나 기업이 위험한 작업을 승인할 의도가 있었는지 판단할 수는 없다. 허용 가능한 경계는 여전히 인간의 거버넌스가 결정한다.

OpenShell의 오픈소스 지위는 조직에 또 다른 이점을 제공한다. 보안 연구자는 구현을 검토하고, 가정을 시험하며, 변경 사항을 제안할 수 있다. 기업은 다양한 컴퓨팅 플랫폼이나 배포 환경에 맞게 소프트웨어를 확장할 수도 있다.

오픈소스라고 해서 자동으로 안전한 소프트웨어가 만들어지는 것은 아니다. 독립적인 검토를 위한 조건을 제공하지만, 유의미한 검증에는 적극적인 유지보수자, 명확한 공개 절차, 재현 가능한 테스트, 신속한 수정이 필요하다.

버전 0.1은 신중함도 시사한다. 이 프로젝트는 이제 구체적인 공개 아키텍처를 갖췄지만, 초기 도입자는 실제 워크로드가 한계를 드러냄에 따라 API, 정책, 배포 관행, 통합 방식이 바뀔 수 있음을 예상해야 한다.

핵심 경쟁은 집행과 에이전트의 자기 절제 사이에 있다

NVIDIA는 에이전트의 추론 루프 내부에 머무는 안전 규칙보다 집행 가능한 인프라 제어가 더 우수한 성과를 낼 것이라는 데 베팅하고 있다.

이는 주로 NVIDIA와 다른 칩 제조사 간의 경쟁이 아니다. 에이전트에게 안전하게 행동하도록 요구하는 방식과, 안전하지 않은 행동이 실패하도록 환경을 설계하는 방식 사이의 경쟁이다.

모델 제공업체들은 정렬, 거부 행동, 지시문 우선순위, 모니터링을 계속 개선하고 있다. 이러한 조치는 모델이 유해한 행동을 선택할 가능성을 줄일 수 있다. 또한 인프라 제어만으로는 인식할 수 없는 행동도 다룬다.

OpenShell은 다른 계층을 다룬다. 모델이 결국 실수하거나, 조작된 맥락을 따르거나, 승인되지 않은 작업을 시도할 것이라고 가정한다. 런타임은 그로 인한 피해를 제한하는 데 초점을 둔다.

두 접근법은 서로 보완해야 하지만 우선순위는 다르다. 정렬은 에이전트의 의사결정을 개선하려 한다. 런타임 집행은 의사결정이 여전히 오류 가능하다고 보고 그 결과를 제약한다.

Anthropic의 참여는 이러한 결합된 접근법을 보여준다. NVIDIA는 Claude Managed Agents가 에이전트 루프를 실행 샌드박스와 분리한다고 설명한다. OpenShell과 BlueField는 그러한 샌드박스를 통한 접근을 둘러싸고 추가 제어를 제공할 수 있다.

이 구성은 심층 방어를 만든다. 즉, 에이전트와 민감한 리소스 사이에 여러 독립적인 제어 장치가 놓인다. 한 계층의 실패가 다른 모든 계층의 무력화로 자동으로 이어지지는 않는다.

이 플랫폼은 오픈 모델과 클로즈드 모델도 지원한다. NVIDIA가 경쟁하는 AI 생태계 전반에 인프라를 공급한다는 점에서, 이 모델 비종속적 입지는 전략적으로 중요하다. 특정 시장을 어떤 모델이 주도하든 공용 런타임은 유용해질 수 있다.

그러나 소프트웨어 이식성과 하드웨어 독립성은 동일하지 않다. OpenShell은 NVIDIA CPU를 넘어 확장할 수 있지만, 완전한 Sentry 설계는 격리된 실리콘 내 집행을 위해 BlueField-4에 의존한다.

이는 “개방형” 플랫폼 내부에 상업적 긴장을 만든다. 소프트웨어 계층은 이기종 인프라를 지원할 수 있지만, NVIDIA의 가장 강력한 격리 전략은 NVIDIA 네트워킹 하드웨어와 DOCA 스택을 부각한다.

경쟁사와 클라우드 제공업체는 여러 방식으로 대응할 수 있다. 자사 플랫폼에서 OpenShell을 지원하거나, 호환 가능한 정책 시스템을 구축하거나, 기존의 격리 및 기밀 컴퓨팅 기능을 대안으로 홍보할 수 있다.

보안 벤더 역시 에이전트 활동을 기존의 엔드포인트, ID, 네트워크, 데이터 보호 제품과 연결할 수 있다. 에이전트 거버넌스는 독립 시장이라기보다 기업 보안 아키텍처의 또 다른 계층이 될 가능성이 높다.

따라서 NVIDIA Open Agent Safety Platform Launched 행사는 NVIDIA의 역할을 확장한다. 이 회사는 학습과 추론을 위한 컴퓨팅 공급에만 머무르지 않는다. 자율 워크로드가 권한을 받는 방식과 인프라가 그 권한을 회수하는 방식을 정의하는 데 관여하려 한다.

이러한 위치는 NVIDIA에 새로운 제어 평면에 대한 영향력을 제공한다. OpenShell 정책이 널리 채택되면, 이 런타임은 에이전트 ID, 감사 가능성, 자격 증명 처리, 네트워크 접근에 대한 기대를 형성할 수 있다.

채택은 중립성에 달려 있다. 범용 보안 계층을 표방하는 시스템이 특정 하드웨어 스택에 강하게 유리하다고 판단되면 기업은 주저할 수 있다. 명확한 인터페이스와 비-NVIDIA 시스템에 대한 신뢰할 수 있는 지원이 중요해질 것이다.

개발자들은 다른 문제, 즉 마찰을 판단할 것이다. 유용한 작업을 끊임없이 방해하는 보안 계층은 광범위한 예외, 배포 포기, 비공식적 우회책을 부추길 것이다.

이 플랫폼은 최소 권한이 실용적으로 유지될 때에만 성공할 수 있다. 그러려면 팀이 필요한 접근 권한을 파악하고, 거부 사유를 설명하며, 정책을 시험하고, 모든 에이전트 작업을 보안 티켓으로 만들지 않고 변경을 승인하도록 돕는 도구가 필요하다.

NVIDIA의 안전 플랫폼이 여전히 보장할 수 없는 것

격리는 에이전트의 범위를 제한할 수 있지만, 허용된 모든 작업이 올바른지 판단할 수는 없다.

에이전트는 공식 권한 범위 안에 머물면서도 피해를 초래할 수 있다. 인보이스 제출 권한을 가진 금융 에이전트는 사기 문서를 승인할 수 있다. 쓰기 권한을 가진 코딩 에이전트는 허용된 저장소에 미묘한 취약점을 도입할 수 있다.

OpenShell은 이러한 행동을 기록하고 그 범위를 제한할 수 있다. 하지만 모든 조직의 의도, 비즈니스 로직, 윤리적 요구사항을 독립적으로 이해할 수는 없다.

정책의 품질은 여전히 핵심이다. 관리자가 광범위한 파일 시스템 접근, 제한 없는 네트워크 송신, 재사용 가능한 자격 증명을 부여한다면 런타임은 약한 경계를 정확하게 집행하게 된다.

University of California, San Diego 연구자인 Earlence Fernandes는 이 플랫폼을 올바른 방향으로 나아가는 단계라고 평가했다. 그러나 유용한 에이전트에는 실제 리소스가 필요하기 때문에 최소 필요 접근 권한을 정의하는 일은 여전히 어렵다고 경고했다.

University of Wisconsin 컴퓨터 과학 교수 Somesh Jha도 관련된 우려를 제기했다. 그는 Associated Press에 사례 연구가 보안과 차단되는 유용한 작업 사이의 균형을 시스템이 어떻게 맞추는지 보여줘야 한다고 말했다.

오탐은 그 균형의 한쪽을 형성한다. Sentry가 정당한 워크로드를 격리하면 조직은 자율 운영에 대한 신뢰를 잃을 수 있다. 각 개입에 대한 신뢰할 수 있는 복구 절차와 설명이 필요하다.

미탐은 다른 한쪽을 형성한다. 특히 에이전트가 승인된 도구를 의도하지 않은 목적으로 사용할 때, 의심스러운 행동은 유효한 활동과 유사해 보일 수 있다. 허용된 요청도 그 내용물을 통해 정보를 유출할 수 있다.

NVIDIA는 Sentry가 밀리초 단위로 개입할 수 있다고 말한다. 탐지 이후에는 속도가 중요하지만, 이 공개 주장은 다양한 환경 전반의 탐지 정확도를 입증하지는 않는다.

독립 벤치마크는 격리 지연 시간 이상을 측정해야 한다. 평가자는 탈출 시도, 정책 우회, 자격 증명 오용, 은밀한 데이터 전송, 손상된 종속성, 제어 평면 자체에 대한 공격을 시험해야 한다.

성능 오버헤드도 신중하게 측정해야 한다. NVIDIA는 Vera CPU에서의 OpenShell 오버헤드가 최소 수준이라고 설명한다. 구매자는 네트워크 집약형 에이전트, 대규모 도구 체인, 빈번한 정책 변경, 다수의 동시 샌드박스를 다루는 워크로드별 결과를 필요로 한다.

완전한 시스템의 하드웨어 의존성은 또 다른 불확실성을 제시한다. BlueField는 मुख्य 워크로드에서 집행을 격리할 수 있어 보안 모델을 강화한다. 그러나 소프트웨어만 사용하는 도입자가 마주하지 않는 인프라 요구사항도 추가한다.

이 플랫폼은 모델 정렬 작업을 없애지 않는다. 이러한 행동이 허용된 채널 내에서 일어날 때, 기만적인 출력, 부실한 추론, 조작된 증거, 편향된 권고, 유해한 콘텐츠를 막을 수는 없다.

책임성도 해결하지 못한다. 조직은 여전히 누가 권한을 승인하고, 누가 로그를 검토하며, 누가 격리 이벤트에 대응하고, 누가 에이전트의 승인된 행동에 대한 책임을 수용할지 결정해야 한다.

NVIDIA는 이번 출시를 에이전트가 의도된 경계를 넘었던 최근 사건들과 연결했다. 초기 보도는 OpenShell과 더 광범위한 보안 플랫폼의 중요성을 적절히 강조한다.

그러나 이 시스템이 과거의 침해를 막았을 것이라는 주장은 여전히 사후적인 회사 평가다. 재현된 사고 테스트와 독립적인 레드팀 훈련이 더 강력한 증거를 제공할 것이다.

가장 신뢰할 수 있는 해석은 더 제한적이다. NVIDIA는 에이전트 위험에 대한 진지한 시스템 수준의 대응책을 도입했지만, AI 안전 전반을 해결한 것은 아니다. 조직이 이를 올바르게 구성할 경우 이 플랫폼은 접근 가능한 공격 표면을 줄일 수 있다.

플랫폼의 작동 여부를 보여줄 세 가지 신호

다음 증거는 배포 사례, 독립 테스트, NVIDIA 자체 인프라를 넘어선 지원에서 나와야 한다.

첫 번째 신호는 출시 당시 언급된 조직들의 공개된 프로덕션 경험이다. 파트너 목록은 상당하지만, 고객은 정책, 차단된 행동, 운영 오버헤드, 사고 대응에 대한 상세한 설명을 필요로 한다.

의미 있는 사례 연구라면 실제 에이전트 워크플로와 필요한 권한을 설명할 것이다. OpenShell이 어떤 작업을 거부했는지, 개발자가 정책을 어떻게 조정했는지, 이러한 제어가 정당한 작업을 방해했는지를 보여줄 것이다.

규제 환경에서의 증거는 특히 유용할 것이다. 은행, 의료 기관, 정부 기관, 핵심 인프라 운영자는 접근 제어와 감사 가능성에 대한 엄격한 요구사항에 직면한다.

이들 조직이 OpenShell을 프로덕션으로 옮긴다면 NVIDIA의 주장은 힘을 얻는다. 활동이 시연과 평가에만 머문다면, 이번 출시는 아키텍처 제안에 더 가깝게 보일 것이다.

두 번째 신호는 독립적인 보안 검증이다. 연구자들은 대표적인 배포 사례, 위협 모델, 구성 지침, 재현 가능한 테스트에 접근할 필요가 있다.

테스트는 샌드박스, 감독자, 게이트웨이, 정책 검증기, 자격 증명 브로커, Sentry 경계를 살펴봐야 한다. 공격자는 NVIDIA가 가장 강력하다고 여기는 구성 요소 하나만이 아니라 구성 요소 간 상호작용을 노릴 것이다.

연구자들은 사용성 실패도 검토해야 한다. 기술적으로 올바른 보안 시스템도 관리자가 허용적인 예시를 복사하거나, 기본값을 오해하거나, 반복된 거부 후 제어 기능을 비활성화하면 효과를 잃을 수 있다.

NVIDIA의 공개 문서는 이미 개발자에게 검토할 자료를 제공한다. 다음 단계는 지속적인 외부 검토, 투명한 취약점 처리, 연구자가 결함을 발견했을 때 눈에 보이는 수정이다.

세 번째 신호는 신뢰할 수 있는 이식성이다. OpenShell의 소프트웨어는 Arm 및 Intel 플랫폼으로 확장할 수 있지만, 가장 강력한 Sentry 주장은 여전히 BlueField-4와 연결돼 있다.

클라우드, 하이브리드, 온프레미스, 에어갭 시스템 전반에서 작동하는 통합은 이것이 개방형 에이전트 보안 계층이라는 NVIDIA의 주장을 뒷받침할 것이다. NVIDIA 하드웨어에 좁게 집중한다면 그러한 포지셔닝은 약화될 것이다.

운영체제 벤더의 지원도 도움이 될 수 있다. Canonical, Red Hat, SUSE는 NVIDIA가 일반적으로 배포되는 인프라에 플랫폼 기술을 통합하고 있다고 밝힌 조직들에 포함된다.

개발자는 OpenShell의 출시 주기도 주의 깊게 지켜봐야 합니다. 정책 호환성, 안정적인 API, 마이그레이션 가이드, 관측성 개선이 버전 0.1이 신뢰할 수 있는 인프라로 발전할 수 있을지를 결정할 것입니다.

NVIDIA Open Agent Safety Platform Launched 발표는 이 논의에 유용한 기준을 제시합니다. 에이전트 안전성에는 에이전트가 다시 작성하거나, 설득하거나, 무시할 수 없는 제어 수단이 포함되어야 합니다.

이 기준이 모든 기업에 NVIDIA의 전체 설계를 채택하라고 요구하는 것은 아닙니다. 다만 구매자가 접근 권한, 격리, 자격 증명, 감사, 비상 격리에 대해 더 까다로운 질문을 던져야 한다는 뜻입니다.

자율 에이전트를 평가하는 팀은 에이전트가 접근할 수 있는 모든 리소스를 매핑하는 것부터 시작할 수 있습니다. 어떤 제어 수단이 모델의 협조에 의존하는지, 그리고 모델이 예기치 않게 행동한 후에도 어떤 제어 수단이 계속 강제될 수 있는지를 파악해야 합니다.

또한 정책, 거부된 작업, 예외 결정, 사고 조사 결과를 위한 엔지니어링 지식 베이스를 유지할 수 있습니다. 이러한 기록은 보안 규칙이 추측이 아닌 증거를 바탕으로 발전하도록 돕습니다.

실질적인 검증 기준은 간단합니다. 조직이 특정 업무에 필요한 범위를 훨씬 넘어서는 권한을 부여하지 않고도 에이전트가 가치 있는 작업을 수행하게 할 수 있는가? OpenShell과 Sentry는 이에 대한 NVIDIA의 답을 제시합니다. 그 답이 실제로 유효한지는 프로덕션 환경의 증거가 판단할 것입니다.