Los agentes de IA siguen iniciando sesión como humanos – y tu registro de auditoría lo está pagando
Durante los últimos cuatro años, las empresas han incorporado agentes de IA en infraestructuras de identidad que nunca fueron diseñadas para reconocerlos como actores distintos. Esa incompatibilidad ahora es visible en los datos, no solo en los análisis post-mortem de incidentes. Un nuevo informe basado en actividad de inicio de sesión anonimizada de más de 20,000 organizaciones muestra que los agentes de IA operan en entornos empresariales prácticamente igual que cuando llegó la IA generativa: autenticados como, o a través de, un humano.
El informe es el Okta Enterprise AI Index, y se basa en datos de inicio de sesión desde junio de 2022 hasta junio de 2026, abarcando más de 100 productos de IA distintos, consolidados en 74 suites de proveedores para su análisis. La magnitud del conjunto de datos hace que el hallazgo sea difícil de descartar como un caso aislado. No se trata de la mala configuración de un proveedor ni de la implementación apresurada de IA en una empresa. Es un patrón que se repite en decenas de miles de organizaciones que eligen, o simplemente adoptan por defecto, la misma manera de autorizar los flujos de trabajo de agentes de IA.
Las cifras de crecimiento son impactantes. Empresas nativas de IA como Anthropic, OpenAI y Cursor más que cuadruplicaron su base de clientes empresariales durante el periodo del estudio, y Anthropic superó a OpenAI en cuentas empresariales totales en marzo de 2026, y luego la superó en usuarios activos mensuales el mes siguiente. Estos hitos demuestran lo rápido que la IA agente ha pasado de la experimentación a ser una herramienta estándar en la empresa. Pero el hallazgo más relevante está detrás de esa curva de crecimiento: las prácticas de identidad y acceso para agentes de IA no han avanzado al ritmo de la implementación de esos agentes.
El intercambio seguro de datos de Kiteworks se construyó sobre una premisa diferente: cada actor que accede a contenido confidencial, sea humano o máquina, necesita una identidad verificable, permisos definidos y su propia entrada en el registro de auditoría. Esa premisa es precisamente lo que este informe encuentra ausente en la mayoría de las implementaciones empresariales de IA actuales.
Conclusiones clave
1. La adopción de IA en la empresa ha superado las prácticas de identidad empresarial.
Los nuevos datos de inicio de sesión que cubren cuatro años y más de 20,000 organizaciones muestran que los proveedores nativos de IA han multiplicado por más de 4 sus cuentas empresariales, mientras que el modelo de identidad detrás de esas herramientas apenas ha cambiado desde la época de los proyectos piloto.
2. Los agentes siguen usando credenciales humanas prestadas.
Las cuentas de servicio, las claves API estáticas y los inicios de sesión humanos compartidos siguen siendo la forma predeterminada en que las organizaciones autorizan los flujos de trabajo de agentes de IA, según la investigadora de Okta Fei Liu, y cada uno de estos métodos fue creado para un mundo sin actores de software autónomos.
3. Un inicio de sesión prestado significa un registro de auditoría roto.
Cuando un agente de IA se autentica como una persona, los registros muestran el nombre de esa persona asociado a acciones que nunca realizó, lo que hace casi imposible reconstruir lo que realmente hizo el agente durante una revisión de incidentes.
4. La carrera empresarial Anthropic-OpenAI es un síntoma, no la historia.
Que Anthropic supere a OpenAI en cuentas empresariales y usuarios activos mensuales a principios de 2026 confirma lo rápido que la IA agente está entrando en los flujos de trabajo empresariales, más rápido de lo que la mayoría de los programas de identidad y acceso han logrado gobernarla.
5. El control de acceso segmentado por agente cierra la brecha.
Asignar a cada agente de IA su propia identidad gobernada, permisos y registro de auditoría, en vez de canalizarlo por la sesión de un humano, es la diferencia entre una implementación de IA gobernable y una sin gobierno.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Leer ahora
Cuentas de servicio, claves API estáticas e inicios de sesión compartidos: tres formas en que la identidad del agente se descompone
Según Fei Liu, la investigadora de Okta citada en el informe, las organizaciones dependen en gran medida de tres mecanismos para autorizar los flujos de trabajo de agentes de IA: cuentas de servicio, claves API estáticas y, en algunos casos, inicios de sesión humanos compartidos. Cada uno resuelve un problema de integración a corto plazo. Pero también crea un problema de gobernanza a largo plazo que la mayoría de las organizaciones aún no ha enfrentado.
Las cuentas de servicio son las más comunes de las tres. Permiten que un agente de IA actúe como una identidad no humana designada dentro de una aplicación, lo que suena correcto hasta que se observa cómo suelen aprovisionarse y supervisarse esas cuentas. Muchas cuentas de servicio se crean una sola vez, se les otorgan amplios controles de acceso para cubrir cualquier cosa que el agente pueda llegar a necesitar, y luego se dejan sin revisión. Nadie revisa los permisos a medida que el rol del agente se expande. Nadie vincula acciones individuales a una tarea, solicitud o justificación empresarial concreta. La cuenta existe, el agente la utiliza y los registros resultantes describen la cuenta, no el trabajo realizado. Aplicar etiquetas de clasificación de datos al contenido al que pueden acceder las cuentas de servicio es el requisito previo que permite delimitar el acceso con precisión; sin esto, un programa de gobernanza no puede imponer restricciones basadas en la sensibilidad sobre lo que un agente puede alcanzar mediante esa cuenta.
Las claves API estáticas presentan problemas similares, agravados por la forma en que se gestionan operativamente. Una clave que autoriza a un agente a leer archivos, consultar una base de datos o llamar a un sistema interno normalmente no expira, no rota automáticamente y a menudo se copia en archivos de configuración, variables de entorno o, peor aún, directamente en una ventana de contexto o prompt del agente, donde puede quedar expuesta, registrada o exfiltrada sin que nadie lo note. Una vez que esa clave existe en más de un lugar, «quién tiene acceso» deja de ser una pregunta que alguien pueda responder con confianza.
El tercer patrón, los inicios de sesión humanos compartidos, es el más preocupante porque elimina por completo la distinción entre persona y proceso. Las credenciales de un empleado se entregan a un script de automatización, un bot o un agente de IA para que actúe «como» esa persona en un sistema que no tiene una vía de aprovisionamiento separada para identidades de máquina. A partir de ese momento, cada acción que realiza el agente aparece en los registros como si la hubiera realizado el humano. Una filtración de datos confirmada a través de un inicio de sesión humano compartido que usó un agente deja a las organizaciones sin poder delimitar con precisión el alcance de la filtración; las obligaciones de notificación bajo HIPAA, GDPR u otros marcos similares se aplican al máximo posible de exposición a menos que haya pruebas que lo acoten, pruebas que un registro de auditoría mixto humano-agente no puede proporcionar.
Por qué «Cuando un agente de IA hereda el inicio de sesión de un humano, pierdes el registro de auditoría» debería preocupar a todo CISO
La advertencia de Liu en el informe es directa: «cuando un agente de IA hereda el inicio de sesión de un humano, pierdes completamente tu registro de auditoría». Esa frase describe una falla mecánica concreta, no un riesgo vago. Un registro de auditoría solo es útil si puede decirte, después del hecho, quién hizo qué, cuándo y por qué. Una vez que un agente actúa bajo la sesión de un humano, ese registro apunta al actor equivocado en cada evento. El nombre en el registro es correcto. La historia que cuenta, no.
Esto es especialmente relevante en los momentos en que realmente se necesita un registro de auditoría: una investigación de filtración, una auditoría de cumplimiento, una consulta regulatoria o una revisión interna sobre cómo se movió un contenido confidencial dentro de la organización. En cada uno de esos escenarios, alguien termina haciendo una versión de la misma pregunta: ¿lo hizo una persona o lo hizo un proceso automatizado, y bajo qué autoridad? Si la respuesta es «no podemos saberlo, porque el agente inició sesión como Sarah», la investigación se estanca, la respuesta de cumplimiento se debilita y la organización no puede demostrar los controles de acceso que marcos como NIST CSF, ISO 27001 y SOC 2 exigen como base. Alimentar un registro de auditoría limpio y atribuido a agentes en tiempo real a una plataforma SIEM es el mecanismo operativo que convierte la atribución de agentes de una herramienta forense revisada después de un incidente en una capa de detección de comportamiento que identifica actividad anómala de agentes antes de que ocurra una filtración.
También existe un costo menos visible que aparece mucho antes de cualquier incidente: la responsabilidad se erosiona gradualmente, en el curso normal del negocio. Cuando nadie puede decir con certeza qué acciones fueron realizadas por una persona y cuáles por un agente, las aprobaciones de excepciones, las revisiones de acceso a datos y la aplicación del principio de mínimo privilegio se vuelven mucho más difíciles de gestionar correctamente. Los revisores empiezan a aprobar accesos amplios porque reducirlos parece arriesgado cuando no pueden aislar lo que el agente necesita realmente. Así es como la configuración de seguridad incorrecta se agrava con el tiempo, no por una mala decisión, sino por muchas decisiones aparentemente razonables apiladas sobre un modelo de identidad que nunca se diseñó para separar humanos del software que actúa en su nombre.
Shadow AI es un problema de identidad antes que de datos
La mayoría de las conversaciones sobre shadow AI se centran en dónde termina el contenido confidencial: un modelo no autorizado, un complemento no aprobado, una extensión de navegador que nadie revisó. Es una preocupación real, pero los datos de Okta apuntan a algo anterior. Antes de que un agente pueda mover o exponer datos, debe autenticarse en algún lugar. Si ese paso de autenticación pasa por una cuenta compartida, una clave API sin gestión o un inicio de sesión prestado, la organización ya perdió visibilidad antes de que siquiera surja la pregunta de gobernanza de datos.
Por eso la identidad merece el primer plano en cualquier conversación de gobernanza de IA, no una nota al pie bajo prevención de pérdida de datos. Un agente con una identidad bien gestionada y segmentada está limitado por diseño: solo puede acceder a lo que su rol permite, y cada acción que realiza es atribuible a ese agente y tarea específicos. Un agente que opera bajo la sesión de un humano o una cuenta de servicio con permisos amplios no está realmente limitado; su alcance real depende de lo que ese humano o esa cuenta pueda acceder, que suele ser mucho más de lo que la tarea del agente requiere. Los programas de gobernanza de datos de IA que empiezan con documentos de política pero omiten la arquitectura de identidad solo resuelven la mitad fácil del problema. Shadow AI — agentes y herramientas de IA que operan fuera de cualquier programa de identidad autorizado — es la consecuencia directa de esa brecha: agentes sin gobierno que la organización no puede ver, delimitar ni atribuir acciones cuando surge un incidente.
El Informe Anual de Pronóstico de Seguridad de Datos y Riesgo de Cumplimiento 2026 de Kiteworks identifica la gobernanza de IA como una de las prioridades clave de seguridad de datos que enfrentan las organizaciones este año. Los hallazgos de Okta refuerzan esa conclusión desde otra perspectiva: las herramientas agentes han sido adoptadas más rápido que los controles de identidad y acceso de confianza cero necesarios para gobernarlas. Los programas de gestión de riesgos de la cadena de suministro que extienden los requisitos de gobernanza de identidad a proveedores de IA de terceros — cubriendo los agentes que esos proveedores implementan dentro de los entornos de los clientes, no solo las herramientas que los clientes implementan por sí mismos — cierran la brecha de identidad en la cadena de suministro que los datos de Okta sugieren que la mayoría de las organizaciones aún no ha delimitado.
Cómo Kiteworks da a cada agente de IA su propia identidad verificable
Kiteworks aborda este problema desde el mismo punto de partida que señalan los hallazgos de Okta: humanos y agentes de IA son identidades de primer nivel que deben autenticarse, autorizarse y registrarse individualmente, bajo una sola capa de gobernanza y no dos separadas. El Control Plane de Kiteworks gobierna cada solicitud de contenido confidencial, ya provenga de una persona, una aplicación o un agente, mediante ese modelo único, de modo que el acceso de un agente nunca se canaliza por un atajo como una credencial humana prestada o una cuenta de servicio sin gestión.
El Secure MCP Server es la pieza diseñada específicamente para este momento. Autentica mediante OAuth 2.0, con el token de acceso almacenado en el almacén seguro de credenciales del sistema operativo en vez de en cualquier lugar donde el modelo de IA pueda leerlo, copiarlo o filtrarlo. Esto es un diseño radicalmente distinto a entregar a un agente una clave API estática o una contraseña humana compartida: el agente nunca posee una credencial que pueda exponer por medio de un prompt, un archivo de registro o una sesión comprometida. Cada operación que realiza el agente, ya sea leer un archivo, navegar por una carpeta o recuperar contenido para una tarea, se evalúa en tiempo real contra políticas RBAC y ABAC y se registra de forma individual, no agrupada en una entrada genérica que simplemente dice que lo hizo una persona. Esa es la respuesta estructural a la advertencia de Fei Liu: cuando la credencial nunca sale del almacén seguro y cada acción se autoriza y registra individualmente, no hay identidad compartida que el registro de auditoría pueda perder de vista. El CISO Dashboard muestra esta telemetría de auditoría a nivel de agente en tiempo real, dando al liderazgo de seguridad la visibilidad unificada sobre todos los eventos de acceso a contenido mediado por IA que el informe de Okta identifica como ausente en la mayoría de las implementaciones actuales.
Kiteworks Compliant AI aplica esa misma disciplina a lo que los agentes pueden ver y usar, no solo a cómo se autentican. La aplicación de políticas a nivel de contenido determina a qué puede acceder o qué puede retener un agente antes de que el contenido llegue a la ventana de contexto del modelo, de modo que el límite de identidad y el límite de datos se refuercen mutuamente en vez de depender uno completamente del otro. La minimización de datos aplicada en esta capa — asegurando que cada agente reciba solo el contenido mínimo que su tarea requiere — reduce el radio de exposición cuando se expone una credencial de agente, ya que el alcance accesible del agente ya está limitado por diseño.
Cómo construir un modelo de control de acceso segmentado por agente con RBAC y ABAC
Resolver la brecha de identidad significa ir más allá de «¿este agente tiene una credencial?» hacia «¿este agente específico, para esta tarea concreta, tiene el permiso exacto que necesita ahora?». Es una cuestión de roles y atributos, no de aprovisionamiento estático.
El control de acceso basado en roles (RBAC) da a cada agente un rol definido y limitado a su función real. Por ejemplo, un agente de resumen que solo necesita acceso de lectura a los documentos que resume, o un agente de flujos de trabajo que archiva registros y necesita acceso de escritura a una carpeta específica, y nada más en ambos casos. El control de acceso basado en atributos (ABAC) añade contexto a ese rol: la clasificación de sensibilidad del contenido, el momento de la solicitud, el entorno de implementación del agente y la tarea que está ejecutando influyen en si una solicitud es autorizada. Juntos, RBAC y ABAC permiten a la organización conceder a un agente exactamente el acceso que su tarea requiere y nada de lo que podría necesitar algún día, lo opuesto a cómo se aprovisionan la mayoría de las cuentas de servicio hoy en día.
Este modelo también produce algo que el informe de Okta destaca como ausente: un registro de auditoría limpio donde cada entrada nombra a un agente real, vinculado a una tarea concreta, evaluado contra una política específica, no el nombre de una persona sustituyendo un trabajo que nunca hizo. Cuando una revisión de incidentes o una auditoría de cumplimiento pregunta qué ocurrió, la respuesta ya está en el registro, atribuida correctamente desde el principio. Un plan documentado de respuesta a incidentes que cubra escenarios de mal funcionamiento de agentes de IA — específicamente los pasos para aislar una identidad de agente comprometida, revocar sus credenciales y delimitar qué contenido accedió — convierte el registro de auditoría limpio en una capacidad operativa de respuesta, no solo en un activo forense.
Qué deben hacer las empresas ahora para cerrar la brecha de identidad de los agentes de IA
La magnitud del conjunto de datos de Okta (cuatro años, más de 20,000 organizaciones, más de 100 productos de IA) deja claro que este no es un problema limitado a los primeros adoptantes ni a los rezagados. Es casi universal, lo que significa que la mayoría de los equipos de seguridad e identidad tienen trabajo por hacer, sin importar cuán maduro sea su programa de gobernanza de IA.
Algunos puntos de partida surgen directamente de los hallazgos del informe. Primero, haz un inventario de cada agente de IA que opera actualmente en el entorno e identifica exactamente qué credencial utiliza: cuenta de servicio, clave API o inicio de sesión humano. No puedes corregir lo que no has mapeado. Segundo, trata cualquier agente que se autentique mediante un inicio de sesión humano compartido como una prioridad inmediata de remediación, ya que ese patrón produce la mayor pérdida de registro de auditoría descrita en el informe. Tercero, evalúa si tu infraestructura actual de IAM realmente puede aprovisionar identidades segmentadas y distintas para actores no humanos, o si fue construida solo pensando en personas. Cuarto, construye las decisiones de acceso de agentes en torno a los principios de intercambio de datos de confianza cero: verifica cada solicitud, concede el acceso mínimo necesario y registra el resultado, en vez de confiar en un agente solo porque corre bajo una cuenta determinada. Una evaluación de riesgos formal que mapee el tipo de credencial y permisos actuales de cada agente frente a los requisitos reales de su tarea — e identifique dónde las credenciales compartidas o las cuentas de servicio sobreaprovisionadas crean una exposición inaceptable — es la base probatoria para una hoja de ruta de remediación priorizada.
Nada de esto requiere esperar a una filtración para justificar el trabajo. Los datos de Okta describen una brecha estructural en cómo las empresas autorizan agentes de IA hoy, no un riesgo hipotético a futuro. Cerrarla ahora, mientras la adopción de IA agente sigue acelerándose, es mucho más económico que intentar reconstruir un registro de auditoría después de descubrir que nunca existió.
Para saber más sobre cómo dar a los agentes de IA su propia identidad gobernada en vez de credenciales humanas prestadas, agenda una demo personalizada hoy.
Preguntas frecuentes
El Okta Enterprise AI Index es un informe basado en datos de inicio de sesión anonimizados de más de 20,000 organizaciones desde junio de 2022 hasta junio de 2026, que abarca más de 100 productos de IA distintos consolidados en 74 suites de proveedores. Rastrea cómo las empresas adoptan herramientas de IA y, especialmente, cómo se autentican y autorizan esas herramientas dentro de los entornos corporativos. El informe encontró que los agentes de IA siguen siendo autorizados comúnmente a través de cuentas de servicio, claves API estáticas o inicios de sesión humanos compartidos, en lugar de identidades segmentadas específicamente para el agente. Las organizaciones que evalúan su propia exposición a este patrón pueden comenzar revisando cómo su infraestructura de IAM aprovisiona actualmente actores no humanos. Aquellas sujetas a obligaciones de cumplimiento normativo — HIPAA, GDPR, CMMC — deben tratar la brecha de autenticación documentada por el informe de Okta como un hallazgo de cumplimiento, ya que estos marcos exigen controles de acceso y registros de auditoría demostrables sin importar si el actor es un humano o un agente.
Una cuenta de servicio suele aprovisionarse una sola vez con permisos amplios para cubrir cualquier cosa que el agente pueda necesitar, y rara vez se revisa después. Eso significa que el agente a menudo tiene mucho más acceso del que su tarea requiere, y cada acción que realiza se atribuye a la cuenta en vez de a una tarea específica y rastreable. Esto rompe el principio de mínimo privilegio y debilita los controles de acceso que los marcos de cumplimiento esperan que las organizaciones mantengan. Las identidades segmentadas por agente, en cambio, pueden limitarse exactamente a lo que una tarea requiere. La minimización de datos aplicada al alcance de la cuenta de servicio — aprovisionando a cada agente solo con acceso a las fuentes de datos específicas que su tarea designada requiere — es la práctica operativa que convierte el mínimo privilegio de una intención de política en una realidad en tiempo de ejecución.
Cuando un agente de IA se autentica usando las credenciales de una persona, cada acción que realiza se registra bajo la identidad de esa persona, aunque la persona nunca haya realizado esas acciones. Esto hace que sea prácticamente imposible distinguir la actividad humana de la del agente durante una investigación de seguridad, una auditoría de cumplimiento o un proceso de respuesta a incidentes. Fei Liu de Okta lo describe con precisión: una vez que un agente hereda un inicio de sesión humano, el registro de auditoría se pierde porque el registro ya no refleja quién o qué hizo realmente el trabajo. Las credenciales segmentadas por agente evitan esto asegurando que cada entrada en el registro nombre al actor real. Las organizaciones también deben verificar que sus configuraciones de alertas SIEM traten los patrones anómalos en los registros atribuidos a agentes — horarios de acceso inesperados, volúmenes de datos inusuales o solicitudes de recursos fuera de alcance — como señales de detección de alta prioridad y no como ruido de fondo.
El Secure MCP Server es el punto de conexión gobernado de Kiteworks para agentes de IA que usan el Model Context Protocol para acceder a contenido empresarial. En vez de emitir una credencial estática que el agente pueda poseer o exponer, autentica mediante OAuth 2.0 con el token almacenado en el almacén seguro de credenciales del sistema operativo, y evalúa cada solicitud en tiempo real contra políticas RBAC y ABAC. Esto mantiene las credenciales completamente fuera del alcance del agente, que es justamente el modo de falla que describe el informe de Okta cuando los agentes heredan inicios de sesión humanos. La clasificación de datos aplicada al contenido gobernado por el Secure MCP Server hace que la aplicación de ABAC sea precisa — las decisiones de acceso pueden distinguir entre contenido público y contenido confidencial en el momento de cada solicitud del agente, en vez de aplicar un solo permiso general al alcance completo del agente.
No necesariamente. El paso más urgente es aprovisionar a los agentes de IA como su propia clase de identidad gobernada, junto a los usuarios humanos y bajo las mismas políticas, en vez de canalizar agentes por sesiones humanas o cuentas de servicio genéricas como atajo. Kiteworks lo hace a través del Control Plane de Kiteworks, que gobierna el acceso, uso e intercambio de contenido confidencial tanto para humanos como para agentes bajo un solo conjunto de políticas, combinado con controles RBAC y ABAC segmentados según la tarea real de cada agente. Una evaluación de riesgos que mapee qué agentes operan actualmente con credenciales compartidas — y priorice la remediación según la sensibilidad del contenido al que esas credenciales pueden acceder — da a los equipos de identidad y seguridad el punto de partida enfocado que hace que la remediación de identidad de agentes sea manejable y no abrumadora.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección asequible de la privacidad en IA - Artículo del Blog
Cómo el 77% de las organizaciones está fallando en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: Por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.