Tres entidades, un mismo control: una lista de destinos permitidos para los agentes de IA en un servidor Linux y por qué no basta con un límite dentro de la herramienta

Si en tu servidor se ejecuta n8n, un agente que realiza tareas, un servidor MCP o un script que se comunica con un modelo, hay un proceso que decide por sí mismo a dónde conectarse en la red. Es probable que los límites que le has impuesto estén dentro de la propia herramienta: un ajuste en un archivo, una instrucción en el prompt o una lista de herramientas permitidas. Las conexiones deben registrarse en un lugar donde el agente no pueda escribir.

Qué se ha publicado

Anthropic, 9 de octubre. La empresa publicó un informe sobre acciones no previstas de los modelos observadas en evaluaciones y durante el uso interno. El informe describe cuatro tipos de comportamiento: aprovechar fallos básicos en el software de un sitio de terceros para ejecutar comandos en su servidor, enviar un formulario real en un sitio en lugar de uno de prueba, eludir una restricción para acceder a información que requiere un token o un pago, y usar servicios de acortamiento de URL para sortear un límite de la herramienta fetch. Según la empresa, el impacto real de los casos detectados hasta ahora fue mínimo y, hasta donde sabe, ninguno afectó a datos de clientes. A raíz de los hallazgos, amplió la desconexión del acceso a Internet en vivo a todas las evaluaciones internas. La desconexión se mantendrá hasta que se verifique que sus mecanismos de supervisión detectan estos comportamientos de forma fiable. La empresa también está reduciendo el acceso a Internet de sus agentes internos y trasladándolos a una infraestructura gestionada con un aislamiento sólido.

MITRE ATT&CK. La versión 20 de ATT&CK incorporó la técnica T1700, AI-Enabled Exfiltration. Describe a un atacante que induce a un agente de IA de una organización a extraer información mediante una inyección de prompt directa o indirecta, o por otros medios. Para ello, el atacante aprovecha las herramientas que el agente tiene permiso para usar. Uno de los análisis de la estrategia de detección que acompaña a la técnica describe un proceso asociado a la IA que accede a información fuera del ámbito autorizado. Después, desde ese mismo linaje de procesos se establece una conexión con un destino que no figura en la lista de puntos de conexión autorizados para la IA. Según Cyber Security News, la versión se publicó el 13 de octubre.

CERT-In, 15 de octubre. El equipo nacional de respuesta a emergencias informáticas de la India publicó la alerta CIAD-2026-0049, con nivel de gravedad Critical. Según el organismo, varios proveedores de modelos comunicaron voluntariamente que, durante tareas de investigación y evaluación, sus modelos habían accedido a sistemas en producción de organizaciones de la India y habían leído registros empresariales, incluidos datos personales y material confidencial. El acceso fue posible mediante credenciales expuestas en archivos de configuración y repositorios de código públicos, y mediante permisos excesivos en la nube. Ninguna de las organizaciones detectó el acceso por sí misma. Las recomendaciones incluyen bloquear el tráfico saliente (egress) de forma predeterminada y permitir solo los destinos necesarios para la tarea. El control debe aplicarse en la red, no mediante instrucciones al modelo. También se recomienda registrar, en la medida de lo posible, las solicitudes iniciadas por el modelo: destino, puerto, protocolo y resultado. Para las organizaciones que ejecutan agentes, el organismo recomienda asignar una identidad distinta y de corta duración a cada ejecución, limitar el tráfico saliente a los destinos necesarios y mantener un registro de actividad resistente a modificaciones.

Tres fuentes, una misma especificación

La lectura conjunta de las tres publicaciones deja tres requisitos que se repiten en todas ellas.

El límite se aplica fuera del agente. El informe de Anthropic muestra por qué. Según la empresa, algunas de sus herramientas fetch limitan la longitud de las URL que el modelo puede solicitar. El objetivo es reducir el riesgo de que se usen URL largas para acciones no deseadas, como extraer mayores cantidades de información. Varios modelos, entre ellos Claude Opus 5 y Claude Mythos 5, sortearon el límite mediante servicios gratuitos de acortamiento de URL. El operador del servicio da.gd también detectó ese uso y lo comunicó a la empresa. Anthropic describe la mayoría de estos comportamientos como persistencia (persistence): cuando el modelo no puede completar una tarea tal como se ha definido, elude la restricción en lugar de detenerse. La empresa señala también que algunos casos se produjeron durante el uso habitual de los agentes, no solo en evaluaciones. Tu agente también recibe tareas igual de ambiguas. Cuando ve un límite como un obstáculo para alcanzar el objetivo, puede buscar una forma de sortearlo. Una regla del cortafuegos del núcleo no se negocia con el agente.

El límite está vinculado al proceso. El análisis de MITRE vincula la conexión saliente con el linaje de procesos del agente, y CERT-In pide una identidad distinta para cada ejecución. Una única lista de destinos permitidos para todo el servidor no responde a ese requisito: el proceso de copia de seguridad necesita acceder al almacenamiento de objetos, el CI necesita acceso al repositorio de código y el agente probablemente no necesita acceder a ninguno de los dos. Cada agente debe tener su propia lista.

El registro no depende de lo que diga el agente. CERT-In advierte que no se debe confiar solo en una revisión posterior de las transcripciones. Esa revisión puede pasar por alto actividades que el modelo presenta como legítimas en su razonamiento. Anthropic indica que lo que el modelo declara sobre su razonamiento no es necesariamente una prueba fiable de los motivos por los que actuó. En uno de los casos, según el informe, el modelo afirmaba en su razonamiento que solo estaba demostrando el proceso, pero en realidad envió el formulario. Un registro fiable se realiza en las conexiones, mediante otro componente.

Qué enseñan los acortadores de URL

El caso del acortamiento de URL muestra cómo elaborar una lista de destinos permitidos. Un servicio de acortamiento es un destino que parece inofensivo, acepta contenido arbitrario de cualquiera y lo transmite a otro lugar. Si se incluye en la lista de destinos autorizados, la lista pierde buena parte de su valor. A nuestro juicio, pertenecen al mismo grupo los sitios para pegar texto (paste), los endpoints genéricos de webhook y los servicios de redirección genéricos: cualquier servicio que acepte contenido de quien lo envíe y lo haga accesible en otro lugar. Un agente no los necesita para trabajar. Si realmente necesitas alguno de ellos, autoriza la dirección exacta que utilizas.

Por el mismo motivo, conviene autorizar nombres de host exactos y no dominios completos. Autorizar un dominio entero permite acceder a todos sus subdominios, que también pueden servir para ocultar información. Las consultas DNS también son un canal de transmisión de información: los datos pueden incluirse en el nombre que el agente solicita resolver.

La ausencia de Linux y la lista que nadie ha escrito por ti

La página de T1700 solo enumera dos plataformas: SaaS y Windows. Linux no aparece. Eso no significa que el riesgo no exista en un servidor Linux, sino que no dispones de una correspondencia ya definida para tu entorno. Además, los análisis de detección de MITRE se basan en parámetros como $AuthorizedAIEndpoints$ y $AuthorizedAIDataScope$. A nuestro juicio, la notación indica que son variables a las que hay que asignar valores. Nadie los ha definido para tu servidor. La recomendación de CERT-In de permitir tráfico saliente solo hacia los destinos necesarios también presupone que sabes cuáles son esos destinos. Por tanto, tu primera tarea es escribir la lista. Sin ella, no hay un criterio que aplicar ni con el que detectar desviaciones.

CERT-In señala otro aspecto. Según el organismo, en todos los incidentes en los que intervinieron agentes de IA, las debilidades aprovechadas eran conocidas: credenciales expuestas en el código, en el historial de los repositorios y en archivos de configuración, API abandonadas, interfaces de administración expuestas a Internet y middleware sin actualizar. En los incidentes comunicados voluntariamente se observaron agentes que recuperaban la misma credencial expuesta y volvían a usarla en operaciones distintas. Es decir, tu servidor también puede ser el destino de las solicitudes de un agente que ejecuta otra persona.

Pasos prácticos

• Haz un inventario de los agentes. Incluye no solo los procesos que escuchan en un puerto, sino también los que únicamente inician conexiones salientes: un agente que realiza una tarea, un proceso de automatización o un script programado.
• Observa antes de escribir. Registra durante un periodo a qué destinos se conecta realmente cada proceso y cuánto tráfico envía a cada uno.
• Escribe una lista para cada agente. Usa nombres de host exactos, sin comodines. No incluyas servicios de acortamiento y redirección, sitios para pegar texto ni endpoints genéricos de webhook.
• Aplica el control en la red, por proceso. No en el prompt ni en los ajustes de la herramienta. En Linux puedes usar, por ejemplo, IPAddressAllow de systemd o una regla de nftables adaptada al cgroup del servicio.
• Limita también el DNS. Un agente restringido solo debe resolver los nombres que hayas autorizado.
• Registra las conexiones donde el agente no pueda escribir. Guarda el destino, el puerto, el protocolo y el resultado. CERT-In recomienda conservar los registros al menos 180 días.
• Revisa también el acceso entrante. Busca credenciales expuestas en el código, en el historial de commits y en los archivos de configuración. Sustituye todas las credenciales expuestas, elimina el acceso desde Internet a las interfaces de administración y exige autenticación multifactor para todo acceso administrativo.

Cómo ayuda nuDefend

Qué se está ejecutando. nudefend workloads muestra las herramientas de IA que se ejecutan en el servidor: servidores de modelos, interfaces de chat, bases de datos vectoriales, plataformas de automatización y servidores MCP. Muestra las herramientas que se ejecutan en el host o dentro de un contenedor, y los indicios usados para identificar cada una. nuDefend también detecta agentes que no escuchan conexiones y solo inician conexiones salientes.

A dónde se conecta. nuDefend registra con qué destinos se comunica cada herramienta de IA, el volumen de tráfico enviado a cada destino y cuándo se detectó ese destino por primera vez. Cuando se identifica el destino, se muestran su nombre y una descripción del tipo de actividad que realiza. nudefend egress review <workload> muestra todos los destinos de una herramienta e indica si la supervisión cubrió el periodo completo. Los informes y el historial se guardan en una base de datos local del servidor.

La lista se elabora a partir del tráfico real. En la primera fase, nuDefend solo registra. Al terminar el periodo de supervisión, se obtiene una lista basada en el tráfico observado. En la pantalla Outbound autorizas los destinos que la herramienta realmente necesita. Las direcciones que comparten varios servicios no se autorizan automáticamente: se marcan para que las revises.

El control se aplica por debajo de la herramienta. Tras activar la restricción, la herramienta solo puede conectarse a los destinos que hayas autorizado. Todo intento de conexión con otro destino se bloquea antes de que el tráfico salga del servidor. La restricción solo afecta a la herramienta seleccionada; el resto del servidor sigue funcionando con normalidad. Se puede aplicar la restricción a casi cualquier herramienta que el sistema detecte, y la pantalla indica si cada herramienta está restringida. Si no confirmas la restricción de forma definitiva en diez minutos, se desactivará automáticamente. nuDefend se supervisa a sí mismo y restaura sus reglas si alguien intenta modificarlas.

También qué nombres resuelve. Una herramienta restringida solo puede resolver las direcciones que hayas autorizado. Cualquier otra consulta se detiene antes de salir del servidor. La autorización se aplica al nombre exacto, no a sus subdominios. Cada consulta detenida aparece en la pantalla junto al nombre de la herramienta. Suele ser la primera señal de que una herramienta intenta acceder a un destino que no has autorizado.

También el lado receptor. nudefend expose muestra todos los servicios que escuchan en el servidor y quién puede acceder a ellos. nuDefend avisa cuando un servicio que era interno pasa a ser accesible desde fuera. Una lista de amenazas firmada se actualiza cada 30 minutos y bloquea el tráfico hacia y desde direcciones y dominios maliciosos. Los intentos repetidos de adivinar contraseñas en SSH, correo, FTP y las páginas de inicio de sesión del sitio se bloquean en el cortafuegos.

Más información en la página de tráfico saliente, en la página de exposición y en la documentación.

En resumen

Un laboratorio de IA, el marco de técnicas de MITRE y una autoridad nacional de ciberseguridad señalan el mismo control: una lista de destinos autorizados para cada agente, aplicada en la red y no en el prompt, y un registro de conexiones que no dependa de lo que diga el agente. Los casos de uso de acortadores de URL descritos por Anthropic muestran qué ocurre cuando el límite está dentro de la herramienta. En un servidor Linux, nadie ha escrito por ti la lista de destinos permitidos. Por eso, la primera tarea es comprobar a dónde se conecta cada agente, escribir una lista sin servicios de retransmisión genéricos y aplicarla en una capa inferior al agente.