Amazon AWS añade Private Key JWT a AgentCore Identity, sustituyendo secretos compartidos por control de KMS

Amazon AWS ha añadido la autenticación Private Key JWT a AgentCore Identity, ofreciendo a los agentes automatizados una nueva alternativa a los secretos de cliente OAuth de larga duración. El cambio orienta la autenticación de clientes hacia aserciones firmadas y de corta duración respaldadas por AWS Key Management Service. También crea un registro más claro de cada solicitud de firma en AWS CloudTrail.

Esta combinación importa porque un agente autónomo puede solicitar tokens con mucha más frecuencia que una aplicación convencional orientada a empleados. Un secreto de cliente copiado puede seguir siendo útil hasta que alguien lo rote o revoque. Una aserción Private Key JWT expira rápidamente y requiere acceso a una clave de firma protegida para cada nueva solicitud.

La tensión central no se limita a claves frente a contraseñas. Amazon Bedrock AgentCore Identity ahora promete un control más sólido sin obligar a los desarrolladores a crear y operar su propio servicio de firma. Que esa promesa se cumpla depende de la compatibilidad con los proveedores de identidad, de una configuración precisa de las claims, de los permisos de KMS y de una cobertura de auditoría completa.

Amazon AWS lleva la autenticación de clientes OAuth a KMS

El cambio importante es que AgentCore Identity puede autenticar un cliente OAuth sin almacenar un secreto de cliente reutilizable.

En el nuevo patrón descrito en el anuncio de Private Key JWT, AgentCore Identity construye un JSON Web Token y lo firma mediante AWS KMS. El proveedor de identidad verifica esa firma usando la clave pública correspondiente.

La clave privada permanece dentro de KMS. Un agente, proceso de aplicación o administrador no necesita exportar la clave a un archivo de configuración, una imagen de contenedor, una variable de entorno o un almacén de secretos independiente.

El JWT firmado es una aserción de cliente, lo que significa que demuestra la identidad del cliente OAuth ante un servidor de autorización. No es el token de acceso que finalmente se presenta a una API. El servidor de autorización valida la aserción antes de emitir ese token de acceso.

Esta distinción es fácil de pasar por alto. La autenticación de clientes OAuth responde a si la aplicación que solicita un token es el cliente registrado. La concesión OAuth determina qué autoridad representa el token resultante y qué permisos recibe.

Por tanto, Private Key JWT puede funcionar con más de un flujo de concesión. AgentCore Identity admite acceso delegado por el usuario mediante la concesión de código de autorización y acceso de máquina a máquina mediante credenciales de cliente. Sus patrones de autenticación más amplios también cubren configuraciones de intercambio de tokens en nombre de otro.

Para una solicitud delegada por el usuario, una persona autoriza primero el acceso a través del proveedor de identidad. A continuación, AgentCore Identity autentica al cliente OAuth al intercambiar el código de autorización por tokens. La aprobación del usuario y la identidad del cliente siguen siendo controles independientes.

Para una solicitud de máquina a máquina, ningún usuario completa una pantalla interactiva de consentimiento. El agente solicita un token de acceso bajo la propia autoridad de la aplicación. Private Key JWT autentica esa aplicación durante el intercambio de credenciales de cliente.

Esto hace que la función sea relevante más allá del inicio de sesión. Se dirige al acceso saliente de los agentes a API empresariales, servicios de software y otros recursos protegidos. Estas son precisamente las conexiones en las que una credencial estática puede convertirse en una carga operativa.

AgentCore Identity ya actúa como intermediario entre agentes, servidores de autorización y servidores de recursos. Recupera credenciales mientras mantiene los secretos a largo plazo y los refresh tokens alejados del código de los agentes. Private Key JWT amplía ese límite al material de autenticación del cliente OAuth.

