AI gateway para agentes: modelos, tools MCP y gobierno operativo
Un AI gateway para agentes es la frontera operativa que gobierna el tráfico hacia modelos LLM y herramientas MCP. Esta guía explica qué debe controlar, qué no sustituye y cómo migrar sin abrir un bypass de autorización.
Un AI gateway para agentes es un proxy gobernado que media las llamadas de aplicaciones y agentes hacia modelos LLM y herramientas, centralizando catálogo, credenciales upstream, políticas de uso, límites, observabilidad y auditoría sin sustituir la autorización de negocio del sistema destino.
La distinción evita tres confusiones. LiteLLM Proxy encaja especialmente como gateway de modelos, coste, claves y routing; MCP en producción describe cómo asegurar y operar servidores; Streamable HTTP es un transporte. El gateway puede integrar las tres capas, pero no las reemplaza ni debe reclamar autoridad sobre el dominio.
Tampoco es un filtro mágico de prompts. Puede rechazar una tool no catalogada, una región no permitida o un presupuesto agotado. No puede saber por sí solo si la persona tiene derecho a ver la factura 1842, ni debe confiar en una afirmación del modelo sobre esa autorización.
Checklist
Catálogo, allowlist, tenant y policy
El catálogo es el inventario controlado de capacidades: modelo lógico, proveedor, versión, región, modalidad de datos, límites, coste orientativo, owner y estado. Para una tool añade servidor, nombre, versión de esquema, operaciones mutantes, scopes requeridos, timeout y nivel de riesgo. Versionarlo permite saber qué podía hacer un agente en una fecha concreta.
La allowlist debe ser positiva y por contexto. Un tenant de desarrollo puede ver un modelo barato y una tool sandbox; producción puede exigir un modelo aprobado, una tool read-only y aprobación humana para mutaciones. No uses un booleano global `mcp_enabled`: expresa sujeto, tenant, entorno, tool, acción, datos y razón.
La decisión combina autenticación ya validada, atributos confiables y contexto: `principal_id`, `tenant_id`, workload, repo, environment, tool_name, acción, sensibilidad, región, presupuesto y riesgo. El modelo puede proponer una tool, pero no puede elevar ninguno de esos atributos.
Mantén separación entre policy de plataforma y autorización de dominio. El gateway responde `allow`, `deny` o `require_approval` para el tráfico; el backend comprueba ownership, relación con cliente, estado de workflow y permisos finos. Si el backend devuelve 403, el gateway propaga la denegación, no reintenta con una identidad más potente.
Una policy decision debe ser determinista y explicable. Guarda identificador y versión de regla, motivo codificado y hash de argumentos redactados. Evita registrar prompts completos o tokens; la evidencia debe reconstruir por qué una ruta pasó sin convertir el log en un almacén de secretos.
Identidad, credenciales y secreto no expuesto
Usa una identidad de workload por aplicación o agente, con audience específica del gateway y expiración corta. Valida issuer, firma, audience, expiración y tenant; no aceptes un JWT emitido para otro API. Para usuarios humanos, propaga contexto verificable, pero no confundas identidad con autorización final.
¿Te está sirviendo? Hay una dosis cada semana
Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratisPuntos a revisar
Lo que conviene comprobar
Las claves de OpenAI, Anthropic, Azure, Google o servidores MCP deben residir en un secret manager, workload identity o broker. El gateway obtiene una credencial de mínimo privilegio para cada upstream y rota sin que el agente la vea. Nunca incrustes la clave en una tool description, variable enviada al modelo, URL, excepción o traza.
Conserva el vínculo entre caller y gateway: `actor`, `workload`, `tenant` y `trace_id`. Si una tool actúa en nombre de un usuario, el backend debe recibir una delegación válida para ese recurso, no el token interno del gateway reutilizado como permiso universal.
Bloquea headers y campos que intenten sobrescribir identidad, proveedor, región o tenant. Normaliza URLs, impide SSRF y evita que un argumento de tool seleccione un host arbitrario. Los errores externos se mapean a mensajes seguros.
Rate limits, tokens y coste
Mide dos presupuestos. El de capacidad limita solicitudes, concurrencia, tiempo y tamaño; el financiero limita tokens, llamadas de tools y gasto estimado. Un agente puede consumir pocos requests pero lanzar un prompt enorme o una cadena de tools cara, así que cuenta por tenant, workload, usuario y workflow cuando el riesgo lo requiera.
Define tokens de entrada y salida, tamaño de contexto, número de tools por turno, profundidad de reintentos, timeout, concurrencia y gasto diario. Usa reservas para evitar carreras y devuelve `retry-after` solo cuando reintentar tenga sentido. Un fallback no debe saltarse policy ni multiplicar silenciosamente el coste.
Registra usage real del proveedor, moneda, modelo efectivo, tags de producto y resultado. Para tools, mide duración, bytes, llamadas downstream y mutaciones. Así el owner compara calidad, latencia y coste en vez de optimizar una cifra aislada.
El control económico no autoriza datos. Un modelo barato en otra región puede violar residencia; una ruta rápida puede no soportar una clasificación. Ordena la decisión: seguridad y datos, autorización, disponibilidad, coste y optimización.
Estrategia de migración: shadow, corte y bloqueo
Inventaria clientes, claves, endpoints, modelos, tools, tenants y datos. Asigna owner y clasifica cada llamada. Sin ese mapa, el primer bloqueo mezclará tráfico legítimo con bypasses olvidados.
Despliega shadow para evaluar policy sin duplicar acciones mutantes. Compara decisión esperada, coste, p95, errores y diferencias de payload; mide también llamadas directas que no aparecen en gateway.
Migra un workload de bajo riesgo. Cambia su endpoint, entrega identidad de workload, retira la clave del proveedor y prueba fallos, timeouts, streaming, schemas y redacción. El rollback no debe reabrir acceso directo global.
Bloquea bypass con egress y secretos, y activa deny-by-default para capacidades nuevas. Toda excepción tiene motivo, propietario, expiración y alerta; una excepción permanente es una segunda arquitectura sin gobierno.
Revisa tras cada corte trazas, autorización del backend, costes, latencia y pruebas negativas. Amplía solo cuando la evidencia muestre que el gateway no se convierte en autoridad de negocio implícita.
Preguntas frecuentes
¿Un AI gateway reemplaza a LiteLLM Proxy?
No necesariamente. LiteLLM Proxy resuelve gateway de modelos, claves, routing y coste; este patrón puede complementarlo con catálogo y policy transversal para modelos y tools.
¿Un AI gateway reemplaza la seguridad de MCP?
No. El servidor MCP debe validar entradas, identidad y autorización de sus recursos, además de su supply chain. El gateway añade frontera de plataforma y egress.
¿El gateway puede autorizar una tool?
Decide si una capacidad está permitida para tenant y contexto, pero el backend debe autorizar recurso y operación final.
¿Debo bloquear acceso directo desde el primer día?
En producción el objetivo sí debe ser bloquearlo; shadow y cortes graduales descubren dependencias sin conservar un bypass permanente.
¿Qué debo trazar?
Identidad, tenant, capacidad, versión de policy, modelo o tool efectivo, upstream, latencia, usage, decisión y resultado del backend, con redacción proporcional.
Cómo desplegar un AI gateway para agentes sin abrir un bypass
- Inventariar tráfico. Localiza modelos, tools MCP, claves, tenants, endpoints directos y operaciones mutantes.
- Diseñar el catálogo. Versiona capacidades, owners, regiones, clasificación de datos, scopes, límites y estado.
- Conectar identidad. Emite tokens con audience del gateway y recupera credenciales upstream desde broker o secret manager.
- Aplicar policy. Evalúa allowlist, tenant, entorno, datos, cuota y riesgo; devuelve deny o aprobación cuando corresponda.
- Preservar autorización. Haz que backend compruebe ownership, scopes y estado antes de ejecutar cada operación.
- Observar y probar. Añade trazas, auditoría redactada, tests negativos, límites y pruebas de prompt injection, SSRF y cross-tenant.
- Bloquear bypass. Fuerza egress por gateway, retira claves directas y caduca excepciones con owner y fecha.
Conclusión
La decisión no es poner un proxy delante del LLM, sino elegir una frontera de control explicable. Un AI gateway aporta valor cuando hace visible el catálogo, limita modelos y tools por tenant, protege credenciales, mide coste y conecta cada decisión con una traza. Pierde valor cuando se vende como sustituto de autorización, servidor MCP seguro o sandbox.
Empieza con una ruta observable, una allowlist pequeña y egress cerrado. Amplía capacidades con contratos versionados y revisión de owners. El modelo puede razonar; el gateway puede gobernar tráfico; el backend debe seguir decidiendo si la acción está permitida.
Fuentes y referencias
También te puede interesar
LiteLLM Proxy: gateway IA, costes y modelosMCP en producción: seguridad, permisos y supply chainOAuth 2.1 para MCP: guía de autorizaciónOpenTelemetry GenAI para agentes de IASandbox para agentes de IA: ejecución aisladaRecibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratis
