AI News

NVIDIA는 자사의 AI Red Team이 올린 새로운 글을 통해 기업용 AI 배포에 대한 더 큰 메시지를 전하고 있다. 기업이 AI 에이전트를 실제 도구, 코드베이스, 내부 데이터 앞에 두고 싶다면, 모델 자체 밖에 있는 인프라 통제가 필요하다는 것이다.

NVIDIA Developer Blog에 게시된 가이드에서 팀은 지난 6개월 동안 기업용 에이전트를 평가하면서 같은 악용 가능 패턴을 반복적으로 발견했다고 밝혔다. NVIDIA에 따르면 반복적으로 드러난 문제는 취약한 접근 제어, 안전하지 않은 명령 실행, 네트워크 이그레스 제한 부재, 그리고 에이전트 환경 내 평문 비밀 정보였다. 중요한 점은 이것들이 완전히 새로운 보안 개념이라는 게 아니라, NVIDIA가 현재의 에이전트 스택이 여전히 이런 부분에서 자주 실패하므로 프롬프트 기반 보호나 판정 모델을 주된 방어선으로 봐서는 안 된다고 주장한다는 점이다.

NVIDIA의 경고는 프롬프트 튜닝이 아니라 에이전트 아키텍처에 관한 것이다

“Four Ways to Deploy More Secure AI Agents”라는 제목의 이 글은 NVIDIA AI Red Team에서 작성했으며, 대형 언어 모델이 에이전트 하니스(harness)를 통해 라이브 시스템에 연결될 때 어떤 일이 벌어지는지에 초점을 맞춘다. NVIDIA는 이 문제를 실무적인 기업 관점에서 설명한다. 버그 리포트를 검토하고, 수정하고, 테스트를 실행하고, 패치를 제출할 수 있는 디지털 동료는 생산성을 높일 수 있지만, 같은 설정이 넓고 충분히 이해되지 않은 공격면을 가진 특권 소프트웨어를 만들 수도 있다.

이런 관점이 중요한 이유는 조언의 대상이 모델 연구자보다 AI 에이전트를 중심으로 프로덕션 시스템을 구축하는 팀이기 때문이다. NVIDIA는 관찰된 실패 모드가 대화형 코딩 어시스턴트부터 상시 작동하는 자율형 어시스턴트까지 여러 유형의 에이전트에서 나타났으며, 특정 프레임워크 하나에 국한되지 않았다고 말한다.

회사의 핵심 주장은 모델 제어면 내부의 방어가 적대적 압박 아래에서는 충분히 신뢰할 수 없다는 것이다. 글에 따르면 프롬프트 기반 보호와 “LLM-as-a-judge” 패턴은 소셜 엔지니어링, 점진적인 “개구리 삶기”식 조작, 그리고 겉보기에는 정당한 워크플로 안에 숨겨진 공격에 지속적으로 취약했다. NVIDIA의 입장은 모델 밖에서 강제되는 결정론적 통제가 필요하다는 것이다.

NVIDIA가 기업에 우선하라고 권하는 네 가지 통제

첫째, NVIDIA는 접근 통제를 첫 번째 방어층으로 다뤄야 한다고 말한다. 평가 과정에서 팀은 개별 사용자의 자격 증명을 사용하면서도 내부 네트워크의 어떤 인증된 사용자라도 접근할 수 있는 에이전트를 발견했다. NVIDIA에 따르면 이는 에이전트의 정당한 권한 오용을 허용했을 뿐 아니라, 어떤 경우에는 자격 증명을 수집해 의도된 에이전트 문맥 밖에서 사용하는 경로도 만들었다. 실무적 권고는 분명하다. 각 에이전트를 명시적으로 승인된 사용자로 제한하고, 최소 권한 원칙에 따라 에이전트 권한을 호출 사용자에 맞추는 것이다.

둘째, NVIDIA는 명령 실행이 접근 가능한 에이전트에서 여전히 가장 큰 영향력을 가진 위험이라고 경고한다. 많은 에이전트 프레임워크가 셸을 노출하는데, 이는 유연하고 특수 도구의 필요성을 줄여주기 때문이다. 그러나 모델 출력이 명령 실행을 유발할 수 있다면, 프롬프트 인젝션이나 악성 사용자 입력이 일반적인 개발자 명령을 임의 코드 실행 경로로 바꿀 수 있다. NVIDIA는 패키지 설치와 테스트 실행을 포함해 소프트웨어 워크플로에서 흔한 명령이 리뷰 모델을 통과할 만큼 무해해 보이면서도 여전히 침해를 가능하게 할 수 있다고 지적한다.

회사는 Docker나 NVIDIA OpenShell 같은 샌드박스 실행 환경, 비실행 작업공간 밖의 쓰기를 막는 OS 수준 제한, 그리고 명령줄 접근이 불가피할 때 실행 가능한 명령에 대한 매우 좁은 허용 목록을 권장한다. 또한 더 미묘한 위험도 강조한다. 셸이 없어도 파일 읽기/쓰기 도구는 에이전트가 시작 파일, 설정 파일 또는 나중에 다른 프로세스가 실행하는 다른 위치를 수정할 수 있다면 권한 상승을 가능하게 할 수 있다.

