PKIaaS para infraestructura de IA y agentes de IA

Los agentes de IA ya no son una hipótesis. Se están implementando en entornos de producción en 2026 para automatizar flujos de trabajo, ejecutar llamadas a API, modificar configuraciones, activar transacciones e interactuar con sistemas críticos a la velocidad y escala de las máquinas. Un único flujo de trabajo de IA basado en agentes puede involucrar a cinco o más agentes que se pasan tareas entre sí, llaman a API externas, leen bases de datos y escriben en registros, todo ello sin intervención humana en cada paso.

La cuestión de seguridad que la mayoría de las organizaciones que implementan estos sistemas no han resuelto por completo es: ¿cómo saber qué agente hizo qué y cómo demostrarlo? La mayoría de los agentes de IA actuales se autentican en las API y los servicios mediante credenciales estáticas: claves de API, secretos de cliente y tokens compartidos. Estas credenciales no contienen ninguna información de identidad más allá de su valor de cadena. Se pueden copiar. No caducan automáticamente. No proporcionan un registro de auditoría que vincule una acción específica con una instancia de agente específica. Y según el Informe de IBM de 2025 sobre el coste de una filtración de datos, el 97 % de las organizaciones que sufrieron filtraciones relacionadas con modelos de IA carecían de controles de acceso a la IA.

La solución al problema de la identidad de los agentes de IA es la misma que resolvió el problema de la identidad de las máquinas para servidores, dispositivos y cargas de trabajo: identidad criptográfica respaldada por una autoridad de certificación controlada. La infraestructura de clave pública como servicio (PKI como servicio) proporciona la infraestructura de CA que emite identidades únicas, efímeras y verificables a los agentes de IA, lo que permite el uso de mTLS para la comunicación entre agentes y servicios, OAuth anclado en certificados para cadenas de delegación y un registro de auditoría que permite atribuir criptográficamente cada acción del agente a una identidad específica.

Respuesta rápida: ¿Qué aporta PKIaaS a la identidad de los agentes de IA?

PKIaaS emite a cada agente de IA un certificado X.509 único que codifica su identidad (nombre, tipo, entorno de implementación, ámbito autorizado y organización emisora). El certificado tiene una duración limitada (de minutos a horas para agentes efímeros; de 24 a 48 horas para agentes persistentes), se renueva automáticamente mediante la infraestructura de identidad y está firmado por la CA de PKIaaS cuya raíz se encuentra en el paquete de confianza de cada servicio al que llama el agente. Cuando el agente realiza una llamada a la API, presenta el certificado; el servicio lo verifica con la CA raíz de PKIaaS; y la conexión solo se establece si la verificación es exitosa. Cada emisión de certificado se registra en el registro de auditoría de PKIaaS, lo que proporciona un registro criptográficamente atribuible de qué agente estuvo activo durante qué período de tiempo y qué acciones estaba autorizado a realizar.

Puntos Clave

• Las credenciales estáticas (claves API, secretos de cliente, tokens compartidos) no permiten la rendición de cuentas de los agentes de IA. No contienen ninguna información de identidad más allá de su valor de cadena, se pueden copiar y compartir entre agentes, no caducan automáticamente y no generan un registro de auditoría que vincule una acción específica con una instancia de agente concreta. La identidad de agente basada en certificados proporciona todas estas propiedades de forma estructural, no mediante políticas que puedan eludirse.
• Incluso los agentes de IA efímeros creados para una sola tarea merecen una identidad criptográfica única. Un certificado con un período de validez de 30 minutos, emitido a un agente de corta duración, implica que, si el certificado se extrae de alguna manera, pierde su validez en ese lapso. La misma clave API, asignada al mismo agente de corta duración, es válida hasta que alguien la reemplace manualmente, lo cual podría no ocurrir nunca.
• El problema de la cadena de delegación es el problema de identidad sin resolver más complejo en la IA con agentes. Cuando el Agente A invoca al Agente B, que llama a una herramienta, la cual desencadena una transacción, cada salto en esa cadena debe ser criptográficamente verificable hasta un ser humano o entidad responsable. La identidad basada en certificados, combinada con el Intercambio de Tokens OAuth 2.0 (RFC 8693) anclado a dichos certificados, proporciona el mecanismo técnico para una cadena de delegación verificable.
• mTLS para la comunicación entre agentes y servicios es el equivalente en IA de la confianza cero para cargas de trabajo. Un agente de IA que presenta un certificado emitido por PKIaaS a una API se verifica criptográficamente antes de procesar cualquier solicitud a nivel de aplicación. Un agente sin un certificado PKIaaS válido es rechazado en la capa TLS, independientemente de si afirma ser un agente autorizado en la carga útil de la aplicación.
• El marco regulatorio para la identidad de los agentes de IA está en constante evolución. El Centro Nacional de Excelencia (NCCoE) del NIST publicó en 2026 un documento conceptual sobre la identidad y autorización de agentes de IA y software. La UIT ha creado un grupo de trabajo sobre la confianza y la identidad de los agentes de IA. Los requisitos de rendición de cuentas y supervisión humana de la Ley de IA de la UE generan obligaciones implícitas de auditabilidad para los sistemas de IA basados ​​en agentes. La identidad basada en certificados es el mecanismo técnico más maduro para satisfacer estos requisitos emergentes.