La ruta de la solicitud ahora tiene varias etapas explícitas. El agente solicita a AgentCore Identity acceso autorizado. AgentCore Identity crea una aserción con tiempo limitado, llama a KMS para firmarla y la envía al endpoint de tokens del proveedor de identidad.

El proveedor de identidad comprueba la firma frente a la clave pública registrada. También evalúa las claims que identifican al cliente, la audiencia, la hora de emisión y la expiración. Si estas comprobaciones se superan, el proveedor devuelve un token de acceso a través de AgentCore Identity.

Este diseño no elimina la confianza. Reubica la confianza en las políticas de KMS, los roles de IAM, la configuración de OAuth y el registro de clave pública del proveedor de identidad. Estos controles son más granulares que una cadena copiada, pero también introducen más puntos donde una discrepancia puede detener la autenticación.

Cómo Private Key JWT cambia el modelo de secretos

Private Key JWT reduce la dependencia de secretos compartidos, pero su seguridad depende de controlar quién puede pedir a KMS que firme.

La autenticación tradicional de clientes OAuth suele usar client_secret_basic o client_secret_post. Ambos métodos envían un ID de cliente y un secreto compartido al servidor de autorización. La diferencia es si esas credenciales aparecen en una cabecera HTTP Basic o en el cuerpo de la solicitud.

La documentación de AWS describe HTTP Basic como el método predeterminado para proveedores personalizados de AgentCore Identity. El secreto sigue siendo reutilizable hasta su rotación, expiración o revocación. Cada sistema que posee una copia pasa a formar parte del límite de seguridad de la credencial.

Private Key JWT sustituye ese modelo simétrico por un par de claves asimétricas. Una parte controla la clave privada de firma, mientras que el proveedor de identidad almacena únicamente la clave pública de verificación. La exposición de la clave pública no permite a un atacante generar aserciones válidas.

El enfoque sigue el perfil JWT de OAuth, que define los JWT para la autenticación de clientes y las concesiones de autorización. La solicitud de token incluye una aserción de cliente y la identifica como una aserción JWT bearer.

Una aserción típica contiene una claim de emisor que identifica al cliente, una claim de sujeto para ese cliente y una claim de audiencia que nombra el endpoint de tokens. También incluye horas de expiración y emisión. Un identificador JWT único puede ayudar a un proveedor de identidad a detectar intentos de repetición.

Estos campos no son metadatos decorativos. Una audiencia incorrecta puede invalidar un JWT firmado correctamente. Una diferencia de reloj puede hacer que el proveedor rechace una aserción por ser prematura o haber expirado.

Private Key JWT tampoco garantiza automáticamente la protección contra repeticiones. RFC 7523 deja algunas defensas contra repetición a la política de despliegue. Los proveedores de identidad necesitan límites de duración adecuados y, cuando sea compatible, seguimiento de aserciones únicas.

Las ventanas de expiración cortas reducen la utilidad de una aserción capturada. No protegen un sistema en el que un atacante tiene permiso para invocar repetidamente la clave de firma. Por eso la política de claves de KMS y los permisos de IAM se convierten en la capa central de aplicación.

AWS KMS representa una clave asimétrica como un par público y privado vinculado. Para las claves de firma, el componente privado permanece protegido dentro del servicio. El componente público puede descargarse y registrarse con un proveedor de identidad externo.

KMS admite varios tipos de claves asimétricas, incluidas claves RSA y de curva elíptica para firma y verificación. El tipo de clave y el algoritmo elegidos deben coincidir con lo que acepta el proveedor de identidad.

AgentCore Identity necesita permiso para usar la clave configurada para firmar. AWS afirma que las personas que llaman a la operación Sign de KMS requieren autorización kms:Sign mediante la política de claves. El servicio utiliza entonces el componente privado sin devolverlo.

Esta es una mejora significativa de contención. Una filtración de configuración que exponga un ARN de clave no revela material de clave privada. Un atacante aún necesitaría credenciales de AWS y autorización efectiva para invocar la clave.

