Cuando un agente de inteligencia artificial accede a tu sistema de facturación, consulta tu CRM o aprueba un pago en tu nombre, ¿quién ha hecho eso exactamente? Técnicamente, un software.

Pero con qué permisos, bajo qué identidad y dejando qué rastro son preguntas que hoy la mayoría de las empresas no pueden responder con precisión. Eso es exactamente lo que la Coalition for Secure AI (CoSAI) ha decidido abordar.

Qué es CoSAI y quién está detrás

CoSAI es una iniciativa de seguridad para la IA que opera bajo el paraguas de OASIS Open, el consorcio internacional de estándares y código abierto. La integran como patrocinadores fundadores Google, Microsoft, IBM, NVIDIA, Anthropic, Amazon, Cisco, OpenAI, PayPal y Meta, entre otras cuarenta organizaciones. No es una coalición menor: es, en la práctica, la hoja de ruta conjunta de casi toda la industria tecnológica de primer nivel sobre cómo construir sistemas de IA seguros.

El 20 de marzo de 2026, su Comité Técnico ha aprobado un documento de trabajo titulado Agentic Identity and Access Management, que establece cómo deben gestionarse las identidades y los accesos de los agentes de IA autónomos en entornos empresariales.

El problema que nadie había resuelto del todo

Los sistemas de gestión de identidades y accesos que usan las empresas hoy, los que deciden quién puede entrar a qué sistema y con qué permisos, han sido diseñados para personas. Para empleados que se autentican una vez, tienen un rol más o menos estable y actúan de forma predecible.

Los agentes de IA no funcionan así. Son efímeros, pueden ser miles ejecutándose en paralelo, actúan en nombre de usuarios distintos al mismo tiempo, encadenan llamadas a múltiples sistemas y su comportamiento es no determinista: el mismo agente puede hacer cosas diferentes según el contexto. Darles una cuenta de servicio compartida, que es lo que muchas empresas hacen hoy, es como dar las llaves de todo el edificio a alguien sin dejar rastro de quién entró a qué habitación.

El documento de CoSAI pone nombre a los escenarios de fallo que ya se están dando: un agente con tareas de facturación con accesos muy amplios que es manipulado mediante prompt injection para alterar registros de proveedores, un agente de soporte que encadena herramientas de CRM y correo para filtrar datos personales al exterior, o un agente de operaciones que usa credenciales reutilizadas de un ingeniero humano para modificar configuraciones de producción dejando logs ambiguos.

Lo que propone el documento

La propuesta central es tratar a los agentes de IA como identidades de primer nivel, con su propio ciclo de vida, sus propios permisos y su propia trazabilidad, del mismo modo que se trata a un empleado o a un sistema de software tradicional. Cada agente debería tener una identidad única, de corta duración, vinculada al código exacto y a la versión del modelo que está ejecutando en ese momento.

El documento articula nueve principios, entre los que destacan tres con implicaciones prácticas inmediatas.

El primero es el privilegio cero permanente: un agente no debería tener accesos de larga duración «por si acaso». Sus credenciales deberían ser de corta duración, acotadas a la tarea concreta que está ejecutando. Si el agente termina su trabajo, sus permisos caducan.

El segundo es la separación entre lo que el agente puede hacer por sí mismo y lo que puede hacer en nombre de un usuario. Cuando actúa en tu nombre, esa delegación tiene que ser explícita, visible en los logs y acotada: no puede heredar todos tus permisos sin más.

El tercero es la aplicación en cada salto. En una cadena de agentes, donde un agente orquestador delega en sub-agentes, la autenticación y la autorización tienen que verificarse en cada paso, no solo en el punto de entrada. De lo contrario, un agente comprometido en el medio de la cadena puede escalar privilegios que no le corresponden.

Aunque el documento está orientado a entornos corporativos, el problema que describe es más amplio. A medida que los agentes de IA se integran en más servicios, desde asistentes personales hasta plataformas que gestionan tus finanzas o tu salud, la pregunta de con qué identidad actúan y qué rastro dejan se vuelve también una cuestión de privacidad y de derechos del usuario.

El RGPD ya establece que cualquier tratamiento de datos personales tiene que ser trazable y atribuible a un responsable. Si un agente de IA accede a datos personales y no existe una identidad clara que responda por esa acción, hay un problema de cumplimiento normativo que va más allá de la seguridad técnica.

¿Normativa futura?

El documento de CoSAI no es una normativa vinculante. Es una propuesta técnica de un consorcio con suficiente peso en la industria como para influir en cómo se desarrollan los estándares que vendrán después. El mismo camino que han seguido otras especificaciones de OASIS que luego han terminado siendo referenciadas en regulaciones europeas y contratos públicos.

Lo que sí deja claro es que la industria ha reconocido oficialmente que los sistemas actuales de gestión de identidades no están preparados para el mundo de los agentes autónomos, y que hay consenso sobre el tipo de controles que hacen falta. Para las empresas que ya están desplegando agentes de IA, el documento es también una lista de comprobación de lo que probablemente se les va a exigir en los próximos años.

El documento completo, en inglés, está disponible en la web de CoSAI.