El «harness» de los agentes de IA se convierte en una nueva superficie de ataque

Si se pregunta a un responsable de seguridad dónde está el riesgo de un agente de IA, la respuesta casi siempre empieza por el modelo: si se puede evadir con un jailbreak, si se puede confiar en sus pesos. Ese reflejo cada vez tiene menos sentido. Un número creciente de demostraciones de explotación, pruebas de red team independientes y evaluaciones de investigadores apunta en cambio al código que se sitúa entre el modelo y el mundo exterior. Ese código se llama harness: dota al modelo de herramientas y convierte su salida de texto en acciones reales — un comando de shell, una escritura de archivo, una llamada a una API. En muchas empresas, esa capa no está inventariada por completo, ni probada, ni claramente asignada a un equipo.

Qué es exactamente un harness de IA

Al pedir una definición, los profesionales convergen en metáforas distintas. Michael Bargury, cofundador y director de tecnología de la firma de seguridad Zenity, lo llama las 'manos, piernas y ojos' del modelo: este solo genera tokens de texto, y es el harness el que los convierte en un comando de shell, una escritura de archivo o una llamada a una API. Rob T. Lee, responsable de IA e investigación en el SANS Institute, compara el modelo con un motor y el harness con el chasis. Michael Sromin, ingeniero senior de aprendizaje automático en Lasso Security, lo describe como el sistema operativo que gestiona todo el bucle de una aplicación agéntica, conectando modelo, herramientas y usuario. Omar Santos, ingeniero distinguido de Cisco, ofrece la definición más formal: la capa que rodea a un modelo y lo hace utilizable — orquestación, uso de herramientas, prompts, contexto, roles, evaluaciones y barreras de seguridad incluidas. Las cuatro definiciones apuntan al mismo problema: en el harness es donde se ejerce realmente la autoridad de un agente. Se sitúa entre el razonamiento del modelo y un sistema de archivos real, una clave de API o una base de datos de producción. Un modelo perfectamente alineado sirve de poco si el código que lo rodea confía en un patrón de shell genérico o reutiliza un espacio de trabajo con contenido no confiable en varias ejecuciones.

Tres formas en que un harness falla

Elad Meged, ingeniero fundador e investigador de seguridad en Novee Security, mostró en la conferencia Black Hat USA cómo logró acceder a los repositorios oficiales de automatización de Anthropic, Google y OpenAI usando solo issues de GitHub. Las fallas concretas variaban según el proveedor — ejecución de código, credenciales expuestas, instrucciones inyectadas que un componente más potente, situado más adelante, aceptaba sin volver a validarlas. El error arquitectónico de fondo, sin embargo, era sorprendentemente el mismo en los tres casos: un componente tomaba una decisión de seguridad que otro componente más potente, más adelante en la cadena, confiaba sin comprobarla de nuevo. 'No es un fallo del modelo, es un fallo de frontera de confianza', resume Meged.

La segunda fuente de fallos está en el propio diseño del harness, sin necesidad de ningún error de código. Los investigadores de Lasso Security simplemente sustituyeron el harness de un mismo modelo abierto, dejando modelo, prompt y herramientas idénticos. La tasa de éxito de los ataques pasó del 1% al 24%, y el resultado se invirtió por completo en 43 de cada 100 combinaciones de modelo y tarea probadas. 'Cambiar de harness es, en la práctica, obtener un agente completamente distinto', afirma Sromin, que recomienda evaluar harness y modelo juntos en lugar de adoptar una configuración por defecto sin probarla.

La tercera vulnerabilidad recorre la cadena de suministro del harness. El equipo de Michael Bargury en Zenity examinó 'skills' — archivos que enseñan a un agente una tarea nueva — y encontró malware ladrón de credenciales oculto en algunos que habían pasado todos los escáneres del mercado, incluidos los de Anthropic y Cisco. Un skill malicioso se escribía en el archivo de memoria que un agente recarga en cada reinicio: eliminar el skill no bastaba, porque la instrucción de reinstalación permanecía activa y el malware volvía en el siguiente arranque. Otro se hacía pasar por una herramienta oficial de Anthropic, borraba la herramienta legítima tras ejecutarse y la sustituía por la versión del atacante, sin cambio visible para el usuario. El caso más llamativo fue una campaña de herramientas de código abierto clonadas y modificadas en secreto para robar credenciales, que acumularon cerca de 1,7 millones de descargas antes de ser detectadas y detenidas.

• Inventario: catalogar cada harness en producción, aunque internamente se le llame 'copiloto', 'asistente de flujo de trabajo' o 'plugin'
• Mapa de accesos: identificar qué herramientas y datos puede alcanzar cada harness, y reducir esos permisos al mínimo necesario
• Prueba independiente: evaluar harness y modelo juntos en lugar de confiar en una configuración por defecto sin verificarla

Los equipos piensan en términos de aplicaciones, servicios, pipelines o bots. Los harness desaparecen en repositorios de código, productos SaaS y pantallas de configuración de proveedores, en lugar de aparecer como activos propios en el inventario de seguridad.

Qué cambia para las empresas que despliegan agentes de IA

Para una empresa que despliega agentes de IA de forma interna — como extensión de herramientas tipo Copilot, automatización propia o un framework de agentes —, el harness casi nunca figura hoy como una línea aparte en el inventario de seguridad. Santos recomienda no esperar a tener visibilidad total: se puede cubrir entre el 60% y el 70% con relativa rapidez empezando por los sistemas en producción, dejando prototipos e IA en la sombra para una segunda fase. Este enfoque coincide con obligaciones ya vigentes en varias jurisdicciones para documentar sistemas automatizados de alto riesgo: la herramienta que ejecuta las acciones del agente debe figurar en el mismo inventario que el modelo. En la práctica, esto significa tratar el harness como un componente propio en los procesos de compra y auditoría, con su propia evaluación de riesgo, su propio ciclo de parches y un principio de mínimo privilegio en los accesos, sea cual sea el modelo que funcione detrás.