Sin embargo, el permiso para firmar sigue siendo sensible. Un rol con acceso amplio a kms:Sign podría potencialmente solicitar firmas fuera de la ruta de carga de trabajo prevista. Los equipos deben vincular los permisos a los roles de ejecución correctos de AgentCore y evitar el acceso general con comodines.

El cambio también afecta a la rotación. Con un secreto compartido, ambas partes deben sustituir el mismo valor confidencial. Con la autenticación asimétrica, los equipos pueden introducir una nueva clave pública en el proveedor de identidad mientras mantienen el verificador anterior durante una transición controlada.

Esta superposición puede reducir el tiempo de inactividad, siempre que el proveedor de identidad admita varias claves activas. Si solo acepta una clave pública, la rotación sigue exigiendo una sincronización coordinada. Private Key JWT cambia el material que se rota, no la necesidad de un proceso de rotación probado.

Los flujos de concesión compatibles sirven a diferentes identidades de agentes

Private Key JWT autentica al cliente OAuth, mientras que la concesión seleccionada determina si un agente actúa por sí mismo o por un usuario.

La concesión de código de autorización es adecuada para agentes que acceden a recursos en nombre de una persona. Un usuario inicia sesión mediante un proveedor de identidad y aprueba los permisos solicitados. El servidor de autorización devuelve un código que el cliente intercambia por tokens.

Durante ese intercambio, AgentCore Identity utiliza la aserción Private Key JWT para demostrar que el cliente registrado realiza la solicitud. La aserción no sustituye el consentimiento del usuario. Refuerza la autenticación en el endpoint de tokens.

Este flujo es adecuado para un agente que lee el calendario de un usuario, busca registros autorizados de un empleado o actualiza un sistema de gestión de clientes dentro de permisos delegados. El acceso resultante sigue vinculado al usuario y a los scopes aprobados.

La concesión de credenciales de cliente aborda un caso distinto. Aquí, la carga de trabajo actúa por sí misma sin un usuario interactivo. Un agente programado podría llamar a una API interna de inventario, procesar alertas de servicio o recuperar datos operativos aprobados.

Private Key JWT autentica a ese cliente de máquina antes de que el servidor de autorización emita un token de aplicación. Como no hay ninguna persona presente, la identidad del cliente, los scopes del token y la política de autorización posterior asumen una mayor carga de seguridad.

Las organizaciones no deberían tratar las dos concesiones como opciones de despliegue intercambiables. Usar credenciales de cliente para una tarea que debería conservar la identidad del usuario puede ocultar la responsabilidad. Usar un flujo delegado para trabajo de servicio en segundo plano puede crear dependencias frágiles de cuentas individuales.

El acceso en nombre de otro introduce otra variante. Un agente recibe evidencia de una identidad de usuario existente y la intercambia por un token adecuado para otro recurso. El flujo debe preservar la relación entre el usuario, el agente y el servicio de destino.

La documentación de AgentCore Identity describe tanto el intercambio de tokens estándar como los enfoques de concesión de autorización basados en JWT para estos casos. La compatibilidad sigue dependiendo del servidor de autorización externo y de sus reglas de intercambio de tokens.

Private Key JWT puede autenticar al cliente que participa en ese intercambio. No decide si el token de usuario entrante es válido ni si debe permitirse la delegación solicitada. Estas decisiones siguen correspondiendo a los sistemas pertinentes de identidad y autorización.

Esta separación es uno de los puntos arquitectónicos más sólidos de la función. Los equipos pueden elegir una concesión en función de la autoridad que necesita un agente y, después, elegir Private Key JWT según cómo el cliente debe demostrar su identidad.

También pone de relieve por qué un único “credential de agente” es un modelo mental inseguro. Un agente puede tener una identidad de carga de trabajo, operar para un usuario, llamar a varios servidores de recursos y usar tokens diferentes para cada destino.

