El agente escapó. ¿Quién dejó la puerta abierta?

8 min de lectura

El modelo no venía con una shell

Se describe a un agente de IA como si hubiera llegado al trabajo con un portátil y ambiciones propias. Después escanea una red, encuentra una credencial y accede a un sistema que nadie quería que tocara. La historia suena a una nueva especie de intruso.

Las acciones son reales. Que el modelo trajera sus propias herramientas es una ficción.

En evaluaciones recientes de ciberseguridad, varios modelos accedieron a sistemas reales fuera de los ejercicios asignados. Anthropic informó de que un entorno de evaluación mal configurado había dejado abierto el acceso a internet. OpenAI informó de que unos modelos de investigación con medidas de protección reducidas aprovecharon debilidades de una infraestructura compartida y accedieron a sistemas de Hugging Face. Son fallos graves. Ninguno de los informes describe un archivo de pesos que decidiera instalarse en un ordenador y conectarse a internet.

Los pesos necesitan un entorno de ejecución

Los pesos de un modelo de lenguaje son números almacenados en archivos. Recogen lo que produjo el entrenamiento. Por sí solos no hacen nada. Un entorno de ejecución para inferencia los carga en memoria, acepta entradas, realiza cálculos y produce salidas. Apaga ese entorno y el modelo no se queda allí pensando en sus planes para mañana.

Esto se ve mejor con un modelo de pesos abiertos. Puedes ejecutarlo mediante llama.cpp, vLLM u Ollama. Estos programas pueden ofrecer una interfaz HTTP para que otra aplicación envíe una solicitud. Un programa local también puede llamar directamente a una biblioteca de inferencia. La interfaz de red es una decisión de despliegue, no una propiedad oculta en los pesos.

Un modelo alojado por un proveedor sigue la misma separación básica. Tu aplicación envía una solicitud al entorno de ejecución del proveedor y recibe una respuesta. El proveedor puede suministrar algunas herramientas como parte de su plataforma. Tu aplicación puede aportar otras. En cualquier caso, el modelo no obtiene acceso al sistema de archivos de tu empresa, a la base de datos de producción ni a una shell por el mero hecho de que alguien le haya hecho una pregunta.

Alguien proporciona las herramientas

Supongamos que se pide a un asistente de operaciones que resuma los trabajos de copia de seguridad que han fallado. Para obtener los registros, alguien le da una herramienta de ejecución de comandos de propósito general en una máquina de diagnóstico. Esa máquina tiene un cliente SSH y una cuenta de mantenimiento autorizada a conectarse a través de un servidor de salto: una máquina intermedia que los administradores utilizan para llegar a sistemas privados. Por esa vía, la cuenta puede acceder a un servidor de bases de datos que no tiene dirección pública.

Una conexión SSH puede ejecutar un comando en una máquina remota o reenviar una conexión de red a través de las máquinas de su recorrido. Por tanto, una solicitud a la herramienta de comandos podría llegar más allá de la máquina de diagnóstico, quizá hasta un servicio que el asistente nunca debía inspeccionar. El modelo no ha aprendido a atravesar un cortafuegos con el pensamiento. La aplicación ejecuta el comando solicitado; el cliente SSH instalado, las credenciales aceptadas y la ruta de red permitida hacen posible cada salto.

El flujo documentado de llamadas a funciones lo deja claro: la aplicación que hace la solicitud ofrece herramientas, el modelo devuelve una propuesta de llamada, el software la ejecuta y el resultado vuelve al modelo. Los entornos de ejecución para modelos de pesos abiertos pueden seguir el mismo patrón; algunos también permiten configurar conexiones directas a servidores de herramientas. El software que ejecuta las llamadas puede estar en una aplicación, en la plataforma de un proveedor o en un entorno de ejecución local. Sigue siendo software instalado y configurado por personas.

Ahí hay que buscar el límite de los permisos. ¿Qué herramienta se ofreció? ¿Con qué cuenta se ejecuta? ¿Qué credenciales utiliza? ¿A qué máquinas puede llegar? Un prompt que pide al modelo que tenga cuidado es una indicación. Una herramienta que no puede borrar registros impone un límite.

La magia depende del público

He trabajado repetidamente en grandes organizaciones con profesionales considerados expertos técnicos que no podían configurar su propio ordenador de trabajo ni empezar un proyecto sin ayuda. Otros instalaban sus herramientas, resolvían problemas de dependencias y mantenían sus scripts en funcionamiento. Sin ese apoyo, se quedaban bloqueados. Pero seguían llevando la etiqueta de «experto». Es un problema grave de competencia profesional que las grandes organizaciones ocultan detrás de los cargos y las fronteras entre departamentos.

