가상의 시나리오를 생각해 보겠습니다. AI 팩토리의 에이전트가 문서를 가져옵니다. 그 문서에는 사용자가 에이전트에게 실행하도록 의도한 적 없는 숨겨진 지시가 들어 있습니다. 에이전트는 그 지시를 따릅니다. 연결을 열고, 모델 컨텍스트 프로토콜(MCP)을 통해 도구를 호출하고, 아무도 요청하지 않은 레코드를 가져와 아무도 승인하지 않은 곳으로 전송합니다. 이를 포착했어야 할 가드레일은 같은 컨테이너의 사이드카로 실행되고 있었기 때문에 에이전트는 먼저 이를 꺼 버렸습니다. 로그도 에이전트의 통제하에 있어 이 사건은 기록조차 되지 않았습니다. 걸린 시간은 1초도 채 되지 않았습니다. 경로상 그 어떤 것도 이를 감지할 수 없었기에 아무도 알아차리지 못했습니다.
이는 이례적인 장애가 아닙니다. 제어 장치가 에이전트와 동일한 신뢰 도메인 내에서 에이전트 곁에 배치되어, 침해되거나 잘못된 판단을 내린 에이전트가 이를 비활성화하거나 우회하거나 증거를 조작할 수 있는 환경이라면 어디서든 기본적으로 발생할 수 있는 장애입니다. 간단히 말해, 에이전트가 스스로를 통제하게 해서는 안 됩니다.
The F5 Application Delivery and Security Platform은 모든 앱과 API를 제공하고 보호합니다. 그다음은 AI 에이전트입니다. AI 에이전트는 모델을 호출하고, MCP를 통해 도구를 실행하며, 다른 에이전트와 통신하고, 팩토리 내부와 외부의 API에 접근하는 등 기존과는 다르게 작동합니다. 가치를 창출하려면 에이전트가 샌드박스 외부의 모델, 도구, API 및 데이터에 통제된 방식으로 접근할 수 있어야 하며, 이러한 상호작용에는 반드시 집행 가능한 정책이 적용되어야 합니다. NVIDIA OpenShell 레퍼런스 아키텍처는 NVIDIA가 NVIDIA GTC 베를린에서 공개하는 아키텍처로, 바로 이러한 요구사항을 중심으로 설계되었습니다. 이 아키텍처는 에이전트의 런타임 권한, 하드웨어 기반 정책 집행, 추론을 NVIDIA 하드웨어의 세 계층에 배치하고, 이들 계층을 잇는 경로에 파트너가 참여할 수 있는 여지를 둡니다. 각 주체의 역할을 가장 명확하게 보여주는 방법은 샌드박스 밖으로 나가는 요청의 흐름을 따라가는 것입니다.
NVIDIA OpenShell 참조 아키텍처의 역할
이 참조 아키텍처는 에이전트를 신뢰할 수 없다는 전제에서 출발하며, 이에 따라 하드웨어를 분리합니다.
안전한 AI 에이전트를 위한 NVIDIA OpenShell 참조 아키텍처에서 NVIDIA OpenShell은 NVIDIA Vera CPU에서 실행되며 에이전트의 런타임 권한을 관리합니다. OpenShell의 감독자는 외부 요청을 평가하고, 구성된 HTTP, GraphQL 및 MCP 트래픽에 세분화된 제어를 적용하며, 자격 증명을 보호하고, 각 정책 결정을 기록합니다. 에이전트는 샌드박스에서 실행되지만, 이를 관리하는 감독자는 그렇지 않습니다.
NVIDIA Sentry는 NVIDIA BlueField-4 DPU에 독립적인 하드웨어 모니터링 및 정책 적용 계층을 추가합니다. 이 계층은 에이전트가 접근하거나 수정할 수 없는 격리된 보안 도메인에서 위협 탐지, 요청 및 응답 검사, 에이전트 거버넌스, 밀리초 단위의 격리 조치를 수행합니다. NVIDIA Sentry는 선택적 계층이며, NVIDIA Vera Rubin 시스템에서는 모델로 향하는 경로에 위치합니다.
NVIDIA Vera Rubin NVL72 인프라는 에이전트가 호출하는 모델을 실행합니다. 따라서 이 아키텍처는 에이전트가 접근할 수 없는 인프라에서 에이전트의 작업 허용 여부를 이미 결정하고, 에이전트의 동작도 모니터링합니다. F5는 AI 트래픽을 위한 콘텐츠 검사, 레드팀 테스트, 애플리케이션 딜리버리를 통해 이러한 제어 기능을 보완하며, 이는 에이전트 사이버 보안을 위한 NVIDIA와의 협력을 기반으로 합니다.
OpenShell과 NVIDIA Sentry가 결정하는 사항
OpenShell은 어떤 에이전트가 어떤 정책에 따라 요청했는지, 그리고 대상과 메서드가 허용되는지를 파악합니다. 보호를 한층 강화하기 위해 NVIDIA Sentry는 NVIDIA DOCA를 사용하여 NVIDIA BlueField-4에서 실행되며, 에이전트를 독립적으로 모니터링하고 실리콘 수준에서 정책을 적용하며 수 밀리초 이내에 에이전트를 격리합니다. 이 두 시스템을 통해 에이전트의 작업 허용 여부는 에이전트가 통제할 수 없는 영역에서 결정됩니다. 이것이 바로 이 설계의 핵심입니다.
런타임 권한, 행동 모니터링, AI 특화 콘텐츠 검사는 상호 보완적인 보호 계층을 제공합니다. F5는 지원되는 프롬프트, 모델 응답 및 도구 호출을 검사하여 프롬프트 인젝션, 탈옥, 민감한 데이터 노출을 탐지함으로써 OpenShell의 런타임 거버넌스와 NVIDIA Sentry의 지속적인 행동 모니터링 및 하드웨어 격리형 정책 시행을 보완합니다.
F5는 에이전트가 주고받는 내용을 검사합니다
F5 AI Guardrails는 프롬프트, 모델 응답, OpenShell이 제어하는 프로토콜을 통해 전달되는 도구 호출 등 적용 경로에서 라우팅된 지원 트래픽을 검사합니다. 검사 결과를 바탕으로 세 가지 작업을 수행합니다. 프롬프트 인젝션, 탈옥, 정책을 벗어난 도구 호출을 차단합니다. 민감한 데이터가 외부로 나가기 전에 이를 삭제 처리합니다. 모든 결정을 세션 기록에 감사 로그로 남깁니다. 판정 결과와 텔레메트리는 OpenShell 및 NVIDIA Sentry에서 사용할 수 있으므로, 차단된 요청은 운영자 정책에 따라 격리 조치까지 포함하는 에이전트 수준의 결정으로 이어질 수 있습니다. 가로채기는 에이전트의 컨테이너 내부가 아닌 적용 경로에서 이루어지므로 에이전트가 Guardrails를 비활성화하거나 우회할 수 없습니다. 끌 수 있는 사이드카도 없습니다.
F5 AI Red Team은 가드레일이 제 역할을 충실히 수행하도록 검증합니다. 일반 사용자가 이용하는 것과 동일한 경로를 통해 비공개 및 공개 에이전트와 모델을 공격하고, 그 과정에서 발견한 사항을 가드레일 정책에 반영하여 방어 체계가 관리 대상 에이전트의 발전 속도에 발맞추도록 합니다.
에이전트를 관리한다는 것은 에이전트가 수행한 작업을 입증하는 것도 의미합니다. F5 컨트롤 플레인에는 사용자, 프롬프트 컨텍스트, 도구 호출, 승인된 매개변수 등의 세션 기록이 보관됩니다. OpenShell에는 정책 결정이 기록되고, NVIDIA Sentry에는 파일 액세스, 커널 호출, DPU 패킷 메트릭 등의 시스템 기록이 보관됩니다. 이러한 기록을 서로 연계하면 에이전트가 조작할 수 없는 출처를 바탕으로 모델이 의도한 것, 에이전트가 시도한 것, 에이전트가 실제로 수행한 것을 하나의 타임라인에서 파악할 수 있습니다.
The F5 AI Security Platform 제어 플레인과 AI Red Team은 팩토리 내부의 서버 측에서 실행됩니다. 에이전트가 호출하는 프로덕션 추론 모델은 NVIDIA Vera Rubin NVL72에서 실행되며, AI Red Team도 보안 테스트에 GPU 리소스를 사용합니다. AI Guardrails는 Arm CPU만 있으면 되므로 NVIDIA Vera와 BlueField-4에서 실행할 수 있습니다. 아래의 두 참조 아키텍처는 각 구성 요소가 어디에 배치되는지 보여줍니다.
NVIDIA OpenShell 기반의 두 가지 F5 참조 아키텍처
NVIDIA의 3개 계층에 걸쳐 구성됩니다. Vera에서는 OpenShell 내부의 에이전트 하네스에 AI Guardrails를 적용하고, NVIDIA BlueField-4에서는 에이전트의 장애 영향 범위 밖에서 팩토리가 필요로 할 때 데이터 플레인과 함께 AI Guardrails를 다시 적용하며, Vera Rubin NVL72에서는 모델과 함께 컨트롤 플레인 및 AI Red Team을 배치합니다. 이를 통해 두 가지 레퍼런스 아키텍처가 만들어집니다. 두 아키텍처 모두 NVIDIA OpenShell 레퍼런스 아키텍처를 기반으로 구축되고 동일한 정책과 컨트롤 플레인을 사용하며, 차이점은 에이전트의 경로에 무엇이 배치되는가입니다.
참조 아키텍처 1: NVIDIA OpenShell 및 NVIDIA Sentry와 함께 사용하는 F5 AI Guardrails
NVIDIA 스택을 설계된 방식대로 운영하는 운영자를 위한 구성입니다. F5 AI Guardrails는 하나의 정책에 따라 두 곳에서 실행됩니다. NVIDIA Vera에서는 OpenShell 내부의 에이전트 하네스에 적용되고, NVIDIA Sentry에 통합된 BlueField-4 DPU에서는 에이전트가 접근할 수 없는 위치에서 실행됩니다. 전자는 에이전트가 전송하는 내용을 전송 시점에 포착합니다. 후자는 에이전트가 비활성화할 수 없습니다. Guardrails는 지원되는 트래픽 중 해당 시스템으로 라우팅된 트래픽을 차단하고 민감 정보를 삭제하며 감사하고, BlueField에서는 그 판정 결과를 NVIDIA Sentry가 즉시 활용해 에이전트를 격리할 수 있습니다. 추가 하드웨어는 필요하지 않습니다. NVIDIA 스택을 표준으로 채택한 NVIDIA Cloud Partner는 다른 요소를 변경하지 않고도 콘텐츠 검사를 수행할 수 있습니다.
더욱 확장된 규모와 엔터프라이즈급 제공을 지원합니다. F5 BIG-IP Next for Kubernetes 는 NVIDIA Sentry와 함께 NVIDIA BlueField-4 DPU에서 또는 호스트 CPU에서 팩토리의 데이터 플레인으로 실행되며, F5 AI Guardrails는 동일한 정책에 따라 그 내부에서 실행됩니다. NVIDIA Sentry는 기본적인 정책 적용을 담당하고, BIG-IP Next for Kubernetes는 트래픽을 전달합니다. BIG-IP Next for Kubernetes는 NVIDIA Dynamo와 통합되어 Vera Rubin NVL72의 여러 모델 인스턴스에 걸쳐 에이전트 및 애플리케이션 트래픽을 라우팅하고 부하를 분산합니다. 테넌트를 격리하고, Model Context Protocol(MCP) 연결을 확장하고 보호하며, 테넌트별 토큰 사용량을 관리하고, 운영자가 테넌트와 모델 전반을 한눈에 파악할 수 있도록 합니다. 또한 BIG-IP Next for Kubernetes는 이를 통해 라우팅되는 트래픽에 운영자의 외부 송신 정책을 적용하여 OpenShell의 런타임 액세스 제어와 NVIDIA Sentry의 인프라 정책 적용을 보완합니다.
선택은 운영자의 몫입니다. OpenShell과 NVIDIA Sentry에 AI Guardrails를 도입하거나, AI Guardrails가 내장된 BIG-IP Next for Kubernetes를 추가할 수 있습니다. 두 경우 모두 정책과 제어 플레인은 동일합니다. 두 번째 옵션은 전체 팩토리에 테넌트 격리, 이그레스 제어 및 트래픽 관리 기능을 추가로 제공합니다.
별도로 측정된 수치이므로 보안 아키텍처와 구분해 제시합니다. NVIDIA BlueField-3 DPU에서 BIG-IP Next for Kubernetes를 대상으로 실시한 The Tolly Group의 테스트(보고서 #226104, 2026년 3월 발행)에서 BIG-IP Next for Kubernetes는 테스트 기준 대비 40% 더 높은 토큰 처리량을 달성했습니다. 이때 데이터 경로는 호스트 CPU에서 오프로드되었습니다. 이는 BIG-IP Next for Kubernetes의 데이터 플레인만을 측정한 결과이며, 여기에서 설명한 검사 기능은 포함되지 않습니다. AI에서 성능은 곧 경제성입니다.
팩토리 내부에 상주하는 보안
완전한 자체 호스팅 배포 환경에서는 F5 보안 처리 및 감사 기록이 운영자의 환경 내에 유지됩니다. 즉, 제어 플레인과 Red Team은 모델과 함께 서버 측에 있고, 검사는 Vera 및 BlueField-4에서 수행됩니다. 외부 모델 및 서비스에 대한 액세스는 계속해서 엔터프라이즈 정책의 적용을 받습니다. 다이어그램에 퍼블릭 대상이 표시된 데에는 이유가 있습니다. 모든 프롬프트와 응답을 AI 팩토리 내부에 유지하려면 로컬로 호스팅되는 대상과 외부 송신 제한도 필요합니다. 이 아키텍처는 이를 가능하게 합니다. 실제 적용 여부는 운영자의 정책에 따라 결정되며, 해당 송신 정책은 BIG-IP Next for Kubernetes에서 시행됩니다.
에이전트 시대는 새로운 보안 요구사항을 만들어냈다기보다, 가장 중요한 통제 지점을 에이전트가 건드릴 수 없는 인프라에 위치한 에이전트의 이그레스 경로로 옮겼습니다. F5는 바로 이러한 경로를 30년 동안 다뤄 왔습니다. NVIDIA OpenShell 참조 아키텍처에서 이 경로는 에이전트가 말로 회피할 수 없는 경로입니다.
자세히 알아보려면 F5 AI Security Platform, F5 AI Guardrails, F5 AI Red Team, F5 BIG-IP Next for Kubernetes 웹페이지를 방문해 보시기 바랍니다.
작성자 소개
Kunal Anand는 최고제품책임자(CPO)로서 F5의 제품 조직을 이끌고 있습니다. 제품 비전, 전략 및 실행을 총괄하며, 고객의 중대한 과제를 해결하고 탁월한 경험을 제공하는 혁신적인 솔루션의 개발을 주도합니다. 이전에는 최고기술·AI책임자로서 회사의 기술 및 AI 전략과 비전을 수립했습니다. F5에 합류하기 전에는 Imperva에서 최고기술책임자(CTO)와 최고정보보안책임자(CISO)를 겸임했습니다. Kunal은 2013년에 공동 창업한 애플리케이션 보안 스타트업 Prevoty가 2018년 Imperva에 인수되면서 Imperva에 합류했습니다. Prevoty 이전에는 BBC Worldwide에서 기술 담당 이사를 역임했습니다. Kunal은 혁신과 기술 분야에서 풍부한 경험과 전문성을 갖추고 있으며, Gravity, MySpace 및 NASA 제트추진연구소에서 보안, 데이터, 기술 및 엔지니어링 팀을 이끄는 직책을 맡았습니다. Kunal은 모델 학습, AI 기반 알고리즘을 활용한 제품 개선, AI 아키텍처 설계 및 구현 등 AI와 머신러닝 분야에서 15년 이상의 경험을 보유하고 있습니다. Kunal은 Babson College에서 컴퓨터 과학 학사 학위를 취득했습니다.
Kunal Anand의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.