El token de acceso de carga de trabajo de AgentCore Identity añade otra capa. AWS afirma que ese token puede incluir la identidad del agente y la del usuario final cuando el agente solicita credenciales al almacén. AgentCore Runtime puede proporcionárselo automáticamente a los agentes alojados.

Ese token de carga de trabajo autoriza el acceso a AgentCore Identity. El token de acceso OAuth externo autoriza el acceso a la API de destino. La aserción Private Key JWT autentica al cliente OAuth durante la emisión del token.

Por tanto, en una transacción integral pueden aparecer tres tokens, cada uno con una función distinta. Confundirlos puede provocar una validación incorrecta, un registro excesivo o una exposición accidental.

Las revisiones de seguridad deben asociar cada token con su emisor, audiencia, titular, duración y destino. También deben identificar qué componente puede renovarlo o sustituirlo. Este ejercicio detecta errores de diseño que los diagramas a nivel de producto pueden ocultar.

La presión competitiva más amplia recae sobre las integraciones de agentes basadas en secretos. Los secretos estáticos de cliente son conocidos y cuentan con amplio soporte, pero escalan mal cuando muchas cargas de trabajo autónomas necesitan permisos y trazas de auditoría independientes.

Private Key JWT aumenta la carga de configuración, al tiempo que reduce la duplicación de credenciales. Para los equipos que ya operan AWS IAM, KMS y CloudTrail, este intercambio puede resultar atractivo. En implementaciones más pequeñas, la superficie adicional de políticas puede superar el beneficio inmediato.

Configurar la cadena de confianza requiere más que seleccionar un método

La configuración solo tiene éxito cuando KMS, IAM, AgentCore Identity y el proveedor de identidad externo coinciden en los mismos detalles criptográficos y de OAuth.

El primer requisito es una clave KMS asimétrica configurada para firma y verificación. Las claves de cifrado no pueden realizar esta tarea. La especificación de la clave y el algoritmo de firma deben coincidir con una combinación aceptada por el proveedor de identidad de destino.

AWS KMS expone la parte pública de una clave de firma asimétrica. Los equipos registran esa clave pública con su proveedor de identidad, ya sea directamente o mediante una configuración compatible de JSON Web Key.

El proveedor de identidad debe asociar la clave con el cliente OAuth correcto. También debe admitir Private Key JWT en su endpoint de tokens. Las interfaces de registro y los algoritmos aceptados difieren entre proveedores, por lo que este paso sigue siendo específico de cada proveedor.

A continuación, los administradores crean o actualizan un proveedor de credenciales OAuth personalizado en la consola de Amazon Bedrock AgentCore. La configuración necesita la información de descubrimiento del proveedor, el identificador de cliente, el ARN de la clave KMS y el algoritmo de firma.

El descubrimiento de OAuth permite a AgentCore Identity localizar los endpoints de autorización y tokens a partir de los metadatos del proveedor. Los equipos deben verificar que el endpoint de tokens descubierto coincida con el valor de audiencia esperado por el proveedor de identidad.

AgentCore Identity también necesita permiso para invocar KMS. La operación de firma de KMS requiere una clave con uso SIGN_VERIFY y un algoritmo compatible con esa clave.

KMS acepta un mensaje sin procesar o un resumen precomputado, según el tipo de mensaje seleccionado. Una implementación de JWT debe evitar el doble hash accidental, ya que la verificación externa presupone el comportamiento de hashing especificado por el algoritmo.

La configuración del encabezado JWT también importa. El proveedor de identidad puede utilizar un identificador de clave para seleccionar la clave pública adecuada. Un identificador ausente o incorrecto se vuelve especialmente problemático durante la rotación, cuando pueden estar activas varias claves públicas.

Las reclamaciones de la carga útil requieren el mismo cuidado. El emisor y el sujeto suelen corresponder al ID del cliente OAuth. La audiencia normalmente identifica el endpoint de tokens del servidor de autorización, aunque los requisitos del proveedor deben determinar el valor exacto.

