NVIDIA, AI 에이전트 보안 스택을 제시하다

NVIDIA는 AI 에이전트 보안 문제를 모델이 "더 신중하게 추론"하도록 하는 방식으로는 해결할 수 없다는 입장을 밝혔다. 이 회사는 이를 순수한 엔지니어링 문제로 규정한다. 즉 명확한 보안 요구사항, 강제 가능한 통제, 각 통제에 대한 명확한 책임자, 그리고 그 보호 조치가 실제로 작동한다는 증거, 이 네 가지가 모두 갖춰져야 한다는 것이다.

NVIDIA는 실제 에이전트 배포 사례를 관찰한 결과 반복적으로 나타나는 다섯 가지 보안 문제를 제시했다. 첫째는 무단 데이터 접근으로, 에이전트가 문서에 숨겨진 악성 지시를 만나 고객 데이터를 허가되지 않은 대상으로 유출하려 시도하는 경우다. 둘째는 권한 상승으로, 에이전트가 부여받은 작업 범위를 넘어서는 권한을 획득하는 경우다. 셋째는 접근 통제 우회로, 에이전트가 자신의 권한 범위 밖에 있는 자격 증명을 얻으려 시도하는 경우다. 넷째는 모니터링 방해로, 권한을 변경하거나 보안 모니터링 자체를 방해하려는 시도다. 다섯째는 도구 무결성 문제로, 에이전트가 의존하는 스킬이나 종속성이 변조되거나 손상된 경우다.

모델뿐 아니라 스택 전체를 봐야 한다

NVIDIA는 이 문제를 세 개의 층으로 구조화한다. 핵심 추론 능력을 제공하는 모델 층, 컨텍스트와 도구와 워크플로를 조직하는 하네스 층, 그리고 에이전트의 행동을 실제로 실행하는 런타임 환경 층이다. 이 세 층 중 어느 하나만 안전해서는 충분하지 않으며, 전체 체계는 코드, 데이터, 아이덴티티, 서비스, 인프라가 함께 올바르게 작동해야 성립한다.

NVIDIA가 제시한 구체적인 사례는 이렇다. 고객 기록을 업데이트하는 에이전트가 첨부 문서에 숨겨진 악성 지시를 만나 허가되지 않은 데이터 유출을 시도한다. NVIDIA의 설계에서는 에이전트 자신의 의사결정 루프 바깥에 있는 네트워크 정책이 이 전송을 차단하며, 동시에 보호된 감사 로그가 이 시도를 기록해 이후 조사에 활용할 수 있도록 한다. 이 사례를 중심으로 NVIDIA는 에이전트 배포에 필수적인 다섯 가지 요건을 제시한다. 에이전트의 판단과 무관하게 항상 유효한 강제 가능한 경계, 각 에이전트가 개별 아이덴티티를 가지고 해당 작업에 필요한 자격 증명만 보유하는 것, 에이전트가 접근할 수 있는 정보와 승인할 수 있는 작업을 명시한 정책, 모든 도구 호출과 승인 결정을 기록하는 보호된 감사 로그, 그리고 중대한 결과를 초래하는 작업 전에 반드시 사람의 승인을 거치도록 하는 것이다.

왜 "에이전트 바깥에서 강제"해야 하는가

[분석] NVIDIA의 이 프레임워크를 관통하는 논리는, 에이전트가 "추론"으로 우회할 수 없는 통제만이 진정한 통제로 간주된다는 것이다. 이는 모델이 "더 잘 판단하기를" 기대하는 것과는 근본적으로 다른 태도이며, 제로 트러스트 네트워크 아키텍처가 클라이언트 기기를 다루는 방식과 같다. 기본적으로 신뢰하지 않고, 모델 스스로가 자신의 경계를 집행하는 주체가 되지 않도록 하는 것이다. 고객 기록 사례에서 실제로 데이터 유출을 막은 것은 모델의 판단이 아니라 네트워크 정책이었다. 이는 브라우저와 엔드포인트를 둘러싸고 전통적인 애플리케이션 보안이 수십 년 전에 배운 교훈과 일치한다. 집행 지점은 손상된 구성 요소가 손댈 수 없는 곳에 있어야 한다. 그것이 방화벽이든, IAM(아이덴티티 및 접근 관리) 계층이든, 아니면 NVIDIA OpenShell처럼 에이전트의 실행 환경을 감싸는 정책 계층이든 마찬가지다.

[분석] NVIDIA가 거명한 도구 목록은 제품 카탈로그라기보다 스택 전반에 걸친 역할 분담처럼 읽힌다. NVIDIA 자체의 OpenShell은 집행 런타임을 제공하고, Cisco DefenseClaw는 그 위에 거버넌스 계층을 추가한다. JFrog는 에이전트가 사용을 허가받기 전에 스킬을 스캔하고 검증한다. ReversingLabs의 Spectra Assure와 Capital One의 VulnHunter는 공급망과 코드 무결성 문제를 서로 다른 각도에서 다루는데, 전자는 소프트웨어 패키지 내 악성코드를 탐지하고 후자는 AI 기반 코드 보안 스캔을 수행한다. 그리고 CrowdStrike SafeMind와 Palo Alto Networks Prisma AIRS는 공격자 관점에서 검증을 수행하여, 공격 시뮬레이션과 지속적인 레드팀 테스트를 통해 방어가 실제로 작동하는지 시험한다. 이 목록에서 스택 전체를 커버하는 단일 공급업체는 없다. 그리고 어쩌면 그것이 핵심일 것이다. 서로 다른 전문 공급업체가 연결될 수 있는 참조 아키텍처는 단일 기업이 약속하는 "종단 간 해결책"보다 더 오래 지속될 가능성이 높다. 왜냐하면 에이전트 보안은 전통적으로 서로 다른 팀이 맡아온 아이덴티티, 코드, 런타임, 모니터링이라는 여러 영역에 걸쳐 있기 때문이다.

[분석] 현재 에이전트를 배포하고 있는 기업에게 NVIDIA의 이 목록이 시사하는 실질적인 출발점은 제품 구매가 아니라 자체 점검이다. 각 에이전트가 공유된 서비스 자격 증명이 아니라 개별적으로 범위가 제한된 아이덴티티를 가지고 있는가. 시스템 프롬프트뿐 아니라 각 에이전트가 접근할 수 있는 범위를 정의한 정책 문서가 존재하는가. 도구 호출과 승인 결정이 에이전트 자신이 수정할 수 없는 곳에 기록되고 있는가. 그리고 쉽게 되돌릴 수 없는 작업 전에 사람이 개입하는 체계가 있는가. 이 네 가지 질문은 NVIDIA가 제시한 다섯 가지 요건과 직접적으로 대응하며, 위에서 언급한 제3자 제품 중 어느 것도 도입하지 않고도 기업 스스로 먼저 확인해 볼 수 있다.