Autenticación de identidad de agentes y la cadena de delegación

Cada marco de cumplimiento que regula el acceso a datos confidenciales plantea la misma pregunta fundamental: ¿quién autorizó esto? Para los empleados humanos, la respuesta es sencilla: credenciales autenticadas, acceso basado en roles y una trazabilidad que vincula cada evento de acceso con una persona específica. Para los agentes de IA, la mayoría de las organizaciones actualmente no tiene respuesta. El agente opera bajo una cuenta de servicio. La cuenta de servicio se autentica en el sistema. Y cuando el auditor pregunta quién autorizó al agente a acceder a ese registro de paciente, a ese documento CUI o a ese portafolio de cliente, la respuesta honesta es: no lo sabemos.

Esto no es una brecha teórica. La HIPAA §164.312(a)(2)(i) exige identificación única de usuario para cada persona o programa de software que accede a ePHI. CMMC AU.2.042 requiere que las actividades de los procesos que actúan en nombre de usuarios autorizados sean rastreables hasta esos usuarios. La Regla 204-2 de la SEC exige que los registros de actividades de asesoría sean atribuibles a individuos autorizados. Ninguno de estos requisitos hace una excepción para los agentes de IA, y ninguno se cumple con una credencial de cuenta de servicio que comparten cinco agentes.

En este artículo se explica qué exige la identidad autenticada de agentes, cómo la cadena de delegación conecta las acciones del agente con la responsabilidad humana y por qué este es el principio fundamental de gobernanza del que dependen todos los demás controles de cumplimiento para agentes de IA.

Resumen Ejecutivo

Idea principal: Identidad autenticada de agente significa que cada agente de IA tiene una credencial de identidad única y verificable a nivel de flujo de trabajo, distinta de las cuentas de servicio compartidas, vinculada al humano específico que autorizó el flujo de trabajo. La cadena de delegación es el registro documentado de ese vínculo: humano autorizador, identidad del agente y evento de acceso a datos regulados. Sin esto, ninguna trazabilidad de auditoría está completa, ningún control de acceso es atribuible y ninguna postura de cumplimiento para agentes de IA es defendible.

Por qué te debe importar: La cadena de delegación no es solo una formalidad de cumplimiento. Es el mecanismo que da sentido a todos los demás controles de gobernanza de IA. Las políticas ABAC dependen de saber qué agente realiza la solicitud. Los registros de auditoría con evidencia de manipulación dependen de tener algo atribuible que registrar. Los paquetes de evidencia regulatoria dependen de poder demostrar quién autorizó qué. Una implementación de IA sin identidad autenticada de agente y una cadena de delegación preservada no puede demostrar cumplimiento, sin importar cuán sólidos sean los demás controles.

Puntos clave

1. Las cuentas de servicio compartidas no son identidad de agente. Una cuenta de servicio autentica un sistema, no un agente ni un flujo de trabajo. Cuando varios agentes comparten una credencial, ningún evento de acceso en el registro resultante puede atribuirse a un agente específico, un flujo de trabajo específico o al humano que lo autorizó. Eso no es una trazabilidad incompleta: es una inexistente.
2. La identidad única de agente debe asignarse a nivel de flujo de trabajo, no a nivel de sistema. La unidad de autenticación es la instancia del flujo de trabajo: este agente, ejecutando esta tarea, autorizado por esta persona, en este momento. Las cuentas de servicio a nivel de sistema no pueden ofrecer esta granularidad. Las credenciales de identidad a nivel de flujo de trabajo sí pueden.
3. La cadena de delegación debe capturarse en el momento del acceso, no reconstruirse después. Al igual que los registros de auditoría, los registros de la cadena de delegación no pueden crearse retroactivamente. Si el evento de autenticación no vincula al agente con su humano autorizador en el momento en que se emite la credencial y ocurre el evento de acceso, ese vínculo nunca existirá. No hay reconstrucción forense que lo recupere después.
4. La responsabilidad humana no termina cuando el agente actúa de forma autónoma. Un agente de IA que opera de manera autónoma dentro de un flujo de trabajo sigue actuando en nombre del humano que autorizó ese flujo. La responsabilidad regulatoria sigue la delegación, no la ejecución. El humano autorizador es responsable de lo que haga el agente dentro del alcance delegado, por eso la cadena de delegación debe documentarse.
5. La identidad de agente es el requisito previo para cualquier otro control de cumplimiento. La evaluación de políticas ABAC requiere una identidad de agente conocida para comparar. El registro de auditoría requiere algo a lo que atribuir. El alcance de acceso necesita un principal definido cuyo alcance pueda limitarse. Sin identidad autenticada de agente, ninguno de estos controles puede funcionar como se diseñó.