La expiración debe ser breve. La hora de emisión debe reflejar un reloj sincronizado. Un identificador de token único es valioso cuando el proveedor registra las aserciones aceptadas previamente.

Después de guardar el proveedor de credenciales, los equipos deben probar de forma independiente cada flujo previsto. Una solicitud de credenciales de cliente exitosa no demuestra que el intercambio de código de autorización o de tokens esté configurado correctamente.

Las pruebas deben comenzar con ámbitos mínimos. Si la autenticación tiene éxito pero la autorización falla, la distinción resulta más fácil de diagnosticar. Añadir permisos amplios para sortear un error puede ocultar un problema de audiencia o de registro de cliente.

Los equipos también deben probar rutas negativas. Una solicitud firmada con la clave incorrecta debe fallar. Una aserción expirada debe fallar. Una audiencia incorrecta y un invocador de KMS no autorizado deben generar evidencias distinguibles.

Aquí es donde se hace visible el intercambio operativo. Los secretos compartidos son lo bastante simples como para que los equipos a menudo validen solo la ruta feliz. Private Key JWT ofrece límites más sólidos, pero estos límites requieren pruebas explícitas.

La configuración también crea dependencias entre equipos administrativos. Un equipo de seguridad en la nube puede ser responsable de las políticas de KMS e IAM. Un equipo de identidad puede controlar el cliente OAuth y el registro de la clave pública.

Los propietarios de aplicaciones configuran AgentCore Identity y determinan los ámbitos de concesión. Los equipos de auditoría deciden qué registros de CloudTrail deben conservarse y generar alertas. Ninguna selección en una sola consola resuelve estas cuestiones de responsabilidad.

Un despliegue útil comienza con una integración no crítica. Los equipos pueden documentar los requisitos de reclamaciones, las respuestas ante fallos, los pasos de rotación y las responsabilidades de escalamiento antes de aplicar el método a muchos agentes.

La automatización debe seguir a ese primer despliegue validado. Las plantillas de infraestructura pueden estandarizar las políticas de claves y la configuración de los proveedores de credenciales, pero no deben asumir el comportamiento del proveedor de identidad.

El resultado no es un sistema sin secretos. Los tokens siguen existiendo, los servidores de autorización siguen manteniendo la confianza y los permisos de AWS siguen siendo credenciales. La afirmación más acotada es más defendible: el cliente OAuth ya no depende de un secreto compartido y reutilizable.

CloudTrail convierte cada firma en una señal de auditoría

La firma respaldada por KMS ofrece a los defensores un evento del lado de AWS que pueden correlacionar con solicitudes de tokens y actividad de agentes.

AWS KMS se integra con CloudTrail, que registra las llamadas realizadas por usuarios, roles y servicios de AWS. Su registro de auditoría de KMS incluye operaciones criptográficas y acciones de administración de claves.

Por tanto, una transacción de Private Key JWT debería generar evidencia en torno a la solicitud de firma de KMS. El evento puede identificar la operación, región, hora, clave relevante y el principal de AWS o contexto de servicio involucrado.

Ese registro no contiene por sí solo toda la historia. CloudTrail muestra que una identidad autorizada de AWS solicitó una firma. Los registros del proveedor de identidad externo muestran si aceptó la aserción y emitió un token.

Los registros de auditoría del servicio de destino muestran qué hizo el token de acceso resultante. Una investigación eficaz correlaciona las tres capas en lugar de tratar el evento de KMS como prueba de acceso exitoso a recursos.

CloudTrail aún puede responder preguntas importantes. Los investigadores pueden buscar volúmenes de firma inesperados, solicitudes desde el rol equivocado, llamadas en una región no aprobada o actividad relacionada con una clave fuera de su calendario normal.

Importa la configuración de los selectores de eventos. AWS clasifica los eventos de KMS como eventos de administración, y las trazas de CloudTrail normalmente registran actividad de administración. Sin embargo, los administradores pueden excluir explícitamente los eventos de KMS.

