Informe de seguridad de agentes IA: 1.280 productos, 282 con SSO; mayoría sin control de identidad

Un nuevo informe sobre seguridad de agentes de IA presenta una imagen preocupante pero concreta: en los entornos examinados para el 2026 State of Agent Security Report hay alrededor de 1.280 productos de terceros que ya incorporan capacidades de IA; de esos, sólo 282 pasan por el circuito de inicio de sesión único (SSO) y el resto —casi mil— permanece fuera del alcance directo de la infraestructura de identidad por defecto. En términos simples: la mayoría de los "agentes" no llegan a través de un proceso de adopción controlado, sino que aparecen dentro de aplicaciones existentes como actualizaciones de producto o funciones heredadas, y por tanto escapan a las herramientas tradicionales de gobernanza.

Esto no es un problema de modelos —el informe insiste en ello— sino de ecosistema. Un agente, explicado en sus partes fundamentales, combina un modelo para razonar con una "andamiaje" que lo convierte en actor: qué sistemas puede consultar, qué APIs puede invocar, qué credenciales usa y cuándo actúa automáticamente. Según el documento, casi todo el riesgo práctico reside en ese andamiaje y en las conexiones que el agente hereda, no en la calidad del modelo base.

La consecuencia inmediata es una brecha en la lógica dominante de seguridad: las herramientas y procesos que evaluaban IA asumen un momento de decisión —una compra, una integración, una puerta de entrada— que concede un punto de instrumentación y un responsable. Los agentes heredados no atraviesan ese punto. Se instalan dentro de plataformas que la empresa ya usa y, en muchos casos, funcionan con permisos que proceden de la configuración de la aplicación anfitriona o de tokens almacenados en el entorno, no de la identidad corporativa gestionada por TI.

¿A quién afecta esto? A cualquier organización que use aplicaciones de terceros a gran escala: CRM, plataformas de chat, suites de productividad, entornos de nube y catálogos de aplicaciones. El informe menciona que agentes nacidos en un CRM pueden acabar leyendo un data warehouse y creando tickets en sistemas de gestión, y que agentes desplegados en la nube terminan alojando tokens con acceso a varias aplicaciones. En términos regulatorios, la incapacidad para enumerar y atribuir sistemas de IA también afecta el cumplimiento: obligaciones como las estipuladas por el EU AI Act presuponen que una organización puede inventariar sus sistemas de IA y demostrar supervisión.

El informe refiere además declaraciones de líderes de la industria que elevan el riesgo a la categoría de sistémico: se cita a ejecutivos que han tratado la cadena de suministro de software como un vector crítico y que ahora aplican la misma mirada a los agentes. Si actores de gran tamaño exigen control sobre agentes en sus procesos de compra y evaluación, eso transformará cuestionarios y contratos en indicadores de riesgo exigibles para proveedores.

Qué está confirmado y qué es estimación: las cifras del informe (1.280 productos con IA, 282 detrás de SSO) son la base factual reportada por los autores; la caracterización técnica del problema —el enfoque en andamiaje y conectividad frente al modelo— se despliega como análisis del mismo informe. Las proyecciones sobre crecimiento exponencial de agentes heredados y la idea de que las prácticas actuales colapsan al escalar son inferencias razonadas por los autores y por expertos del sector; constituyen estimaciones basadas en tendencias observables, no certezas inmutables. Lo que aún es incierto es la rapidez con la que proveedores y reguladores implementarán contramedidas efectivas y cómo evolucionará la normativa concreta en distintos mercados fuera de la UE.

Desde el punto de vista técnico, la pieza crítica es la "alcanzabilidad" (reach): un agente puede actuar directamente sobre sistemas si tiene credenciales, conectores o permisos heredados. Las herramientas clásicas —escáneres de modelos, filtros de prompts, revisiones puntuales— evalúan componentes aislados; no miden cadenas de impacto que atraviesan identidades humanas y no humanas, aplicaciones y permisos encadenados. Este es el talón de Aquiles identificado: la superficie que importa no es la configuración percibida hoy, sino lo que un agente puede alcanzar mañana.

Riesgos concretos que resultan de esta arquitectura: exfiltración de datos a través de agentes con permisos heredados, movimientos laterales facilitados por credenciales usadas por agentes, automatización mal configurada que modifica entornos de producción, y erosión de auditoría y gobernanza cuando las acciones del agente quedan asociadas a la aplicación anfitriona en lugar de a un actor identificable. A nivel operativo, la gestión manual con hojas de cálculo y revisiones trimestrales se vuelve inviable cuando el número de agentes se cuenta por cientos o miles.

¿Qué hacer ya, paso a paso? Primero, detectar: implemente un inventario continuo de agentes y sus permisos en tiempo real, no revisiones puntuales. Herramientas que correlacionan identidades, aplicaciones y acciones —el informe cita soluciones diseñadas para mapear esa "graph" de relaciones— son la pieza inicial para convertir alcance en unidad de análisis. Segundo, identidad y principio de menor privilegio: exija que cualquier agente tenga una identidad separada, provisionada por TI, y que reciba por defecto sin permisos; la elevación debe ser explícita y auditada. Tercero, controles de runtime: restringa y registre todos los conectores que permiten a un agente alcanzar sistemas sensibles, obligando a aprobaciones de negocio y revisiones de seguridad para cada nuevo conector. Cuarto, gestión de secretos y rotación: asegure tokens y credenciales usadas por plataformas y agentes en vaults corporativos con rotación automática y políticas de scope restringido. Quinto, telemetría y respuesta: centralice registros de acciones de agentes en su SIEM/EDR y defina alertas por patrones de acceso inusuales o por cadenas de llamadas entre servicios.

En el plano contractual y de proveedor, exija visibilidad: cláusulas que obliguen a proveedores a documentar agentes incluidos en actualizaciones y a proporcionar mecanismos para desactivar funciones de agente a nivel de cliente. No confíe en cuestionarios tradicionales: pida evidencias de inventario y pruebas de que los agentes pueden ser provisionados con identidades neutralizadas hasta la autorización.

Para equipos que planifiquen la inversión, prioricen capacidades de descubrimiento continuo y automatización de políticas de identidad sobre escaneos estáticos de modelos. A corto plazo, mitigaciones operativas (revocar tokens no auditados, limitar conectores, habilitar logging) reducen el riesgo inmediato. A medio plazo, implemente flujos de aprobación y gateo de conectores desde el proveedor y trabaje con legal/compliance para actualizar contratos. A largo plazo, promueva arquitecturas que sitúen el runtime controlado por la organización en servicios críticos, y presione a proveedores para que sus funciones de agente respeten modelos de identidad delegada y auditabilidad.

La agenda regulatoria y de buenas prácticas ya está en marcha: la exigencia de inventario y supervisión que propone la EU AI Act y los marcos de confianza cero y gestión de identidad, como el NIST Zero Trust, ofrecen principios aplicables: visibilidad contínua, menor privilegio, segmentación y telemetría. Sin esos pilares, las organizaciones seguirán viéndose sorprendidas por agentes que nunca pasaron por un proceso de adopción.

En conclusión, el salto no es técnico sino organizativo: la seguridad debe dejar de preguntar "qué modelo usamos" y empezar a mapear "qué puede alcanzar cada actor (humano o no humano) en mi entorno". Esa transición exige herramientas distintas, políticas de identidad más estrictas y contratos que obliguen a los proveedores a exponer y permitir controlar los agentes que envían dentro de las plataformas que gestionan.