Cuando los agentes de IA se conectan a herramientas a través del Protocolo de contexto modelo (MCP), obtienen acceso a capacidades que van desde consultas de bases de datos y llamadas API hasta operaciones de archivos e integraciones de servicios de terceros. En producción, estas interacciones necesitan una gobernanza, controles y observabilidad adecuados alineados con las políticas de seguridad de una organización. Esto incluye desinfectar las entradas de las herramientas antes de que lleguen a los sistemas backend, generar pistas de auditoría en formatos específicos o redactar datos confidenciales en la capa de protocolo. Estos requisitos están determinados por los estándares de gobierno interno, las regulaciones de la industria y las características específicas de cada entorno de producción. Esta publicación le muestra cómo implementar un proxy MCP sin servidor en Amazon Bedrock AgentCore Runtime que le brinda una capa programable para implementar estos controles.
Amazon Bedrock AgentCore Gateway proporciona gobernanza y control centralizados para la integración de agentes y herramientas, incluido el descubrimiento de herramientas semánticas, credenciales administradas y aplicación de políticas. Para las organizaciones que necesitan incorporar lógica personalizada en la ruta de solicitud de Gateway, Gateway admite interceptores Lambda. Estos interceptores le permiten ejecutar código de validación, transformación o filtrado como funciona AWS Lambda en cada invocación de herramienta. Esto le permite mantener su lógica personalizada autónoma y administrada junto con la configuración de su puerta de enlace.
Sin embargo, algunas organizaciones han invertido en una lógica de filtrado MCP personalizada que está estrechamente vinculada con bibliotecas internas o sistemas de cumplimiento locales. Quieren reutilizar esa lógica en AgentCore Runtime sin refactorizarla en funciones Lambda. Otros operan en múltiples sistemas o entornos híbridos donde ejecutar controles como un servidor MCP independiente ofrece más portabilidad que un interceptor específico del sistema. En estos casos, un proxy MCP sin servidor que se ejecuta en AgentCore Runtime puede proporcionar un patrón complementario.
AgentCore Runtime es un entorno informático totalmente administrado para implementar agentes de IA y servidores MCP. Proporciona infraestructura sin servidor con escalamiento automático, observabilidad integrada a través de Amazon CloudWatch y OpenTelemetry, y AgentCore Identity para autenticación y autorización. Debido a que Runtime admite de forma nativa el protocolo MCP, le permite alojar servidores MCP, incluidos servidores proxy MCP que agregan controles personalizados al tráfico MCP.
Le mostramos cómo crear e implementar un proxy MCP sin estado en AgentCore Runtime que le permite agregar controles programables al tráfico MCP. El proxy se ejecuta como una carga de trabajo sin servidor en tiempo de ejecución, descubre herramientas de un servidor MCP ascendente al inicio, las vuelve a exponer con su lógica personalizada aplicada y reenvía solicitudes de forma transparente. El servidor MCP ascendente puede ser su elección de punto final compatible con MCP, incluidos servidores MCP que se ejecutan en AgentCore Runtime, servidores MCP autohospedados o servicios MCP de terceros. También puede conectar este proxy a Amazon Bedrock AgentCore Gateway. Esto le permite aprovechar el descubrimiento de herramientas administradas, la administración de credenciales y la aplicación de políticas de Gateway en servidores MCP, funciones Lambda e integraciones SaaS.
Utilizando una implementación de GitHub de código abierto como base, lo guiaremos a través de la arquitectura, le explicaremos cómo funciona la autorización en cada capa, implementaremos el proxy con un script automatizado y probaremos el flujo de un extremo a otro con un agente de muestra. Al final, tendrá un patrón de implementación funcional para agregar controles personalizados al tráfico MCP utilizando AgentCore Runtime.
Descripción general de la solución
El proxy MCP personalizado se ejecuta en AgentCore Runtime y actúa como intermediario entre los clientes MCP y los servidores MCP ascendentes. Los clientes MCP interactúan con el proxy como lo harían con otros servidores MCP; el proxy aplica su lógica especializada y reenvía solicitudes al servidor ascendente. Esta separación le permite introducir controles personalizados en la capa de protocolo sin modificar el servidor MCP ascendente o el cliente.
Componentes de arquitectura
La solución implica tres capas lógicas que funcionan juntas a través de MCP: el cliente MCP, el proxy MCP en AgentCore Runtime y el servidor MCP ascendente. El flujo de solicitudes se mueve a través de estas capas de forma secuencial: el cliente envía solicitudes MCP al proxy, el proxy aplica su lógica personalizada y reenvía la solicitud al servidor MCP ascendente, y el servidor ascendente procesa la solicitud y devuelve la respuesta a través de la misma ruta.
El servidor MCP ascendente se puede alojar en cualquier lugar, incluso en AgentCore Runtime, en su propia infraestructura o como un servicio de terceros. En esta publicación, utilizamos un AgentCore Gateway como servidor MCP ascendente porque proporciona un punto final de herramienta compatible con MCP listo para usar con objetivos registrados, lo que le permite seguir el tutorial de un extremo a otro sin tener que utilizar un servidor MCP separado. El patrón de proxy se aplica a otros puntos finales ascendentes compatibles con MCP y analizamos alternativas a lo largo de la publicación, incluidos los servidores MCP ascendentes que se ejecutan en AgentCore Runtime.
El siguiente diagrama muestra la arquitectura, incluidos los flujos de solicitud y autenticación:
Figura 1: Diagrama de arquitectura que muestra los flujos de solicitud y autenticación. Este tutorial utiliza AgentCore Gateway como servidor MCP ascendente.
El cliente MCP en Runtime trata el proxy MCP personalizado como su servidor de herramientas y envía solicitudes MCP estándar para descubrir e invocar herramientas. Desde la perspectiva del cliente, el proxy no se distingue de otros servidores MCP. AgentCore Runtime proporciona computación administrada, escalado automático y observabilidad integrada para la carga de trabajo del cliente.
El proxy MCP actúa como intermediario entre el cliente y el servidor MCP ascendente. Recibe solicitudes MCP del cliente, aplica su lógica personalizada y reenvía las solicitudes al servidor ascendente. El proxy se ejecuta como un servidor MCP independiente en Runtime, utilizando la misma infraestructura administrada sin servidor que el propio cliente.
El proxy se conecta al servidor MCP ascendente como un cliente MCP estándar. El servidor ascendente trata al proxy como un cliente MCP autenticado, sin diferenciarse de otras personas que llaman autorizadas. El servidor ascendente maneja el acceso a los servicios descendentes y a las herramientas MCP.
Las herramientas en sí, ya sea alojadas como servidores MCP, funciones de AWS Lambda o integraciones de SaaS de terceros, están registradas y administradas por el servidor ascendente. Para las organizaciones que buscan una ruta totalmente administrada hacia la integración de herramientas, AgentCore Gateway proporciona una forma sencilla y segura para que los desarrolladores creen, implementen, descubran y se conecten a herramientas a escala.
Cómo funciona el proxy MCP
Implementamos el proxy usando FastMCP para descubrir herramientas del servidor MCP ascendente al inicio y reenviar cada solicitud del cliente en tiempo de ejecución. El proxy no define herramientas propias y no tiene conocimiento previo de lo que expone el servidor ascendente.
Cuando se inicia el proceso de proxy, envía una solicitud de lista/herramientas MCP estándar al servidor ascendente. El servidor devuelve el catálogo completo de herramientas disponibles. Para cada herramienta, el proxy registra dinámicamente una herramienta FastMCP local con el mismo nombre y descripción. Cada herramienta está respaldada por una función de controlador que reenvía herramientas/solicitudes de llamada al servidor ascendente y devuelve la respuesta. Los clientes MCP que se conectan al proxy ven el mismo catálogo de herramientas y obtienen los mismos resultados que si se conectaran directamente al servidor ascendente.
Debido a que el proxy es un servidor Python MCP estándar que usted posee e implementa, puede insertar una lógica personalizada antes de reenviar una llamada a la herramienta o después de recibir la respuesta. El servidor ascendente maneja la ejecución de la herramienta, mientras que el proxy agrega una capa programable al frente sin reemplazar las capacidades nativas del servidor ascendente.
Autorización entre componentes
La autorización se aplica de forma independiente en cada capa de la arquitectura, creando límites de confianza distintos en todo el flujo.
Agente a proxy MCP: cuando un agente se conecta al proxy MCP, utiliza AgentCore Identity para autenticación y autorización. El proxy utiliza las capacidades que proporciona AgentCore Identity, incluida la gestión centralizada de las identidades de los agentes y el almacenamiento seguro de credenciales. Usted controla qué agentes y principales pueden invocar el proxy utilizando el mismo marco de identidad que utiliza para sus otras cargas de trabajo en AgentCore Runtime. Proxy al servidor MCP ascendente: el proxy debe autenticarse en el servidor MCP ascendente al que se conecta. El método de autenticación depende de los requisitos del servidor ascendente. AgentCore Identity proporciona autorización entrante para cargas de trabajo alojadas en AgentCore Runtime a través de AWS Identity and Access Management (IAM) utilizando AWS Signature Versión 4 (SigV4) y autorización basada en JSON Web Token (JWT) utilizando credenciales de cliente OAuth 2.0. Con la autorización basada en JWT, usted configura el servidor ascendente con una URL de descubrimiento, audiencias permitidas y clientes permitidos. AgentCore Identity valida el token de portador en cada solicitud. El proxy obtiene tokens a través de la concesión de credenciales de cliente OAuth 2.0 y los incluye como Autorización: encabezados de portador.
Para la autorización basada en IAM, el proxy firma solicitudes mediante AWS SigV4 con la función de ejecución de IAM que hereda de AgentCore Runtime. Los permisos específicos difieren según el tipo de servidor ascendente. Si el servidor MCP ascendente está alojado en AgentCore Runtime, puede limitar el permiso bedrock-agentcore:InvokeAgentRuntime para controlar qué personas que llaman pueden acceder a él. Alternativamente, si el servidor ascendente es una puerta de enlace AgentCore, como en este tutorial, el permiso bedrock-agentcore:InvokeGateway se aplica a puertas de enlace e identidades de llamantes específicas. Esto garantiza que solo los servidores proxy confiables puedan acceder al catálogo de herramientas.
El proyecto GitHub adjunto utiliza la autorización basada en IAM como método predeterminado. El script de implementación también admite la autorización basada en JWT para esta integración.
Servidor ascendente a herramientas: el servidor MCP ascendente se autentica en herramientas descendentes mediante proveedores de credenciales AgentCore Identity, que administran tokens OAuth 2.0, claves API y rotación de credenciales de forma transparente. La autorización de salida funciona de la misma manera independientemente de si las solicitudes se originan desde el proxy o desde un cliente directo.
Cada capa de esta arquitectura se autentica de forma independiente. Usted inyecta lógica personalizada en la capa del protocolo MCP a través del proxy, mientras que el servidor ascendente continúa manejando la ejecución de la herramienta y su propia autorización. El resultado es una arquitectura donde los controles personalizados y las capacidades ascendentes operan en capas separadas y bien definidas.
Requisitos previos
Para implementar la solución, debe tener lo siguiente:
Implementar la solución
Complete los siguientes pasos para implementar el proyecto en su cuenta de AWS:
Comience clonando el repositorio de GitHub y revisando la estructura del proyecto. Abra implementar_config.json y establezca los valores para su entorno: 
Figura 2: Captura de pantalla de configuración que muestra los ajustes de implementación. Reemplace el valor en gateway_endpoint con la URL del punto final de MCP de su servidor MCP ascendente (AgentCore Gateway en este ejemplo). Establezca la región en la región de AWS donde se implementa el servidor ascendente. El campo gateway_api_id es opcional. Si su servidor ascendente es una puerta de enlace AgentCore y proporciona su nombre de recurso de Amazon (ARN), el script de implementación limita los permisos de IAM a ese recurso específico. Si lo deja como nulo, el script otorga permisos para invocar todas las puertas de enlace de la cuenta.
El campo auth_mode determina cómo el proxy se autentica en el servidor ascendente y el valor predeterminado es "iam" para la autenticación basada en IAM. Si configura auth_mode en "jwt" para la autenticación basada en OAuth, debe configurar los campos de Cognito (cognito_user_pool_id, cognito_client_id y cognito_domain) con valores de su grupo de usuarios de Cognito. Luego, pase el secreto del cliente Cognito a través del indicador –cognito-client-secret cuando ejecute el script de implementación. Cuando utilice la autenticación IAM, deje todos los campos de Cognito como nulos.
Ejecute el script de implementación automatizada setup_and_deploy.py, desde la raíz del proyecto. Automatiza el flujo de trabajo de implementación completo, que realiza los siguientes pasos en secuencia: Valida los requisitos previos: verifica que AWS CLI, Python y Docker estén disponibles y que las credenciales de AWS estén configuradas. Crea una función de ejecución de IAM: crea una función con una política de confianza que permite a bedrock-agentcore.amazonaws.com asumirla. El rol incluye permisos para invocar la puerta de enlace, escribir en Amazon CloudWatch Logs y extraer imágenes de Amazon ECR. Configura el agente con la CLI de AgentCore: ejecuta la configuración de agentcore con el protocolo MCP, apuntando al punto de entrada del proxy en mcp_proxy/main.py. Durante este paso, la CLI le solicita que seleccione un repositorio de ECR y confirme el modo de autenticación. Inicia el agente en AgentCore Runtime: ejecuta el inicio del agente y pasa el punto final del servidor ascendente como una variable de entorno (GATEWAY_ENDPOINT). AgentCore Runtime crea la imagen del contenedor, la envía a Amazon ECR e inicia el agente. Verifique el estado del agente proxy MCP: estado del agente central –agent mcp_proxy.
Tenga en cuenta el ARN del agente de la salida. Utilice este ARN en el agente del cliente de prueba para invocar posteriormente el proxy.
Cómo configurar el método de autenticación de proxy
El modo de autenticación entre el proxy MCP y el servidor ascendente depende de cómo esté configurada la autorización entrante al servidor ascendente. AgentCore Identity admite la autenticación entrante IAM y JWT para cargas de trabajo alojadas en AgentCore. El código de proxy en GitHub implementa cada modo en una única función _send_gateway_request, donde se realizan las llamadas HTTP salientes al servidor ascendente.
Autorización IAM
El proxy firma cada solicitud saliente al servidor ascendente mediante AWS SigV4. Dado que el proxy se ejecuta en AgentCore Runtime, hereda la función de ejecución de IAM especificada durante la implementación. El script de implementación otorga a este rol permisos bedrock-agentcore:InvokeGateway, con el campo Recurso enfocado a la puerta de enlace. No se requieren credenciales ni tokens adicionales. El proxy utiliza la sesión boto3 del tiempo de ejecución para firmar solicitudes automáticamente.
Autorización OAuth
Si su servidor ascendente utiliza un autorizador JWT, el proxy reemplaza la firma SigV4 con un token de portador obtenido a través de la concesión de credenciales de cliente OAuth 2.0. Este modo está integrado en el proxy y no requiere cambios de código. Debe configurar auth_mode en jwt en la configuración de implementación y proporcionar los detalles de su grupo de usuarios de Cognito.
Cuando selecciona JWT, el script recopila el ID del grupo de usuarios de Cognito, el ID del cliente de la aplicación, el secreto del cliente de la aplicación y el prefijo de dominio. Estos valores se pasan al contenedor AgentCore Runtime como variables de entorno durante el paso de inicio de AgentCore. También puede configurar estos valores directamente en implementar_config.json para omitir las indicaciones interactivas.
Al inicio, el proxy lee la variable de entorno AUTH_MODE. Cuando se establece en jwt, el proxy solicita un token de acceso mediante autenticación HTTP con las credenciales del cliente. El token se almacena en caché en la memoria y se actualiza automáticamente cuando se acerca el vencimiento. Cada solicitud saliente al servidor MCP ascendente incluye el token como Autorización: encabezado de portador en lugar de encabezados de firma SigV4.
El resto del proxy (descubrimiento de herramientas, reenvío de herramientas y el servidor FastMCP) funciona de manera idéntica independientemente del modo de autenticación. La única diferencia es cómo _send_gateway_request autentica sus llamadas salientes.
Prueba la solución
El repositorio incluye test_agent.py, un script de Strands Agents que se conecta al proxy MCP que se ejecuta en AgentCore Runtime y utiliza las herramientas descubiertas.
El agente se conecta al proxy, no al servidor ascendente, invocando el punto final de AgentCore Runtime para el proxy implementado. Envía solicitudes MCP JSON-RPC para descubrir herramientas y llamarlas. La siguiente grabación de pantalla muestra una sesión CLI donde el agente descubre herramientas del proxy y las utiliza para responder preguntas de forma interactiva.
En este ejemplo, el servidor ascendente (un AgentCore Gateway) expone herramientas para operar operaciones aritméticas y el agente actúa como una calculadora que utiliza esas herramientas para realizar operaciones matemáticas básicas.
Figura 3: Grabación de pantalla de prueba que muestra la interacción CLI
Oportunidades de personalización
La arquitectura de proxy le permite interceptar y transformar el tráfico MCP entre el cliente y el servidor MCP ascendente. Los siguientes ejemplos demuestran dos patrones de personalización comunes:
Tokenización
Los argumentos de llamada a herramientas pueden contener información de identificación personal (PII) que no debería llegar a los sistemas backend en texto sin cifrar. El flujo de reenvío del proxy le brinda un punto de intercepción natural para agregar tokenización.
Así es como funciona el flujo: cuando un cliente llama a una herramienta, la función _make_tool_handler del proxy en main.py recibe los argumentos como un diccionario kwargs, los pasa a _send_gateway_request que los envuelve en una carga útil JSON-RPC y los envía (firmados por SigV4) al servidor MCP ascendente, luego formatea la respuesta al cliente. La ruta del código relevante se ve así:
Puede agregar tokenización en dos lugares dentro del cierre del controlador. Antes de llamar a _send_gateway_request, escanea los valores de kwargs en busca de patrones de PII y los reemplaza con tokens reversibles (consulte la Guía de tokenización para mejorar la seguridad de los datos y reducir el alcance de la auditoría en AWS). Después de que _send_gateway_request regresa, invierte los tokens en el contenido de la respuesta antes de devolverlo al cliente. Esto mantiene la PII fuera de los objetivos del backend y al mismo tiempo preserva el flujo de datos de un extremo a otro para el agente.
Control de acceso a nivel de herramienta
Es posible que desee restringir qué herramientas puede invocar una determinada persona que llama, aunque el servidor ascendente exponga el catálogo completo. Puede implementar esto agregando una verificación de política al comienzo de la función de controlador creada por _make_tool_handler. El proxy ya recibe el nombre de la herramienta como parámetro cuando se construye el controlador. Antes de reenviar las herramientas/solicitud de llamada al servidor ascendente, el controlador evalúa la identidad de la persona que llama con respecto a una política de acceso. La identidad se puede extraer de los encabezados de la solicitud entrante o del contexto de la sesión MCP. Si la persona que llama no está autorizada para esa herramienta, el controlador devuelve una respuesta de error sin comunicarse con el servidor ascendente. También puede filtrar la respuesta de herramientas/lista en la función Register_gateway_tools para exponer solo las herramientas que coinciden con una política determinada. De esta forma, las herramientas no autorizadas nunca aparecen en el catálogo de herramientas del cliente.
Limpiar
Para evitar cargos recurrentes, elimine los recursos creados si ya no los necesita más allá de probar esta solución. La CLI de AgentCore proporciona un comando de destrucción que elimina el agente y sus recursos asociados. Ejecute los siguientes comandos desde la raíz del proyecto:
Elimine el agente AgentCore Runtime y sus imágenes ECR:
agentcore destroy –agent –delete-ecr-repo –force Elimine la política de IAM en línea y la función de ejecución:
Si creó una puerta de enlace AgentCore específicamente para este tutorial y ya no la necesita, elimine la puerta de enlace y sus destinos:
Reemplace el nombre del agente, el nombre de la función y el nombre de la puerta de enlace con los valores que utilizó durante la implementación.
Conclusión
Esta publicación demostró cómo crear e implementar un proxy MCP sin servidor en Amazon Bedrock AgentCore Runtime que agrega controles personalizados al tráfico MCP. El proxy descubre dinámicamente herramientas de un servidor MCP ascendente al inicio, las vuelve a exponer como un servidor MCP estándar y reenvía invocaciones de herramientas en tiempo de ejecución. Esto le brinda una capa programable donde puede aplicar lógica personalizada, como validación de entrada, registro, limitación de velocidad o enriquecimiento de respuesta.
Recorrimos el flujo de trabajo de un extremo a otro utilizando una puerta de enlace AgentCore como servidor ascendente y cubrimos cómo adaptar el proxy para puertas de enlace configuradas con autorización de entrada IAM o JWT. El proxy no tiene estado y se ejecuta como un contenedor estándar en AgentCore Runtime. Puede conectarlo a otro servidor ascendente compatible con MCP, encadenar múltiples puntos finales ascendentes o agregar lógica de middleware específica para su carga de trabajo. El código fuente completo, los scripts de implementación y el agente de prueba están disponibles en GitHub.
Para comenzar, clone el repositorio, configure el punto final de su servidor MCP ascendente y ejecute el script de implementación automatizada. Para obtener más información sobre la creación e implementación de agentes en AgentCore y el uso del marco de Strands Agents, explore la documentación de Amazon Bedrock AgentCore y el SDK de Strands Agents.
Sobre los autores
Nizar Kheir
Nizar es arquitecto senior de soluciones en AWS con más de 15 años de experiencia en diversos segmentos de la industria. Actualmente trabaja con clientes del sector público en Francia y en toda EMEA para ayudarlos a modernizar su infraestructura de TI y fomentar la innovación aprovechando el poder de la nube de AWS.