AWS advierte que las operaciones de KMS pueden generar grandes volúmenes de eventos. Algunas organizaciones los filtran para controlar el volumen de registros. Hacerlo puede eliminar precisamente la evidencia de firma que facilita la auditoría de este patrón de autenticación.

Los equipos que adopten Private Key JWT deben revisar su configuración de eventos de administración. Deben confirmar que la actividad relevante de KMS llegue a la traza o al almacén de datos de eventos previsto.

La retención y la capacidad de búsqueda también importan. El historial de eventos resulta útil para investigaciones recientes, mientras que una traza o un almacén de datos de eventos de CloudTrail Lake permite análisis más prolongados. Los registros exportados también pueden alimentar sistemas de supervisión de seguridad.

Una línea base debe diferenciar el comportamiento esperado de renovación de tokens de las anomalías. Un agente de máquina que se ejecuta continuamente puede firmar aserciones a una cadencia regular. Un flujo de trabajo delegado por el usuario puede generar ráfagas durante sesiones activas.

Las desviaciones importantes pueden indicar un bucle de reintentos, un fallo de configuración o uso indebido de credenciales. La firma repetida seguida de rechazo en el endpoint de tokens podría apuntar a una audiencia incorrecta, una clave pública expirada o un problema de reloj.

La actividad de firma sin solicitudes correspondientes a AgentCore merece una inspección más detallada. También la emisión exitosa de tokens sin las llamadas descendentes esperadas. Cada patrón identifica una ruptura distinta en la cadena de confianza.

Los eventos del ciclo de vida de las claves deben recibir alertas independientes. Deshabilitar una clave de firma puede detener todas las integraciones dependientes. Los cambios de políticas pueden ampliar silenciosamente quién tiene permitido invocarla.

CloudTrail también ayuda durante la rotación. Los equipos pueden observar si la clave anterior sigue recibiendo solicitudes de firma después de activar una nueva. La actividad continua puede revelar un proveedor de credenciales pasado por alto o un despliegue retrasado.

Sin embargo, la visibilidad de auditoría sigue siendo condicional. Los registros deben estar habilitados, conservarse, protegerse y revisarse. Un evento registrado pero nunca consultado ofrece poca defensa práctica.

Los eventos de CloudTrail tampoco validan el motivo de negocio de una solicitud. Un agente debidamente autorizado aún puede solicitar un token de acceso en el momento equivocado o usarlo para una tarea demasiado amplia.

Esta limitación desplaza la atención hacia el diseño de autorización. Private Key JWT puede demostrar que el cliente controla el acceso a una clave de firma. No puede determinar si el objetivo del agente, la herramienta seleccionada o la operación solicitada son apropiados.

Las organizaciones necesitan restricciones de ámbitos, políticas de servidor de recursos, controles de carga de trabajo y supervisión del comportamiento en torno a la prueba criptográfica. La firma es una señal de alta calidad, no un sistema completo de gobierno de agentes.

Qué deben vigilar las empresas tras el lanzamiento de Private Key JWT

La siguiente prueba es si Private Key JWT se convierte en una opción operativa predeterminada o sigue siendo una opción avanzada para despliegues estrechamente gestionados.

La primera señal es la interoperabilidad con proveedores de identidad. Una adopción exitosa requiere que los proveedores acepten los algoritmos de firma, las reclamaciones, el formato de audiencia y el método de registro de clave pública seleccionados.

AWS puede simplificar su lado del intercambio, pero no puede estandarizar el flujo administrativo de todos los proveedores. Ejemplos claros y específicos para cada proveedor reducirían los despliegues fallidos y las soluciones alternativas inseguras.

La segunda señal es el comportamiento de rotación. Las empresas necesitan saber si pueden registrar claves públicas superpuestas, actualizar los proveedores de AgentCore sin interrupciones y confirmar la migración mediante registros de auditoría.

