Protección de la identidad de agentes de IA con PKI X.509 en AWS

Cuando los agentes de IA acceden a bases de datos, API y operaciones comerciales sensibles, establecer identidad criptográfica mediante infraestructura de clave pública (PKI) X.509 se vuelve un requisito crítico. El desafío principal es demostrar qué agente realizó una solicitud, prevenir la falsificación entre agentes y confirmar que cada agente actúa solo en nombre de un usuario autorizado. Los enfoques tradicionales, como compartir claves de API entre componentes o pasar tokens OAuth a través de cadenas de agentes, no alcanzan los requisitos de confianza cero que exigen las implementaciones empresariales.

Los marcos de IA multiagente utilizan cada vez más el Model Context Protocol (MCP) para conectar agentes con herramientas externas y fuentes de datos. MCP define cómo un agente impulsado por un modelo de lenguaje de gran escala (LLM) invoca herramientas como consultas de bases de datos u operaciones de correo electrónico. Sin embargo, MCP no tiene un estándar de autenticación integrado. Es agnóstico al transporte por diseño. Esto crea una brecha crítica: sin mecanismos de identidad adecuados, cualquier componente podría suplantar a un agente, reproducir credenciales interceptadas o invocar herramientas sin autorización.

En esta publicación, le mostramos cómo abordar esta brecha usando Keyfactor EJBCA combinado con servicios de AWS. EJBCA es una plataforma PKI que admite despliegue de alta disponibilidad, automatización mediante API REST y validación mediante Online Certificate Status Protocol (OCSP). La arquitectura de referencia utiliza cuatro mecanismos de seguridad complementarios. Primero, los sobres de solicitud firmados proporcionan prueba criptográfica de posesión en cada llamada del agente. Segundo, las aserciones de delegación firmadas por el usuario autorizan a los agentes sin compartir credenciales. Tercero, los tokens con alcance de audiencia según RFC 8693 limitan el alcance de la exposición ante la divulgación de cualquier token individual. Cuarto, la verificación de revocación OCSP en tiempo real propaga los cambios de credenciales de inmediato entre todos los agentes.

La solución utiliza Amazon Bedrock para la inferencia de LLM a través del AWS Strands Agents SDK. Si bien esta arquitectura de referencia usa una base de datos como recurso protegido, el mismo patrón de autenticación 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 que acompaña a esta publicación.

Acerca de Keyfactor EJBCA

Keyfactor ofrece una plataforma de gestión de identidad de máquinas ampliamente adoptada, utilizada por más de 1,500 clientes empresariales en todo el mundo, según Keyfactor. Estas organizaciones abarcan servicios financieros, salud, manufactura y gobierno. Keyfactor ayuda a las organizaciones a establecer y mantener confianza criptográfica mediante la gestión del ciclo de vida de certificados, operaciones PKI y gobernanza de identidad de máquinas.

EJBCA Enterprise es la plataforma de Autoridad Certificadora (CA) y PKI de Keyfactor, diseñada para despliegue de alta disponibilidad y automatización mediante API REST. Disponible como producto empresarial, EJBCA ofrece emisión de certificados X.509, validación OCSP, distribución de listas de revocación de certificados (CRL) y gestión completa del ciclo de vida de certificados tanto a través de una consola web como de una API REST. EJBCA admite despliegue en instalaciones locales, en contenedores o en Amazon Elastic Compute Cloud (Amazon EC2).

La alianza entre AWS y Keyfactor reúne servicios administrados de AWS (Amazon Bedrock, AWS Secrets Manager, Amazon Relational Database Service (Amazon RDS)) con infraestructura PKI que admite gestión del ciclo de vida de certificados, inscripción automatizada y revocación en tiempo real. Esta combinación aborda una brecha en el ecosistema de agentes de IA. Mientras AWS proporciona las capas de cómputo, almacenamiento e inferencia de IA, 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 mostrados aquí a sus propios despliegues multiagente.

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 de los agentes. Estas tres capas utilizan los cuatro mecanismos de seguridad presentados anteriormente: sobres firmados para la prueba de posesión, aserciones de delegación para autorización sin credenciales, tokens con alcance de audiencia para la limitación de exposición y OCSP para la revocación en tiempo real. Los mecanismos se combinan entre capas como se muestra en la siguiente tabla.

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 del usuario (que permanecen en el flujo de inicio de sesión), las credenciales de los agentes (delimitadas por agente) y la cadena de delegación que las conecta.

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