셋째, NVIDIA는 기본 거부(default-deny) 네트워크 이그레스 정책으로 외부 연결을 잠가야 한다고 말한다. Red Team에 따르면 제한 없는 외부 연결은 데이터 유출을 쉽게 하고, 리버스 셸이나 다른 직접적인 운영자 접근을 에이전트 런타임에 허용한다. NVIDIA는 이그레스 통제가 제대로 시행되면 공격이 더 느려지고, 덜 신뢰할 수 있게 되며, 유지하기도 어려워졌다고 보고한다. 상호작용이 직접 외부 채널이 아니라 계속 에이전트를 통해 흘러야 했기 때문이다. 빌더에게 이는 구체적인 배포 규칙으로 이어진다. 에이전트의 작업에 필요한 최소한의 외부 엔드포인트만 허용하라는 것이다.

넷째, 이 글은 가능한 한 영구적인 비밀 정보를 에이전트 환경 밖에 두어야 한다고 말한다. NVIDIA 글에서 추출된 증거는 평문 비밀 정보 노출이 반복되는 실패 모드임을 가리킨다. 더 넓은 권고는 엄격한 비밀 정보 관리, 패키지 소스의 신중한 검증, 도구 권한의 엄격한 통제다. 공통된 목표는 에이전트가 조작될 경우 공격자가 훔치거나 재사용할 수 있는 것을 줄이는 것이다.

지금 코딩 도구와 엔터프라이즈 AI에 이것이 중요한 이유

NVIDIA의 권고는 더 많은 기업이 챗봇 파일럿에서 엔지니어링, IT, 지원, 백오피스 워크플로 내부의 도구 사용 에이전트로 이동하는 시점에 나왔다. 채팅 어시스턴트와 운영 에이전트의 차이는 크다. 시스템이 스크립트를 실행하고, 종속성을 설치하고, 티켓을 열고, 내부 시스템을 조회하고, 저장소에 손을 댈 수 있게 되면 위험 프로필은 모델 안전성보다는 전통적인 소프트웨어 보안과 엔드포인트 강화에 더 가까워진다.

이 때문에 이 가이드는 코딩 어시스턴트나 다른 자율형 워크플로 도구를 배포하는 팀에 특히 중요하다. 코드 중심 에이전트는 종종 테스트 실행, 파일 검사, 패키지 설치, 버전 관리 시스템 연결이 필요하다. 바로 이런 기능들이 NVIDIA가 보기에 보안 통제가 주로 모델의 판단에 의존할 경우 위험해질 수 있는 기능들이다. git 설정과 model context protocol 설정 같은 파일 언급은 유연한 통합이 조용히 새로운 지속성 경로를 만들 수 있는, 떠오르는 에이전트 도구 생태계를 가리키기도 한다.

엔터프라이즈 AI 구매자에게 실무적인 시사점은, 작업 완료율이 높은 벤더 데모만으로는 충분하지 않다는 것이다. 구매자는 실행이 어디서 일어나는지, 런타임이 격리되어 있는지, 어떤 네트워크 목적지가 허용되는지, 사용자 신원이 어떻게 전달되는지, 장기 자격 증명이 에이전트 환경 안에 머무는 일이 있는지를 물어야 한다. 이런 질문은 순수한 보안만큼이나 신뢰성과 거버넌스에도 영향을 미친다.

증거, 주장, 그리고 아직 검증되지 않은 부분

이 이야기는 거의 전적으로 NVIDIA Developer Blog를 통한 NVIDIA 자체 보도에 기반하며, 두 번째 출처는 Google News 피드에서 같은 항목을 반영했을 뿐이다. 즉, 핵심 결과는 독립적인 업계 측정치가 아니라 벤더가 보고한 레드팀 관찰로 읽어야 한다.

그럼에도 NVIDIA는 유용한 구체성을 제공한다. 회사는 AI Red Team이 지난 6개월 동안 여러 에이전트를 평가했고, 프레임워크와 하니스 전반에서 반복적으로 악용 가능한 패턴을 발견했다고 말한다. 또한 셸을 사용해 패키지 설치나 스크립트를 실행하는 것, 셸 시작 파일에 쓰는 것, 제한 없는 외부 트래픽을 유출이나 원격 접근에 활용하는 것 등 위험한 행동의 구체적 예도 제시한다.

하지만 이 글은 몇 개의 에이전트를 테스트했는지, 어떤 벤더나 오픈소스 스택이 포함되었는지, 각 실패 모드가 얼마나 자주 나타났는지, 또는 실제 운영에서 몇 건의 사고가 있었는지를 수치화하지 않는다. 또 한 통제 집합이 다른 집합보다 얼마나 효과적인지 보여주는 비교 벤치마크 데이터도 제시하지 않는다. 따라서 이 가이드는 포괄적인 시장 조사라기보다 직접 테스트 경험이 있는 Red Team의 실용적인 아키텍처 조언으로 이해하는 것이 가장 좋다.