Una función que solo funciona durante la configuración inicial resuelve la mitad del problema. La autenticación en producción también necesita una recuperación predecible cuando una clave se deshabilita, sustituye o compromete.

La tercera señal es la adopción de auditoría. CloudTrail proporciona a los equipos acceso a los registros de firma, pero las organizaciones deben conservar los eventos de KMS y conectarlos con los registros del proveedor de identidad y del servidor de recursos.

Las guías de detección harían la función más útil. Las tasas elevadas de firma, los principales desconocidos, los errores repetidos y la actividad regional inesperada son candidatos prácticos para alertas.

Los equipos de seguridad también deben vigilar los límites del modelo de permisos de AgentCore Identity. La política ideal permite que una carga de trabajo use una clave de firma para un proveedor aprobado sin conceder acceso de firma no relacionado.

Las claves entre cuentas aportan flexibilidad, pero requieren políticas de recursos cuidadosas. AWS KMS admite el uso entre cuentas para firma cuando los llamadores especifican el ARN de la clave y reciben los permisos necesarios.

Esa capacidad puede respaldar una gestión centralizada de la seguridad. También puede crear dependencias entre las cuentas de las aplicaciones y una cuenta central de identidad. Las interrupciones o los errores de políticas en la cuenta central pueden afectar a numerosos agentes.

Las empresas deberían medir los resultados operativos en lugar de asumir que el diseño criptográfico garantiza el éxito. Entre los indicadores útiles se encuentran la carga de trabajo de rotación de secretos, los fallos en las solicitudes de tokens, los intentos de firma no autorizados y el tiempo de recuperación tras cambios de claves.

También deberían comparar Private Key JWT con la autenticación JWT firmada mediante AWS IAM. La documentación de AgentCore Identity describe un método AWS_IAM_ID_TOKEN_JWT que utiliza una aserción emitida por IAM y exige que el servidor de autorización confíe en AWS IAM.

Ambos enfoques se alejan de los secretos de cliente compartidos, pero establecen la confianza de formas distintas. Private Key JWT pide al proveedor de identidad que confíe en una clave pública gestionada por el cliente. El método IAM le pide que confíe en AWS IAM como emisor.

La compatibilidad del proveedor determinará a menudo qué vía resulta práctica. Algunos sistemas de identidad ya admiten Private Key JWT para clientes OAuth confidenciales. Es posible que menos estén configurados para aceptar directamente a AWS IAM como emisor.

Por tanto, Private Key JWT ocupa un punto intermedio útil. Aplica un método estándar de autenticación OAuth y, al mismo tiempo, mantiene el material de firma privado bajo el control de KMS.

La relevancia más amplia de esta función radica en cómo trata a un agente. En lugar de proporcionar al agente una credencial reutilizable, la plataforma realiza una operación criptográfica con autorización limitada cuando se necesita acceso.

Este patrón reduce el valor de los datos de configuración copiados. También crea un punto de control aplicable para cada solicitud de token. Son mejoras concretas para cargas de trabajo autónomas que operan con frecuencia y con supervisión limitada.

La contrapartida es una mayor precisión en la configuración. Los equipos deben alinear algoritmos, claves públicas, claims de JWT, políticas de IAM, concesiones OAuth, ámbitos de tokens y controles de registro.

Amazon AWS ha hecho que esa complejidad sea más manejable al incorporar la firma en AgentCore Identity. No ha hecho que desaparezcan las decisiones de confianza que lo rodean.

Antes de adoptar el método de forma generalizada, elija un agente representativo y siga su ruta completa de acceso. Identifique cada principal, token, concesión, ámbito, fuente de registros y mecanismo de revocación implicados.

Después, pruebe la rotación y los fallos, no solo la autenticación correcta. Si su equipo puede explicar quién solicitó cada firma y qué ocurrió después, Private Key JWT está haciendo más que sustituir un secreto.