Cuando el acceso supera a la gobernanza: el verdadero riesgo interno de la era agéntica

Las empresas están entregando a los agentes de IA las llaves de sus contenidos más sensibles más rápido de lo que nadie está escribiendo las reglas sobre cómo deben usarse esas llaves. Esa brecha entre la velocidad de despliegue y la madurez de la gobernanza se está convirtiendo, sin hacer ruido, en el problema de seguridad que define 2026, y los propios responsables de seguridad ya lo dicen.

El acceso de los agentes acaba de convertirse en la amenaza número uno

En un estudio realizado por Sapio Research por encargo de Exabeam en junio de 2026 y publicado el 16 de septiembre de 2026 — The Agentic Insider: From Monitoring to Understanding, que encuestó a 600 responsables de decisión de seguridad y finanzas en siete países —, el 48 % de los responsables de seguridad señaló a los agentes de IA que operan con un acceso excesivo, comprometido o no previsto como la mayor amenaza a la que se enfrenta hoy su organización. Eso sitúa el acceso de los agentes por delante de los actores de amenazas externos (28 %) y muy por delante de los empleados internos comprometidos y los empleados internos malintencionados (12 % cada uno). Por primera vez en una categoría de amenazas que los equipos de seguridad llevan años siguiendo, un problema de infraestructura supera a un adversario.

Qué cuenta realmente como «agente»

Importa cómo define el estudio su objeto. Sus autores se cuidan de separar los «sistemas autónomos orientados a objetivos que pueden acceder a recursos corporativos y emprender acciones con una intervención humana limitada» de los «chatbots conversacionales». Esa distinción es el problema entero en miniatura. Un chatbot responde dentro de una ventana de chat; un agente actúa —lee un repositorio de contratos, extrae la ficha de un cliente, redacta y envía un mensaje, actualiza un sistema de registro— y lo hace, por diseño, con una intervención humana limitada. Como lo expresó Gabrielle Hempel, de Exabeam, en un análisis relacionado, un agente puede reunir «identidad válida, acceso autorizado, herramientas previstas, ningún atacante» y aun así provocar un incidente. Cuanta más autonomía concede una organización a un agente —que es toda la justificación económica para desplegarlo—, menos realista resulta gobernar ese agente decidiendo de antemano, para cada tarea, exactamente a qué puede acceder.

Por qué la delimitación manual de permisos deja de funcionar

Esa es la trampa en la que está cayendo la mayoría de las organizaciones. La respuesta instintiva a «el agente tiene demasiado acceso» es recortarlo: roles más estrechos, cuentas de servicio más ajustadas, revisiones de permisos agente por agente. Eso funciona con el primer agente. No funciona con el quincuagésimo, y menos aún cuando la tarea de ese mismo agente cambia de hora en hora, o cuando el patrimonio de contenidos al que necesita llegar abarca el correo electrónico, los recursos compartidos de archivos, los registros del CRM y datos estructurados que nadie inventarió pensando en agentes. La delimitación manual presupone un conjunto de recursos estático y enumerable y un conjunto de tareas estático y enumerable. La IA agéntica incumple ambas premisas de forma continua.

Supervisar no es lo mismo que comprender

Los datos de Exabeam muestran la tensión que esto genera incluso allí donde la gobernanza no se ha descuidado. El 60 % de los responsables de seguridad ha puesto en marcha herramientas específicas de seguridad o gobernanza de la IA, y el 56 % ha ampliado sus plataformas de SIEM y de detección existentes para cubrir a los agentes. Pero el 27 % sigue citando el contexto de comportamiento y la correlación limitados como su mayor carencia de supervisión y, como observó Steve Wilson, Chief AI and Product Officer de Exabeam, «las organizaciones están avanzando de forma significativa en la supervisión de los agentes de IA, pero supervisar la actividad no es lo mismo que comprender el comportamiento». La supervisión indica qué hizo un agente después de haberlo hecho. No indica, antes del hecho, si se le debería haber permitido hacerlo.

El problema presupuestario que se esconde detrás del problema de seguridad

Una segunda restricción agrava la primera: el dinero. El 55 % de los responsables de seguridad afirma haber retrasado o recortado una iniciativa de seguridad porque no supo plantear el riesgo en los términos financieros que su CFO aceptaría, aun cuando el 93 % declara que seguridad y finanzas están ampliamente alineadas en cuanto a tolerancia al riesgo y el 81 % dice que su CFO entiende el riesgo de ciberseguridad en términos generales. La brecha no es de confianza, sino de traducción. «Los CFO rara vez cuestionan si un riesgo de ciberseguridad es real», señaló Mike Byron, CFO de Exabeam; la tarea más difícil es «entender cómo la inversión reduce el riesgo en términos de negocio medibles». Un modelo de gobernanza capaz de señalar decisiones concretas y registradas —a esta identidad se le denegó este dato para este fin, en esta fecha— se traduce a una conversación presupuestaria con mucha más facilidad que un panel de supervisión.

La capa que falta: la política decidida en el momento de la solicitud

Al juntar esas piezas, se perfila la forma de una respuesta viable. No es supervisar mejor a los agentes después de que actúen, ni una hoja de cálculo más grande de permisos por agente decididos antes de que actúen. Es una capa de políticas situada en el propio punto de acceso que evalúa, para cada solicitud, si estos datos pueden usarse para este fin por esta identidad —humana o agente— antes de que nada se mueva. Esa decisión tiene que tomarse de forma dinámica, a partir de los atributos de los datos, de la identidad y de la acción solicitada, en lugar de zanjarse una sola vez por anticipado para un rol que inevitablemente quedará obsoleto. Y cada decisión, de permiso o de denegación, debe quedar registrada, de modo que el registro de la aplicación de la política sirva a la vez como la evidencia que necesitan tanto los auditores como los CFO.

Esta es la dirección en la que ha construido Kiteworks con su Data Policy Engine, que evalúa en tiempo real los datos, la identidad y la acción solicitada frente a la política y aplica una directiva —bloquear, solo lectura, justificación obligatoria o permitir—, registrando cada decisión en una pista de auditoría inmutable. Extendido específicamente a los agentes, Kiteworks describe ese mismo punto de control aplicándose antes de que cualquier solicitud de IA toque datos: verificación de identidad, evaluación de políticas basada en atributos y registro de auditoría, con la identidad del agente vinculada a la persona que la autorizó. El propio planteamiento de la compañía sobre lo que está en juego es tajante: los agentes de IA «no ejercen ningún juicio ético independiente. Accederán a cualquier dato que no se les impida tocar de forma explícita».

No es una razón para frenar el despliegue de agentes. Es una razón para dejar de tratar el acceso como algo que se decide una vez y empezar a tratarlo como algo que se decide cada vez.

Si está definiendo cómo debería ser un límite de política para los agentes en su propio entorno, escriba a sales@kiteworks.com o inicie una conversación. No necesita configurar Claude ni MCP para preguntar. Consulte el catálogo de agentes y el soporte de asistentes.