NVIDIA está utilizando una nueva publicación de su AI Red Team para hacer un punto más amplio sobre el despliegue de IA empresarial: si las empresas quieren poner agentes de IA frente a herramientas reales, bases de código y datos internos, necesitan controles de infraestructura fuera del propio modelo.

En una guía publicada en el NVIDIA Developer Blog, el equipo dice que encontró repetidamente los mismos patrones explotables al evaluar agentes empresariales durante los últimos seis meses. Según NVIDIA, los problemas recurrentes fueron control de acceso débil, ejecución de comandos insegura, ausencia de restricciones de salida de red y secretos en texto plano dentro de entornos de agentes. Lo importante no es que se trate de conceptos de seguridad totalmente nuevos, sino que NVIDIA sostiene que las actuales pilas de agentes siguen fallando con suficiente frecuencia en estos puntos como para que las protecciones basadas en prompts y los modelos de revisión no deban considerarse la principal línea de defensa.

La advertencia de NVIDIA trata sobre la arquitectura del agente, no sobre el ajuste de prompts

La publicación, titulada “Four Ways to Deploy More Secure AI Agents”, proviene del NVIDIA AI Red Team y se centra en lo que ocurre cuando un modelo de lenguaje grande se conecta a sistemas en vivo mediante un arnés de agente. NVIDIA enmarca el problema en términos empresariales prácticos: un compañero digital que puede revisar un informe de error, aplicar una corrección, ejecutar pruebas y enviar un parche puede impulsar la productividad, pero la misma configuración también puede crear software privilegiado con una superficie de ataque amplia y poco comprendida.

Ese enfoque importa porque el consejo va dirigido menos a investigadores de modelos que a equipos que construyen sistemas de producción alrededor de agentes de IA. NVIDIA dice que los modos de fallo observados aparecieron en varios tipos de agentes, desde asistentes interactivos de programación hasta asistentes autónomos siempre activos, y no se limitaron a un solo framework.

El argumento principal de la empresa es que las defensas dentro del plano de control del modelo no son lo bastante fiables bajo presión adversaria. Según la publicación, las protecciones basadas en prompts y los patrones de “LLM-as-a-judge” resultaron consistentemente vulnerables a la ingeniería social, a la manipulación gradual tipo “frog-boiling” y a ataques ocultos dentro de flujos de trabajo aparentemente legítimos. La postura de NVIDIA es que se requieren controles deterministas aplicados fuera del modelo.

Los cuatro controles que NVIDIA dice que las empresas deben priorizar

Primero, NVIDIA dice que los controles de acceso deben considerarse la primera capa de defensa. En sus evaluaciones, el equipo encontró agentes que usaban las credenciales de usuarios individuales pero eran accesibles para cualquier usuario autorizado en una red interna. Según NVIDIA, eso no solo permitía el uso indebido de los permisos legítimos del agente, sino que en algunos casos también creaba vías para recopilar credenciales y usarlas fuera del contexto previsto del agente. La recomendación práctica es clara: restringir cada agente a usuarios explícitamente aprobados y alinear los permisos del agente con el usuario que lo invoca bajo reglas de mínimo privilegio.

Segundo, NVIDIA advierte que la ejecución de comandos sigue siendo el riesgo de mayor impacto en los agentes accesibles. Muchos frameworks de agentes exponen una shell porque es flexible y reduce la necesidad de herramientas especializadas. Pero si la salida del modelo puede desencadenar la ejecución de comandos, entonces la inyección de prompts o la entrada maliciosa del usuario pueden convertir comandos normales de desarrollador en una vía para la ejecución arbitraria de código. NVIDIA señala que comandos comunes en flujos de trabajo de software, incluida la instalación de paquetes y la ejecución de pruebas, pueden parecer lo bastante benignos como para pasar un modelo revisor y aun así permitir una intrusión.

La empresa recomienda entornos de ejecución aislados como Docker o NVIDIA OpenShell, restricciones a nivel de sistema operativo que impidan escrituras fuera de espacios de trabajo no ejecutables y listas de अनुमति muy estrechas para comandos ejecutables cuando el acceso a la línea de comandos sea inevitable. También destaca un riesgo más sutil: incluso sin una shell, las herramientas de lectura y escritura de archivos pueden permitir escalada de privilegios si un agente puede modificar archivos de inicio, archivos de configuración u otras ubicaciones que luego ejecuta otro proceso.

Tercero, NVIDIA dice que la conectividad saliente debe bloquearse con políticas de salida de red de denegación por defecto. Según el Red Team, las conexiones salientes sin restricciones simplifican la exfiltración de datos y permiten shells inversas u otro acceso directo del operador al entorno de ejecución del agente. NVIDIA informa que cuando los controles de salida se aplicaron correctamente, los ataques se volvieron más lentos, menos fiables y más difíciles de mantener porque las interacciones tenían que seguir pasando por el agente en lugar de por un canal externo directo. Para los desarrolladores, eso se traduce en una regla concreta de despliegue: permitir solo los puntos finales externos mínimos necesarios para la tarea del agente.

Cuarto, la publicación dice que los secretos persistentes deben mantenerse fuera de los entornos de agentes siempre que sea posible. La evidencia extraída en la publicación de NVIDIA apunta a la exposición de secretos en texto plano como un modo de fallo recurrente. Su recomendación más amplia es una gestión estricta de secretos, una validación cuidadosa de las fuentes de paquetes y un control rígido de los permisos de las herramientas. El hilo conductor es reducir lo que un atacante puede robar o reutilizar si un agente es manipulado.

Por qué esto importa ahora para las herramientas de programación y la IA empresarial

Las recomendaciones de NVIDIA llegan a medida que más empresas pasan de pilotos de chatbot a agentes que usan herramientas dentro de flujos de trabajo de ingeniería, TI, soporte y back office. La brecha entre un asistente de chat y un agente operativo es grande: una vez que el sistema puede ejecutar scripts, instalar dependencias, abrir tickets, consultar sistemas internos o tocar repositorios, el perfil de riesgo empieza a parecerse tanto a la seguridad tradicional del software y al endurecimiento de endpoints como a la seguridad del modelo.

Eso hace que esta guía sea especialmente relevante para equipos que despliegan un asistente de programación u otras herramientas de flujo de trabajo autónomas. Un agente centrado en código a menudo necesita ejecutar pruebas, inspeccionar archivos, instalar paquetes y conectarse a sistemas de control de versiones. Esas son precisamente las capacidades que NVIDIA dice que pueden volverse inseguras si los controles de seguridad dependen principalmente del juicio del modelo. La mención de archivos como la configuración de git y la configuración de model context protocol también apunta al ecosistema emergente de herramientas de agentes, donde las integraciones flexibles pueden crear silenciosamente nuevas vías de persistencia.

Para los compradores de IA empresarial, la conclusión práctica es que las demos de proveedores que muestran una alta tasa de finalización de tareas no bastan. Los compradores deben preguntar dónde ocurre la ejecución, si el entorno de ejecución está aislado, qué destinos de red están permitidos, cómo se propaga la identidad del usuario y si alguna credencial de larga duración llega a residir dentro del entorno del agente. Esas preguntas afectan tanto a la fiabilidad y la gobernanza como a la seguridad pura.

Evidencia, afirmaciones y lo que sigue sin verificarse

Esta historia se basa casi por completo en la propia información de NVIDIA a través del NVIDIA Developer Blog, con una segunda fuente que simplemente refleja el mismo elemento en un feed de Google News. Eso significa que los hallazgos centrales deben leerse como observaciones de red team reportadas por el proveedor, no como mediciones independientes de la industria.

Aun así, NVIDIA ofrece una especificidad útil. Dice que su AI Red Team evaluó múltiples agentes durante los últimos seis meses y encontró patrones explotables recurrentes en varios frameworks y arneses. También da ejemplos concretos de comportamientos de riesgo, incluido el uso de una shell para ejecutar instalaciones de paquetes o scripts, la escritura en archivos de inicio de shell y el aprovechamiento del tráfico saliente sin restricciones para exfiltración o acceso remoto.