Qué exige la identidad autenticada de agente

La identidad autenticada de agente no es lo mismo que la autenticación del sistema. Un servidor que se autentica en una base de datos con una cuenta de servicio prueba que el servidor está autorizado para conectarse. No dice nada sobre qué agente está operando en ese servidor en ese momento, bajo qué autorización de flujo de trabajo o en nombre de quién. Para el cumplimiento, estas distinciones lo son todo.

Identidad única por instancia de flujo de trabajo

Los marcos de cumplimiento exigen que los eventos de acceso sean atribuibles a una entidad autorizada específica. Para agentes de IA, la entidad relevante es la instancia del flujo de trabajo: el agente específico ejecutando una tarea concreta bajo la autorización de un humano específico. Esto requiere que las credenciales de identidad se asignen a nivel de flujo de trabajo: no compartidas entre agentes, no reutilizadas entre sesiones, no agrupadas entre tipos de agentes. Una credencial que identifica de manera única «el agente de documentación clínica que procesa el resumen de alta del Encuentro de Paciente #4471, autorizado por la Dra. Chen a las 9:14 AM del 15 de marzo» es fundamentalmente diferente de una credencial que identifica «la cuenta de servicio de documentación clínica».

La implementación práctica es un token de identidad emitido al iniciar el flujo de trabajo: el humano autorizador se autentica, delega un alcance de tarea específico al agente y la credencial resultante vincula la identidad del agente con la del autorizador durante la duración de ese flujo de trabajo. El token lleva la cadena de delegación en sus atributos, y cada acceso a datos que el agente realice bajo ese token se atribuye automáticamente tanto al agente como a su humano autorizador.

Autenticación independiente del modelo

La autenticación de identidad de agente debe realizarse en la capa de gobernanza de datos, no dentro del modelo. Un modelo que «sabe» que está operando como el Agente A tiene ese conocimiento como parte del prompt, lo que puede sobrescribirse por inyección, alterarse por actualizaciones del modelo o simplemente ignorarse si el comportamiento del modelo cambia. La autenticación aplicada en la capa de datos, por la infraestructura de gobernanza que controla el acceso a datos regulados, no puede ser anulada por el comportamiento del modelo. El agente presenta credenciales; la capa de gobernanza las verifica; el acceso se permite o deniega según lo que esas credenciales autoricen. El conocimiento del modelo sobre su propia identidad no es relevante en este proceso.

Alcance de la credencial para el flujo de trabajo autorizado

La credencial de identidad debe codificar el alcance autorizado del agente: no solo quién es, sino qué puede hacer. Una credencial que identifica al agente pero le otorga acceso amplio al repositorio no cumple con el principio de mínimo necesario de HIPAA ni con el requisito mínimo necesario AC.2.006 de CMMC. La credencial debe codificar las categorías de datos autorizadas, las operaciones permitidas y el contexto del flujo de trabajo que las delimita. Este es el puente entre la identidad autenticada y la aplicación de políticas ABAC: la identidad establece quién es el agente; los atributos de alcance de la credencial establecen qué está autorizado a hacer.

La cadena de delegación: qué es y qué debe contener

La cadena de delegación es el registro documentado que conecta un evento de acceso a datos regulados, realizado por un agente de IA, con el humano que autorizó el flujo de trabajo que lo generó. No es un solo registro, sino una secuencia enlazada: el humano autorizador autoriza el flujo de trabajo, el flujo de trabajo emite la credencial del agente, la credencial del agente regula el acceso a los datos, el acceso a los datos produce una entrada en el registro de auditoría y la entrada del registro de auditoría referencia tanto la identidad del agente como la autorización original. Cada eslabón de esa cadena debe estar presente y ser a prueba de manipulaciones para que la cadena cumpla los requisitos regulatorios.

Qué debe contener cada eslabón

