Este es el sexto blog de una serie de siete partes sobre la seguridad de la identidad como base de la seguridad de la IA.
En resumen:
Los agentes de IA recuperan datos utilizando los permisos de quien se autentica (correcto), pero los envían a espacios de trabajo compartidos donde los destinatarios tienen permisos mixtos (incorrecto). Por ejemplo, el agente de un director financiero en un canal de Slack puede exponer salarios de nivel ejecutivo a analistas junior. Cuatro vulnerabilidades críticas (CVSS 9.3-9.4) afectaron a Anthropic, Microsoft, ServiceNow y Salesforce en 2025. El patrón fue siempre el mismo: recuperación autorizada, pero destinatarios no autorizados. La solución requiere una autorización detallada que calcule la intersección de los permisos de todos los destinatarios antes de que los datos salgan de la capa de recuperación, un paso que ocurre después de que el trabajo de OAuth está hecho.
El problema
OAuth se diseñó para un mundo más simple: un usuario, una aplicación y un conjunto de permisos. Los agentes de IA rompen con ese modelo, pues funcionan en contextos compartidos donde varias personas ven lo que el agente produce. Ni el protocolo ni las plataformas que se crearon con dicho protocolo anticiparon algo así.
Esto hace que el agente de IA herede un acceso de nivel ejecutivo y lo transmita a todos los demás usuarios. Según McKinsey, el 80 % de las organizaciones ya se toparon con comportamientos riesgosos de los agentes de IA, entre ellos, la exposición inadecuada de datos y el acceso a sistemas sin autorización. Y tienen motivos de sobra para preocuparse.
¿Qué sucede en la práctica? El documento técnico de OpenID Foundation sobre la IA de agentes describe esta situación:
Un director financiero implementa un agente de IA en un canal de Slack. El agente se autentica con las credenciales del director financiero y hereda el acceso a datos de salarios, materiales de la junta directiva y sistemas de RR. HH. Un analista junior pregunta: “¿Cuál es nuestro presupuesto de compensación para el tercer trimestre?". El agente recupera hojas de cálculo de presupuesto, planes de compensación y cronogramas de salarios de nivel ejecutivo. ¿El director financiero tiene acceso a estos archivos? Sí. Lo que hace el agente es responder al canal. Esto significa que, ahora, el analista junior conoce el salario del CEO. Y también todas las personas que estén en ese canal.
El agente actuó exactamente como se esperaba. El problema es el modelo de autorización.
El patrón: cuatro plataformas, un factor común
Entre junio y octubre de 2025, cuatro vulnerabilidades de gravedad crítica revelaron un patrón. Estas vulnerabilidades no son idénticas, pero comparten un factor común: la autorización se verifica al momento de recuperar los datos, no al momento de producir la respuesta.
Servidor MCP de Slack de Anthropic, julio de 2025
Johann Rehberger descubrió la primera vulnerabilidad crítica de MCP. Cuando los agentes publican en Slack, la plataforma “despliega” los hipervínculos para generar vistas previas. Un atacante inyecta un prompt que hace que el agente, que opera con permisos OAuth de administrador, lea archivos confidenciales e inserte esos datos en una URL. Los bots de vista previa de Slack obtienen la URL y completan la exfiltración sin clics. Anthropic archivó el servidor en lugar de aplicar un parche. Recuperación: permisos de administrador (correcto). Destino de la respuesta: servidor del atacante (incorrecto).
Microsoft 365 Copilot (EchoLeak), junio de 2025
Aim Security reveló el primer ataque sin clics contra un agente de IA de producción. Un atacante envía un correo electrónico con instrucciones ocultas y el destinatario nunca lo abre. El motor RAG de Copilot ingiere la carga útil junto con los archivos de SharePoint y OneDrive. Luego, codifica los datos confidenciales en una URL de salida que omite la política de seguridad de contenido. Los investigadores llamaron a esto “infracción del alcance de LLM”: el agente combinó datos no confiables con datos confiables sin aislar los límites de confianza. Microsoft implementó una solución, pero el patrón continúa. Recuperación: permisos M365 de la víctima (correcto). Destino de la respuesta: URL del atacante (incorrecto).
Plataforma de IA de ServiceNow (BodySnatcher), octubre de 2025
Aaron Costello de AppOmni descubrió que Virtual Agent y Now Assist confiaban en un secreto codificado y una dirección de correo electrónico para vincular cuentas. Un atacante que solo conociera el correo electrónico de un objetivo podría hacerse pasar por cualquier usuario, incluidos los administradores, y evitar por completo la MFA. Una vez realizada la suplantación, los atacantes invocan a agentes de IA con todos los privilegios de la víctima para acceder a registros del ITSM o activar flujos de trabajo privilegiados. Costello llamó a este problema “la vulnerabilidad de IA más grave detectada hasta la fecha”. Recuperación: permisos del usuario suplantado (correcto). Identidad del solicitante: atacante (incorrecto).
Salesforce Agentforce (ForcedLeak), septiembre de 2025
Noma Security descubrió que la inyección de prompts a través de formularios de la web a clientes potenciales permitía la exfiltración de datos de CRM. Un atacante envía un formulario con instrucciones ocultas; cuando un empleado le pregunta a la IA sobre ese cliente potencial, el agente ejecuta ambas solicitudes. Lo peor es que el dominio my-salesforce-cms.com permanecía en la lista de dominios autorizados a pesar de haber caducado. Los atacantes compraron el dominio por USD 5 y crearon un canal de exfiltración de confianza. Recuperación: permisos de CRM del empleado (correcto). Destino de la respuesta: dominio del atacante (incorrecto).
El factor común es que cada sistema verificaba si el usuario que invocaba la información podía acceder a los datos. Ninguno comprobaba si los destinatarios de la información estaban autorizados a recibirla.
Lo que nunca se le pidió a OAuth
Durante dos décadas, OAuth funcionó porque las aplicaciones devolvían datos al mismo usuario que autorizaba el acceso. Los agentes de IA echan por tierra esta premisa. Los agentes se autentican de diferentes maneras: con credenciales de usuario delegadas, con sus propias identidades de servicio o como automatizaciones creadas por el usuario y compartidas con otros. El patrón varía, pero el problema es el mismo: responden en contextos compartidos donde varias personas ven la respuesta.
Por lo tanto, la autorización ocurre durante la recuperación, pero no se realiza ninguna verificación al momento de responder. Los contextos donde hay varios públicos exigen que OAuth amplíe la autorización para que tenga en cuenta al público. En las especificaciones de OAuth, el “público” es la API de destino. Sin embargo, en este caso, nos referimos a algo diferente: las personas que ven lo que el agente responde.
OAuth sienta las bases. Ampliar su capacidad de autorización para que incluya al público es lo que ayuda a que los agentes de IA sean seguros.
¿Qué arquitectura resuelve esto?
Para solucionar este problema, hace falta una autorización que tenga en cuenta al público. Es decir, la capa de autorización debe conocer al público antes de la recuperación y calcular la intersección de permisos en tiempo real. Así, el agente responde solo con los datos que cada integrante del público tiene autorización para ver.
La arquitectura implica el funcionamiento simultáneo de tres componentes:
Motor de autorización detallada. Modela los permisos como relaciones, no como roles estáticos. Calcula en milisegundos la intersección de aquello a lo que todos los integrantes del público pueden acceder.
Capa de gestión de credenciales. Almacena tokens de OAuth para aplicaciones conectadas. Emite credenciales con alcance definido a los agentes según la intersección de permisos calculada.
Gobernanza de identidad. Mantiene la precisión del gráfico de permisos a través de la revisión y el saneamiento continuos. Sin permisos precisos, el cálculo de la intersección genera respuestas incorrectas.
Flujo de intersección de permisos
En resumen: Desde el inicio, los datos del salario del CEO no se recuperan. El token emitido al agente no tiene acceso. No se trata de filtrar después de la recuperación, sino de definir el alcance antes de la recuperación.
¿No es más fácil usar la DLP? La prevención de pérdida de datos (DLP) detecta datos confidenciales después de que aparecen en la respuesta. La autorización detallada evita que se recuperen estos datos desde el principio. La DLP es el cinturón de seguridad. La recuperación con alcance definido evita directamente el impacto.
Cómo resuelven el problema Okta y Auth0
El RBAC tradicional asigna roles estáticos. la FGA modela los permisos como relaciones: “El VP del área de ventas puede ver los datos del presupuesto porque es miembro del canal de finanzas”. Este gráfico de relaciones hace posible el cálculo de intersecciones. Cuando el agente necesita saber a qué datos pueden acceder todos los miembros del canal, la API batchCheck de FGA responde en milisegundos a partir de miles de millones de relaciones.
Token Vault almacena tokens de actualización de OAuth para cualquier aplicación SaaS y gestiona el ciclo de vida del token automáticamente. La capa de orquestación recupera tokens de la bóveda y emite credenciales con alcance definido a los agentes según la intersección de permisos calculada.
Cuando los agentes abarcan múltiples aplicaciones, la autorización debe incluirlas a todas. Cross-App Access extiende OAuth al trasladar el consentimiento y la aplicación de políticas al proveedor de identidades, lo que brinda al área de TI empresarial un control centralizado sobre las conexiones entre agente y aplicación.
La autorización en tiempo real es tan precisa como los datos de permisos subyacentes. Identity Governance ayuda a garantizar que los permisos se revisen y corrijan de forma constante. Cuando los permisos se desvían o se acumulan las cuentas huérfanas, el cálculo de intersecciones produce respuestas incorrectas. La gobernanza mantiene la precisión del gráfico de permisos.
Exigencias normativas
Artículo 32 y Artículo 5(1)(f) del RGPD. El Artículo 32 exige “medidas técnicas y organizativas apropiadas”, incluida la protección contra “la divulgación no autorizada o el acceso a datos personales”. El Artículo 5(1)(f) exige que los datos sean “tratados de tal manera que se garantice una seguridad adecuada”. Cuando un agente de IA revela información de identificación personal (PII) de los empleados a usuarios internos no autorizados, se infringen ambos artículos. Las sanciones pueden alcanzar los 20 millones de euros o el 4 % de los ingresos anuales globales.
CCPA, Sección 1798.150. El derecho privado de acción de California permite a los consumidores presentar una demanda cuando la información personal “está sujeta a acceso y exfiltración, robo o divulgación no autorizados como resultado de la violación por parte de la empresa del deber de implementar y mantener procedimientos de seguridad razonables”. La sobreexposición interna a través de agentes de IA podría infringir este estándar. Daños estatutarios: entre USD 100 y USD 750 por consumidor por incidente.
Sección 404 de la Ley Sarbanes-Oxley. La Sección 404 de esta ley exige a las empresas públicas “establecer y mantener una estructura de control interno adecuada”. Cuando los agentes de IA con permisos ejecutivos pueden revelar información no pública importante a empleados no autorizados, su capacidad para demostrar controles adecuados se ve seriamente socavada. Los auditores podrían señalar esto como una deficiencia significativa.
Como confirma la investigación de McKinsey, el 80 % de las organizaciones ya se han encontrado con comportamientos riesgosos por parte de los agentes de IA, incluida la exposición inadecuada de datos. La FGA calcula las intersecciones de permisos antes de la recuperación para ayudar a abordar directamente estas obligaciones de cumplimiento.
La pregunta para su próxima revisión de seguridad
Pregúntele a su equipo de seguridad: “Por cada agente de IA implementado en un espacio de trabajo compartido, ¿podemos demostrar que el resultado del agente está restringido a los datos que cada integrante de ese espacio de trabajo tiene autorización para ver?"
Si la respuesta es “no”, podría tener una infracción normativa en potencia.
La tecnología para resolver esto ya existe. Descubra cómo Okta y Auth0 protegen a los agentes de IA en okta.com/ai y auth0.com/ai, descargue el documento técnico sobre cómo proteger a los agentes de IA o comuníquese con su representante de Okta para evaluar las brechas de intersección de permisos en sus implementaciones de IA.
A continuación: El séptimo blog reúne los seis desafíos de identidad en un marco unificado.
