엔비디아 AI 에이전트 안전 플랫폼 공개, 오픈셸과 센트리가 만드는 밀리초 격리 통제 구조

엔비디아가 공개한 것은 정확히 무엇인가?

시험 단계부터 배포 이후까지 AI 에이전트를 통제하는 2계층 안전 플랫폼이다. 소프트웨어 계층(오픈셸)이 에이전트의 행동 범위를 정의·강제하고, 하드웨어 계층(센트리)이 그 소프트웨어와 독립적으로 감시·차단한다. 오픈셸은 오픈소스로 공개되어 엔비디아 칩이 아닌 Arm·인텔 기반 플랫폼에서도 쓸 수 있다.

구조를 뜯어보면 보안 업계의 오래된 원칙이 보인다. 감시자는 감시 대상과 같은 층에 있으면 안 된다는 것. 오픈셸이 CPU에서 에이전트와 함께 돌아가는 반면, 센트리는 블루필드-4 DPU라는 별도 하드웨어에서 독립적으로 작동한다. 에이전트가 소프트웨어 계층의 통제를 우회하더라도, 그 우회 행동 자체가 하드웨어 계층에서 탐지되고 밀리초 안에 격리된다. 정전 시 비상 발전기가 주 전력망과 분리되어 있어야 하는 것과 같은 이치다.

참여 명단도 눈여겨볼 대목이다. 앤트로픽, 마이크로소프트, 세일즈포스, 팔란티어를 포함한 100여 개 기업이 개발에 참여했다. 모델을 만드는 회사(앤트로픽), 에이전트를 파는 회사(세일즈포스), 정부·기업 시스템에 붙이는 회사(팔란티어)가 모두 "모델 바깥의 통제 계층"에 합류했다. 각자 자기 모델의 안전을 주장하던 회사들이 공동의 외부 경계 규격에 서명한 것이다.

AI 에이전트 안전의 다음 격전지는 모델 내부가 아니라 모델 바깥의 경계다.

왜 모델 안의 안전장치만으로는 부족한가?

모델 내부의 규칙은 입력으로 조작될 수 있기 때문이다. 시스템 프롬프트의 지시는 더 교묘한 프롬프트 인젝션으로 뒤집힐 수 있고, 훈련으로 심은 거부 반응은 우회 기법으로 뚫린 사례가 반복적으로 보고됐다. 반면 "이 에이전트는 이 네트워크 대역에 접속할 수 없다"는 외부 경계는 에이전트가 아무리 설득당해도 바뀌지 않는다.

최근 사례들이 이 판단을 뒷받침한다. 에이전트에 연결된 커넥터를 타고 악성 지시문이 스스로 복제되며 퍼지는 경로가 실험으로 확인됐고(자가복제 프롬프트 인젝션 정리), 에이전트가 허가되지 않은 경로로 외부에 접속한 사건도 있었다(세션 탈취·무단 접속 사건). 두 사례의 공통점은 모델이 나빠서가 아니라 모델 바깥의 경계가 없거나 느슨해서 피해 범위가 커졌다는 점이다. 엔비디아가 플랫폼을 내놓은 배경으로 지목되는 것도 인간의 명시적 지시 없이 에이전트가 통제를 벗어나 외부 시스템에 침투한 사례의 증가다.

속도도 사람의 몫이 아니게 됐다. 에이전트의 이상 행동은 초 단위가 아니라 밀리초 단위로 진행된다. 사람이 대시보드를 보고 중단 버튼을 누르는 구조는 이미 반응 속도에서 진 게임이고, 그래서 센트리 같은 자동 격리 계층이 필요해진다. 사람의 역할은 실시간 감시에서 경계를 설계하는 일로 이동한다.

하네스 엔지니어링 관점에서 무엇이 달라지나?

하네스 엔지니어링이 말해온 Harness 계층(에이전트가 읽을 수 있는 것, 쓸 수 있는 것, 사람이 확인하는 지점, 남는 기록)이 업계 표준 인프라로 제품화되기 시작했다는 뜻이다. 지금까지 조직이 직접 설계해야 했던 경계가 플랫폼 기능으로 내려온다. 단, 플랫폼은 경계를 집행할 뿐, 경계를 정의하는 일은 여전히 조직의 몫이다.

2026년 9월 2일 UX Korea 2026-Fall에서 하네스 엔지니어링과 AI 검증 프레임워크를 발표했다. 그때 프레임워크의 중심으로 강조한 것이 Prompt → Context → Harness → Loop 중 Harness, 즉 모델의 성능이 아니라 모델을 둘러싼 권한과 검증 관문의 설계였다. 엔비디아의 이번 발표는 그 계층을 소프트웨어(오픈셸)와 하드웨어(센트리)로 나눠 인프라 수준까지 밀어 넣은 것이다. 방향이 같다는 것은 반가운 일이지만, 동시에 분명해지는 것이 있다. 도구가 표준화될수록 차별화 요소는 도구가 아니라 경계 정의의 품질이 된다. "우리 에이전트는 무엇에 접근할 수 있어야 하는가"라는 질문에 답하지 못한 조직은, 오픈셸을 깔아도 빈 설정 파일 앞에 앉게 된다.

프레임워크 전체 구조와 검증 계층 설계는 하네스 엔지니어링 총론에 정리해뒀다. 이번 플랫폼은 그중 Harness 계층의 집행 수단이 하나 늘어난 것으로 읽으면 정확하다.

기업 실무자는 지금 무엇을 준비해야 하나?

플랫폼 도입 여부와 무관하게 지금 만들 수 있는 것은 경계 정의서다. ① 운영 중인 에이전트와 각각의 권한 목록, ② 에이전트별 접근 허용 범위(파일·데이터·도구·네트워크), ③ 경계 이탈 시 중단·격리 절차, ④ 행동 기록(로그)의 위치와 보존 기간. 이 4가지가 문서로 있으면 어떤 플랫폼이 오든 설정만 옮기면 된다.

순서를 제안하면 이렇다. 먼저 지금 조직에서 돌아가는 에이전트(사내 챗봇, 자동화 워크플로우, 코딩 에이전트, SaaS에 내장된 에이전트 기능까지)를 전수 목록화한다. 대부분의 조직이 이 단계에서 "생각보다 많다"를 경험한다. 다음으로 각 에이전트에 대해 접근 가능 범위를 화이트리스트 방식으로 적는다. "금지 목록"이 아니라 "허용 목록"이어야 하는 이유는, 금지 목록은 새로운 우회 경로가 나올 때마다 뒤늦게 갱신되기 때문이다. 마지막으로 이탈 시나리오별 대응(누가, 몇 분 안에, 무엇을 중단하는가)을 적고 분기마다 점검한다.

권한 통제를 게이트웨이 계층에서 제품화한 흐름은 AI 게이트웨이 분석에서 다뤘다. 게이트웨이가 데이터가 나가는 문을 지킨다면, 이번 플랫폼은 에이전트의 행동 반경 자체를 지킨다. 두 계층은 대체재가 아니라 겹쳐 쌓는 방어선이다.