)
Última actualización: 10 de noviembre, 2026
Un equipo de plataforma despliega un agente de soporte en el clúster un viernes. El lunes, ese agente ha llamado a un servidor MCP de facturación con un token emitido para otro servicio, y nadie sabe qué pod hizo la llamada. ¿Dónde debe ir un MCP gateway en Kubernetes para que esto no pase? Para muchos equipos, la respuesta es un sidecar: un contenedor del gateway dentro del mismo pod que el agente, por el que pasa cada llamada MCP. Aplica identidad, políticas de herramientas y registro en el punto más cercano posible.
TL;DR
- Los sidecars nativos ya son estables: Kubernetes los declaró estables en la v1.33, así que el gateway arranca antes que el agente y se detiene después (Kubernetes, 2025).
- MCP es más fácil de intermediar: la revisión 2026-07-28 eliminó las sesiones de protocolo y copia el método y la herramienta en cabeceras HTTP (especificación MCP, 2026).
- El token passthrough está prohibido: la guía de seguridad de MCP lo define como un antipatrón que puede crear un confused deputy (especificación MCP, 2026).
- El control de acceso sigue fallando: el 92 % de las organizaciones con una brecha ligada a la IA no tenía controles de acceso de IA adecuados (IBM, 2026).
- La escala llega rápido: Gartner prevé más de 150.000 agentes por empresa media del Fortune 500 global en 2028 (Gartner, 2026).
De un vistazo: sidecar frente a MCP gateway central
Respuesta rápida
¿Cuándo conviene ejecutar un MCP gateway como sidecar?
Cuando cada agente necesita su propia identidad, política y rastro de auditoría, y quieres aplicar controles antes de que el tráfico salga del pod. Elige un gateway central si necesitas límites compartidos, una sola vía de actualización y menos piezas. Muchos clústeres acaban con ambos: sidecars para el control local y una capa central para la política global.
| Factor | Sidecar por pod | Gateway central del clúster | Por nodo (DaemonSet) |
|---|---|---|---|
| Punto de control | Dentro del pod del agente | Servicio compartido en el clúster | Un proxy por nodo |
| Granularidad de identidad | Por carga de trabajo del agente | Por cliente, si se propaga | Por nodo, salvo etiquetado |
| Impacto de una mala configuración | Una carga de trabajo | Todos los agentes que lo usan | Todos los pods del nodo |
| Consumo de recursos | Un contenedor extra por pod | Un despliegue escalado | Un pod por nodo |
| Límites entre agentes | Difícil sin almacén compartido | Encaje natural | Parcial |
| Esfuerzo de actualización | Reinicio progresivo de cada agente | Un único despliegue | Un despliegue por grupo de nodos |
Cómo comparamos
Leímos la documentación de sidecars de Kubernetes, las notas de la v1.33 y la revisión actual de MCP, fechada el 2026-07-28, con sus páginas de transporte, autorización y seguridad. Después cruzamos cada ubicación con los riesgos del OWASP Top 10 for Agentic Applications. No hicimos benchmarks de productos ni citamos datos de rendimiento de fabricantes.
Qué significa el patrón sidecar para el tráfico de agentes
Un sidecar es un contenedor auxiliar que comparte red y ciclo de vida con el contenedor principal del pod. Para un agente, eso significa que el gateway escucha en localhost, ve cada petición MCP antes de que salga del pod y un cliente mal configurado no puede saltárselo. El agente habla con una dirección local y el sidecar decide.
Según Kubernetes (2025), los sidecars nativos son un tipo especial de init containers con restartPolicy: Always. Arrancan antes que los contenedores de la aplicación, siguen activos durante toda la vida del pod y terminan cuando salen los principales. También admiten sondas de arranque, disponibilidad y estado.
Con los sidecars clásicos, el agente podía arrancar primero y lanzar llamadas antes de que el proxy estuviera listo. Con los nativos, el gateway ya funciona cuando llega la primera petición.
Quien haya gestionado una service mesh reconocerá el patrón. Un proxy de red genérico ve HTTP. Un sidecar que entiende MCP ve qué herramienta se llama, con qué argumentos y en nombre de qué agente.
)
Por qué la especificación MCP 2026-07-28 facilita los sidecars
La revisión actual de MCP es más amable con los proxies que las anteriores. Eliminó las sesiones de protocolo, así que cada petición es independiente. Además copia el método y el nombre de la herramienta en cabeceras HTTP, de modo que un sidecar puede aplicar políticas sin analizar cada cuerpo. Las decisiones por petición salen más baratas y predecibles.
La especificación MCP (2026) indica que el servidor Streamable HTTP expone un único endpoint que acepta POST, y cada mensaje JSON-RPC viaja en su propia petición. La misma revisión eliminó el endpoint de streaming por GET. Para un sidecar, eso supone no tener que seguir estado de sesión entre reinicios.
| Cabecera | Qué lleva | Uso de política en el sidecar |
|---|---|---|
| MCP-Protocol-Version | Revisión del protocolo de la petición | Rechazar versiones que no validan cabeceras |
| Mcp-Method | Método JSON-RPC, como tools/call | Permitir o denegar por método |
| Mcp-Name | Nombre de herramienta, recurso o prompt | Listas de herramientas permitidas por agente |
| Mcp-Param-* | Valores de parámetros que el servidor marca con x-mcp-header | Comprobar argumentos sin analizar todo el cuerpo |
Hay una trampa. Las cabeceras solo sirven si coinciden con el cuerpo. La especificación obliga a los servidores a rechazar discrepancias con el error HeaderMismatch, código -32020. También dice que los intermediarios que aplican políticas sobre cabeceras deberían rechazar peticiones de versiones antiguas sin esa validación.
Tu sidecar debe comprobar que cabeceras y cuerpo coinciden, y rechazar peticiones heredadas cuando la política dependa de las cabeceras. Si no, un atacante puede etiquetar una llamada destructiva con un nombre de herramienta inofensivo.
Arquitectura de referencia: cómo funciona un MCP gateway como sidecar
El agente envía cada petición MCP al sidecar en 127.0.0.1. El sidecar valida la petición y comprueba la identidad y la política del agente. Después cambia su credencial por un token limitado al servidor de destino y registra la decisión. Una network policy impide que el agente llegue directamente a los servidores MCP.
| Componente | Función | Por qué importa |
|---|---|---|
| Contenedor del agente | Planifica y llama a herramientas a través de un endpoint local | Sin rutas directas a los servidores |
| Sidecar del gateway | Valida, autoriza, reescribe credenciales y registra | Control antes de que el tráfico salga del pod |
| Identidad de carga de trabajo | Demuestra qué agente ejecuta el pod | Políticas y logs ligados a una identidad real |
| Network policy de salida | Solo permite tráfico MCP desde el sidecar | Evita que un cliente mal configurado se lo salte |
| Servidores MCP | Exponen herramientas y recursos | Solo reciben tokens emitidos para ellos |
| Plano de control central | Distribuye políticas y recoge logs | Mantiene coherentes cientos de sidecars |
Las credenciales son donde fallan casi todos los diseños. La especificación MCP (2026) indica que el token passthrough está prohibido de forma explícita. Un servidor que acepta tokens pensados para otros recursos, y los reenvía, crea un confused deputy. El sidecar debe obtener un token cuya audiencia sea el servidor MCP de destino, con resource indicators, como exige la especificación de autorización.
Vincula el sidecar solo a localhost. Las reglas de transporte obligan a validar la cabecera Origin y, en local, recomiendan escuchar en 127.0.0.1 en lugar de en todas las interfaces. Un sidecar que escucha en 0.0.0.0 es una puerta abierta para cualquier pod que pueda alcanzarlo.
Por último, saca la política de la imagen: descárgala firmada desde un plano de control central.
Políticas que aplicar en el sidecar
Empieza por seis controles: audiencia del token, herramientas permitidas por agente, validación de argumentos, límites de uso, inspección de salidas y logs de auditoría estructurados. Cada uno responde a un riesgo documentado en la guía de seguridad de MCP o en la lista agéntica de OWASP. Juntos convierten "el agente puede llamar a todo" en "solo a estas herramientas, así".
| Control | Cómo lo aplica el sidecar | Riesgo que reduce |
|---|---|---|
| Audiencia del token | Pide tokens ligados al servidor de destino y nunca reenvía el del agente | Confused deputy, reutilización de tokens |
| Lista de herramientas | Compara Mcp-Name con las herramientas aprobadas del agente | Mal uso de herramientas, exceso de autonomía |
| Validación de argumentos | Revisa los valores de Mcp-Param y del cuerpo según reglas | Llamadas destructivas o fuera de alcance |
| Límites de uso y coste | Limita llamadas por herramienta y por minuto | Bucles descontrolados, abuso de APIs de pago |
| Inspección de salidas | Analiza respuestas en busca de instrucciones inyectadas o secretos | Prompt injection indirecta, fuga de datos |
| Logs de auditoría | Registra agente, herramienta, hash de argumentos, decisión y latencia | Forense y evidencias de cumplimiento |
Según OWASP (2025), el mal uso de herramientas y el abuso de identidad y privilegios están entre los principales riesgos de las aplicaciones agénticas. Ambos nacen de permisos más amplios de lo que pide la tarea. Una lista de herramientas por agente en el sidecar es la solución más directa.
El registro merece su propio diseño. Nuestra guía de auditoría de MCP explica qué campos necesita un CISO. Como mínimo, registra la identidad del agente, la herramienta, la decisión y un hash de los argumentos, no valores en bruto con posibles datos personales.
La inspección de salidas es el control que más se olvida. La respuesta de una herramienta puede llevar instrucciones dirigidas al modelo. Analizarla antes de que llegue al agente cierra una vía que los controles de entrada no ven.
Pros, contras y cuándo gana un gateway central
Los sidecars dan precisión a cambio de un coste. Cada pod lleva un contenedor extra, cada cambio de política debe llegar a todos los sidecars y los límites entre agentes necesitan un almacén compartido. Un gateway central es más fácil de operar y actualizar. La elección depende de cuántos agentes tienes y de cuánto difieren sus permisos.
El primer coste son los recursos: un sidecar por pod suma memoria y CPU a cada réplica. Con miles de agentes, se nota en la factura.
La deriva de políticas es el segundo. Si los sidecars cachean la política y uno no se actualiza, dos pods del mismo agente pueden comportarse distinto. Un plano de control con políticas versionadas y comprobaciones de estado lo evita.
Los límites globales son el tercero. Un presupuesto por herramienta para todos los agentes encaja de forma natural en un gateway central y cuesta en los sidecars. Muchos equipos lo resuelven con un modelo híbrido: sidecars para identidad, listas y registro, y un gateway central para cuotas compartidas y enrutado.
Según Gartner (2026), en 2028 una empresa media del Fortune 500 global tendrá más de 150.000 agentes en uso. Nuestra comparativa de MCP gateways y la guía AI gateway frente a MCP gateway explican las diferencias entre opciones centrales.
Seguridad y gobernanza: lo que el sidecar no resuelve
Un sidecar controla el camino, no la intención. No sabe si una llamada permitida sirve al usuario o a un atacante. IBM (2026) indica que el 92 % de las organizaciones con una brecha ligada a la IA no tenía controles de acceso adecuados. Solo el 40 % los usaba en modelos y datos.
Quedan tres riesgos incluso con un sidecar perfecto:
- Prompt injection: una llamada permitida puede dispararse por contenido hostil que el agente leyó antes. Inspecciona entradas y salidas, no solo cabeceras.
- Fuga de datos: una herramienta permitida puede recibir campos sensibles. Combina las listas con clasificación de datos y redacción.
- Mal uso de herramientas: una herramienta aprobada puede usarse de forma destructiva. Exige aprobación humana para acciones irreversibles, como borrados o pagos.
Los servidores MCP alojados en Kubernetes traen su propia exposición. Nuestro análisis del CVE del servidor MCP de Kubernetes mostró cómo un servidor con permisos de clúster amplía el impacto de una sola llamada maliciosa.
NeuralTrust lo aborda como una sola capa clara para todos tus agentes. Controlas el acceso de los agentes a modelos, servidores MCP y APIs a través del Agent Gateway (TrustGate), con acceso al catálogo completo de MCP. Proteges prompts, respuestas y llamadas a herramientas con Agent Runtime Security (TrustGuard). Ambos se despliegan en tu propia infraestructura u on-premises.
¿Cuál deberías elegir?
Ajusta la ubicación a tu escala y a cuánto difieren los permisos de tus agentes. Unos pocos agentes con accesos parecidos pueden compartir un gateway central. Muchos agentes con permisos distintos, o con exigencias de auditoría estrictas, ganan con sidecars. Los entornos grandes suelen necesitar ambas capas con una única fuente de políticas.
| Si... | Elige | Por qué |
|---|---|---|
| Tienes menos de diez agentes con accesos similares | Gateway central | Lo más sencillo de operar y actualizar |
| Necesitas identidad y auditoría por agente | Sidecar | Control y logs ligados a cada carga de trabajo |
| Operas en un sector regulado | Sidecar con plano de control central | Control local con políticas coherentes y versionadas |
| Necesitas cuotas compartidas entre agentes | Gateway central o híbrido | Los límites globales necesitan un solo contador |
| Tienes miles de agentes en varios clústeres | Híbrido | Precisión en el pod y escala en el centro |
| Aún estás pilotando MCP | Primero un gateway central | Aprende el modelo de políticas antes de multiplicarlo |
Conclusión
Un MCP gateway como sidecar pone el control justo donde empieza el tráfico del agente. Los sidecars nativos de Kubernetes y el transporte sin sesiones de MCP 2026-07-28 hacen que el patrón sea práctico hoy. Valida cabeceras frente al cuerpo, no reenvíes tokens, escucha solo en localhost y registra cada decisión. Después decide dónde sigue ganando el control central: normalmente, sidecars para identidad y listas, y una capa central para cuotas y políticas compartidas.
Asegura tus agentes en Kubernetes en producción con NeuralTrust
Pasa el tráfico MCP de cada agente por una sola capa clara, con seguridad en tiempo real en cada llamada.
)
Comparativas relacionadas
- Los 6 mejores MCP gateways para empresas (2026)
- AI gateway frente a MCP gateway: diferencias clave
- Auditoría de MCP: qué deben registrar los CISO
- Autenticación MCP: guía de seguridad OAuth
Preguntas frecuentes sobre MCP gateway
1. ¿Qué es un MCP gateway?
Un MCP gateway es un punto de control entre los agentes de IA y los servidores del Model Context Protocol. Autentica a los agentes, decide qué herramientas puede llamar cada uno, reescribe credenciales para que cada servidor reciba tokens emitidos para él y registra cada decisión. Puede funcionar como servicio central, proxy por nodo o sidecar en el pod de cada agente.
2. ¿Qué hace un MCP gateway?
Aplica políticas al tráfico de herramientas. Sus tareas habituales: comprobar identidades, mantener listas de herramientas por agente, validar argumentos, limitar el uso, inspeccionar respuestas en busca de instrucciones inyectadas y registrar todo. Con la revisión MCP 2026-07-28 puede leer el método y la herramienta en las cabeceras HTTP. Los servidores deben rechazar discrepancias con el cuerpo y, si tu gateway filtra por cabeceras, debería comprobarlas.
3. ¿Qué es un sidecar en Kubernetes?
Un sidecar es un contenedor auxiliar que se ejecuta junto al principal dentro del mismo pod y comparte su red. Desde Kubernetes v1.33, los sidecars nativos son estables. Son init containers con restartPolicy en Always, así que arrancan antes que la aplicación, siguen activos durante toda la vida del pod y se detienen después.
4. ¿En qué se diferencia un MCP gateway de un servidor MCP?
Un servidor MCP expone herramientas, recursos y prompts a los agentes. Un MCP gateway se sitúa delante de uno o varios servidores y controla quién los usa y cómo. El servidor hace el trabajo y el gateway decide si la petición debe llegar a él. Separarlos te permite cambiar políticas sin tocar las herramientas.
5. ¿Cómo se despliega un servidor MCP en Kubernetes?
Empaqueta el servidor en un contenedor, ejecútalo como deployment con su propia service account y exponlo solo dentro del clúster. Dale el rol más limitado posible, porque los permisos de todo el clúster amplían el impacto. Después coloca un gateway delante, como sidecar o servicio central, y bloquea el acceso directo de los agentes.
6. ¿Qué diferencia hay entre un MCP gateway y un AI gateway?
Un AI gateway gobierna el tráfico entre aplicaciones y proveedores de modelos: enrutado, cuotas e inspección de prompts. Un MCP gateway gobierna el tráfico entre agentes y herramientas expuestas por MCP. Muchas empresas necesitan ambos, porque los agentes llaman a modelos para decidir y a herramientas para actuar. Algunas plataformas combinan los dos en una sola capa.
7. ¿Un sidecar añade latencia a las llamadas MCP?
Sí, un poco, porque cada petición da un salto local extra y pasa una comprobación de políticas. Sobre localhost, ese salto suele ser pequeño frente a la propia llamada a la herramienta. Mídelo en tu clúster, evalúa las políticas en memoria y evita consultar servicios remotos de políticas en cada petición.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde dirige la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda impulsada por IA, estrategia de contenidos y SEM. Conecta con él en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Nombrada pionera en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026 y destacada en la Gartner Market Guide for Guardian Agents 2026, la Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
- Kubernetes, "Kubernetes v1.33: Octarine", 23 de abril de 2025. https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/
- Documentación de Kubernetes, "Sidecar Containers", 2026. https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/
- Model Context Protocol, "Streamable HTTP", revisión de la especificación 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
- Model Context Protocol, "Security Best Practices", revisión de la especificación 2026-07-28. https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices
- Model Context Protocol, "Authorization", revisión de la especificación 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications", 9 de diciembre de 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
- IBM y Ponemon Institute, "Cost of a Data Breach Report 2026", 29 de julio de 2026. https://assets.ibm.com/adobe/assets/urn:aaid:aem:21111142-1251-4369-86fb-57b82f5bb108/original/as/Cost%20of%20a%20Data%20Breach%20Report%202026.pdf
- Gartner, "Gartner Identifies Six Steps to Manage AI Agent Sprawl", 28 de abril de 2026. https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl