Imaginemos una situación hipotética: un agente de una fábrica de IA recupera un documento. Oculta en él hay una instrucción que el usuario nunca quiso que el agente ejecutara. El agente la sigue: abre una conexión, invoca una herramienta mediante el Protocolo de Contexto de Modelo (MCP), obtiene un registro que nadie había solicitado y lo envía a un destino que nadie había autorizado. El mecanismo de protección que debería haberlo detectado era un sidecar ubicado en el mismo contenedor, así que el agente lo desactivó primero. El registro estaba bajo el control del agente, por lo que el incidente nunca quedó registrado. Tiempo transcurrido: menos de un segundo. Nadie lo vio porque ningún elemento de la ruta podía hacerlo.
No se trata de un fallo excepcional. Es el fallo habitual siempre que los controles se encuentran junto al agente, en el mismo dominio de confianza, donde un agente comprometido o engañado puede desactivarlos, eludirlos o manipular las pruebas. En pocas palabras: el agente no puede supervisarse a sí mismo.
La F5 Application Delivery and Security Platform proporciona y protege todas las aplicaciones y API. Los agentes de IA son los siguientes, y se comportan de forma diferente: un agente llama a modelos, invoca herramientas mediante MCP, se comunica con otros agentes y accede a API tanto dentro de la fábrica como fuera de ella. Para aportar valor, los agentes necesitan acceso controlado a modelos, herramientas, API y datos más allá de su entorno aislado, y esas interacciones deben seguir sujetas a políticas de obligado cumplimiento. La arquitectura de referencia NVIDIA OpenShell, que NVIDIA presenta en NVIDIA GTC Berlin, se ha diseñado precisamente en torno a este principio. Distribuye los permisos de ejecución del agente, la aplicación de controles mediante hardware y la inferencia entre tres niveles de hardware de NVIDIA, y deja espacio para los socios en la ruta que los conecta. La forma más clara de mostrar qué función desempeña cada uno es seguir una solicitud desde que sale del entorno aislado.
Qué hace la arquitectura de referencia NVIDIA OpenShell
La arquitectura de referencia parte de la premisa de que el agente no es de confianza y, en consecuencia, separa el hardware.
Dentro de la arquitectura de referencia de NVIDIA OpenShell para agentes de IA seguros, NVIDIA OpenShell se ejecuta en CPU NVIDIA Vera y controla los permisos del agente durante la ejecución. Su supervisor evalúa las solicitudes salientes, aplica controles granulares al tráfico HTTP, GraphQL y MCP configurado, protege las credenciales y registra cada decisión relativa a las políticas. El agente se ejecuta en un entorno aislado. El supervisor que lo controla, no.
NVIDIA Sentry añade una capa independiente de supervisión y aplicación de medidas de seguridad basada en hardware en las DPU NVIDIA BlueField-4, dentro de un dominio de seguridad aislado al que el agente no puede acceder ni modificar. Esta capa ofrece detección de amenazas, inspección de solicitudes y respuestas, control de agentes y contención en cuestión de milisegundos. NVIDIA Sentry es una capa opcional y, en los sistemas NVIDIA Vera Rubin, se sitúa en la ruta de acceso a los modelos.
La infraestructura NVIDIA Vera Rubin NVL72 ejecuta los modelos a los que recurren los agentes. Por tanto, la arquitectura ya decide si un agente puede actuar y supervisa lo que hace desde una infraestructura que el agente no puede manipular. F5 complementa estos controles con inspección de contenido diseñada para el tráfico de IA, ejercicios de red teaming y entrega de aplicaciones, sobre la base de nuestra colaboración con NVIDIA en materia de ciberseguridad para agentes.
Qué deciden OpenShell y NVIDIA Sentry
OpenShell sabe qué agente ha realizado una solicitud, con arreglo a qué política y si el destino y el método están permitidos. Para ofrecer una protección adicional, NVIDIA Sentry se ejecuta en NVIDIA BlueField-4 mediante NVIDIA DOCA para supervisar de forma independiente a los agentes, aplicar políticas directamente en el silicio y poner en cuarentena a los agentes en cuestión de milisegundos. Entre ambos, la decisión sobre si el agente puede actuar se toma fuera del control del propio agente. Ese es el objetivo del diseño.
Los permisos en tiempo de ejecución, la supervisión del comportamiento y la inspección de contenido específica para la IA proporcionan capas de protección complementarias. F5 incorpora la inspección de los prompts compatibles, las respuestas de los modelos y las llamadas a herramientas para detectar inyecciones de prompts, jailbreaks y la exposición de datos confidenciales, complementando la gobernanza en tiempo de ejecución de OpenShell, así como la supervisión continua del comportamiento y la aplicación de políticas con aislamiento por hardware de NVIDIA Sentry.
F5 inspecciona lo que el agente envía y recibe
F5 AI Guardrails inspecciona el tráfico compatible que se le dirige desde la ruta de aplicación de políticas, incluidas las instrucciones, las respuestas del modelo y las llamadas a herramientas transmitidas mediante protocolos controlados por OpenShell. Hace tres cosas con lo que detecta: bloquea las inyecciones de instrucciones, los intentos de eludir las restricciones y las llamadas a herramientas que incumplen las políticas; oculta los datos confidenciales antes de que salgan; y registra cada decisión en el historial de la sesión. Sus veredictos y datos de telemetría están disponibles para OpenShell y NVIDIA Sentry, de modo que una solicitud bloqueada puede dar lugar a una decisión en el ámbito del agente, incluso a su contención, conforme a la política del operador. Como la interceptación se produce en la ruta de aplicación de políticas y no dentro del contenedor del agente, este no puede desactivar Guardrails ni eludirlo mediante otra ruta. No hay ningún sidecar que se pueda desactivar.
F5 AI Red Team garantiza la eficacia de las medidas de protección. Ataca a los agentes y modelos a través de la misma vía que utilizaría un usuario, tanto en entornos privados como públicos, y sus hallazgos se incorporan a las políticas de protección, de modo que las defensas evolucionen al mismo ritmo que los agentes que controlan.
Gobernar un agente también implica demostrar qué hizo. El plano de control de F5 conserva el registro de la sesión: usuario, contexto del prompt, llamadas a herramientas y parámetros aprobados. OpenShell conserva sus decisiones de políticas. NVIDIA Sentry conserva el registro del sistema: acceso a archivos, llamadas al kernel y métricas de paquetes de la DPU. Al correlacionarlos, estos registros ofrecen una cronología única de lo que pretendía el modelo, lo que intentó el agente y lo que finalmente hizo, a partir de fuentes que el agente no podía manipular.
El F5 AI Security Platform control plane y el equipo de IA Red Team se ejecutan dentro de la fábrica, en el servidor. Los modelos de inferencia de producción a los que recurren los agentes se ejecutan en NVIDIA Vera Rubin NVL72, y el equipo de IA Red Team también utiliza recursos de GPU para realizar pruebas de seguridad. AI Guardrails solo requiere una CPU Arm, por lo que puede ejecutarse en NVIDIA Vera y BlueField-4. Las dos arquitecturas de referencia que aparecen a continuación muestran dónde se ubica cada componente.
Dos arquitecturas de referencia de F5 en NVIDIA OpenShell
Distribuido entre los tres niveles de NVIDIA: AI Guardrails en Vera, aplicado al entorno del agente dentro de OpenShell; AI Guardrails de nuevo en NVIDIA BlueField-4, fuera del radio de impacto del agente, junto con el plano de datos cuando la fábrica lo necesita; y el plano de control y AI Red Team en Vera Rubin NVL72, junto con los modelos. Esto da lugar a dos arquitecturas de referencia. Ambas se basan en la arquitectura de referencia NVIDIA OpenShell, utilizan la misma política y el mismo plano de control, y la diferencia radica en lo que se encuentra en la ruta del agente.
Arquitectura de referencia 1: F5 AI Guardrails con NVIDIA OpenShell y NVIDIA Sentry
Para el operador que ejecuta la pila de NVIDIA tal y como se ha diseñado. F5 AI Guardrails se ejecuta en dos ubicaciones bajo una única política: en NVIDIA Vera, aplicado al entorno del agente dentro de OpenShell, y en la DPU BlueField-4 integrada en NVIDIA Sentry, donde el agente no puede acceder. La primera detecta lo que envía el agente en el momento en que lo envía. La segunda es la que el agente no puede desactivar. Guardrails bloquea, oculta y audita el tráfico compatible que se dirige a él y, en BlueField, sus veredictos están disponibles para NVIDIA Sentry, lo que permite contener al agente de inmediato. No se requiere hardware adicional. Un NVIDIA Cloud Partner que estandarice el uso de la pila de NVIDIA obtiene inspección de contenido sin tener que cambiar nada más.
Para ofrecer una mayor escalabilidad y una distribución de nivel empresarial. F5 BIG-IP Next for Kubernetes se ejecuta en la DPU NVIDIA BlueField-4 junto con NVIDIA Sentry, o en la CPU del host, como plano de datos de la fábrica, y F5 AI Guardrails se ejecuta en su interior bajo la misma política. NVIDIA Sentry se encarga de la aplicación básica de las políticas; BIG-IP Next for Kubernetes transporta el tráfico. BIG-IP Next for Kubernetes enruta y equilibra la carga del tráfico de agentes y aplicaciones entre las instancias de modelos en Vera Rubin NVL72, integrándose con NVIDIA Dynamo. Aísla los entornos de cada inquilino, escala y protege las conexiones de Model Context Protocol (MCP), controla el uso de tokens por inquilino y ofrece al operador una vista unificada de todos los inquilinos y modelos. BIG-IP Next for Kubernetes también aplica las políticas de salida externa del operador al tráfico que enruta, como complemento de los controles de acceso en tiempo de ejecución de OpenShell y de la aplicación de políticas de infraestructura de NVIDIA Sentry.
La elección corresponde al operador. Puede incorporar AI Guardrails a OpenShell y NVIDIA Sentry, o añadir BIG-IP Next for Kubernetes con AI Guardrails integrado. La política y el plano de control son los mismos en ambos casos. La segunda opción añade aislamiento entre inquilinos, control del tráfico saliente y gestión del tráfico para toda la fábrica.
Una cifra, presentada por separado de la arquitectura de seguridad porque se midió de forma independiente. En las pruebas realizadas por The Tolly Group de BIG-IP Next for Kubernetes en DPU NVIDIA BlueField-3 (informe n.º 226104, publicado en marzo de 2026), BIG-IP Next for Kubernetes ofreció un rendimiento de tokens un 40 % superior al de la referencia evaluada, con la ruta de datos descargada de las CPU del host. Se trata de una medición del plano de datos de BIG-IP Next for Kubernetes de forma aislada. No incluye las funciones de inspección descritas aquí. En la IA, el rendimiento es economía.
Seguridad que permanece en la fábrica
En una implementación totalmente autoalojada, el procesamiento de seguridad y los registros de auditoría de F5 permanecen dentro del entorno del operador: el plano de control y Red Team en el servidor junto con los modelos, y la inspección en Vera y BlueField-4. El acceso a modelos y servicios externos sigue rigiéndose por la política empresarial; los destinos públicos aparecen en el diagrama por un motivo. Mantener todas las solicitudes y respuestas dentro de la fábrica de IA también requiere destinos alojados localmente y restricciones sobre el tráfico saliente externo. La arquitectura lo hace posible. La política del operador determina si se aplica y BIG-IP Next for Kubernetes se encarga de hacer cumplir dicha política de tráfico saliente.
La era de los agentes no ha creado tanto un nuevo requisito de seguridad como trasladado el punto de control más importante a la salida del agente, sobre una infraestructura que este no puede manipular. F5 lleva tres décadas trabajando precisamente en ese tipo de ruta. En la arquitectura de referencia NVIDIA OpenShell, es una ruta que el agente no puede eludir mediante la conversación.
Para obtener más información, le animo a visitar nuestras páginas web de F5 AI Security Platform, F5 AI Guardrails, F5 AI Red Team y F5 BIG-IP Next for Kubernetes.
Sobre el autor
Kunal Anand dirige la organización de productos de F5 como director de Producto. Es responsable de la visión, la estrategia y la ejecución de los productos, y garantiza el desarrollo de soluciones innovadoras que resuelven retos críticos y ofrecen experiencias excepcionales a los clientes. En su anterior cargo como director de Tecnología e IA, Kunal definió la estrategia y la visión tecnológica y de inteligencia artificial de la empresa. Antes de incorporarse a F5, Kunal desempeñó simultáneamente los cargos de director de Tecnología y director de Seguridad de la Información en Imperva. Su trayectoria en Imperva comenzó en 2018 con la adquisición de Prevoty, una startup de seguridad de aplicaciones que cofundó en 2013. Antes de incorporarse a Prevoty, fue director de Tecnología en BBC Worldwide. Kunal cuenta con una amplia trayectoria en innovación y conocimientos técnicos, y ha ocupado puestos de liderazgo al frente de equipos de seguridad, datos, tecnología e ingeniería en Gravity, MySpace y el Laboratorio de Propulsión a Chorro de la NASA. Kunal cuenta con más de 15 años de experiencia en inteligencia artificial y aprendizaje automático, que abarca desde el entrenamiento de modelos y el uso de algoritmos basados en IA para mejorar productos hasta el diseño y la implementación de arquitecturas de IA. Kunal es graduado en Ciencias de la Computación por Babson College.
Más artículos de Kunal AnandArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.