에이전트 스택 전 계층 보호, 엔비디아 AI 보안 위한 엔지니어링 접근법 제시

엔비디아(www.nvidia.co.kr)가 AI 보안을 위한 엔지니어링 접근법을 제시했다. 

AI 보안은 엔지니어링의 문제다. 이는 명확한 보안 요구사항, 강제 적용 가능한 통제 수단, 명확한 책임 주체, 그리고 보안 조치가 실제로 작동한다는 것을 입증할 수 있는 증거가 필요하다는 의미다. 

기술은 변해도 보안의 기본 원칙은 변하지 않는다

인터넷과 클라우드 컴퓨팅은 소프트웨어가 작동하는 방식을 변화시켰지만, 신원을 확인하고, 접근을 제어하며, 노출을 제한하고, 보호 조치가 제대로 작동하는지 검증해야 한다는 핵심 보안 원칙은 여전히 유효하다. 

AI 에이전트는 추론하고, 도구를 사용하며, 접하는 데이터에 따라 행동을 조정하는 등 새로운 기능을 제공한다. 이러한 기능을 안전하게 활용하기 위해서는 기존에 확립된 보안 원칙을 새로운 운영 환경에 맞게 적용해야 한다. 

이처럼 빠른 변화는 조직에 부담으로 작용한다. 조직은 AI가 제공하는 생산성 향상의 이점을 활용하고자 하지만, 이러한 시스템을 관리하고 보호하기 위한 보안 관행은 여전히 발전 중이다. 

보안은 전체 에이전트 스택에 달려 있다

애플리케이션은 코드, 데이터, 신원, 서비스, 인프라에 의존한다. 보안은 이러한 구성 요소들이 어떻게 함께 작동하는지에 따라 좌우되며, AI 에이전트는 이러한 시스템을 확장한다. 

모델은 기능을 제공하고, 하네스(harness)는 컨텍스트, 도구, 워크플로우를 구성하며, 런타임 환경은 작업이 실행되는 인프라를 제공한다. 이 스택의 각 부분은 각각의 보안 책임을 지닌다. 데이터, 명령, 작업이 시스템을 거쳐 이동하는 과정에서 적절한 보호를 구현하려면 각 계층에 걸쳐 통제 수단을 적용해야 한다. 

예를 들어, 고객 정보를 업데이트하는 에이전트가 첨부 문서에서 악의적인 명령을 접한 뒤, 고객 데이터를 승인되지 않은 대상으로 내보내려고 시도할 수 있다. 

이 경우 네트워크 정책은 해당 데이터 전송을 차단해야 하며, 보호된 로그에는 도구 호출 시도, 인가 결정, 실행 결과가 기록돼야 한다. 이를 통해 보안 팀은 어떤 도구가 사용됐고, 어느 대상으로 접근을 시도했는지 파악할 수 있다. 

고객 정보를 업데이트할 수 있는 권한이 해당 데이터를 외부로 내보낼 수 있는 권한까지 자동으로 확장돼서는 안 된다. 에이전트는 추가 권한을 요청할 수는 있지만, 스스로 해당 권한을 승인할 수는 없다.

에이전트 운영 방식에 보안 내재화하기

에이전트가 잘못된 판단을 내리더라도 보안 경계는 유지돼야 한다. 에이전트가 실행되는 환경은 에이전트가 수행할 수 있는 작업 범위를 결정하므로, 에이전트의 추론과는 독립적으로 파일, 네트워크 대상, 프로세스에 대한 제한을 설정해야 한다. 

명령과 안전장치는 행동을 유도하는 데 도움이 될 수 있지만, 보안을 위해서는 실제로 강제 적용할 수 있는 경계 또한 필요하다. 

각 에이전트에는 추적 가능한 신원과 할당된 작업 범위로 제한된 자격 증명이 필요하다. 조직은 에이전트가 어떤 정보에 접근할 수 있는지, 어떤 시스템을 변경할 수 있는지, 어떤 작업에 승인이 필요한지를 명확하게 정의한 정책을 마련해야 한다. 이러한 경계 안에서도 중대한 작업이나 권한 변경에는 사람의 승인이 필요하다. 

또한 팀은 에이전트가 사용하는 도구, 스킬, 종속 요소의 출처와 무결성을 검증해야 한다. 문제가 발생할 경우, 도구 호출 내역, 인가 결정, 실행 결과에 대한 보호된 기록은 조사자가 사건의 경위를 재구성하는 데 도움이 된다. 접근 권한을 취소하고 사고를 격리하기 위한 명확한 절차가 마련돼 있어야 이러한 증거를 실제 대응 조치로 이어갈 수 있다. 