Sin embargo, la publicación no cuantifica cuántos agentes fueron probados, qué proveedores o pilas de código abierto estuvieron involucrados, con qué frecuencia apareció cada modo de fallo ni cuántos incidentes ocurrieron en producción. Tampoco presenta datos comparativos de benchmarks que muestren la eficacia de un conjunto de controles frente a otro. Como resultado, la guía se entiende mejor como consejo arquitectónico práctico de un Red Team con experiencia de prueba directa, y no como una encuesta integral del mercado.

La crítica a los filtros de prompts y a los esquemas LLM-as-a-judge también es la evaluación de NVIDIA. Muchos equipos de seguridad probablemente estarán de acuerdo con la dirección general, pero el artículo no incluye resultados de pruebas validados externamente en la evidencia proporcionada. Eso no hace que la advertencia sea menos relevante; significa que los lectores deben separar la lección general de cualquier suposición de que todos los productos de agentes fallan de la misma manera.

Implicaciones para creadores y equipos de plataforma

Para los creadores, el cambio más claro es de la seguridad a nivel de aplicación hacia la seguridad a nivel de sistema. Si un agente de IA puede tocar recursos cercanos a producción, entonces el diseño del despliegue empieza a importar más que una buena ingeniería de prompts. Los límites del sandbox, la propagación de identidad, las listas de permitidos para endpoints y el aislamiento de secretos se convierten en decisiones centrales del producto.

Eso tiene implicaciones de coste y de flujo de trabajo. El aislamiento puede ralentizar la ejecución o complicar los entornos de desarrollo. Las políticas de salida de denegación por defecto obligan a los equipos a mapear las dependencias con detalle. La correspondencia de permisos por usuario puede forzar una integración más profunda con los sistemas corporativos de identidad. Pero esas restricciones pueden ser necesarias si las empresas quieren que los agentes de IA pasen de experimentos a flujos de trabajo empresariales aprobados.

La guía también sugiere una definición más madura de automatización del lugar de trabajo. En lugar de preguntarse si un agente puede completar un flujo de trabajo de extremo a extremo, los equipos quizá deban preguntar si puede hacerlo dentro de un radio de impacto estrictamente limitado. Eso influirá en las decisiones de arquitectura en todas las plataformas de IA empresarial, incluidas las herramientas que se exponen, dónde se ejecutan y cuánta autonomía es aceptable.

Qué observar a continuación

Una señal útil será si los principales frameworks de agentes y plataformas empresariales empiezan a incluir estos controles por defecto en lugar de como pasos opcionales de endurecimiento. En particular, los desarrolladores deberían observar integraciones de aislamiento más robustas, modelos de identidad y autorización más granulares, políticas de salida de red más fáciles de gestionar y diseños de secretos que eviten credenciales persistentes.

Una segunda señal es si más proveedores publican datos de pruebas adversarias en lugar de afirmaciones generales de seguridad. La publicación de NVIDIA plantea preocupaciones creíbles, pero el mercado aún carece de evidencia coherente de terceros sobre cuán comunes son estos modos de fallo de los agentes entre productos.

Por último, será importante seguir si los patrones de seguridad por defecto pasan a formar parte de la adquisición de agentes de IA, especialmente en sectores regulados. Si los compradores empiezan a exigir pruebas de aislamiento y aplicación de mínimo privilegio, la arquitectura de seguridad podría convertirse en un diferenciador competitivo en lugar de una lista de verificación de back office.

Perspectiva de Creati.ai

El mensaje de NVIDIA trata menos de un exploit nuevo y más de una corrección del mercado. La primera ola de agentes de IA a menudo se juzgó por la autonomía y la conveniencia. Esta guía sostiene que las empresas deberían juzgarlos como operadores de software con privilegios. Ese es un cambio saludable para la categoría.

Para fundadores y equipos de producto, la lección estratégica es sencilla: los agentes de IA ganadores en la IA empresarial no serán solo los que completen tareas, sino los que puedan demostrar dónde se ejecutan, a qué pueden acceder y qué no pueden filtrar. La calidad del modelo sigue importando, pero la arquitectura de despliegue se está convirtiendo rápidamente en la verdadera capa de confianza para los agentes de IA, la automatización del lugar de trabajo y cualquier asistente de programación serio.