Cuatro formas de desplegar agentes de IA más seguros

El NVIDIA AI Red Team comparte cómo los controles de acceso, el sandboxing, las restricciones de red y la gestión de secretos pueden reducir los riesgos al desplegar agentes de IA a escala empresarial.

La creciente integración de agentes de IA en los flujos de trabajo de profesionales del conocimiento ofrece beneficios claros. Por ejemplo, pueden revisar reportes de errores, implementar y probar una solución, enviar un parche y notificar a un humano para su revisión. Al gestionar tareas rutinarias, los agentes tienen el potencial de generar grandes ganancias en productividad. Por otro lado, conectar un modelo de lenguaje (LLM) a herramientas en vivo y datos corporativos mediante un entorno agente implica el riesgo de convertir a un asistente útil en software privilegiado con una superficie de ataque mal comprendida.

En los últimos seis meses, el NVIDIA AI Red Team ha evaluado múltiples agentes de IA, desde herramientas simples de codificación interactiva hasta asistentes digitales autónomos siempre activos. Cuando un agente resultó ser explotable, generalmente observamos los mismos modos de falla clave, independientemente del framework o entorno utilizado, incluyendo:

  • Falta de control de acceso al agente.
  • Herramientas del agente que permiten la ejecución arbitraria de código.
  • Ausencia de controles de salida (egress) de red.
  • Secretos expuestos al agente en texto plano.

En esta publicación, examinamos estos modos de falla y describimos los controles que tienen éxito bajo presión adversaria. Aunque nuestros ejemplos se centran en agentes conectados a chats —la mayoría de los que encontramos en nuestras evaluaciones—, los patrones se generalizan a cualquier agente.

Implementar control de acceso al agente

El modo de falla más común en los despliegues de IA actuales es la falta de control de acceso al agente. Descubrimos múltiples agentes que poseían credenciales de usuarios individuales y eran accesibles para cualquier usuario autorizado dentro de la red interna. Si bien esto abría la puerta al uso indebido de las credenciales legítimas de los agentes, también nos permitió a menudo recopilar esas credenciales y usarlas fuera del contexto previsto del agente, como se muestra en ejemplos posteriores.

  • Utilice controles de acceso robustos como primera línea de defensa contra la actividad adversaria.
  • Restrinja cada agente a usuarios explícitamente autorizados; los agentes que no respondían a usuarios no autorizados fueron significativamente más difíciles de probar.
  • Haga coincidir los permisos del agente con los del usuario que lo invoca, siguiendo el principio de menor privilegio.

Limitar la ejecución de código

Muchos entornos exponen una shell Bash o una herramienta de ejecución de comandos. A menudo se utilizan por su generalidad, ya que soportan una amplia gama de tareas rutinarias sin requerir una herramienta separada por función. Sin embargo, cuando la salida del modelo controla la ejecución de comandos, un atacante que pueda influir en esa salida —a través de entrada directa o inyección indirecta de prompts— puede ejecutar comandos en el entorno. Esto les permite lograr resultados maliciosos como la exfiltración de datos o la persistencia de ejecución en el host.

Las mitigaciones comunes para este riesgo suelen involucrar el uso de agentes de revisión tipo "LLM-as-a-judge" para bloquear comandos dañinos, el uso de listas blancas (allowlists) para comandos aceptables, o simplemente confiar en que el modelo "sabe lo que hace". Todas brindan una defensa limitada contra la manipulación adversaria.

Muchas tareas comunes de línea de comandos soportan flujos de trabajo de desarrollo y desarrollo guiado por pruebas (TDD). Esto significa que generalmente requieren la capacidad de ejecutar comandos como pytest o npm install, lo que implica que los patrones de "LLM-as-a-judge" a menudo están predispuestos a aceptar la ejecución de estos comandos. Cuando son influenciados por entradas controladas por un atacante, estos comandos equivalen a la ejecución arbitraria de código.

En algunos casos, obtener ejecución remota de código (RCE) completa con una reverse shell es tan simple como pedirle al agente que escriba y ejecute un script de Python o instale un paquete remoto, como se muestra en nuestra publicación anterior sobre este tema.

Incluso sin una herramienta de línea de comandos, la capacidad de interactuar con el entorno donde corre el agente mediante herramientas de lectura y escritura de archivos a menudo expone caminos inesperados hacia la ejecución de código y la escalada de privilegios.

Un atacante que pueda escribir contenido en archivos del sistema como ~/.bashrc o ~/.zshrc, o archivos de configuración como ~/.gitconfig, hooks.json, MCP.json o archivos de habilidades, puede lograr la ejecución de código cuando un proceso diferente ejecute el archivo relevante, incluso si la ejecución de línea de comandos no está disponible directamente. Las ubicaciones y archivos donde los agentes pueden escribir deben estar estrictamente controlados y limitados a ubicaciones no ejecutables.

  • Trate la ejecución arbitraria de código como el riesgo de mayor impacto en un agente accesible.
  • Evite las herramientas de línea de comandos siempre que sea posible.
  • Bloquee las escrituras fuera de un espacio de trabajo no ejecutable a nivel de sistema operativo.
  • Si se requiere una herramienta de ejecución de comandos, utilice una lista blanca estricta de menor privilegio para comandos ejecutables y ejecute la herramienta en un entorno aislado con controles de salida de red robustos.
  • Tenga precaución al procesar argumentos o cadenas como nombres de archivos, títulos de documentos y otros datos externos a través de la línea de comandos. Asegúrese de que estén sanitizados y normalizados antes de su uso para prevenir problemas como el path traversal o la inyección de comandos.

Denegar la salida de red por defecto

Las conexiones de red salientes permiten la exfiltración de datos y la creación de conexiones directas, como reverse shells y SOCKS, a través de las cuales los atacantes pueden interactuar directamente con el entorno de ejecución del agente. Cuando se aplicaron controles de salida de red y se configuraron adecuadamente con el principio de menor privilegio, nuestras interacciones a través del proceso del agente se ralentizaron, haciendo que el impacto fuera menos confiable. Mantener el estado y la alineación del agente, navegar por los filtros de salida y reiniciar las sesiones después de que el agente comenzara a rechazar solicitudes, aumentó significativamente la carga operativa.

  • Aplique una política de denegación de salida de red por defecto, con una lista blanca de endpoints limitada al conjunto mínimo requerido para las tareas que el agente debe realizar.
  • Haga cumplir estas restricciones en cada límite de red que toque el agente, utilizando controles ambientales que no sean accesibles para el agente.

Mantener los secretos fuera del alcance del agente

Los agentes a menudo requieren acceso a secretos para realizar su función: tokens de plataforma, claves de API, tokens de acceso a sistemas de control de versiones (VCS) y, en algunos casos, tokens de actualización OAuth. Aunque el consejo de seguridad convencional sugiere inyectar secretos como variables de entorno en la memoria para evitar que se escriban en el disco, esto es razonable solo cuando solo su código se ejecuta en un contenedor.

Cuando un agente con capacidad de ejecución de comandos comparte ese entorno, el riesgo de que el agente filtre accidentalmente o sea engañado para revelar estos secretos en texto plano es extremadamente alto. Para mitigar esto, los secretos no deben estar presentes en el entorno del agente. En su lugar, utilice servicios de gestión de secretos que requieran una autenticación fuera de banda o una interacción humana explícita para cada acceso.

Vía NVIDIA Developer.