NVIDIA, 'AI 보안은 엔지니어링 문제': 에이전트 스택 모든 계층에 검증 가능한 통제를

NVIDIA는 2026년 9월 21일 공식 블로그에 Saša Zdjelar가 쓴 글을 올렸다. 제목은 직설적이다. AI 보안은 엔지니어링 문제라는 것이다. 핵심 주장은 보안이 구호나 프롬프트에 머물면 안 되고, 명확한 보안 요구사항, 강제할 수 있는 통제, 지정된 책임자, 방어가 작동한다는 증거로 구체화돼야 한다는 점이다. AI 능력이 커질수록 업계는 보안 엔지니어링을 서두르고, 방어 도구에 대한 접근을 넓히고, 효과가 있는 방법을 더 빨리 공유해야 한다고 글은 말한다. 글은 단순한 사실에서 출발한다. 기술은 바뀌어도 보안의 기본은 변하지 않는다. 인터넷과 클라우드는 소프트웨어가 동작하는 방식을 바꿨지만, 신원을 확립하고, 접근을 통제하고, 노출을 제한하고, 방어가 작동하는지 확인한다는 책임은 그대로였다. AI 에이전트는 새로운 능력을 더한다. 추론하고, 도구를 쓰고, 마주친 데이터에 따라 행동을 바꾼다. 이 능력이 옛 원칙을 무효로 만들지는 않는다. 새 운영 조건에서 그 원칙을 다시 적용하라는 요구다. 글은 압박의 출처도 솔직히 짚는다. 조직은 AI의 생산성을 원하지만, 이런 시스템을 통제하고 보호하는 관행은 아직 만들어지는 중이다.

글 전체를 읽는 열쇠는 스택 전체를 보는 시각이다. 애플리케이션은 코드, 데이터, 신원, 서비스, 인프라에 의존하고, 보안은 이 요소들이 어떻게 맞물리는지에 달려 있다. AI 에이전트는 이 시스템을 확장한다. 글은 에이전트를 세 계층으로 나눈다. 모델은 능력을 제공한다. 하네스는 컨텍스트, 도구, 워크플로를 조직한다. 런타임 환경은 동작이 실행되는 인프라를 제공한다. 계층마다 보안 책임이 있고, 데이터와 지시와 동작이 시스템을 흐르므로 모든 계층에 통제가 필요하다. 어느 한 계층에 모든 것을 맡길 수는 없다. 글은 한 장면으로 이를 설명한다. 에이전트가 고객 레코드를 갱신하다가 첨부 문서에서 악성 지시를 만나 고객 데이터를 승인되지 않은 목적지로 내보내려 한다. 네트워크 정책이 전송을 막고, 보호된 로그가 시도된 도구 호출과 권한 결정과 결과를 기록해야 한다. 그래야 보안팀이 어떤 도구가 쓰였고 어디로 보내려 했는지 알 수 있다. 여기서 권한의 세분화가 문제 된다. 고객 레코드를 수정할 권한이 그 데이터를 내보낼 권한으로 자동 확장돼서는 안 된다. 에이전트는 추가 접근을 요청할 수 있지만, 그 접근을 스스로 승인할 수는 없다.

여기서 글에서 가장 무거운 문장이 나온다. 보안 경계는 에이전트가 잘못된 결정을 내려도 유지돼야 한다. 제한이 에이전트 자신의 판단에 기대면 안 된다는 뜻이다. 에이전트가 실행되는 환경이 그 추론과 별개로 파일, 네트워크 목적지, 프로세스에 제한을 둬야 한다. 지시와 안전장치는 행동을 유도할 수 있지만, 보안에는 강제할 수 있는 경계도 필요하다. 글은 엔지니어링 요건을 몇 가지 든다. 각 에이전트는 추적 가능한 신원과 맡은 작업에 한정된 자격 증명을 가져야 한다. 조직은 에이전트가 접근할 수 있는 정보, 변경할 수 있는 시스템, 승인이 필요한 동작을 정하는 명확한 정책이 있어야 한다. 중대한 동작과 권한 변경에는 여전히 사람의 승인이 필요하다. 에이전트가 쓰는 도구, 스킬, 의존성의 출처와 무결성도 확인해야 한다. 사고 이후도 다룬다. 도구 호출, 권한 결정, 결과에 대한 보호된 기록은 조사관이 경위를 재구성하게 돕는다. 접근 권한을 회수하고 사고를 봉쇄하는 절차가 분명하면 그 증거가 행동으로 이어진다. 로그는 보기 좋으라고 있는 것이 아니라 대응을 사실에 근거하게 하려고 있다. 제품 측면에서 NVIDIA는 오픈소스 보안 런타임 NVIDIA OpenShell을 내세운다. 에이전트의 손이 닿지 않는 곳에서 정책을 집행하고, 샌드박스 실행을 제공하며, 에이전트가 데이터, 네트워크, 시스템 자원에 접근하는 방식을 통제한다. 글에 따르면 Open Secure AI Alliance 파트너들이 OpenShell 위에서 개발 중이다. Cisco의 DefenseClaw는 거버넌스 계층을 더하고, JFrog는 OpenShell과 통합해 에이전트 스킬을 검사, 검증하고 어떤 스킬을 쓸 수 있는지 정책을 집행한다.

