Cuando los agentes de IA acceden a bases de datos, API y operaciones empresariales confidenciales, establecer una identidad criptográfica a través de la infraestructura de clave pública (PKI) X.509 se convierte en un requisito fundamental. El principal desafío consiste en demostrar qué agente hizo una solicitud, evitar la falsificación entre los agentes y confirmar que cada agente actúa únicamente en nombre de un usuario autorizado. Los enfoques tradicionales, como compartir claves de API entre componentes o transferir tokens de OAuth a través de cadenas de agentes, no cumplen con los requisitos de confianza cero que exigen las

Los marcos de IA con múltiples agentes utilizan cada vez más el Protocolo de contexto modelo (MCP) para conectar a los agentes con herramientas y fuentes de datos externas. El MCP define cómo un agente basado en un modelo de lenguaje de gran tamaño (LLM) invoca herramientas como las consultas a bases de datos o las operaciones de correo electrónico. Sin embargo, MCP no tiene un estándar de autenticación incorporado. Su diseño es independiente del transporte. Esto crea una brecha crítica: sin los mecanismos de identidad adecuados, cualquier componente podría hacerse pasar por un agente, reproducir las credenciales interceptadas

En esta publicación, le mostramos cómo abordar esta brecha utilizando Keyfactor EJBCA en combinación con los servicios de AWS. EJBCA es una plataforma de PKI que admite la implementación de alta disponibilidad, la automatización de las API REST y la validación del protocolo de estado de los certificados en línea (OCSP). La arquitectura de referencia utiliza cuatro mecanismos de seguridad complementarios. En primer lugar, los sobres de solicitud firmados proporcionan una prueba criptográfica de posesión en cada llamada de un agente. En segundo lugar, las aserciones de delegación firmadas por los usuarios autorizan a los agentes a no compartir sus credenciales. En tercer lugar, los tokens basados en la RFC 8693 con el alcance de la audiencia limitan el alcance de la exposición cuando se divulga un solo token. En cuarto lugar, la verificación de revocación del OCSP en tiempo real propaga

La solución utiliza Amazon Bedrock para la inferencia del LLM a través del SDK de agentes de AWS Strands. Si bien esta arquitectura de referencia utiliza una base de datos como recurso protegido, el mismo patrón de autenticación se aplica a cualquier servidor de herramientas compatible con MCP. El código fuente completo de todos los ejemplos está disponible en el repositorio de GitHub adjunto

Acerca de Keyfactor EJBCA

Keyfactor proporciona una plataforma de gestión de identidades de máquinas ampliamente adoptada y utilizada por más de 1500 clientes empresariales en todo el mundo, según Keyfactor. Estas organizaciones abarcan los servicios financieros, la atención médica, la fabricación y el gobierno. Keyfactor ayuda a las organizaciones a establecer y mantener la confianza criptográfica mediante la administración del ciclo de vida de los certificados, las operaciones de PKI y el gobierno de la identidad de las máquinas

