--- title: "El 54 % de las empresas ha tenido un incidente con agentes de IA. La causa raíz es la identidad." slug: "incidente-agente-ia-identidad-comparticion-credenciales" metaDescription: "Nuevas investigaciones muestran que la mayoría de las empresas permiten que los agentes de IA compartan credenciales. Esto es lo que significa para tu radio de impacto y cómo la gobernanza de IA cierra la brecha." publishedAt: "2026-07-23T00:00:00.000Z" ---
Más de la mitad de las empresas ya han tenido un incidente de seguridad confirmado con agentes de IA o un casi accidente. Ese es el titular de la nueva investigación VentureBeat Pulse publicada esta semana, que cubre 107 empresas que usan agentes autónomos de IA activamente en sus negocios.
Esa cifra no sorprenderá a nadie que haya estado atento. Lo que debería preocuparte es la razón detrás de ella.
Solo el 32 % de las empresas asigna a cada agente de IA una identidad gestionada y con alcance propio. El resto permite que los agentes compartan credenciales, usando claves API compartidas, tokens de cuentas de servicio o, en algunos casos, las mismas credenciales que los usuarios humanos. Y solo el 30 % aísla sus agentes de mayor riesgo en entornos sandbox.
Esto no es un problema del modelo. No es un problema de inyección de prompts. Es un problema de gobernanza para el que los equipos de seguridad han estado construyendo las herramientas equivocadas.
Por qué las credenciales compartidas son un fallo estructural
Cuando das a dos agentes la misma clave API, no solo creas un atajo de conveniencia. Colapsas el radio de impacto de cualquier compromiso futuro en un único dominio de fallo.
Piensa en cómo se ve eso en la práctica. Despliegas un agente de IA para gestionar la clasificación de tickets de soporte al cliente. Necesita acceso de lectura a tu CRM. Le das la misma cuenta de servicio que usa tu canal de datos porque configurar una nueva toma medio día y el sprint termina el viernes. Tres meses después, se crea un segundo agente, uno que escribe en tu almacén de datos, con la misma clave porque el patrón ya está establecido.
Ahora tienes dos agentes con perfiles de riesgo muy diferentes compartiendo una única identidad. Si cualquiera de los dos se compromete, por un prompt malicioso, una herramienta mal configurada, una llamada API con permisos excesivos, el atacante no obtiene el radio de impacto de un agente. Obtiene ambos.
Este es el mismo principio que hizo que el movimiento lateral fuera tan efectivo en las brechas tradicionales empresariales. Las credenciales compartidas significan exposición compartida. La única diferencia con los agentes de IA es que se mueven más rápido, toman decisiones más autónomas y a menudo se les concede acceso que levantaría sospechas si un humano pidiera lo mismo.
El problema del stack de seguridad es peor de lo que parece
Aquí está la parte de los datos de VentureBeat que debería incomodar a los líderes de seguridad empresarial: las puntuaciones de satisfacción.
Las organizaciones en esta encuesta calificaron sus controles actuales de seguridad de IA con un promedio de 4,2 sobre 5. Mientras tanto, solo un tercio cree que sus defensas están realmente por delante de los atacantes habilitados por IA. Y una clara mayoría planea cambiar o actualizar sus herramientas dentro del año.
Satisfechos con controles que simultáneamente planean reemplazar. Esa es una combinación peligrosa.
La razón de esta desconexión es de dónde provienen los controles. El stack de seguridad para la mayoría de las empresas es abrumadoramente nativo del proveedor: guardarraíles de OpenAI, controles de Google Cloud, políticas de Azure, funciones gestionadas de agentes de Anthropic. No son herramientas malas. Pero fueron diseñadas para gobernar modelos, no para gobernar el comportamiento organizacional de agentes que operan en tu entorno.
Los controles nativos del proveedor responden preguntas como: "¿Esta requête violó la política de contenido?" Son mucho menos efectivos para responder: "¿Debería este agente tener acceso a este sistema? ¿El comportamiento de este agente es coherente con lo que autorizamos? Cuando este agente realizó una acción el martes pasado, ¿estuvo dentro del alcance aprobado por su responsable de negocio?"
Esas segundas preguntas son cuestiones de gobernanza de IA. Y la mayoría de las empresas no están preparadas para responderlas.
Lo que Aona Realmente Hace Aquí
La brecha de seguridad de los agentes no se cerrará con que los proveedores de modelos añadan más barreras. Se cerrará con que las empresas construyan la infraestructura de gobernanza que se sitúa entre los agentes que despliegan y los sistemas a los que esos agentes acceden.
Eso es exactamente para lo que Aona está diseñado.
Aona descubre todos los agentes de IA que operan en tu entorno, no solo los que tu equipo de TI ha autorizado, sino también los que las unidades de negocio han creado de forma independiente, los que tus desarrolladores están probando en producción y los que existen en la zona gris entre herramientas aprobadas y software en la sombra. La IA en la sombra no permanece oculta una vez que los agentes comienzan a tomar acciones.
Una vez que tienes ese inventario, Aona mapea a qué puede acceder cada agente, qué ha estado haciendo realmente y si su comportamiento es coherente con la política establecida por tu equipo de gobernanza. Cuando un agente comienza a comportarse fuera de esos límites, realizando llamadas que no se esperaban, accediendo a sistemas que su responsable de negocio no autorizó, Aona lo detecta como una alerta, no como un ejercicio forense tres meses después.
El problema de compartir credenciales en los datos de VentureBeat es real. Pero el problema más profundo es que la mayoría de las empresas no tienen un método sistemático para saber cuántos agentes están activos, y mucho menos bajo qué identidad opera cada uno. No puedes gestionar identidades que no has inventariado.
Qué Hacer Antes de Que Tu Incidente Sea el Número 55
Si estás en la mayoría de empresas que aún no han tenido un incidente de seguridad confirmado con agentes, los hallazgos estructurales anteriores deberían plantear algunas preguntas concretas para tus equipos de seguridad y gobernanza.
Primero: ¿cuántos agentes de IA están actualmente activos en tu entorno? No solo los que están en tu sistema de tickets, sino todos. La mayoría de las empresas subestiman significativamente. Si tu respuesta es un número redondo, probablemente esté equivocada.
Segundo: ¿con qué credenciales están operando esos agentes? Si no puedes responder eso por agente, casi con seguridad hay credenciales compartidas en algún lugar.
Tercero: ¿quién es el responsable de negocio nombrado para cada agente? No el desarrollador que lo creó, sino la persona responsable de las acciones que realiza. Si el agente causa una caída o una fuga de datos, ¿a quién llaman? Si nadie tiene una respuesta clara, tu postura de gobernanza es más débil de lo que sugiere tu postura de seguridad.
Cuarto: ¿tienes visibilidad de lo que esos agentes están haciendo realmente, casi en tiempo real? El registro nativo del proveedor te dice qué pasó. No te dice si lo que pasó estaba dentro de la política.
Los datos de VentureBeat muestran que las empresas están cómodas dentro de esa brecha. Las puntuaciones de satisfacción son altas. Los incidentes se absorben como casi accidentes. Ese es exactamente el momento antes del incidente que no se mantiene en silencio.
Aona te proporciona el inventario, la capa de políticas y la monitorización para cerrar la brecha antes de que se convierta en tu brecha de seguridad. Si quieres ver cómo es eso aplicado a tu huella real de agentes, contacta con el equipo en [aona.ai](https://aona.ai).
---
Esta publicación hace referencia a la investigación VentureBeat Pulse Research publicada el 16 de julio de 2026, basada en una encuesta a 107 empresas que despliegan activamente agentes autónomos de IA.
