El agente de IA que trabaja para ti probablemente tenga más acceso que tú

La IA no está haciendo el trabajo del representante. Es una herramienta que el representante utiliza. Pero la herramienta termina teniendo más alcance en el sistema que la persona para la que trabaja. Esa brecha, un humano con acceso limitado usando una non-human identity con acceso más amplio, se está convirtiendo en la forma normal de despliegue de IA empresarial, y casi nadie la revisa como revisaría los permisos de una persona.

Informe de Seguridad de Datos e Identidad 2026 de Netwrix, basado en una encuesta a 2,317 líderes de seguridad y TI, respalda ese patrón con cifras. El 72 % de las organizaciones dice que el riesgo de exposición de datos relacionados con la identidad ha aumentado. El 58 % dice que ahora más identidades tienen acceso a datos empresariales que antes. El 41 % ya está ejecutando IA agéntica en producción, con esos agentes actuando en nombre de humanos contra datos sensibles. Las identidades no humanas no son un problema futuro. Ya son el principal actor en muchos entornos.

La parte que no aparece en una revisión de acceso

La mayoría de los programas de gobernanza de identidad se construyeron en torno a un ritmo de incorporación, traslado y salida. Alguien comienza, su acceso crece o cambia, y finalmente se va y se revoca.Service accounts, las claves API, los certificados y los tokens de automatización no siguen ese patrón. Se crean durante una implementación, se heredan de la plantilla que fue más rápida para poner en marcha y luego se dejan solos porque nadie se encarga del seguimiento.

El informe lo confirma. Solo el 19 % de las organizaciones dice que gestionan completamente las identidades no humanas. El 76 % no puede revocar inmediatamente el acceso permanente cuando ya no es necesario. El 64 % tiene al menos algún acceso sobredimensionado a datos críticos. Si sumas todo eso, obtienes una población de credenciales que es más grande que la fuerza laboral humana, más difícil de rastrear y que rara vez se revisa.

Hay una versión específica de este problema que vale la pena destacar: la autenticación basada en certificados se está convirtiendo en el principal mecanismo de confianza para agentes de IA y automatización, pero la mayoría de las organizaciones tienen poca visibilidad sobre la infraestructura de certificados subyacente. Plantillas mal configuradas, derechos de inscripción demasiado permisivos y relaciones de confianza heredadas en Active Directory Certificate Services pueden permitir que un atacante se haga pasar por una identidad privilegiada sin necesidad de tocar una contraseña.

Por qué este es un problema de gestión del cambio, no solo de identidad

Aquí está la parte que se pasa por alto. Los permisos de una cuenta de servicio, la cadena de confianza de un certificado, el alcance de una clave API, nada de eso vive solo en una plataforma de identidad. Vive en archivos de configuración, claves de registro, almacenes de certificados y tareas programadas en los sistemas reales donde opera la cuenta. Cuando cambia una obligación regulatoria, ya sea un nuevo requisito PCI DSS, un control NIST actualizado o una revisión NERC CIP, la revisión de acceso y el paso de revocación se supone que deben ocurrir juntos. En la práctica, se presta atención al lado de la identidad y el lado de la configuración se desvía silenciosamente en segundo plano.

Esa deriva es exactamente donde se oculta el cambio no autorizado. Una clave de registro que otorga a una cuenta de servicio derechos de inscripción más amplios de los que necesita. Un archivo de configuración que aún apunta a una integración desmantelada. Una plantilla de certificado editada hace seis meses que nadie marcó para revisión. Ninguno de estos aparece en una hoja de cálculo de certificación de acceso. Aparecen cuando alguien mira lo que realmente cambió en el sistema.

Vigilando los sistemas en lugar de solo la lista

Aquí es donde la supervisión de la integridad de archivos y la gestión de la configuración de seguridad ganan su lugar en la conversación. Netwrix Change Tracker no gestiona identidades, pero sí vigila los sistemas en los que esas identidades y sus credenciales residen. Establece una línea base de archivos de configuración, claves del registro y ajustes del sistema, y luego señala cualquier cambio que se desvíe de esa línea base en tiempo real. Cuando existe una regla de Cambio Planificado, ya sea vinculada a una ventana de parcheo o a una solicitud aprobada de ServiceNow, los cambios coincidentes se filtran automáticamente. Lo que queda es la actividad no planificada: la edición del registro que nadie aprobó, el cambio de configuración sin una solicitud de cambio correspondiente, la deriva que de otro modo pasaría desapercibida hasta que una auditoría o un incidente obligue a alguien a investigarla.

Ese modelo de circuito cerrado, que compara los cambios observados con los aprobados mediante integraciones ITSM como ServiceNow, BMC Remedy y Cherwell, ofrece a los equipos de seguridad y cumplimiento algo que la revisión de acceso por sí sola no puede: un registro a nivel de sistema de lo que realmente ocurrió, cuándo ocurrió y si era esperado. Combinado con más de 250 informes de cumplimiento predefinidos alineados a marcos como PCI DSS, NIST, HIPAA y DISA STIG, ese registro convierte el "creemos que nuestros controles están funcionando" en evidencia que un auditor puede verificar realmente.

El representante sigue recibiendo la culpa

Si esa integración de Salesforce se ve comprometida, o si el asistente extrae datos silenciosamente fuera de su ámbito previsto, el informe del incidente no nombrará al proveedor de IA. Nombrará la cuenta que se autenticó y a la persona cuyo nombre está asociado a ella. La gobernanza de Identity puede establecer la política sobre lo que esa cuenta debería poder tocar. No puede decirte, por sí sola, qué cambió realmente en el sistema el martes pasado. Esa es una pregunta diferente, y alguien aún tiene que estar atento a la respuesta.