EJBCA Enterprise es la plataforma de autoridad certificadora (CA) y PKI de Keyfactor, diseñada para la implementación de alta disponibilidad y la automatización de las API REST. Disponible como producto empresarial, EJBCA proporciona la emisión de certificados X.509, la validación OCSP, la distribución de listas de revocación de certificados (CRL) y la gestión completa del ciclo de vida de los certificados a través de una consola web y una API REST. EJBCA admite la implementación local, en contenedores o en Amazon Elastic Compute Cloud (Amazon

La asociación entre AWS y Keyfactor reúne los servicios gestionados de AWS (Amazon Bedrock, AWS Secrets Manager, Amazon Relational Database Service (Amazon RDS)) con una infraestructura de PKI que admite la administración del ciclo de vida de los certificados, la inscripción automatizada y la revocación en tiempo real. Esta combinación aborda una brecha en el ecosistema de agentes de IA. Mientras que AWS proporciona las capas de procesamiento, almacenamiento e inferencia de inteligencia artificial, Keyfactor proporciona la capa de identidad criptográfica que vincula a los agentes con credenciales verificables, revocables y de corta duración. Esta arquitectura de referencia conjunta, desarrollada en colaboración por los equipos de ingeniería de AWS y Keyfactor, demuestra cómo integrar estas tecnologías. Puede adaptar los patrones que se muestran aquí a sus propias implementaciones con varios agentes

Descripción general de la solución

La arquitectura implementa tres capas de autenticación, cada una de las cuales aborda un límite de confianza diferente en la cadena de comunicación del agente. Estas tres capas utilizan los cuatro mecanismos de seguridad introducidos anteriormente: sobres firmados como prueba de posesión, aseveraciones de delegación para la autorización sin necesidad de credenciales, fichas con alcance de audiencia para limitar la exposición y OCSP para la revocación en tiempo real. Los mecanismos se combinan en varias capas

La figura 1 muestra las tres capas de autenticación y cómo fluyen las credenciales entre el usuario, los agentes y el servidor de herramientas MCP. El diagrama ilustra la separación entre las credenciales de usuario (que permanecen en el flujo de inicio de sesión), las credenciales de agente (con un alcance por agente) y la cadena de delegación que las conecta

Figura 1: Arquitectura de autenticación de PKI de tres capas para sistemas de agentes de IA en AWS

La figura 2 muestra el flujo de tráfico detallado durante una sesión de usuario típica. Muestra la secuencia de pasos de autenticación, desde el inicio de sesión hasta la emisión del certificado, la delegación de agentes, la invocación de herramientas y la limpieza de la sesión

Figura 2: Flujo del tráfico de autenticación desde el inicio de sesión del usuario hasta la delegación de agentes, la invocación de herramientas y la limpieza de la sesión

Servicios de AWS utilizados

Los siguientes servicios de AWS forman la base de la arquitectura de referencia.

Tutorial de la solución

Los pasos siguientes describen cada componente de la arquitectura, desde el inicio de sesión inicial del usuario hasta la limpieza de la sesión. Cada paso se basa en el anterior y establece una cadena de confianza que conecta al usuario humano con la ejecución final de la herramienta

Prerrequisitos

• Una cuenta de AWS activa con acceso a Amazon Bedrock, Amazon RDS para MySQL, Amazon SES y AWS Secrets Manager.
• Keycloak 26.2 o posterior (obligatorio para el intercambio de tokens estándar según la RFC 8693). Las versiones anteriores utilizan un intercambio antiguo que es incompatible
).
• Keyfactor EJBCA Enterprise con la API REST V1 y un respondedor OCSP configurados.
• Certificado de administrador de la API EJBCA (api-admin.p12) para la autenticación de la API REST.
• Entorno de desarrollo Python 3.9+.
• Familiaridad con los certificados X.509, OCSP, OAuth 2.0, las firmas digitales RSA y los almacenes de claves PKCS #12.

Paso 1: Inicio de sesión de usuario, emisión de certificados y creación de delegaciones

El flujo de inicio de sesión establece la identidad del usuario mediante tres mecanismos y, a continuación, delega la autoridad a los agentes de IA sin compartir las credenciales del usuario. Esta separación es fundamental: los agentes reciben un comprobante de autorización sin tener nunca la clave privada del usuario ni el token de OAuth de sesión completa

En primer lugar, la aplicación autentica al usuario con Keycloak mediante la concesión de una contraseña de OAuth 2.0 y recibe un token de acceso a la sesión completa y un token de actualización. Inmediatamente después, la aplicación realiza un intercambio de tokens según la RFC 8693 para obtener un token con un alcance reducido. La audiencia de este token está restringida al servidor MCP. Solo este token limitado se entrega a los agentes. Si queda expuesto inadvertidamente, no puede acceder a ningún otro servicio

En segundo lugar, la aplicación genera localmente un par de claves RSA 2048+ y envía una solicitud de firma de certificado (CSR) a EJBCA a través del punto final de la API REST pkcs10enroll. EJBCA firma la CSR y devuelve el certificado. La aplicación agrupa el certificado y la clave privada en un contenedor PKCS12 y los almacena en AWS Secrets Manager. La clave privada nunca sale del límite de la aplicación. No se envía a EJBCA, no se comparte con los agentes ni se almacena en el sistema de archivos. Se emiten tres certificados de agente utilizando el mismo flujo basado en la CSR,

En tercer lugar, la clave privada del usuario firma una afirmación de delegación. Se trata de un documento JSON en el que se enumeran las huellas digitales SHA-256 de los tres certificados de agente, junto con el nombre del asunto del usuario, la hora de emisión y la fecha de caducidad. Esta delegación demuestra que el usuario autorizó a estos agentes específicos a actuar en su nombre. Los agentes llevan esta delegación en lugar del certificado del usuario.