두 번째 주제는 증거다. 배포 전에 팀은 통제가 두 가지 시도를 막는다는 증거를 가져야 한다. 에이전트 범위를 넘는 자격 증명을 얻으려는 시도, 민감한 데이터를 승인되지 않은 목적지로 보내려는 시도다. 권한을 바꾸거나 모니터링을 방해하려는 시도도 시험에 넣고, 모델, 도구, 워크플로가 크게 바뀌면 반복한다. 지정된 책임자가 그 결과로 배포 여부를 정하고, 실패한 시험이 시정 조치로 이어지게 한다. 시험이나 운영에서 발견된 장애는 재현, 조사, 해결하고, 각 발견은 반복 가능한 시험이 돼 이후 릴리스에서도 수정이 유효한지 확인한다. 글은 반복적 공격 시뮬레이션으로 방어를 시험하고 강화하는 CrowdStrike의 SafeMind, 모델과 애플리케이션이 바뀌는 동안 지속적 레드팀을 제공하는 Palo Alto Networks의 Prisma AIRS를 예로 든다.

세 번째 주제는 방어자의 도구다. 장애를 조사하려면 작업, 데이터, 환경에 맞는 유능한 도구가 필요하다. 글은 오픈 모델과 클로즈드 모델이 서로 보완하는 필요를 채운다고 본다. 클로즈드 모델은 관리형 기능과 서비스를 제공한다. 오픈 모델은 방어자가 관련 구성 요소를 검사하고, 전략을 조정하고, 스스로 통제하는 인프라에서 일하게 해 준다. 사고 중에는 이 통제권이 장애를 재현하고, 자사 시스템에서 수정을 시험하고, 민감한 증거를 자사 환경 안에 두는 데 도움이 된다. 유능한 AI는 취약점 발견, 수정 검증, 공격 조사를 도울 수 있고, 그 가치는 재현 가능한 발견, 검증 가능한 수정, 빨라진 대응 시간으로 평가해야 한다고 한다. 예로는 AI 기반 코드 보안의 Capital One VulnHunter, 소프트웨어 패키지를 AI로 분석해 악성코드와 변조를 탐지하는 ReversingLabs의 Spectra Assure가 있다. 마지막 절은 열린 협업으로 우위를 방어자에게 기울이자는 내용이며, 무엇이 실패했고 어떤 통제가 효과가 있었는지 공유하자고 주장한다. 우리가 받은 원문 발췌는 거기서 문장 중간에 끊겨 있어 이 부분은 더 다루지 않는다.

주의할 점이 있다. 이 글은 틀과 입장을 밝히는 블로그 글이다. 성능 벤치마크, 비용, 측정된 위험 감소 수치는 없으므로, 본문만으로는 이 조치들이 얼마나 효과적인지 판단할 수 없다. 아래는 출처의 주장이 아니라 본 기사의 분석이다. 개발자에게 가장 직접적인 교훈은 권한 모델과 격리를 에이전트 바깥에 두는 것이다. 에이전트마다 고유한 신원과 최소 권한 자격 증명을 주고, 네트워크와 파일 제한은 시스템 프롬프트가 아니라 런타임이 집행하게 한다. 기업에는 에이전트 배포마다 책임자를 지정하고, 레드팀 시험 통과를 출시 조건으로 삼고, 사고마다 회귀 시험을 늘리라는 뜻이다. 생태계 측면에서 OpenShell과 파트너의 조합은 역할 분담을 보여 준다. 런타임이 집행을 맡고, 거버넌스 계층, 공급망 검사, 지속적 레드팀이 나머지를 채운다. 과제도 분명하다. 첫째, 수정은 되지만 반출은 안 되는 식의 구분을 하려면 정책이 충분히 세밀해야 하는데, 세밀한 정책은 유지 비용이 든다. 둘째, 공급망 위험은 사라지지 않는다. 스킬과 의존성의 출처를 확인하려면 생태계 전체의 공통 기준이 필요하다. 셋째, 지속적 시험은 지속적 비용을 뜻하는데 글은 누가 부담하는지 말하지 않는다. 넷째, 이 글은 관련 플랫폼을 파는 업체에서 나왔으므로 독자는 자기 환경에 비추어 틀을 평가해야 한다. 그래도 보안을 한 번의 약속이 아니라 검증할 수 있고 책임 소재가 분명한 엔지니어링 항목으로 보는 방향은 업계 전체에 참고가 된다.