La Figura 2 ilustra el flujo detallado de tráfico 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 de tráfico de autenticación desde el inicio de sesión del usuario, pasando por la delegación al agente, la invocación de herramientas y la limpieza de la sesión

Servicios de AWS utilizados

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

Recorrido de la solución

Los siguientes pasos recorren 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, estableciendo una cadena de confianza que conecta al usuario humano con la ejecución final de la herramienta.

Requisitos previos

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

Paso 1: Inicio de sesión del usuario, emisión de certificados y creación de la delegación

El flujo de inicio de sesión establece la identidad del usuario mediante tres mecanismos y luego delega autoridad a los agentes de IA sin compartir las credenciales del usuario. Esta separación es crítica: los agentes reciben prueba de autorización sin llegar a poseer la clave privada del usuario ni el token OAuth de sesión completa.

Primero, la aplicación autentica al usuario contra Keycloak usando una concesión de contraseña OAuth 2.0, recibiendo un token de acceso de sesión completa y un token de actualización. Inmediatamente después, la aplicación realiza un intercambio de tokens RFC 8693 para obtener un token con ámbito reducido. La audiencia de este token está restringida al servidor MCP. Solo este token limitado se entrega a los agentes. Si se expone inadvertidamente, no puede acceder a ningún otro servicio de la organización.

Segundo, 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 pkcs10enroll endpoint de la REST API. EJBCA firma la CSR y devuelve el certificado. La aplicación empaqueta el certificado y la clave privada en un contenedor PKCS12 y lo 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 y no se almacena en el sistema de archivos. Se emiten tres certificados de agente usando el mismo flujo basado en CSR, uno por cada rol de agente.

Tercero, la clave privada del usuario firma una aserción de delegación. Este es un documento JSON que enumera las huellas digitales SHA-256 de los tres certificados de agente, junto con el nombre de sujeto 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 - downscope to MCP audience
downscoped_token = keycloak.token_exchange(
    original_token, audience="mysql-mcp-server", scope="database:write"
)
# Client-side key generation (user key never leaves this flow)
private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
csr = build_csr(private_key, f"CN={username},E={username}@org.com")
user_cert = ejbca.pkcs10enroll(csr, ca_name="UserCA")
# User signs delegation over agent cert fingerprints
delegation = mint_delegation(
    username=username,
    user_cert_pem=user_cert,
    user_key_pem=private_key_pem,
    agent_cert_pems=[orch_cert, mysql_cert, email_cert]
)
# Result: {sub, agent_fingerprints[], iat, exp, user_cert_pem, signature_b64}

Paso 2: Sobres firmados de agente a agente

Cuando el agente orquestador enruta una solicitud a un subagente (como el agente de MySQL o el agente de Email), no se limita a pasar su certificado para identificarse. En cambio, firma toda la carga útil de la solicitud, incluido el nombre de la herramienta, los argumentos, una marca de tiempo y un nonce aleatorio criptográfico, utilizando su clave privada con RSA-PSS-SHA256. El sobre firmado resultante proporciona prueba de posesión. El agente receptor puede verificar que quien llama realmente posee la clave privada correspondiente al certificado presentado.

El agente receptor realiza seis comprobaciones de validación sobre 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. Frescura de la marca de tiempo: El sobre debe estar dentro de ENVELOPE_MAX_AGE_SECONDS (por defecto 60 segundos) de la hora actual.
3. Unicidad del nonce: El ReplayCache rechaza cualquier nonce visto previamente, evitando la repetición de solicitudes.
4. Validación de la cadena de CA: El certificado del remitente debe encadenar hasta la CA confiable (UserCA.pem).
5. Autorización de roles: El sufijo de rol del CN del certificado debe estar en ALLOWED_CALLER_ROLES para este agente.
6. Comprobación de revocación OCSP: Una comprobación en tiempo real contra EJBCA confirma que el certificado no ha sido revocado.

Si el orquestador necesita reenviar el mismo prompt (por ejemplo, después de un fallo transitorio), debe crear un nuevo sobre con un nonce fresco. Los sobres antiguos no pueden reproducirse, ni siquiera por el remitente legítimo.

# Orchestrator signs request to sub-agent
envelope = sign_envelope(
    payload={"tool": "query_database", "args": {"sql": "SELECT ..."}},
    cert_pem=orchestrator_cert_pem,
    private_key_pem=orchestrator_key_pem
)
# envelope: {payload_b64, cert_pem, timestamp, nonce, signature_b64, alg}
# Sub-agent verifies (six checks)
verified_payload = verify_envelope(
    envelope,
    allowed_role="orchestrator-agent",
    ca_cert_pem=ca_pem,
    replay_cache=cache
)