# RFC 8693 Token Exchange: alcance reducido a la audiencia de MCP
downscoped_token = keycloak.token_exchange (
 original_token, audience="mysql-mcp-server», scope="database:write»
)
# Generación de claves del lado del cliente (la clave de usuario nunca abandona este flujo)
private_key = rsa.generate_private_key (public_exponent=65537, key_size=2048)
csr = build_csr (private_key, f"cn= {nombre de usuario}, E= {nombre de usuario} @org .com»)
user_cert = ejbca.pkcs10enroll (csr, ca_name="userCA»)
# El usuario firma la delegación sobre las huellas dactilares del certificado del agente
delegación = mint_delegation (
 nombre de usuario = nombre de usuario,
 user_cert_pem=user_cert,
 user_key_pem = private_key_pem,
 agent_cert_pems= [orch_cert, mysql_cert, email_cert]
)
# Resultado: {sub, agent_fingerprint [], iat, exp, user_cert_pem,

Paso 2: sobres firmados de agente a agente

Cuando el agente orquestador envía una solicitud a un subagente (como el agente de MySQL o el agente de correo electrónico), no se limita a pasarle su certificado para identificarlo. En su lugar, firma toda la carga útil de la solicitud, incluidos el nombre de la herramienta, los argumentos, una marca de tiempo y un nonce criptográficamente aleatorio, utilizando su clave privada con el RSA-PSS-SHA256. El sobre firmado resultante constituye una prueba de posesión. El agente receptor puede verificar que la persona que llama realmente posee la clave privada correspondiente al

El agente receptor realiza seis comprobaciones de validación en el sobre antes de procesar la solicitud:

1. Verificación de firma: demuestra que el remitente posee la clave privada (prueba de posesión).
2. Fecha de caducidad de la marca: el sobre debe estar dentro de ENVELOPE_MAX_AGE_SECONDS (60 segundos por defecto) respecto a la hora actual.
3. Exclusividad de Nonce: el ReplayCache rechaza cualquier nonce visto anteriormente, lo que impide la reproducción de la solicitud.
4. Validación en cadena de CA: el certificado del remitente debe estar en cadena con la CA de confianza (userCA.pem).
5. Autorización de funciones: el sufijo de función del certificado CN debe estar en ALLOWED_CALLER_ROLES para este agente.
6. Verificación de revocación del OCSP: una comprobación en tiempo real de la EJBCA confirma que el certificado no se ha revocado.

Si el orquestador necesita volver a enviar el mismo mensaje (por ejemplo, después de un error transitorio), debe crear un sobre nuevo con un nonce nuevo. Los sobres antiguos no se pueden reproducir, ni siquiera los puede reproducir

# Orchestrator firma la solicitud al subagente
envelope = sign_envelope (
 payload= {"tool»: «query_database», «args»: {"sql»: «SELECCIONA... «}},
 cert_pem=orchestrator_cert_pem,
 private_key_pem = orchestrator_key_pem
)
# sobre: {payload_b64, cert_pem, timestamp, nonce, signature_b64, alg}
# El subagente verifica (seis comprobaciones)
verified_payload = verify_envelope (
 sobre,
 allowed_role="agente-orquestador»,
 ca_cert_pem=ca_pem,
 replay_cache=caché

Paso 3: autenticación del servidor MCP

El servidor MCP (FastMCP) es el límite de confianza final antes de que se ejecute cualquier operación de base de datos. Realiza cuatro comprobaciones de validación en cada invocación de herramientas e implementa una defensa en profundidad. Incluso si una credencial está sujeta a un acceso no autorizado, las comprobaciones restantes evitan las operaciones

La secuencia de autenticación:

1. Introspección del token: una POST en el punto final de Keycloak /token/introspect verifica que el token esté activo y que su audiencia contenga «mcp-server». Se rechaza un token de sesión completa
sin la audiencia correcta.
2. Verificación del sobre: el sobre firmado por el agente se valida para comprobar que la firma es correcta, la fecha y hora, la unicidad de Nonce, la confianza en la cadena de CA, la coincidencia de roles (mysql-agent) y la no revocación de OCSP.
3. Verificación de la delegación: se valida la afirmación de delegación del usuario. La firma demuestra que el titular de la clave del usuario autorizó esta delegación, que la huella digital del certificado del agente que llama aparece en la lista de autorizados y que el certificado del usuario se comprueba mediante el OCSP
.
4. Verificación cruzada de identidad: el nombre de usuario del token, el asunto de la delegación y el prefijo CN del certificado del agente deben coincidir. Esto confirma la existencia de una cadena de identidad única y coherente desde el usuario hasta la ejecución de la herramienta
.

# Servidor MCP: cuatro comprobaciones de validación
#1. Token: debe estar activo con la audiencia correcta
info = introspección (token)
afirma info ["active"] y «mcp-server» en info ["aud"]
#2. Sobre: prueba de posesión + frescura + repetición + CA + rol + OCSP
payload = verify_envelope (sobre, «mysql-agent», ca_pem, replay_cache)
#3. Delegación: el usuario autorizó este agente y el certificado de usuario no fue revocado
claims = verify_delegation (delegation, agent_cert_pem, ca_pem)
# 4. Verificación cruzada: cadena de identidad coherente
assert token_username == claims ["sub"] == agent_cn.rsplit («_», 1) [0]
# Todas las comprobaciones han sido aprobadas: ejecuta la herramienta
resultado = execute_sql (payload ["args"] ["sql"])

Paso 4: Prevención de repeticiones

Cada sobre firmado lleva un nonce único, una cadena hexadecimal criptográficamente aleatoria de 128 bits generada con el módulo de secretos de Python. El ReplayCache es un almacén en memoria seguro para subprocesos que recuerda cada nonce hasta que caduque su período de actualización (2 veces ENVELOPE_MAX_AGE_SECONDS). Si aparece el mismo nonce en una segunda solicitud, el sobre se rechaza inmediatamente, incluso si su firma es válida y la marca de tiempo es reciente

validación de la marca de tiempo complementa la verificación del nonce. La marca de tiempo de un sobre debe estar dentro de ENVELOPE_MAX_AGE_SECONDS (60 segundos por defecto) de la hora actual del servidor. En conjunto, estos mecanismos abordan cuatro escenarios

• Reproducción grabada: un usuario no autorizado captura un sobre válido y lo vuelve a enviar más tarde. El nonce ya estaba visto
.
• Entrega retrasada: un sobre interceptado durante el transporte llega pasado el plazo de frescura. La comprobación de la marca de hora
falla.
• Reutilización de solicitudes obsoletas: se vuelve a enviar un sobre antiguo almacenado en caché por un proxy. Las comprobaciones nonce y timestamp fallan.
• Falsificación precalculada: un usuario no autorizado no puede predecir si quiere firmar previamente los sobres en el futuro.

Paso 5: generación de claves del lado del cliente

Una propiedad de seguridad fundamental de esta arquitectura es que las claves privadas se generan localmente y nunca se transmiten a ningún sistema externo. La aplicación genera más de 2048 pares de claves RSA mediante la biblioteca de criptografía de Python. Crea una CSR que contiene solo la clave pública y la información del asunto, y envía únicamente la CSR a EJBCA a través del punto final pkcs10enroll.

EJBCA valida la CSR, aplica el perfil del certificado (validez de 7 días, restricciones de uso de la clave), la firma con la clave de la CA y devuelve el certificado emitido. A continuación, la aplicación agrupa la clave privada local con el certificado devuelto en un contenedor PKCS12 y la almacena en

Este diseño proporciona varias propiedades de seguridad:

• La clave privada del usuario solo se usa al iniciar sesión para firmar la afirmación de delegación. Nunca se comparte con los agentes
. La
• clave privada de cada agente solo la usa ese agente para firmar los sobres. Nunca se comparte entre los agentes
.
• EJBCA nunca ve ni almacena claves privadas. Funciona únicamente como una autoridad de certificación
.
• Si Secrets Manager está sujeto a un acceso no autorizado, la contraseña PKCS12 (que se almacena por separado) añade una capa adicional.
• El material clave se puede rotar de forma independiente si se vuelve a inscribir con una nueva CSR la próxima vez que se inicie sesión.

Paso 6: Cierre de sesión completo y revocación de credenciales

cierre de sesión desencadena una cascada de revocaciones que invalida inmediatamente todas las credenciales pendientes. La secuencia hace que no queden credenciales válidas

1. Revocar el certificado de usuario en EJBCA: esto invalida inmediatamente todas las delegaciones pendientes, ya que la verificación de la delegación comprueba el certificado del usuario a través del OCSP en tiempo real.
2. Revocar los tres certificados de agente: esto invalida todos los sobres firmados pendientes, ya que la verificación de los sobres incluye el OCSP.
3. Elimine todos los secretos de AWS Secrets Manager: utilice ForceDeleteWithoutRecovery para eliminarlos de forma inmediata sin ventana de recuperación.
4. Finalizar la sesión de Keycloak: invalida el token reducido en el punto final de finalización de la sesión.

La cascada de revocación es la propiedad clave de seguridad. La revocación de un certificado de usuario único en la capa de PKI revoca inmediatamente toda la autoridad de los agentes intermedios sin necesidad de revocar individualmente los tokens, eliminar sesiones o ponerse en contacto con cada agente. El OCSP proporciona el mecanismo de propagación y, dado que cada solicitud comprueba el OCSP

Consideraciones de seguridad

Las opciones de diseño de esta arquitectura abordan varias propiedades de seguridad que son importantes para las implementaciones de varios agentes en producción.

claves privadas. La clave privada del usuario solo existe durante el flujo de inicio de sesión y se usa únicamente para firmar la delegación. Las claves de los agentes se clasifican por agente y nunca se comparten. Ningún material clave sobrepasa los límites de la confianza

La delegación en comparación con el intercambio de credenciales. Los agentes demuestran su autoridad a través de una cadena criptográfica (delegando la huella dactilar del agente hasta la firma del sobre) sin tener nunca en sus manos las credenciales de los usuarios. Si se descubre la clave de un agente, solo se revela la clave de ese agente, no la del usuario

Tokens con alcance de audiencia. El intercambio de tokens según la RFC 8693 produce un token que solo acepta el servidor MCP. Un token con un alcance reducido divulgado de forma inadvertida no puede autenticarse en las API de administración de Keycloak, en otros

Prevención de repeticiones. La combinación de no caducar por solicitud y un período de actualización de 60 segundos confirma que cada solicitud es de un solo uso y tiene un límite de tiempo. El ReplayCache

Diseño cerrado a prueba de fallos. Cada error de validación resulta en una denegación inmediata. OCSP inalcanzable: denegación. Firma no válida: denegar. Marca de tiempo caducada: denegar. Reproducido no una vez: denegar. Público equivocado: negar. Los controles de seguridad no se degradan fácilmente

revocación. La revocación inmediata de un certificado de usuario invalida todas las delegaciones, todas las facultades de los agentes y todos los sobres pendientes. Esto se propaga a través del OCSP en tiempo real sin necesidad

Cadena de confianza exclusiva para el futuro. El mapa ALLOWED_CALLER_ROLES establece que solo Orchestrator-agent puede llamar a mysql-agent y email-agent. Los subagentes no pueden llamarse entre sí, no pueden llamar al orquestador

Consideraciones de gobernanza de la IA

La arquitectura de PKI proporciona límites de comportamiento integrados para los agentes de IA de este sistema. Las implementaciones de producción deben utilizar Amazon Bedrock Guardrails para aplicar el filtrado de contenido, evitar temas y comprobar las respuestas de los agentes desde tierra, junto con los controles de acceso basados en la PKI que se describen

• Límites de herramientas: el agente de IA opera bajo estrictas restricciones de herramientas. Solo puede invocar herramientas MCP predefinidas (execute_sql, describe_table, list_tables). El agente no puede ejecutar código arbitrario ni
acceder a recursos fuera del alcance de su certificado.
• Supervisión humana: todas las acciones del agente se registran y son auditables. AWS CloudTrail captura las llamadas a la API de AWS y el servidor MCP registra todas las invocaciones de herramientas validadas con la cadena de identidad completa (usuario, agente, marca de tiempo y operación
).
• Gestión de datos: las consultas y los resultados de los usuarios se mantienen dentro del límite de la sesión autenticada. El token orientado a la audiencia limita el acceso a los datos a
la instancia específica del servidor MCP.
• Límites de comportamiento basados en certificados: los agentes solo pueden invocar las herramientas para las que tengan certificados válidos. Un agente sin un certificado de mysql-agent no puede acceder a la base de datos, independientemente de lo que el
LLM pueda generar como instrucciones.

Ampliación de la arquitectura

Puede ampliar esta arquitectura para admitir otros tipos de agentes, el escalado horizontal y el aislamiento de varios inquilinos. En los siguientes párrafos se describen los puntos de extensión más comunes

• Para agregar nuevos tipos de agentes, solo necesita agregar una entrada en ALLOWED_CALLER_ROLES. Los certificados se emiten automáticamente al iniciar sesión y la afirmación de delegación incluye de forma dinámica la huella digital del nuevo agente. No se requieren cambios en la infraestructura
.
• Para el escalado horizontal, puede implementar el respondedor OCSP de EJBCA en modo de alta disponibilidad detrás de un balanceador de carga. AWS Secrets Manager admite altas tasas de solicitud adecuadas para esta carga de trabajo. Amazon ElastiCache puede respaldar ReplayCache para las
implementaciones distribuidas.
• Para reforzar la arquitectura de producción, puede usar claves de firma EJBCA respaldadas por un módulo de seguridad de hardware (HSM) a través de AWS CloudHSM o un HSM local. El grapado de respuestas de OCSP reduce la latencia de validación y los registros de transparencia de los certificados proporcionan un registro de auditoría completo de los certificados emitidos
.
• Para las implementaciones con varios inquilinos, puede crear autoridades de certificación por inquilino o autoridades de delegación por inquilino para el aislamiento criptográfico de los inquilinos. En combinación con las cuentas de AWS por inquilino, esto
ofrece un fuerte aislamiento entre los inquilinos.
• También puede complementar la identidad de los agentes basada en la PKI con las funciones de administración de identidades y accesos (IAM) de AWS. Utilice la PKI para la autenticación de agente a agente y la IAM para la autorización de los servicios de AWS. Los dos sistemas funcionan de forma independiente y proporcionan una defensa en profundidad
.

Limpiar

Para evitar cargos continuos, elimine los recursos creados durante este tutorial:

• Elimine la instancia de Amazon RDS para MySQL (o la pila de AWS CloudFormation si utilizó la configuración con scripts).
• Elimine todos los secretos de AWS Secrets Manager, incluidos los certificados de usuario y los certificados de agente con el prefijo mcp/.
• Elimine la dirección de correo electrónico del remitente verificada de Amazon SES.
• Cierre las instancias de Amazon EC2 que ejecuten Keycloak y EJBCA (si están implementadas para esta demostración).
• Revoca y elimina todos los certificados de prueba en EJBCA mediante la consola de administración de EJBCA o la API REST.
• Elimine el dominio Keycloak (mcp-realm) y los clientes asociados.
• Si utilizó la configuración basada en scripts, ejecute. /scripts/cleanup.sh (Linux) o. /scripts/cleanup.bat (Windows) para automatizar estos pasos.

Conclusión

En esta publicación, mostramos una arquitectura de referencia para proteger las comunicaciones de los agentes de IA mediante la PKI X.509 con los servicios Keyfactor EJBCA y AWS. La arquitectura aborda la brecha de identidad fundamental en los sistemas de IA con múltiples agentes

• Los sobres de solicitud firmados proporcionan una prueba criptográfica de posesión en cada llamada entre agentes, lo que hace que sea mucho más difícil para una parte no autorizada falsificar la identidad de un agente o reproducir sus solicitudes.
• Las afirmaciones de delegación firmadas por los usuarios desvinculan la autorización del intercambio de credenciales. Los agentes demuestran que están autorizados a actuar en nombre del usuario sin tener la clave privada del usuario ni el token de sesión completa
.
• Los tokens con alcance de audiencia según el RFC 8693 limitan el alcance de cualquier divulgación de un token a un único límite de servicio.
La
• comprobación de revocación por OCSP en tiempo real confirma que la revocación de credenciales surte efecto de forma inmediata en todo el sistema. La revocación de un certificado de usuario pone fin inmediatamente
a toda la autoridad de los agentes intermedios.

Esta arquitectura es independiente del marco. Si bien lo demostramos con el SDK de AWS Strands Agents y FastMCP, los mismos patrones de PKI se aplican a LangChain, CrewAI, AutoGen o cualquier otro marco multiagente que utilice protocolos de herramientas. A medida que los agentes de IA proliferan y obtienen acceso a operaciones cada vez más delicadas, la infraestructura de identidad de los agentes pasa de ser opcional a

Para comenzar con esta arquitectura de referencia, consulta el repositorio de GitHub adjunto. Para obtener más información sobre los servicios utilizados, consulta los siguientes recursos:

• Base amazónica
• Guía del usuario de Amazon Bedrock
• Factor clave: EJBCA Enterprise
• Especificación MCP
• SDK de agentes de AWS Strands
• Presentamos Strands Agents, un SDK de código abierto para agentes de inteligencia artificial (entrada del blog de código abierto de AWS)

Acerca de los autores