El problema de la identidad del agente de IA

Los agentes de IA se diferencian del software tradicional en una dimensión de seguridad crucial: actúan de forma autónoma. Un servidor web atiende las solicitudes, pero no las inicia. Un agente de IA hace ambas cosas. Recibe un objetivo, analiza cómo alcanzarlo y ejecuta acciones en múltiples sistemas, API y herramientas de forma secuencial, sin autorización humana en cada paso. La autoridad para realizar dichas acciones se delegó al agente en el momento de su implementación, y los controles sobre lo que el agente puede hacer suelen ser poco precisos: una clave de API con un alcance amplio, una cuenta de servicio con permisos amplios o un token de acceso a nivel de sistema que nunca se definió para la tarea específica del agente.

Esto crea una brecha de identidad y responsabilidad que se agrava con la escala. Cuando una organización implementa diez agentes de IA, la brecha es manejable: alguien sabe a qué tiene acceso cada agente. Cuando la misma organización implementa mil agentes en docenas de flujos de trabajo, nadie puede responder con certeza: ¿qué agente realizó esa llamada a la API a las 2:47 a. m.? ¿Estaba autorizado para hacerlo? ¿Cómo puedo demostrar que la acción la realizó el Agente A y no alguien que obtuvo sus credenciales?

El informe "Panorama de la seguridad de la identidad 2026" de Palo Alto Networks reveló una proporción de 109:1 entre identidades de máquinas e identidades humanas en entornos empresariales. Los agentes de IA constituyen el componente de mayor crecimiento dentro de este conjunto de identidades de máquinas. Gestionar su identidad con el mismo modelo de credenciales estáticas utilizado en los inicios del software empresarial no representa una medida de seguridad, sino una estrategia para acumular riesgos.

¿Por qué fallan las credenciales estáticas para los agentes de IA?

Las credenciales estáticas fallan para los agentes de IA por las mismas razones por las que fallan para cualquier identidad de máquina, magnificadas por la naturaleza autónoma del comportamiento del agente:

No existe vinculación de identidad. Una clave API demuestra que quien realiza la llamada la posee, no que sea el agente autorizado. Si la clave se extrae del entorno del agente, cualquier proceso que la utilice es indistinguible del agente. En un entorno donde los agentes interactúan entre sí (transmitiendo contexto, delegando subtareas, compartiendo acceso temporal), la posibilidad de filtración de credenciales se multiplica con cada interacción entre agentes.

Sin caducidad automática. Las claves API no caducan a menos que alguien las renueve explícitamente. Un agente de IA que se desactiva mantiene su clave API válida hasta que el equipo de operaciones lo detecta y la revoca. En un entorno dinámico donde los agentes se aprovisionan y desactivan para tareas específicas, el problema de las credenciales huérfanas se acumula rápidamente. Un certificado emitido a un agente con un período de validez de 4 horas caduca con el agente, sin generar credenciales huérfanas ni obligación de limpieza.

Sin no repudio. Si un agente de IA causa daños al llamar a una API que no debería haber llamado o al activar una transacción con parámetros incorrectos, la clave de API en el registro de auditoría no identifica de forma concluyente qué agente realizó la llamada si la clave se compartió o si no se realizó un seguimiento de su custodia. Un certificado X.509 con un número de serie específico, emitido para una implementación de agente específica, proporciona no repudio: la entrada del registro de auditoría hace referencia al certificado, el registro de auditoría de PKIaaS registra cuándo se emitió el certificado y a qué identidad de agente, y la cadena de atribución es criptográficamente completa.

Certificados X.509 como identidad de agente de IA

Un certificado X.509 emitido por una CA PKIaaS a un agente de IA codifica la identidad del agente en un formato estandarizado y criptográficamente verificable. Los campos Nombre Distinguido del Sujeto y Nombre Alternativo del Sujeto del certificado contienen los atributos de identidad del agente. Un certificado de identidad de agente bien diseñado podría codificar:

• CN (Nombre común): El nombre del agente y el identificador de versión (por ejemplo, order-processing-agent-v2.1)
• O (Organización): La unidad de negocio o el equipo propietario del agente
• OU (Unidad Organizativa): El entorno de despliegue (producción, preproducción, entorno de pruebas)
• URI SAN: Un ID de SPIFFE si el agente está implementado en un entorno compatible con SPIFFE (spiffe://trust-domain/agents/order-processing)
• Extensiones OID personalizadas: Versión del agente, ámbito de flujo de trabajo autorizado o ID de implementación en extensiones X.509 personalizadas si el modelo de autorización del agente requiere atributos de política en el certificado.

El certificado está firmado por la CA de PKIaaS, lo que permite su verificación por cualquier servicio que incluya el certificado raíz de la CA de PKIaaS en su paquete de confianza. La clave privada correspondiente al certificado se genera en el entorno de ejecución del agente y permanece siempre en él. La CA de PKIaaS firma el certificado basándose en la solicitud de firma de certificado (CSR) del agente, que contiene la clave pública. La clave privada nunca pasa por la CA de PKIaaS, el gestor de secretos ni ninguna infraestructura compartida; reside únicamente en la memoria segura del agente durante el periodo de validez del certificado.

Aprovisionamiento de identidad de agente en el lanzamiento

El flujo de aprovisionamiento de identidad del agente funciona de la siguiente manera. Cuando se inicia un agente (ya sea como un contenedor en Kubernetes, una función sin servidor, un proceso en una máquina virtual o un trabajo de computación efímero), el paso de aprovisionamiento solicita un certificado a la CA de PKIaaS. La solicitud se autentica mediante uno de varios mecanismos:

• Intercambio de tokens OIDC: La plataforma de orquestación de IA emite al agente un token OIDC de corta duración al iniciarse. El agente presenta este token al punto final ACME de PKIaaS (con enlace de cuenta externa) y recibe un certificado a cambio. GitHub Actions, GitLab CI, AWS STS, Azure AD Workload Identity y GCP Workload Identity emiten tokens OIDC que cumplen esta función. El token OIDC es la credencial de arranque; el certificado es la credencial operativa que el agente utiliza para su funcionamiento.
• Certificación de la plataforma: En entornos Kubernetes, SPIRE certifica la identidad del pod del agente mediante la certificación de nodos de Kubernetes y selectores de pods, y luego emite un SVID (Documento de Identidad Verificable de SPIFFE) al agente directamente a través de la API de carga de trabajo de SPIFFE. Con PKIaaS como CA ascendente de SPIRE, este SVID se encadena a la raíz de PKIaaS.
• Sistema de arranque del gestor de secretos: Para los agentes que no se encuentran en Kubernetes, un administrador de secretos autorizado (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) almacena una credencial de inscripción de un solo uso que el agente utiliza para autenticar su primera solicitud de certificado. La credencial de inscripción se consume al utilizarse y las operaciones posteriores del agente utilizan el certificado emitido.

mTLS para la comunicación entre agentes y servicios, y entre agentes.

Una vez que un agente tiene un certificado emitido por PKIaaS, utiliza ese certificado para la autenticación TLS mutua con cada servicio al que llama. mTLS para la comunicación entre agente y servicio proporciona dos propiedades de seguridad que las credenciales estáticas no pueden ofrecer:

Verificación del servicio por parte del agente: El agente verifica el certificado TLS del servicio con el conjunto de certificados raíz de confianza de la CA de PKIaaS antes de enviar cualquier dato. Un agente de IA que llama a un punto final de API falsificado (un ataque de intermediario destinado a extraer el contexto del agente o manipular sus acciones) se detecta durante el protocolo de enlace TLS porque el punto final falsificado no puede presentar un certificado firmado por la CA de PKIaaS. La solicitud del agente nunca llega a un sistema que no haya verificado criptográficamente.

Verificación del agente por parte del servicio: El servicio verifica el certificado del agente con el conjunto de certificados raíz de confianza de la CA de PKIaaS antes de procesar cualquier solicitud. Un agente no autorizado o un proceso comprometido que intente suplantar la identidad de un agente no puede presentar un certificado válido emitido por PKIaaS (el certificado está vinculado criptográficamente a la clave privada generada en el contexto de ejecución del agente legítimo). El servicio rechaza la conexión antes de ejecutar cualquier lógica de la aplicación.

Para la comunicación entre agentes en flujos de trabajo multiagente, se aplica el mismo patrón mTLS. El agente A presenta su certificado al agente B; el agente B lo verifica con la raíz de PKIaaS; el agente B presenta su certificado al agente A; el agente A lo verifica. Ningún agente puede ser suplantado por un proceso que no posea la clave privada correspondiente.

OAuth basado en certificados: Protección de los flujos de autorización de agentes

Muchos agentes de IA interactúan con API que utilizan OAuth 2.0 para la autorización. El patrón estándar de OAuth para clientes máquina es la concesión de credenciales de cliente: el cliente (agente) presenta un ID de cliente y un secreto de cliente para obtener un token de acceso. El secreto de cliente es una credencial estática con todos los problemas descritos anteriormente.

La autenticación OAuth basada en certificados reemplaza el secreto del cliente con el certificado X.509 del agente. En este patrón, que utiliza la autenticación de cliente TLS mutua de OAuth 2.0 (RFC 8705), el agente se autentica ante el servidor de autorización OAuth mediante su certificado emitido por PKIaaS en el protocolo de enlace TLS (autenticación de cliente mTLS) en lugar de presentar un secreto de cliente en el cuerpo de la solicitud. El servidor de autorización verifica el certificado con el paquete de confianza de la CA de PKIaaS y emite un token de acceso vinculado a la huella digital del certificado. Este token de acceso solo es válido cuando se presenta junto con el certificado que se utilizó para obtenerlo: el token de portador y el certificado del cliente deben coincidir, lo que hace que los tokens de acceso robados sean inútiles sin la clave privada correspondiente.

Para flujos de trabajo multiagente, la especificación OAuth 2.0 Token Exchange (RFC 8693) permite a los agentes obtener tokens de acceso que codifican la cadena de delegación: el Agente B puede solicitar un token que demuestre que actúa bajo la autoridad delegada del Agente A, autorizado por el usuario o la entidad principal del sistema que inició el flujo de trabajo. Combinada con la autenticación basada en certificados en cada salto, la cadena de delegación se vuelve criptográficamente verificable: cada token de acceso en la cadena está vinculado a un certificado específico, cada certificado fue emitido por la CA de PKIaaS a una identidad de agente específica, y el registro de auditoría de PKIaaS registra el historial de emisión.

El problema de la cadena de delegación en flujos de trabajo multiagente

El desafío de identidad más complejo desde el punto de vista técnico en la IA con agentes es la cadena de delegación: cuando el Agente A delega una tarea al Agente B, que llama a una herramienta, la cual activa un pago en un sistema financiero, cada sistema en esa cadena necesita conocer la cadena de autoridad que produjo la acción final. Sin cadenas de delegación criptográficas, el sistema financiero solo ve "El Agente B hizo esta solicitud" sin saber que el Agente B actuaba bajo la autoridad del Agente A, la cual fue otorgada por un responsable humano del flujo de trabajo, cuyo alcance estaba definido por una política organizacional.

Esto es importante por tres razones. Primero, autorización: el sistema financiero necesita verificar que la autoridad máxima en la cadena (la persona o entidad principal) tenía derecho a autorizar el pago que solicita el Agente B. Segundo, responsabilidad: cuando el auditor pregunta quién autorizó una transacción específica, la respuesta debe ser rastreable a través de cada agente en la cadena hasta una decisión responsable por una persona. Tercero, contención: si el Agente B se ve comprometido o mal configurado, el alcance del daño se limita a lo que autoriza la cadena de delegación, no a todo a lo que puede acceder la clave API del Agente B.

El mecanismo técnico para cadenas de delegación criptográfica combina la identidad basada en certificados con el intercambio de tokens. El Agente A posee un certificado PKIaaS que codifica su identidad. El Agente A se autentica ante el servidor de autorización mediante dicho certificado y obtiene un token de acceso limitado a su flujo de trabajo autorizado. Cuando el Agente A delega en el Agente B, utiliza el Intercambio de Tokens RFC 8693 para obtener un token de acceso delegado para el Agente B, que codifica tanto la identidad del Agente A como la del Agente B (y las limitaciones de alcance de la delegación). El Agente B utiliza su propio certificado PKIaaS para la autenticación mTLS al presentar este token delegado. Cualquier sistema al que llame el Agente B puede verificar la cadena de delegación completa a partir de las declaraciones del token y del certificado presentado en el protocolo de enlace mTLS.

Garantizando la seguridad de la infraestructura de IA: Más allá de la identidad del agente.

La identidad de los agentes de IA es el caso de uso más visible de la infraestructura de clave pública (PKI) para la IA, pero no el único. La infraestructura que soporta la IA también requiere seguridad basada en PKI.

Infraestructura de servicio de modelos

Los puntos finales de inferencia de modelos de IA (ya sean alojados localmente, en plataformas de aprendizaje automático de proveedores de nube o mediante servicios API) actúan como backends que los agentes consultan. Estos puntos finales requieren certificados TLS para una transmisión segura, y en entornos donde solo los agentes autorizados deben poder llamar a los puntos finales de inferencia, estos también deben verificar la identidad del agente (mTLS en la capa API de inferencia). Una CA PKIaaS que emite certificados tanto para la infraestructura de inferencia como para los agentes crea la raíz de confianza para esta verificación bidireccional.

Infraestructura de capacitación y ajuste fino

La infraestructura de entrenamiento y ajuste de modelos de IA maneja datos confidenciales: conjuntos de datos de entrenamiento, ponderaciones del modelo, resultados de evaluación y datos de retroalimentación. La comunicación entre los componentes de la infraestructura de entrenamiento (cargadores de datos, nodos de cómputo, almacenamiento de puntos de control del modelo, servicios de seguimiento de experimentos) debe utilizar certificados TLS emitidos por la CA PKIaaS de la organización en lugar de certificados autofirmados. Esto garantiza que la comunicación interna de la infraestructura de entrenamiento esté autenticada y cifrada bajo la jerarquía de confianza de la organización, y que los registros de auditoría capturen la identidad del certificado de cada componente involucrado en el entrenamiento del modelo.

Firma de artefactos modelo

Los artefactos de los modelos de IA (pesos, archivos de configuración, plantillas de comandos, definiciones de herramientas) deben firmarse con certificados de firma de código emitidos por la CA de PKIaaS. Un artefacto de modelo firmado por la CA de PKIaaS de la organización puede verificarse como auténtico (producido mediante el proceso de desarrollo de modelos autorizado de la organización) y sin modificaciones (la firma no es válida si el artefacto ha sido manipulado después de la firma). Esto equivale a la seguridad de la cadena de suministro de software en el ámbito de la IA: al igual que la firma de código garantiza que el software implementado se haya producido mediante un proceso de compilación autorizado, la firma de los artefactos de modelo garantiza que los modelos implementados se hayan producido mediante un proceso de entrenamiento o ajuste fino autorizado.

Infraestructura del marco de agentes

Los componentes de infraestructura de los marcos de IA basados ​​en agentes (orquestadores, almacenes de memoria, registros de herramientas, API de gestión de agentes, plataformas de observabilidad) son, en sí mismos, servicios con los que interactúan los agentes y operadores. Estos componentes deben contar con certificados TLS emitidos por la CA de PKIaaS, y las API que exponen deben requerir autenticación mTLS por parte de los agentes y operadores que las invocan. Una API de orquestación a la que puede acceder cualquier proceso no autenticado no constituye una capa de orquestación segura; es una vulnerabilidad del plano de control que puede ser explotada por un agente cuyo contexto de autenticación haya sido manipulado.

Inventario de identidad de máquinas para agentes de IA

El desafío del inventario de identidades de máquinas descrito en publicaciones anteriores sobre la identidad de las cargas de trabajo es crucial para los agentes de IA, ya que estos se implementan y desaprovisionan con mayor rapidez que las cargas de trabajo tradicionales. Una plataforma de IA basada en agentes puede lanzar cientos de agentes por hora, cada uno con un certificado único. Sin un inventario de identidades de máquinas que registre qué certificados se han emitido a qué agentes y cuáles siguen activos frente a los que se han desactivado, la organización pierde visibilidad sobre la identidad de sus agentes de IA casi inmediatamente después de que comience la implementación a gran escala.

Una plataforma CLM conectada a la CA de PKIaaS proporciona el inventario de identidades de máquina para los agentes de IA: cada emisión de certificado se registra con los atributos de identidad del agente, la marca de tiempo de emisión, el período de validez y la entrada del registro de auditoría de PKIaaS que vincula el certificado con la solicitud de emisión. Para certificados de agente de corta duración (de 1 a 24 horas), el inventario muestra la población actual de agentes activos: qué agentes tienen certificados válidos y cuáles han caducado (y los agentes correspondientes ya no deberían estar activos). Si el inventario CLM muestra un certificado activo para un agente cuya implementación se ha terminado, esto indica que la terminación del agente no incluyó una limpieza adecuada de credenciales o que el certificado fue exfiltrado antes de la terminación del agente.

Para la gobernanza de los agentes de IA, el inventario CLM también proporciona la aplicación de políticas: los certificados emitidos a agentes de IA que superan el período máximo de validez permitido, que se emiten a agentes con convenciones de nomenclatura que infringen la política de la organización o que se emiten a agentes en entornos en los que no están autorizados a operar, se detectan como infracciones de políticas que pueden marcarse para su corrección antes de que el agente provoque un incidente.

El registro de auditoría: Cómo hacer que las acciones de la IA sean atribuibles

Uno de los requisitos de gobernanza para la IA con agentes en entornos regulados es que las acciones de la IA deben ser atribuibles: cuando un agente de IA toma una decisión, modifica un registro o inicia una transacción, debe existir un registro auditable que indique qué agente tomó la decisión, bajo qué autoridad y durante qué período de tiempo. La identidad del agente basada en certificados proporciona esta atribución a nivel de infraestructura, en lugar de depender del registro a nivel de aplicación que controlan los propios agentes.

La cadena de atribución funciona de la siguiente manera: La CA de PKIaaS emite un certificado al Agente X en el momento T con el número de serie S, válido por 4 horas. El Agente X utiliza este certificado para autenticarse en la API de transacciones. El registro de acceso de la API de transacciones registra el número de serie S del certificado del cliente y los detalles de la solicitud. El registro de auditoría de PKIaaS registra que el certificado S se emitió a la identidad del agente “order-processing-agent-v2.1/production” en el momento T con una validez de 4 horas. La combinación de ambos registros produce una atribución completa: “A las 14:32:07, la instancia order-processing-agent-v2.1 en el entorno de producción (certificado S, emitido a las 14:00:00) llamó a la API de transacciones e inició la transacción de pago n.° 4472”.

Esta atribución es criptográficamente irrefutable: el número de serie del certificado en el registro de acceso corresponde a una clave privada específica generada en el contexto de ejecución de la instancia del agente. Ningún otro proceso podría haber presentado el certificado S sin poseer la clave privada correspondiente, la cual se generó en la memoria del agente y no se almacenó en ningún lugar al que otro proceso pudiera acceder. La atribución no depende del registro de actividad del propio agente, el cual podría ser modificado por un adversario comprometido.

Nuevas señales regulatorias para la identidad de los agentes de IA

El marco regulatorio para la identidad de los agentes de IA se encuentra en sus primeras etapas, pero avanza rápidamente. Diversas señales de 2025 y 2026 indican la dirección que tomará:

NIST NCCoE (2026): El Centro Nacional de Excelencia en Ciberseguridad del NIST publicó en 2026 un documento conceptual sobre la identidad y autorización de agentes de software e IA, lo que indica que el principal organismo de normalización de ciberseguridad de EE. UU. está desarrollando directrices formales sobre identidad criptográfica para agentes de IA. Las organizaciones que ahora implementan la identidad de agentes basada en certificados se encuentran a la vanguardia de lo que probablemente se convertirá en una recomendación formal.

Grupo de trabajo de la UIT: La Unión Internacional de Telecomunicaciones (UIT) creó en 2026 un grupo de trabajo sobre confianza e identidad para agentes de IA, con el mandato de desarrollar marcos internacionales para la identidad y la responsabilidad de los agentes. Esto indica que la identidad de los agentes de IA se está tratando como un problema de estándares internacionales, y no solo como una opción de implementación específica del proveedor.

Requisitos de rendición de cuentas de la Ley de IA de la UE: La Ley de IA de la UE, que entró en vigor gradualmente a partir de agosto de 2024, exige que los sistemas de IA clasificados como de alto riesgo mantengan registros de operaciones suficientes para la supervisión humana y la rendición de cuentas posterior. Para los sistemas de IA con agentes que realizan acciones autónomas en categorías de alto riesgo (decisiones de empleo, calificación crediticia, gestión de infraestructuras críticas), el requisito de rendición de cuentas se cumple más fácilmente mediante la atribución criptográfica de las acciones del agente, que proporciona la identidad basada en certificados.

Expectativas de gobernanza de la IA en el sector financiero: La EBA (Autoridad Bancaria Europea) y otros reguladores del sector financiero están incorporando la gobernanza de la IA en sus directrices de gestión de riesgos de las TIC. Para las instituciones financieras que utilizan agentes de IA para automatizar las operaciones, las decisiones crediticias, el servicio al cliente o la detección de fraudes, las expectativas de gobernanza de la IA incluyen la auditabilidad de las decisiones automatizadas, lo que requiere la identificación precisa de los agentes.

Cómo puede ayudar la consultoría de cifrado

• Infraestructura de clave pública como servicio: Consultoría de cifrado Oferta de PKIaaS Proporciona la infraestructura de CA para la identidad de agentes de IA: ACME+EAB para el aprovisionamiento de certificados de agente basado en OIDC, API REST para la integración directa con plataformas de orquestación de IA, complemento de CA ascendente SPIFFE para implementaciones de agentes basadas en Kubernetes y perfiles de certificado diseñados para identidades de agente efímeras de corta duración (validez de 15 minutos a 4 horas). Contáctenos en Consultoría de cifrado para analizar la arquitectura de identidad de su agente de IA.
• Administrador de CertSecure: Consultoría de cifrado Administrador de CertSecure Proporciona la capa de inventario de identidad de máquina para los conjuntos de certificados de agentes de IA: descubrimiento continuo de certificados de agente emitidos por PKIaaS, supervisión de caducidad con seguimiento activo de agentes, aplicación de políticas para períodos de validez de certificados y convenciones de nomenclatura, e integración SIEM que alimenta los eventos del ciclo de vida de los certificados de agente a la pila de supervisión de seguridad junto con los registros de acceso a la puerta de enlace API para la correlación de atribución descrita en esta publicación.
• CBOM Seguro: Para las organizaciones que evalúan la postura criptográfica de su infraestructura de IA antes de implementar la identidad de agente basada en certificados, Encryption Consulting ofrece... CBOM seguro Proporciona un sistema de descubrimiento criptográfico que pone al descubierto las credenciales estáticas existentes (claves API, tokens, secretos de cliente) utilizadas por los agentes y la infraestructura de IA, lo que permite priorizar la migración de credenciales estáticas a una identidad basada en certificados.
• Servicios PKI: Para las organizaciones que diseñan la arquitectura de identidad del agente de IA desde cero, incluyendo la configuración del intercambio de tokens OIDC, el diseño del perfil de certificado para los atributos de identidad del agente, la configuración de mTLS para los puntos finales de inferencia y las API de orquestación, y el diseño de la cadena de delegación utilizando el intercambio de tokens RFC 8693, Encryption Consulting Servicios de PKI Brindar asesoramiento arquitectónico y apoyo en la implementación a través de cada componente del programa de identidad del agente.
• Servicios de asesoramiento en materia de cumplimiento normativo: Para organizaciones en sectores regulados que implementan IA con agentes (servicios financieros bajo DORA, atención médica bajo HIPAA, agencias federales bajo FISMA/FedRAMP o entidades de la UE bajo la Ley de IA), Encryption Consulting Servicios de asesoramiento sobre cumplimiento Mapear la arquitectura de identidad del agente de IA con los requisitos aplicables de responsabilidad regulatoria y auditabilidad, generando un marco de evidencia de cumplimiento que demuestra cómo la identidad del agente basada en certificados satisface las obligaciones pertinentes.

Conclusión

Los agentes de IA son máquinas. Necesitan una identidad de máquina. La tecnología de identidad criptográfica de máquinas se ha probado en producción durante décadas en PKI; la novedad reside en su aplicación a una clase de máquinas más rápidas, autónomas y con mayor impacto que las cargas de trabajo tradicionales. Un agente de IA que modifica configuraciones, activa pagos o interactúa con sistemas críticos no debería estar menos identificado que un servidor web o un portátil unido a un dominio. Debería estar identificado con mayor precisión, porque las consecuencias de un agente de IA no identificado o suplantado no se limitan a un error 503, sino que se traducen en acciones autónomas realizadas con la autorización incorrecta.

PKIaaS proporciona la infraestructura de CA para emitir identidades únicas, efímeras y verificables a los agentes de IA a la escala y velocidad que requieren las implementaciones de IA basadas en agentes. Los patrones, como el intercambio de tokens OIDC para el aprovisionamiento, SPIFFE/SPIRE para agentes basados ​​en Kubernetes, mTLS para la comunicación entre agentes y servicios, OAuth basado en certificados para flujos de autorización y el intercambio de tokens RFC 8693 para cadenas de delegación, ya están listos para producción. El trabajo consiste en configurarlos e integrarlos con las plataformas e infraestructuras de orquestación de IA específicas que utiliza la organización.

Las organizaciones que integren la identidad de agentes de IA basada en certificados en sus programas de IA ahora, antes de que la implementación de agentes alcance un nivel en el que la adaptación posterior sea práctica, contarán con el registro de auditoría, la rendición de cuentas y los controles de acceso que los reguladores están adoptando y que los equipos de seguridad eventualmente exigirán. Las organizaciones que esperen hasta que un requisito regulatorio obligue a implementar esta medida estarán adaptando la infraestructura de identidad a una población de agentes implementada que fue diseñada sin ella.

Si su organización está implementando agentes de IA y desea diseñar una arquitectura de identidad basada en certificados para ellos, póngase en contacto con Encryption Consulting.

Esta publicación se revisa cada seis meses y cuando el NIST, la UIT, las regulaciones de implementación de la Ley de IA de la UE o los principales marcos de IA basados ​​en agentes publican actualizaciones importantes sobre los requisitos o recomendaciones de identidad de los agentes de IA.

Preguntas frecuentes

¿Por qué los agentes de IA necesitan identidad criptográfica en lugar de claves API?

Las claves API son estáticas, compartibles, no caducan automáticamente y no proporcionan ninguna prueba criptográfica de qué agente específico las utilizó. Un certificado X.509 emitido por PKIaaS tiene una vida útil corta, está vinculado criptográficamente al contexto de ejecución del agente específico, es irrepugnable y se rota automáticamente. Un certificado robado es inservible después de su período de validez; una clave API robada es útil hasta que se rota manualmente. El informe de IBM sobre el costo de las filtraciones de datos en 2025 reveló que el 97 % de las organizaciones que sufrieron filtraciones de modelos de IA carecían de controles de acceso a la IA.

¿Qué es el problema de la cadena de delegación de agentes de IA?

En los flujos de trabajo multiagente, el Agente A delega tareas al Agente B, que invoca herramientas y activa transacciones. Cada salto debe ser criptográficamente verificable hasta una entidad principal responsable. Sin cadenas de delegación criptográficas, cualquier agente puede reclamar cualquier autorización. La identidad basada en certificados, combinada con el Intercambio de Tokens OAuth 2.0 (RFC 8693) anclado a certificados emitidos por PKIaaS, proporciona el mecanismo técnico para una cadena de delegación verificable donde la identidad y el alcance de la autorización de cada salto son criptográficamente verificables.

¿Cómo funciona mTLS para la comunicación entre la IA y los servicios?

mTLS requiere que tanto el agente de IA como el servicio presenten y verifiquen certificados antes de que se establezca la conexión. El agente verifica el certificado del servicio (evitando llamadas a puntos finales falsificados) y el servicio verifica el certificado del agente (rechazando agentes no autorizados en la capa TLS). OAuth basado en certificados (RFC 8705) amplía este protocolo al vincular los tokens de acceso de OAuth a la huella digital del certificado del agente, lo que hace que los tokens de acceso robados sean inútiles sin la clave privada correspondiente.

¿Cuál debería ser la duración de los certificados de los agentes de IA?

Para agentes efímeros lanzados para una sola tarea: de 15 minutos a 4 horas, según la duración prevista de la tarea. Para implementaciones de agentes persistentes: de 24 a 48 horas con renovación automática antes de su vencimiento. El período de validez debe ser lo suficientemente corto como para que un certificado comprometido caduque antes de que un atacante pueda explotarlo de manera efectiva, y lo suficientemente largo como para que la infraestructura de renovación automática lo reemplace de forma fiable antes de que el agente se ejecute sin una credencial válida.

¿Cuál es el estatus regulatorio de los requisitos de identidad de los agentes de IA?

En fase de desarrollo, pero con rápido avance. El Centro Nacional de Excelencia (NCCoE) del NIST publicó en 2026 un documento conceptual sobre la identidad y autorización de agentes de IA y software. La UIT creó un grupo de trabajo para 2026 sobre la confianza y la identidad de los agentes de IA. La Ley de IA de la UE establece obligaciones de rendición de cuentas y auditabilidad para los sistemas de IA de alto riesgo. Los reguladores del sector financiero están incorporando la gobernanza de la IA en las directrices de gestión de riesgos de las TIC. La identidad criptográfica basada en certificados es el mecanismo técnico más maduro para satisfacer estos requisitos emergentes de rendición de cuentas y atribución.