Las empresas rusas pasan a una seguridad sistemática de los agentes de IA en lugar de revisiones puntuales

La seguridad de los agentes de IA ya no puede resolverse revisando a mano cada herramienta nueva: los LLM y los agentes de programación tienen acceso al código, al shell, a git, a la red y a los secretos, así que hay que tratarlos como servicios corrientes con permisos muy amplios. Cuando estos sistemas se integran en el desarrollo, las pruebas y la operación, la cuestión no es si se puede confiar en ellos, sino qué restricciones, políticas y observabilidad ha establecido la empresa a su alrededor.

En los últimos dos o tres años, las empresas rusas han dejado de ver la IA generativa como un experimento curioso y han empezado a integrarla en sus procesos diarios. Ya no se trata solo de chats de soporte o borradores de texto: los modelos ayudan a los desarrolladores, participan en revisiones de código, generan código de infraestructura, trabajan con configuraciones y cada vez más forman parte de productos reales. Las recomendaciones internacionales apuntan en la misma dirección: NIST propone considerar la IA generativa un elemento de infraestructura crítica, y ENISA analiza por separado su papel en DevSecOps y la automatización de la ingeniería.

La lógica es sencilla: en cuanto un modelo accede a datos, herramientas y a la posibilidad de ejecutar acciones, deja de ser solo una interfaz y pasa a ser un nodo operativo del sistema.

Con ello cambia también el perfil de amenazas. A los problemas clásicos, como errores de autorización e inyecciones, se suman los riesgos que describe el OWASP Top 10 for LLM Applications: prompt injection, tratamiento inseguro de la respuesta del modelo, fugas de secretos a través del contexto, permisos excesivos de los agentes y diseño inseguro de plugins o tools.

El estudio de varios agentes de IA mostró un patrón repetido: casi todos tienen acceso al shell mediante comandos locales, Docker o SSH, muchos pueden trabajar directamente con git, crear ramas y commits, y en la configuración aparecen con frecuencia modos peligrosos del tipo bypassPermissions. En ese esquema basta una inyección exitosa o una respuesta del modelo tratada de forma insegura para que el agente ejecute un comando arbitrario, extraiga tokens y claves, modifique el código sin que nadie lo note o empiece a moverse por los servicios internos y la cadena CI/CD.

El problema es que la revisión manual de cada agente nuevo escala mal. Aunque el desarrollador de la herramienta ya haya añadido un sandbox por defecto, un módulo para gestionar secretos, la ocultación de datos sensibles en los registros y documentación para un arranque seguro, el equipo de seguridad tiene que analizar casi desde cero hasta qué punto puede fiarse de esos ajustes.

Por eso el autor propone quitar del debate la propia palabra IA y ver al agente como un servicio de caja negra con amplios permisos. Si ese servicio puede leer y modificar archivos, ejecutar comandos, llamar a API externas y subir código, hay que evaluarlo con los dominios habituales: quién inicia exactamente las acciones, qué derechos recibe el agente, dónde se ejecuta, a qué directorios, redes y herramientas accede, qué se registra y con qué rapidez verá el equipo una anomalía.

De ahí se deriva un perfil de protección muy práctico. Primero, reglas claras de autorización y de mínimos privilegios: qué repositorio ve el agente, si puede escribir o solo leer, y si se le permite ejecutar pruebas, migraciones o comandos de shell. Segundo, aislamiento: un contenedor, un runner independiente o un entorno dedicado con mounts estrictamente limitados y sin acceso innecesario a docker.

sock, la API de Kubernetes ni los secretos de producción. Tercero, control de red con listas blancas de dominios y una política clara de solicitudes externas. Y, por último, son obligatorios el análisis estático del código y de las configuraciones, las pruebas dinámicas de laboratorio con archivos honeypot y secretos falsos, y la auditoría y las alertas ante un comportamiento atípico del agente.

Este enfoque no prohíbe adoptar la IA, sino que la convierte de una herramienta de moda y poco predecible en un componente gestionable de la infraestructura de ingeniería.

Qué significa en la práctica: la seguridad no debe frenar la adopción de agentes de programación, pero tampoco se debe confiar en ellos por defecto. Si, junto con los equipos de desarrollo, se define de antemano un perfil único de requisitos, se comprueban los riesgos habituales en un entorno aislado y se fijan las políticas de acceso, la llegada de una nueva herramienta de IA dejará de convertirse cada vez en una peritación urgente y costosa. Para el negocio, esto supone adoptar antes una automatización útil sin riesgo innecesario para el código, los secretos y la infraestructura interna.