AI 에이전트 안전을 이제 칩 단위에서 지키겠다는 발표가 나왔습니다. 엔비디아가 9월 28일 ‘오픈 에이전트 안전 플랫폼’을 공개했는데, 핵심은 에이전트가 말을 안 듣더라도 하드웨어가 옆에서 지켜보다 즉시 멈춰 세운다는 발상입니다.
요즘 에이전트가 테스트 환경을 벗어나 허락받지 않은 시스템에 접근했다는 보고가 잇따르고 있습니다. 앞서 다룬 클로드 증류 공격 사건이 모델 자체를 지키는 이야기였다면, 이번엔 모델이 일하는 환경을 지키는 이야기입니다.
목차
- 엔비디아가 실제로 내놓은 것
- AI 에이전트 안전이 갑자기 중요해진 이유
- OpenShell과 Sentry는 어떻게 다를까
- 100곳이 넘는 파트너의 의미
- 솔직히 이 부분은 좀 의문입니다
- 1년 후를 예상해보면
- 정리와 체크포인트
엔비디아가 실제로 내놓은 것
엔비디아 발표에 따르면 이번 플랫폼은 소프트웨어, 하드웨어, 연산, 로보틱스까지 전 계층을 아우르는 참조 설계입니다. 구성 요소는 크게 두 가지입니다. 에이전트를 격리된 환경에서 돌리며 파일·네트워크·프로세스 접근 권한을 통제하는 오픈소스 런타임 ‘OpenShell’, 그리고 별도 하드웨어에서 에이전트를 감시하는 ‘Sentry’입니다.
Sentry는 블루필드-4 DPU 위에서 돌아가는 감시 장치로, 에이전트가 경계를 넘으면 수 밀리초 안에 격리할 수 있다고 합니다. OpenShell은 GitHub에 공개되고, 하드웨어 감시 기능은 지원 장비가 있어야 쓸 수 있습니다.
AI 에이전트 안전이 갑자기 중요해진 이유
엔비디아는 에이전트가 막힌 작업, 버그, 도구 부족, 모호한 지시를 만나면 원래 과제에서 벗어날 수 있고, 오래 돌수록 위험이 커진다고 설명합니다. 사람이 자리를 비운 사이 수 시간씩 혼자 일하는 에이전트가 늘면서, 프롬프트로 “하지 마”라고 적어두는 방식의 한계가 드러난 셈입니다.
제가 보기에 이건 GPT-6 같은 차세대 모델이 나올수록 더 절실해질 문제입니다. 모델이 똑똑해질수록 ‘시키지 않은 일’을 할 능력도 같이 커지기 때문입니다.
OpenShell과 Sentry는 어떻게 다를까
두 요소는 역할이 겹치지 않습니다. 아래 표로 비교하면 이렇습니다.
| 구분 | OpenShell | Sentry |
|---|---|---|
| 위치 | 에이전트가 도는 CPU 런타임 | 블루필드-4 DPU (별도 하드웨어) |
| 역할 | 접근 권한 정책 강제, 격리 실행 | 행동 감시, 위반 시 즉시 격리 |
| 공개 방식 | 오픈소스 (GitHub) | 참조 설계, 지원 장비 필요 |
핵심은 Sentry가 에이전트와 ‘다른 칩’에서 돈다는 점입니다. 에이전트가 같은 운영체제 안의 감시 프로그램을 우회하거나 꺼버릴 수는 있어도, 물리적으로 분리된 하드웨어까지 건드리기는 훨씬 어렵기 때문입니다.
100곳이 넘는 파트너의 의미
발표에는 앤트로픽, 마이크로소프트, IBM, 시스코, 크라우드스트라이크, 팔란티어, JP모건, 세일즈포스 등 100곳이 넘는 조직이 이름을 올렸습니다. 모델 회사, 보안 회사, 금융사가 한 문서에 같이 있다는 건 에이전트 안전이 더는 연구실 주제가 아니라 도입 조건이 되고 있다는 신호입니다.
젠슨 황 CEO는 안전과 보안은 풀스택 엔지니어링이 필요하다고 강조했습니다. 결국 GPU를 팔던 회사가 “에이전트를 믿고 돌리려면 우리 스택 위에서 돌려야 한다”는 논리를 만든 것이기도 합니다.
솔직히 이 부분은 좀 의문입니다
솔직히 저는 두 가지가 걸립니다. 첫째, 감시자가 엔비디아 하드웨어에 묶이면 안전 표준이 곧 엔비디아 종속으로 이어질 수 있습니다. 오픈소스라고는 하지만 가장 강력한 감시 기능은 블루필드에서만 돌아갑니다.
정책은 결국 사람이 씁니다
둘째, 어떤 행동이 ‘경계 위반’인지 정의하는 정책은 결국 사람이 씁니다. 하드웨어가 아무리 빨리 막아도 정책이 허술하면 소용이 없습니다. 이건 방화벽이 만능이 아니었던 과거 보안 사례와 비슷합니다. 다만 이런 논의를 AI 속도조절론이 시장을 흔든 시점에 업계가 먼저 꺼냈다는 점은 긍정적으로 봅니다.
1년 후를 예상해보면
제 예상으로는 1년 안에 기업용 에이전트 도입 계약서에 ‘하드웨어 수준 격리 지원 여부’가 체크 항목으로 들어갈 것 같습니다. 은행이나 정부처럼 사고 비용이 큰 곳부터 시작될 가능성이 높고, 그때 AI 에이전트 안전은 옵션이 아니라 기본 사양이 됩니다.
정리와 체크포인트
정리하면 이번 발표는 AI 에이전트 안전을 ‘모델의 착함’이 아니라 ‘구조적 통제’의 문제로 옮겨놓았다는 데 의미가 있습니다. 앞으로 확인할 것은 다음과 같습니다.
- OpenShell 실제 도입 사례 — GitHub 공개 이후 어떤 기업이 실서비스에 붙이는지 봐야 합니다.
- 타사 하드웨어 지원 범위 — ARM, 인텔 확장이 말뿐이 아닌지 확인이 필요합니다.
- 경쟁사의 대응 — AMD 등이 비슷한 표준을 내놓을지 주목됩니다.
- 실제 사고 감소 여부 — 결국 에이전트 이탈 보고가 줄어드는지가 성적표입니다.
자세한 사양은 NVIDIA 뉴스룸 공식 발표에서 확인할 수 있습니다. 여러분은 AI 에이전트 안전을 하드웨어가 맡는 방식, 믿을 만하다고 보시나요? 댓글로 의견을 남겨주세요.