AWS mostró cómo conectar servidores MCP protegidos con OAuth a Bedrock AgentCore Gateway

AWS mostró cómo conectar servidores MCP protegidos por OAuth a Amazon Bedrock AgentCore Gateway a través del flujo Authorization Code. El escenario está diseñado para equipos que necesitan inicio de sesión único para agentes de IA en herramientas corporativas sin tokens incrustados y sin configuración manual de cada integración.

Por qué se necesita Amazon Bedrock AgentCore Gateway

AWS posiciona el Gateway como el punto central a través del cual los agentes y clientes MCP obtienen acceso a las herramientas dentro de la empresa. En lugar de configurar cada servidor MCP por separado en un IDE, el equipo puede proporcionar a los desarrolladores una única URL de Gateway y reglas de acceso unificadas. AWS traslada la autenticación, la observabilidad y el control de políticas de acceso a esta capa para que las conexiones a las herramientas no crezcan en un conjunto de configuraciones manuales dispersas.

Esto es especialmente relevante para empresas donde los servidores MCP se multiplican: servicios internos propios, GitHub, Salesforce, Databricks y otros sistemas externos. Muchos de estos servidores están protegidos por OAuth 2.0 y requieren que el agente actúe en nombre de un usuario específico.

En ese esquema, el Gateway libera a las aplicaciones de trabajo adicional: no hay necesidad de incrustar credenciales en código, actualizar tokens de forma independiente o repetir la misma lógica para cada conector.

Dos Modos de Conexión

En el artículo, AWS muestra dos formas de conectar un servidor MCP protegido por OAuth al Gateway. La primera es sincronización implícita al crear un destino: el administrador pasa por el flujo Authorization Code durante CreateGatewayTarget, UpdateGatewayTarget o SynchronizeGatewayTargets, después de lo cual el Gateway lee la lista de herramientas y la almacena en caché. La segunda es proporcionar el esquema de herramientas de antemano sin esperar una solicitud en vivo al servidor durante la creación del destino. AWS nombra directamente la segunda opción como preferida donde la participación humana en crear o actualizar no es posible.

• La sincronización implícita requiere que el administrador complete la autorización y dé al Gateway acceso al servidor MCP ya en la fase de configuración.
• El esquema predefinido permite insertar inmediatamente la lista de herramientas y obtener un destino listo sin autorización al crear.
• En el modo con esquema predefinido, no puede usar SynchronizeGatewayTargets, porque el Gateway se basa en la descripción proporcionada en lugar de la lectura en vivo del servidor.
• Los usuarios de Gateway pueden ejecutar tools/list sin iniciar sesión en cada servidor, porque las definiciones de herramientas ya están en el caché.
• La autorización se activa solo cuando el usuario realmente llama a la herramienta necesaria a través de tools/call.

Como ejemplo, AWS utiliza el servidor MCP de GitHub. Para tal escenario, necesita un Gateway en versión MCP 2025-11-25 o más reciente, de lo contrario la opción Authorization code grant 3LO no estará disponible. La configuración también especifica la URL de retorno: aquí es donde el usuario o administrador regresa después de la pantalla de consentimiento, y luego la aplicación completa el intercambio a través de CompleteResourceTokenAuth.

Cómo Funciona la Autorización

La parte clave del esquema es la vinculación de AgentCore Gateway y AgentCore Identity. Primero, el Gateway obtiene un token de acceso de carga de trabajo, confirmando que tiene derecho a solicitar credenciales en nombre de su carga de trabajo. Luego, a través de un proveedor de credencial, recibe un token de acceso listo o la URL de autorización y URI de sesión si aún no se ha emitido un token para un usuario específico. En la fase de configuración inicial del destino, por esto, puede terminar en el estado Needs authorization, y después de completar el consentimiento pasar a Ready con la etiqueta Authorized.

AWS enfatiza por separado URL session binding. El mecanismo verifica que la autorización fue iniciada y completada por el mismo usuario, no por alguien que accidentalmente recibió un enlace reenviado. Después del consentimiento, el navegador regresa a la devolución de llamada, la aplicación pasa el URI de sesión e identidad del usuario a CompleteResourceTokenAuth, y solo después de esta verificación ocurre el intercambio del código de autorización por un token de acceso. Según AWS, el enlace de autorización y el URI de sesión duran 10 minutos, lo que reduce aún más la ventana para el abuso.

Para el usuario final, la lógica es más simple. La solicitud tools/list se sirve desde el caché de Gateway y no le obliga a iniciar sesión en todos los sistemas conectados de antemano. Pero tools/call ya inicia el flujo Authorization Code solo para ese servidor MCP cuya herramienta se está llamando realmente. Después del inicio de sesión exitoso, el token se almacena en caché en el Token Vault en la vinculación de identidad de carga de trabajo e identidad de usuario, por lo que las llamadas posteriores se pasan sin nueva autorización mientras el token siga siendo válido.

Qué Significa Esto

AWS está moviendo MCP de un conjunto de integraciones puntuales a una capa corporativa gestionada. Para equipos que construyen sistemas de agentes en múltiples herramientas externas e internas, esto reduce el caos en los accesos: el catálogo de herramientas se puede mostrar centralmente, y la autorización del usuario se puede activar solo en el momento de la invocación real del servidor necesario.