Conectar agentes de IA a APIs privadas: MoEngage convirtió 400 en herramientas y se ahorró seis meses de ingeniería

Veinticinco equipos de ingeniería, 400 APIs internas, siete regiones de AWS y una regla innegociable: nada de esto puede tocar internet público. Con ese punto de partida, MoEngage tenía que conectar agentes de IA a APIs privadas sin montar una montaña de infraestructura. Según la compañía, lo resolvió con Amazon Bedrock AgentCore Gateway, se ahorró unos seis meses de ingeniería de plataforma y ahora incorporar una API nueva lleva horas en lugar de días.

MoEngage es la plataforma de engagement con clientes que usan más de 1.350 marcas de consumo para enviar mensajes por push, email, SMS, WhatsApp y RCS. Sus agentes necesitaban crear campañas, consultar segmentos y leer estadísticas de entrega. Esas capacidades ya existían como APIs REST dentro de VPC privadas, aisladas por región para cumplir compromisos de residencia de datos. Como recuerda el propio equipo en el blog de AWS Machine Learning (29 de octubre), construir la funcionalidad no era el problema. Lo difícil era hacerla accesible para los agentes con seguridad. Ninguno de los equipos de producto escribió código de servidor del Model Context Protocol (MCP), no se provisionó red por cada integración y no hay ningún endpoint público en el camino. Los ahorros son estimaciones de la empresa y, como señala el resumen de Readmex, no han sido verificados de forma independiente.

Por qué 20 servidores MCP eran la respuesta equivocada

La vía obvia era que cada equipo levantara su propio servidor MCP. MoEngage hizo las cuentas y la descartó. Más de 20 servidores significan más de 20 despliegues que parchear y mantener compatibles con un protocolo en evolución. Además, los agentes útiles, los que cruzan campaña, segmento y estadísticas, tendrían que conectarse a varios servidores y reconciliarlos.

Su principio fue claro: los equipos de producto no implementan MCP. Construyen APIs REST y declaran qué operaciones son herramientas. El equipo de AI Platform es dueño de toda la capa MCP. Como resume Remio, los equipos de producto mantienen las interfaces y la plataforma controla el acceso de los agentes.

La arquitectura debía cumplir cuatro restricciones a la vez:

Cero endpoints públicos: las APIs son privadas por política, sin NAT ni proxies inversos por integración.

Identidad fuera del alcance del modelo: tenant, usuario y rol los inyecta el servicio que llama, nunca son un parámetro que el LLM pueda alterar.

Catálogo que quepa en contexto: con unos 50 tokens por herramienta, listar las 400 supone más de 20.000 tokens en cada conexión.

Autorización en el servidor: filtrar en el cliente no es una frontera de seguridad.

AgentCore Gateway cubrió esos puntos. Es un servidor MCP totalmente gestionado: se registran las especificaciones OpenAPI y la herramienta se genera sola. Cada operación pasa a ser una herramienta con nombre del tipo `CampaignsAPI___searchCampaigns`, así que si el equipo cambia la especificación, la herramienta cambia con ella. Las políticas Cedar se evalúan antes de serializar el catálogo, de modo que cada agente, autenticado con su propio rol IAM, solo recibe las herramientas que puede usar. Un bot de QA de campañas, por ejemplo, ve las de lectura y nunca recibe las de escritura. La salida hacia los servicios internos va por egreso gestionado sobre Amazon VPC Lattice, y la entrada solo es posible mediante un endpoint de interfaz privado. Según Readmex, los agentes se autentican con SigV4 y descubren herramientas por descripción, no por nombres fijos.

Cómo aplicar esta estrategia de gateway MCP en tu empresa

No hace falta tener 400 APIs para aprovechar la lección. Si tus agentes ya van a depender de servicios internos, estos pasos sirven desde el primer día:

1. Inventaría lo que ya tienes. Si tus APIs cuentan con especificaciones OpenAPI bien descritas, ya tienes el 80% del trabajo. Una descripción pobre produce una herramienta pobre.
2. Decide quién es dueño de la capa de agentes. Centralizar el protocolo en un equipo evita que cada squad necesite experiencia en MCP, como pasó en MoEngage.
3. Saca la identidad del prompt. Si el modelo puede cambiar el tenant o el rol, tienes un riesgo de seguridad, no una funcionalidad.
4. Aplica permisos por agente, del lado del servidor. Un agente que no debe escribir no debería ni ver las herramientas de escritura. Esto además protege tu ventana de contexto.
5. No construyas lo indiferenciado. Un servidor central a medida habría exigido pipeline de generación, formato de políticas, registro de alias y circuit breakers. Nada de eso mejora las campañas de tus clientes.

También hay una cautela. El caso viene del propio proveedor y de su cliente, y atarse a un gateway gestionado implica depender de AWS. Pesa la comodidad frente a la dependencia, y conviene medirlo con tu propio caso.

Si te interesa el mismo patrón en otro contexto, mira cómo Eon aplicó un gateway MCP para acortar el onboarding de sus ingenieros. Para profundizar en el control de riesgos, repasa cómo AWS y Cisco automatizan la seguridad de agentes de IA empresariales. Y si tu preocupación es el aislamiento entre clientes, el caso de Octave y su base multi-tenant sobre Amazon Bedrock aporta otra perspectiva.

La pregunta que debes hacerte hoy

La lección de MoEngage es que la parte más difícil de los agentes no es el modelo, sino el acceso seguro a lo que tu empresa ya sabe hacer. Antes de lanzar otro piloto, pregúntate: ¿cuántas de tus APIs podrían ser herramientas si resolvieras la seguridad una sola vez? Quien consiga conectar agentes de IA a APIs privadas con permisos desde el servidor tendrá una ventaja real de velocidad sobre quien siga montando un servidor por equipo.