Paso 3: autenticación del servidor MCP

El servidor MCP (FastMCP) es la frontera 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 herramienta, implementando defensa en profundidad. Incluso si una credencial sufre un acceso no autorizado, las comprobaciones restantes evitan operaciones no autorizadas.

La secuencia de autenticación:

1. Introspección del token: Un POST al endpoint /token/introspect de Keycloak verifica que el token esté activo y que su audiencia contenga “mcp-server”. Un token de sesión completa sin la audiencia correcta es rechazado.
2. Verificación del sobre: El sobre firmado del agente se valida para comprobar la corrección de la firma, la frescura de la marca de tiempo, la unicidad del nonce, la confianza en la cadena de CA, la coincidencia de rol (mysql-agent) y la no revocación mediante OCSP.
3. Verificación de la delegación: La aserción de delegación del usuario se valida. La firma demuestra que el poseedor de la clave del usuario autorizó esta delegación, la huella digital del certificado del agente que llama aparece en la lista de autorizados, y el certificado del usuario se comprueba mediante OCSP.
4. Cruzamiento de identidad: El nombre de usuario del token, el sujeto de la delegación y el prefijo del CN del certificado del agente deben coincidir todos. Esto confirma una única cadena de identidad consistente desde el usuario hasta la ejecución de la herramienta.

# MCP Server - Four validation checks
# 1. Token: must be active with correct audience
info = introspect(token)
assert info["active"] and "mcp-server" in info["aud"]
# 2. Envelope: proof-of-possession + freshness + replay + CA + role + OCSP
payload = verify_envelope(envelope, "mysql-agent", ca_pem, replay_cache)
# 3. Delegation: user authorized this agent + user cert not revoked
claims = verify_delegation(delegation, agent_cert_pem, ca_pem)
# 4. Cross-check: consistent identity chain
assert token_username == claims["sub"] == agent_cn.rsplit("_", 1)[0]
# All checks passed - execute tool
result = execute_sql(payload["args"]["sql"])

Paso 4: prevención de repetición

Cada sobre firmado lleva un nonce único, una cadena hexadecimal criptográficamente aleatoria de 128 bits generada con el módulo secrets de Python. El ReplayCache es un almacén en memoria seguro para hilos que recuerda cada nonce hasta que su ventana de frescura expira (2x ENVELOPE_MAX_AGE_SECONDS). Si el mismo nonce aparece en una segunda solicitud, el sobre se rechaza de inmediato, incluso si su firma es válida y la marca de tiempo es reciente.

La validación de la marca de tiempo complementa la comprobación del nonce. La marca de tiempo de un sobre debe estar dentro de ENVELOPE_MAX_AGE_SECONDS (por defecto 60 segundos) respecto a la hora actual del servidor. Juntos, estos mecanismos abordan cuatro escenarios de acceso no autorizado:

• Repetición grabada: Un usuario no autorizado captura un sobre válido y lo reenvía más tarde. El nonce ya fue visto.
• Entrega retrasada: Un sobre interceptado en tránsito llega después de la ventana de frescura. La comprobación de la marca de tiempo falla.
• Reutilización de solicitudes obsoletas: Un sobre antiguo almacenado en caché por un proxy se reenvía. Ambas comprobaciones, la del nonce y la de la marca de tiempo, fallan.
• Falsificación precalculada: Un usuario no autorizado no puede predecir los nonces futuros para presfirmar sobres.

Paso 5: Generación de claves en el lado del cliente

Una propiedad de seguridad crítica de esta arquitectura es que las claves privadas se generan localmente y nunca se transmiten a ningún sistema externo. La aplicación genera pares de claves RSA 2048+ usando la biblioteca cryptography de Python. Construye un CSR que contiene únicamente la clave pública y la información del sujeto, y envía solo el CSR a EJBCA a través del pkcs10enroll endpoint.

EJBCA valida el CSR, aplica el perfil de certificado (validez de 7 días, restricciones de uso de clave), lo firma con la clave de la CA y devuelve el certificado emitido. La aplicación entonces empaqueta la clave privada mantenida localmente junto con el certificado devuelto en un contenedor PKCS12 y lo almacena en AWS Secrets Manager.

Este diseño proporciona varias propiedades de seguridad:

• La clave privada del usuario se usa solo en el inicio de sesión para firmar la aserción de delegación. Nunca se comparte con los agentes.
• La clave privada de cada agente es usada solo por ese agente para firmar sobres. Nunca se comparte entre agentes.
• EJBCA nunca ve ni almacena claves privadas. Opera puramente como una autoridad certificadora.
• Si Secrets Manager sufre un acceso no autorizado, la contraseña del PKCS12 (almacenada por separado) añade una capa adicional.
• El material de claves puede rotarse de forma independiente reinscribiéndose con un nuevo CSR en el siguiente inicio de sesión.

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

El cierre de sesión desencadena una cascada de revocación que invalida de inmediato todas las credenciales pendientes. La secuencia da como resultado que no queden credenciales válidas tras su finalización:

1. Revocar el certificado de usuario en EJBCA: Esto invalida inmediatamente todas las delegaciones pendientes, porque la verificación de la delegación comprueba el certificado del usuario mediante OCSP en tiempo real.
2. Revocar los tres certificados de agente: Esto invalida todos los sobres firmados pendientes, ya que la verificación del sobre incluye OCSP.
3. Eliminar todos los secretos de AWS Secrets Manager: Usando ForceDeleteWithoutRecovery para su eliminación inmediata sin ventana de recuperación.
4. Terminar la sesión de Keycloak: Invalida el token de ámbito reducido a través del endpoint de terminación de sesión.

La cascada de revocación es la propiedad de seguridad clave. Revocar un solo certificado de usuario en la capa PKI revoca rápidamente toda la autoridad de los agentes posteriores sin necesidad de revocar tokens individualmente, eliminar sesiones o contactar con cada agente. OCSP proporciona el mecanismo de propagación, y como cada solicitud comprueba OCSP, el efecto es inmediato.

Consideraciones de seguridad

Las decisiones de diseño en esta arquitectura abordan varias propiedades de seguridad que son importantes para implementaciones multiagente en producción.

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

Delegación en comparación con el uso compartido de credenciales. Los agentes demuestran su autoridad a través de una cadena criptográfica (delegación a huella del agente a firma del sobre) sin mantener nunca las credenciales del usuario. Si se expone una clave de agente, solo se revela la clave de ese agente, no la del usuario.

Tokens con ámbito de audiencia. El intercambio de tokens RFC 8693 produce un token aceptado únicamente por el servidor MCP. Un token de ámbito reducido divulgado inadvertidamente no puede autenticarse contra las API de administración de Keycloak, otros servicios, ni siquiera contra una instancia diferente del servidor MCP.

Prevención de repetición. La combinación de nonces por solicitud y una ventana de frescura de 60 segundos confirma que cada solicitud es de un solo uso y limitada en el tiempo. El ReplayCache es seguro para subprocesos y se autolimpia.

Diseño de fallo cerrado. Cada fallo de validación resulta en una denegación inmediata. OCSP inaccesible: denegar. Firma no válida: denegar. Marca de tiempo caducada: denegar. Nonce repetido: denegar. Audiencia incorrecta: denegar. No hay degradación elegante para las comprobaciones de seguridad.

Cascada de revocación. Revocar un certificado de usuario invalida rápidamente todas las delegaciones, toda la autoridad de los agentes y todos los sobres pendientes. Esto se propaga mediante OCSP en tiempo real sin requerir una limpieza individual de credenciales.

Cadena de confianza solo hacia adelante. El mapa ALLOWED_CALLER_ROLES garantiza que solo orchestrator-agent pueda llamar a mysql-agent y a email-agent. Los subagentes no pueden llamarse entre sí, no pueden llamar hacia arriba al orquestador y no pueden suplantar al usuario.

Consideraciones de gobernanza de IA

La arquitectura PKI proporciona límites de comportamiento integrados para los agentes de IA en este sistema. Las implementaciones en producción deben usar Amazon Bedrock Guardrails para aplicar filtrado de contenido, evitación de temas y comprobaciones de fundamentación en las respuestas de los agentes, junto con los controles de acceso basados en PKI descritos en esta publicación.

• 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 ámbito de su certificado.
• Supervisión humana: Todas las acciones de los agentes se registran y son auditables. AWS CloudTrail captura las llamadas a la API de AWS, y el servidor MCP registra cada invocación de herramienta validada con la cadena de identidad completa (usuario, agente, marca de tiempo y operación).
• Manejo de datos: Las consultas y los resultados de los usuarios permanecen dentro del límite de la sesión autenticada. El token con ámbito de audiencia restringe 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 herramientas para las que tengan certificados válidos. Un agente sin un mysql-agent certificado no puede acceder a la base de datos, independientemente de lo que el LLM pueda generar como instrucciones.