Un desarrollador independiente a menudo tiene que ser todo un departamento de TI: configurar el ordenador, construir la aplicación, desplegarla y averiguar por qué falla una conexión. En una gran empresa, la misma cadena de trabajo pasa por varios equipos. Cada traspaso permite que alguien deje de preguntarse qué ocurre después. La organización aporta una amplitud de conocimientos que una persona puede pasar toda su carrera sin adquirir. Siempre hay otro que entiende la pieza que falta. Con el tiempo, depender de lo que saben otros acaba pasando por conocimientos propios.

Por eso importa la distinción entre ciencia de datos y desarrollo de software cuando interpretamos el comportamiento de la IA. Saber entrenar o evaluar un modelo no cualifica a nadie para explicar una intrusión en una red. Un veterano de Unix que observa nuestro ejemplo de SSH reconoce comandos que podría haber escrito él mismo. El observador que siempre delegó ese trabajo en otro equipo carece de ese punto de referencia. El veterano ve una secuencia conocida. El observador ve una máquina haciendo algo que no sabe explicar.

El problema se vuelve peligroso cuando ese observador habla con la autoridad de un experto. Se atribuyen al modelo capacidades que proporcionó su entorno. Una laguna en los conocimientos del observador se convierte en una afirmación sobre la autonomía del modelo, y se pide al público que acepte la conclusión. Es un diagnóstico equivocado con consecuencias reales: la atención se aleja del software que ejecuta los comandos y de las personas que le concedieron acceso. Antes de aceptar la afirmación, pregunta qué podría haber hecho una persona experimentada con la misma shell, las mismas credenciales y el mismo acceso a la red.

El viejo problema de las redes, más rápido

Pon un servidor en internet y da por hecho que alguien buscará vulnerabilidades en él. Eso ya ocurría antes de que se pudiera pedir a un modelo que hiciera la búsqueda. CISA recomienda identificar los activos expuestos, eliminar la exposición innecesaria, aplicar parches a lo que quede y supervisarlo. Son tareas habituales de seguridad, no inventos de emergencia para la era de la IA.

Un agente capaz puede cambiar el ritmo. Puede recurrir a una utilidad de Unix poco conocida, combinarla con otra familiar, examinar el resultado, probar otra ruta y seguir. Un atacante humano puede hacer lo mismo. El agente puede hacerlo más veces sin cansarse ni tener que buscar en viejos mensajes de foros. Eso convierte un sistema mal configurado en un problema más urgente. No hace que la ruta de red aparezca de la nada.

Mi regla es sencilla: el código que no está instalado no puede explotarse en esa máquina. Un servicio innecesario deja de ser un punto de ataque allí en cuanto se elimina. Menos paquetes, menos puntos de acceso expuestos y menos herramientas con capacidades amplias dejan menos lugares donde pueda esconderse un error. Eso no garantiza que un sistema pequeño sea seguro. El servicio que queda todavía puede tener una vulnerabilidad. Me niego a pagar por un riesgo que no sirve para nada.

La misma regla se aplica al repertorio de herramientas de un agente. Un asistente que resume los resultados de las copias de seguridad necesita registros concretos, no una shell con una ruta SSH por la red de operaciones. Dale una operación de lectura limitada y haz que el servicio que la implementa imponga qué registros puede ver. No conviertas «resumir» en acceso a todas las máquinas a las que llega una cuenta de mantenimiento.

Una herramienta puede funcionar perfectamente y ser peligrosa

No todos los fallos requieren una vulnerabilidad de software. Un atacante podría introducir instrucciones en una entrada de registro que el asistente está a punto de leer, instándolo a «arreglar» el problema de las copias de seguridad en otra máquina. Si la herramienta de comandos ya dispone de ese acceso SSH, una orden dañina puede ejecutarse aunque todos los servidores estén al día con sus parches. OWASP lo llama «Excessive Agency»: demasiadas funciones, permisos o autonomía para la tarea.

Por eso la seguridad de la red y el control de acceso deben tratarse juntas. Un cortafuegos no resuelve un exceso de permisos en una herramienta. Una instrucción al modelo no sustituye la autorización en el servicio que recibe la llamada. Impón la restricción donde se ejecuta la acción, según la identidad y los permisos de la persona o la tarea para la que trabaja la herramienta.

Inspecciona el sistema que has construido

Elimina servicios innecesarios, cierra los puertos que no necesitan estar expuestos, limita los permisos de las herramientas y revoca las credenciales que la tarea no requiere. Quienes despliegan el agente pueden tomar esas decisiones ahora.

La pregunta útil para un CTO y para cualquiera a quien se le pida confiar en un producto de IA es concreta: ¿Qué software ejecuta el modelo, qué inicia el bucle, qué herramientas están conectadas y a qué puede acceder realmente la cuenta que hay detrás de cada una? El modelo puede ser rápido e ingenioso. Las puertas siguen formando parte de un sistema informático que alguien construyó.