La brecha de seguridad de los agentes IA: el 54% de las empresas ya ha tenido un incidente

Imagina que despliegas un agente de IA con acceso a tu CRM, a datos financieros y a la capacidad de enviar mensajes a clientes. Le das unas credenciales compartido con otros veinte agentes. No tiene identidad propia. No está aislado. Si uno de ellos se ve comprometido, todos lo están. Suena a escenario hipotético, pero ya está pasando.

Un estudio de VentureBeat Pulse Research publicado en julio de 2026, basado en respuestas de 107 empresas con más de 100 empleados, dibuja un panorama incómodo: los agentes IA están actuando en producción con niveles de acceso real, mientras que los controles de seguridad que deberían contenerlos van muy por detrás. La conclusión central del informe tiene nombre propio: la agent security gap, la distancia entre la autonomía que se concede a los agentes y las garantías que existen para limitar lo que pueden hacer — y hasta dónde puede llegar un fallo.

El dato que lo define: 54% con incidentes

De las empresas que ya tienen agentes en producción, el 54% ha experimentado algún tipo de evento de seguridad relacionado con ellos. No es una proyección ni una estimación teórica: es algo que ya ha pasado. De ese 54%, un 18% fueron incidentes confirmados con impacto real, y un 36% fueron casi-accidentes detectados a tiempo. Solo un 42% declara no haber tenido ningún problema.

Lo más revelador es la proporción entre incidentes y casi-accidentes. Que haya casi el doble de near-misses que de incidentes confirmados sugiere que las empresas están funcionando cerca del límite: los problemas se detectan, pero con poco margen. Si los controles de contención fueran más robustos, buena parte de esos casi-accidentes nunca llegarían a producirse.

La exposición crece con el tamaño de la empresa. Las organizaciones de 101 a 1.000 empleados registran un 49% de incidentes o near-misses. Las de más de 1.000 empleados suben al 63%. Pero el aislamiento mediante sandbox — la única medida que limita el radio de explosión de un fallo — cae del 35% al 20% según aumenta el tamaño. Las empresas que más agentes usan en más sistemas son precisamente las que menos contención tienen.

El problema estructural: la identidad compartida

La debilidad más profunda que identifica el estudio no es un fallo técnico concreto: es la identidad. Solo un 32% de las empresas otorgan a cada agente una identidad propia, con alcance y permisos delimitados. El resto opera en un modelo de credenciales compartidas de un modo u otro: un 48% dice que algunos agentes tienen identidad propia pero muchos otros comparten credenciales, y un 32% reconoce que sus agentes funcionan principalmente con claves API compartidas o con credenciales de cuentas de servicio o incluso de usuarios humanos.

En conjunto, el 69% de las empresas (74 de 107) tienen algún grado de compartición de credenciales en su flota de agentes. Esto tiene consecuencias directas. Si un agente con credenciales compartidas queda comprometido — o simplemente tiene un error de permisos — el alcance del daño no se limita a ese agente. Puede actuar en nombre de todos. Y después, durante la investigación forense, es imposible saber cuál de los agentes sharing credentials fue el causante.

La correlación con los incidentes es llamativa. Las empresas con compartición de credenciales en algún punto de su flota sufrieron un incidente o near-miss en los últimos doce meses en un 63,5% de los casos. Las empresas donde cada agente tiene su propia identidad con alcance delimitado lo sufrieron en un 40,9%. Son grupos de tamaño distinto, así que no es causalidad probada, pero una diferencia de 23 puntos porcentuales dentro de la misma encuesta sugiere que la relación es real.

La identidad no es un detalle organizativo: es la base sobre la que se construyen el acceso con mínimo privilegio y la atribución limpia. Sin ella, todo lo demás se tambalea.

Observan, aplican permisos, pero casi nadie aísla

El estudio preguntó también por las prácticas reales de seguridad de los agentes: observación, aplicación de permisos en tiempo de ejecución y aislamiento. Los resultados siguen un patrón predecible pero inquietante.

Un 49% de las empresas aplican permisos con alcance definido y los refuerzan en tiempo de ejecución. Un 47% monitorizan y registran la actividad de los agentes, aunque la aplicación en runtime es limitada. Pero solo un 30% aíslan a sus agentes de mayor riesgo en sandbox. Es decir: la medida que limita el radio de daño cuando todo lo demás falla es la menos adoptada.

Desde el punto de vista de defensa en profundidad, el orden debería ser el inverso. La observación te dice lo que ha pasado. La aplicación de permisos intenta evitarlo. El aislamiento es lo que contiene el daño cuando la prevención falla. Y sin embargo, es el control que menos empresas han implementado.

La pila de seguridad es prestada

Aquí viene el dato más sorprendente del informe. Cuando se pregunta qué herramientas de seguridad usan para sus agentes, el stack dominante no es una solución dedicada a seguridad de agentes: son los controles native de los propios proveedores de modelos y nubes.

Un 51% usa los guardrails incorporados de OpenAI. Un 36% usa controles de Google Cloud. Un 35% los de Microsoft Azure. Un 29% los controles de agentes gestionados de Anthropic. Los especialistas dedicados en seguridad de agentes IA — Palo Alto Networks, CrowdStrike, Cisco, HiddenLayer, Zenity — están en porcentajes de un solo dígito.

Y cuando se pregunta cuál es su capa de seguridad principal para agentes, un 82% nombra un control provider-native o de hyperscaler. Las empresas están protegiendo a sus agentes principalmente con las herramientas que ya venían integradas en la plataforma que compraron.

La satisfacción con estas herramientas es alta: 4,2 sobre 5. Pero ahí está la contradicción más notable del informe. Las empresas están muy satisfechas con unos controles que, según sus propios datos, no están funcionando bien: más de la mitad ya ha tenido un incidente, y la mayoría sigue con credenciales compartidas.

Paradójicamente, esa satisfacción elevada coexiste con planes de cambio: la mayoría de las empresas afirman que piensan cambiar de tooling en el próximo año. La confianza, parece, es más fina de lo que sugiere la nota.

Qué significa esto en la práctica

El patrón que describe el estudio es bastante claro. Las empresas están desplegando agentes con acceso real a sistemas y datos — lo cual es, en muchos casos, exactamente lo que necesitan para ser útiles — pero los cimientos de seguridad que deberían contener a esos agentes están incompletos.

No hay una solución mágica, pero la dirección es conocida. Cada agente necesita su propia identidad, no credenciales compartidas. Los agentes de mayor riesgo necesitan entornos aislados. Los controles de seguridad dedicados a agentes — no solo los guardrails del proveedor — tienen que ganar peso en el stack. Y los presupuestos tienen que reflejar el riesgo real.

Lo que el informe deja claro es que la brecha no es tecnológica: la tecnología para hacer esto bien existe. La brecha es de adopción, de prioridad y de comprensión del riesgo. Y mientras persista, cada nuevo agente que sale a producción es un nuevo vector que nadie ha contenido.