Extensión de la arquitectura

Puede extender esta arquitectura para admitir tipos de agentes adicionales, escalado horizontal y aislamiento multiinquilino. Los siguientes párrafos describen los puntos de extensión más comunes.

• Para añadir nuevos tipos de agentes, solo necesita añadir una entrada en ALLOWED_CALLER_ROLES. Los certificados se emiten automáticamente al iniciar sesión, y la aserción de delegación incluye dinámicamente la huella digital del nuevo agente. No se requieren cambios en la infraestructura.
• Para el escalado horizontal, puede desplegar el respondedor OCSP de EJBCA en modo de alta disponibilidad detrás de un balanceador de carga. AWS Secrets Manager admite tasas de solicitud altas adecuadas para esta carga de trabajo. El ReplayCache puede estar respaldado por Amazon ElastiCache para despliegues distribuidos.
• Para reforzar la arquitectura para producción, puede usar claves de firma de EJBCA respaldadas por un módulo de seguridad de hardware (HSM) mediante AWS CloudHSM o un HSM local. El grapado de respuestas OCSP reduce la latencia de validación, y los registros de Certificate Transparency proporcionan una pista de auditoría completa de los certificados emitidos.
• Para despliegues multiinquilino, puede crear entidades de certificación por inquilino o autoridades de delegación por inquilino para lograr un aislamiento criptográfico de los inquilinos. Combinado con cuentas de AWS por inquilino, esto proporciona un aislamiento fuerte entre inquilinos.
• También puede complementar la identidad de los agentes basada en PKI con roles de AWS Identity and Access Management (IAM). Use PKI para la autenticación entre agentes e IAM para la autorización de servicios de AWS. Los dos sistemas funcionan de forma independiente, proporcionando defensa en profundidad.

Limpieza

Para evitar cargos continuos, elimine los recursos creados durante esta guía:

• Elimine la instancia de Amazon RDS para MySQL (o la pila de AWS CloudFormation si usó la configuración mediante scripts).
• Elimine todos los secretos de AWS Secrets Manager, incluidos los certificados de usuario y los certificados de agente bajo el mcp/ prefijo.
• Elimine la dirección de correo electrónico del remitente verificada de Amazon SES.
• Finalice las instancias de Amazon EC2 que ejecutan Keycloak y EJBCA (si se desplegaron para esta demostración).
• Revoque y elimine todos los certificados de prueba en EJBCA utilizando la consola de administración de EJBCA o la API REST.
• Elimine el realm de Keycloak (mcp-realm) y los clientes asociados.
• Si utilizó la instalación mediante scripts, ejecute ./scripts/cleanup.sh (Linux) o ./scripts/cleanup.bat (Windows) para automatizar estos pasos.

Conclusión

En esta publicación, demostramos una arquitectura de referencia para proteger las comunicaciones de los agentes de IA mediante X.509 PKI con Keyfactor EJBCA y servicios de AWS. La arquitectura aborda la brecha fundamental de identidad en los sistemas de IA multiagente a través de cuatro mecanismos complementarios:

• Los sobres de solicitudes firmadas proporcionan prueba criptográfica de posesión en cada llamada entre agentes, lo que dificulta significativamente que una parte no autorizada suplante la identidad de un agente o reproduzca sus solicitudes.
• Las aserciones de delegación firmadas por el usuario desacoplan la autorización del uso compartido de credenciales. Los agentes demuestran que están autorizados a actuar en nombre del usuario sin poseer la clave privada del usuario ni el token de sesión completo.
• Los tokens con alcance de audiencia según RFC 8693 limitan el alcance de la exposición ante cualquier divulgación de un token a un único límite de servicio.
• La verificación de revocación en tiempo real mediante OCSP confirma que la revocación de credenciales surte efecto inmediato en todo el sistema. Revocar un certificado de usuario finaliza rápidamente toda la autoridad de los agentes descendentes.

Esta arquitectura es agnóstica del marco de trabajo. Si bien la 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 sensibles, la infraestructura de identidad de agentes pasa de ser opcional a esencial.

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

• Amazon Bedrock
• Amazon Bedrock User Guide
• Keyfactor EJBCA Enterprise
• MCP Specification
• AWS Strands Agents SDK
• Introducing Strands Agents, an Open Source AI Agents SDK (entrada del blog de AWS Open Source)

Sobre los autores