엔비디아 오픈쉘(OpenShell)은 에이전트가 직접 변경할 수 없는 외부 영역에서 정책을 강제 적용하는 오픈 소스 보안 런타임이다. 샌드박스 환경에서 에이전트의 실행을 격리하는 동시에, 데이터와 네트워크, 시스템 리소스에 대한 접근 방식을 제어한다. 오픈 시큐어 AI 얼라이언스(Open Secure AI Alliance) 파트너사들은 오픈쉘을 기반으로 다양한 솔루션을 개발하고 있다. 시스코(Cisco)의 디펜스클로(DefenseClaw)는 거버넌스 계층을 추가하며, 제이프록(JFrog)은 오픈쉘과 통합해 에이전트 스킬을 스캔하고 검증하며, 에이전트가 어떤 스킬에 접근할 수 있는지에 대한 정책을 적용한다. 

엔지니어링 팀에는 보안을 입증할 수 있는 증거가 필요하다

배포에 앞서 팀은 적절한 통제 수단이 에이전트의 권한 범위를 넘어서는 자격 증명을 획득하려는 시도나 민감한 데이터를 승인되지 않은 대상으로 전송하려는 시도를 실제로 차단할 수 있다는 증거를 확보해야 한다.

테스트에는 권한 변경을 시도하거나 모니터링 기능을 방해하려는 행위도 포함돼야 한다. 또한 모델, 도구, 워크플로우에 중대한 변경이 발생할 때마다 테스트를 반복해야 한다. 

명확하게 지정된 책임자는 이러한 테스트 결과를 바탕으로 시스템의 배포 준비 여부를 판단하고, 실패한 테스트가 반드시 시정 조치로 이어지도록 해야 한다. 테스트나 실제 운영 과정에서 발견된 실패는 재현하고 조사해 해결해야 한다. 발견된 각 문제를 반복 가능한 테스트 항목으로 전환하면, 향후 릴리스에서도 수정 사항이 지속적으로 제대로 작동하는지 확인할 수 있다. 

대표적인 사례로는 반복적인 공격 시뮬레이션을 통해 방어 체계를 테스트하고 강화하는 크라우드스트라이크(CrowdStrike)의 세이프마인드(SafeMind)와, 모델과 애플리케이션이 변화함에 따라 지속적으로 레드팀 테스트를 수행하는 팔로알토 네트웍스(Palo Alto Networks)의 프리즈마 에어스(Prisma AIRS)가 있다. 

방어자는 적시에 적합한 도구를 활용해야 한다

보안 실패를 조사하려면 작업, 데이터, 운영 환경에 적합한 역량을 갖춘 도구가 필요하다. 오픈 모델과 폐쇄형 모델은 서로 다른 요구사항을 상호 보완적으로 충족한다. 

폐쇄형 모델은 관리형 기능과 서비스를 제공하는 반면, 오픈 모델은 방어자가 관련 구성 요소를 직접 살펴보고 전략을 조정하며, 자신이 통제하는 인프라에서 작업할 수 있는 선택지를 제공한다.

보안 사고가 발생했을 때 이러한 통제권은 민감한 증거를 자체 환경 내에 유지하면서 문제를 재현하고, 수정 사항을 실제 시스템을 대상으로 테스트하는 데 도움이 될 수 있다.

고성능 AI는 취약점을 찾고, 수정 사항을 검증하며, 공격을 조사하는 과정에서도 활용될 수 있다. 이러한 AI의 가치는 재현 가능한 발견 사항, 검증 가능한 수정 결과, 대응 시간 단축과 같은 기준을 통해 평가해야 한다. 

관련 사례로는 AI를 활용한 코드 보안을 제공하는 캐피털 원(Capital One)의 벌른헌터(VulnHunter)와, 소프트웨어 패키지를 AI 기반으로 분석해 악성코드와 변조 여부를 탐지하는 리버싱랩스(ReversingLabs)의 스펙트라 어슈어(Spectra Assure)가 있다. 

개방형 협업을 통해 방어자에게 유리한 환경 만들기

무엇이 실패했는지, 어떤 통제 수단이 효과를 발휘했는지, 수정 사항이 어떻게 검증됐는지에 대한 증거를 공유하면 다른 팀들도 자체 시스템의 보안을 강화할 수 있다. 

엔비디아의 보안 연구와 오픈 시큐어 AI 얼라이언스는 연구 결과와 실질적인 도구, 전문 지식을 더 폭넓은 보안 커뮤니티와 공유함으로써 이러한 협업을 지원한다. 

AI 보안은 엔지니어링의 문제다. 모든 에이전트 배포 환경에는 강제 적용 가능한 보안 경계, 명확한 책임 주체, 그리고 보호 조치가 실제로 작동한다는 것을 입증할 수 있는 증거가 필요하다. 개방형 연구와 공동으로 활용할 수 있는 도구는 더 많은 방어자가 이러한 기준을 충족하고, AI 역량이 발전함에 따라 보안 수준도 지속적으로 향상할 수 있도록 지원한다. 

엔비디아의 보안 연구와 오픈 시큐어 AI 얼라이언스에 대한 자세한 내용은 관련 페이지에서 확인할 수 있다.