La cadena es tan fuerte como su eslabón más débil. Un evento de autorización que no registre el alcance específico delegado. Una credencial de agente que no vincule al humano autorizador. Un registro de acceso a datos que registre la operación pero no la identidad del agente. Cada brecha rompe la cadena en ese punto, y una cadena rota no puede presentarse a un regulador como evidencia de acceso autorizado.

Por qué la cadena debe preservarse en el registro y no ser reconstruible desde él

Un error común es pensar que la información de la cadena de delegación puede inferirse de los registros existentes después del hecho, cruzando marcas de tiempo, correlacionando la actividad de cuentas de servicio con calendarios de quién estaba trabajando, o emparejando llamadas API con IDs de trabajos de flujo de trabajo. Este proceso de inferencia no produce una cadena de delegación. Produce una hipótesis sobre lo que pudo haber ocurrido. Los reguladores exigen evidencia, no hipótesis. La cadena de delegación debe estar incrustada en cada entrada de registro de acceso como parte de la arquitectura, no reconstruida a partir de registros circunstanciales como parte de una investigación forense.

Cómo Kiteworks implementa la identidad autenticada de agente y la preservación de la cadena de delegación

La Red de Datos Privados de Kiteworks implementa la identidad autenticada de agente y la preservación de la cadena de delegación como parte fundamental de su arquitectura: es el primero de los cuatro puntos de control de gobernanza por los que pasa cada interacción de un agente de IA con datos regulados antes de que se conceda el acceso.

Emisión de credenciales a nivel de flujo de trabajo

Cuando un humano autorizador delega un flujo de trabajo a un agente de IA a través de Kiteworks, la plataforma emite una credencial de identidad única para esa instancia de flujo de trabajo. La credencial está vinculada al humano autorizador específico, codifica el alcance de datos autorizado y las operaciones permitidas, lleva una expiración asociada a la duración del flujo de trabajo y no puede reutilizarse entre instancias de flujo de trabajo ni compartirse entre agentes. Ninguna instancia de flujo de trabajo comparte credencial, lo que significa que cada evento de acceso bajo esa credencial es atribuible de manera única a un solo flujo de trabajo, un solo agente y un solo humano autorizador.

Cadena de delegación en cada entrada de registro de auditoría

Cada evento de acceso a datos procesado a través de Kiteworks genera una entrada en el registro de auditoría que incluye la cadena de delegación completa: la identidad autenticada del humano autorizador, la credencial de agente a nivel de flujo de trabajo, los datos específicos accedidos, la operación realizada, el resultado de la evaluación de políticas y una marca de tiempo a prueba de manipulaciones. Esta entrada se crea en el momento del acceso, no es reconstruible después. Se envía directamente al SIEM de la organización y es el registro que cumple simultáneamente con HIPAA §164.312(a)(2)(i), CMMC AU.2.042 y la Regla 204-2 de la SEC para cada interacción de agentes de IA con datos regulados.

Integración con la evaluación de políticas ABAC

La identidad autenticada de agente y la cadena de delegación no solo cumplen los requisitos de auditoría, sino que permiten que el Motor de Políticas de Datos evalúe cada solicitud de acceso con precisión. La evaluación de políticas no es «¿este tipo de agente puede acceder a esta categoría de datos?», sino «¿esta instancia específica de agente, operando bajo esta autorización humana específica, puede realizar esta operación específica sobre este registro de datos específico en este momento?». Esa granularidad solo es posible porque la identidad y la cadena de delegación están presentes. Sin ellas, la evaluación de políticas se reduce al alcance de acceso por sesión o tipo de agente, lo cual no satisface el principio de mínimo necesario de HIPAA, CMMC AC.2.006 ni las prácticas 3.1.1 y 3.1.2 de NIST 800-171.

La autenticación de identidad de agente y la preservación de la cadena de delegación no son características de una implementación de IA conforme: son la base sobre la que se construyen todos los demás controles de cumplimiento. Descubre más sobre Kiteworks Compliant AI o agenda una demo.

Recursos adicionales

• Artículo del Blog
  Estrategias Zero‑Trust para una protección de privacidad de IA asequible
• Artículo del Blog
  Cómo el 77% de las organizaciones falla en la seguridad de datos de IA
• eBook
  Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juegan 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.