프롬프트 필터링과 LLM-as-a-judge 설정에 대한 신뢰성 비판도 NVIDIA의 평가다. 많은 보안팀이 큰 방향성에는 동의할 가능성이 높지만, 제공된 증거에는 외부에서 검증된 테스트 결과가 포함되어 있지 않다. 그렇다고 해서 경고의 중요성이 줄어드는 것은 아니다. 독자들은 일반적인 교훈과 모든 에이전트 제품이 같은 방식으로 실패한다는 가정을 분리해야 한다.

빌더와 플랫폼 팀에 대한 시사점

빌더에게 가장 분명한 변화는 애플리케이션 계층 안전성에서 시스템 계층 안전성으로의 이동이다. AI 에이전트가 프로덕션에 가까운 리소스에 접근할 수 있다면, 배포 설계가 영리한 프롬프팅보다 더 중요해진다. 샌드박스 경계, 신원 전달, 엔드포인트 허용 목록, 비밀 정보 격리는 핵심 제품 결정이 된다.

이것은 비용과 워크플로 측면의 함의도 가진다. 샌드박싱은 실행을 느리게 하거나 개발 환경을 복잡하게 만들 수 있다. 기본 거부 이그레스 정책은 팀이 의존성을 상세히 매핑하도록 요구한다. 사용자별 권한 일치는 기업 신원 시스템과 더 깊은 통합을 강제할 수 있다. 하지만 기업이 AI 에이전트를 실험에서 승인된 엔터프라이즈 워크플로로 발전시키고 싶다면 이런 제약이 필요할 수 있다.

이 가이드는 또한 업무 자동화에 대한 더 성숙한 정의를 시사한다. 에이전트가 워크플로를 끝에서 끝까지 완료할 수 있는지 묻기보다, 팀은 그것이 엄격히 제한된 파급 범위 안에서 그렇게 할 수 있는지를 물어야 할지도 모른다. 이는 어떤 도구가 노출되는지, 어디서 실행되는지, 어느 정도의 자율성이 허용되는지 등을 포함해 엔터프라이즈 AI 플랫폼 전반의 아키텍처 선택에 영향을 줄 것이다.

다음에 주목할 것

유용한 신호 하나는 주요 에이전트 프레임워크와 엔터프라이즈 플랫폼이 이런 통제를 선택적 강화 단계가 아니라 기본값으로 제공하기 시작하는지 여부다. 특히 더 강력한 샌드박싱 통합, 더 세분화된 신원 및 권한 부여 모델, 관리하기 쉬운 네트워크 이그레스 정책, 그리고 지속 자격 증명을 피하는 비밀 정보 설계가 주목할 만하다.

두 번째 신호는 더 많은 벤더가 일반적인 안전성 주장 대신 적대적 테스트 데이터를 공개하는지 여부다. NVIDIA의 글은 신뢰할 만한 우려를 제기하지만, 시장은 여전히 이런 에이전트 실패 모드가 제품 전반에 얼마나 흔한지에 대한 일관된 제3자 증거가 부족하다.

마지막으로, 특히 규제 산업에서 secure-by-default 패턴이 AI 에이전트 조달의 일부가 되는지 추적하는 것이 중요하다. 구매자들이 격리와 최소 권한 강제의 증명을 요구하기 시작하면, 보안 아키텍처는 백오피스 체크리스트가 아니라 경쟁 차별화 요소가 될 수 있다.

Creati.ai 관점

NVIDIA의 메시지는 새로운 익스플로잇 하나에 관한 것이라기보다 시장 보정에 더 가깝다. AI 에이전트의 첫 물결은 자율성과 편의성으로 평가되는 경우가 많았다. 이 가이드는 기업이 그것들을 특권 소프트웨어 운영자처럼 평가해야 한다고 주장한다. 이는 이 카테고리에 건강한 전환이다.

창업자와 제품 팀에게 전략적 교훈은 간단하다. 엔터프라이즈 AI에서 성공하는 AI 에이전트는 단순히 작업을 완료하는 것만이 아니라, 어디에서 실행되는지, 무엇에 접근할 수 있는지, 그리고 무엇을 유출할 수 없는지를 증명할 수 있어야 한다. 모델 품질도 여전히 중요하지만, 배포 아키텍처가 빠르게 AI 에이전트, 업무 자동화, 그리고 진지한 코딩 어시스턴트를 위한 진짜 신뢰 계층이 되고 있다.

추천

NVIDIA Red Team, 기업용 AI 에이전트 보안을 위한 네 가지 아키텍처 통제 방안 제시

NVIDIA의 AI Red Team은 모델 수준의 방어가 실패하고 있기 때문에 기업용 AI 에이전트에 더 엄격한 접근, 샌드박싱, 네트워크 통제, 비밀 정보 관리가 필요하다고 말한다.