6 puntos por GN⁺ 2026-03-23 | Aún no hay comentarios. | Compartir por WhatsApp
  • Experiencia de Pinterest al adoptar MCP como estándar de conexión de herramientas para agentes de IA e integrarlo a nivel de producción en flujos reales de ingeniería como IDE, chat interno y agentes de IA
  • Elección de una arquitectura que combina múltiples servidores MCP por dominio (Presto, Spark, Airflow, etc.) con un registro central, en lugar de un único servidor monolítico
  • Aplicación del principio de mínimo privilegio sobre datos sensibles mediante una capa doble de autenticación con JWT de usuario final + identidad de malla SPIFFE y control de acceso basado en grupos de negocio
  • Logro de resultados cuantitativos de 66,000 llamadas mensuales, 844 usuarios activos mensuales y un ahorro estimado de 7,000 horas al mes
  • La clave para posicionar MCP no como un simple experimento sino como infraestructura de productividad de ingeniería fue un diseño centrado en la seguridad, un pipeline de despliegue unificado y la integración directa en las herramientas que el personal ya usa

Contexto de la adopción de MCP

  • Model Context Protocol (MCP) es un estándar open source que usa un protocolo unificado cliente-servidor para que los LLM se comuniquen con herramientas y fuentes de datos, en vez de implementar integraciones separadas por modelo o por herramienta
  • Pinterest aprovechó MCP no para simples preguntas y respuestas, sino como base para la automatización de tareas de ingeniería: desde “lee los logs y encuentra el problema” hasta “analiza un ticket de bug y propone un PR de corrección”

Diseño inicial de la arquitectura

Hosting en la nube, no local

  • Aunque también se admite el esquema de servidores MCP locales (comunicación por stdio), se adoptó como ruta principal (paved path) el uso de servidores MCP alojados en la nube interna
    • El objetivo era operar en un entorno donde fuera fácil aplicar lógica interna de enrutamiento y seguridad
    • Los servidores locales solo se permiten para fines experimentales

Múltiples servidores pequeños vs. un solo servidor monolítico

  • En lugar de un único servidor gigante, se eligieron múltiples servidores MCP pequeños por dominio
    • Permiten aplicar controles de acceso distintos por servidor
    • Evitan que el contexto del modelo se llene innecesariamente
  • Retroalimentación inicial: se señaló que crear un nuevo servidor MCP requería demasiado trabajo previo, como pipeline de despliegue, configuración del servicio y preparación operativa
    • Como solución se construyó un pipeline de despliegue unificado: los equipos solo definen la lógica de la herramienta y la plataforma se encarga automáticamente del despliegue y el escalado

Registro interno de MCP

  • Una fuente única de verdad (source of truth) que administra la lista de servidores MCP aprobados y cómo conectarse a ellos
  • Web UI: permite a las personas explorar servidores, equipo responsable, canal de soporte, postura de seguridad, estado en vivo y herramientas disponibles
  • API: la usan clientes de IA (chat interno de IA, integración con IDE, agentes) para descubrir y validar servidores, y para determinar si “este usuario puede usar el servidor X”
  • Solo los servidores registrados en el registro son reconocidos como servidores aprobados para producción, cumpliendo el papel de columna vertebral de gobernanza

Estado de los servidores MCP en operación

Servidores principales (por uso)

  • Servidor MCP de Presto: el servidor más usado por volumen de tráfico; los agentes (incluidos los IDE con asistencia de IA) consultan datos basados en Presto bajo demanda y usan esos datos directamente dentro del flujo de trabajo sin cambiar al dashboard
  • Servidor MCP de Spark: base de la experiencia de depuración de Spark con IA; soporta diagnóstico de fallas de jobs de Spark, resumen de logs y registro estructurado de análisis de causa raíz, convirtiendo hilos operativos en conocimiento reutilizable
  • Servidor MCP de Knowledge: endpoint de conocimiento general; los bots internos de IA lo usan para conocimiento de la empresa, preguntas y respuestas, documentación y preguntas de depuración

Integración con servicios internos de Pinterest

  • Integración de herramientas MCP en la interfaz web interna de chat con LLM que muchas personas en Pinterest usan a diario
    • El frontend maneja automáticamente el flujo de OAuth y luego devuelve la lista de herramientas permitidas para el usuario actual
    • El agente de chat con IA enlaza directamente las herramientas MCP al toolkit del agente, ofreciendo la misma experiencia que una llamada de herramienta normal
  • Incorporación de herramientas MCP también en el bot de IA de la plataforma interna de chat
    • Manejo de autenticación y autorización a través de la API del registro
    • Soporte para restringir ciertas herramientas MCP a canales específicos (por ejemplo, las herramientas MCP de Spark solo pueden usarse en el canal de soporte de Airflow)

Seguridad, gobernanza y políticas

Estándar de seguridad de MCP

  • Se definió por separado un MCP Security Standard: todo servidor MCP que no sea experimental debe tener un equipo propietario asignado, estar registrado en el registro interno y contar obligatoriamente con aprobación de tickets de revisión de seguridad/legal, privacidad y, cuando aplique, GenAI
  • Según el resultado de la revisión, se determinan políticas de seguridad como los grupos de usuarios que pueden acceder al servidor

Doble capa de autenticación (AuthN) y autorización (AuthZ)

  • Flujo basado en JWT de usuario final

    1. El usuario interactúa desde una superficie como chat de IA, plugin de IDE o bot de IA
    2. El cliente ejecuta un flujo de OAuth contra la pila interna de autenticación y luego entrega el JWT al registro MCP y al servidor objetivo
    3. Envoy valida el JWT, mapea los headers X-Forwarded-User y X-Forwarded-Groups, y aplica políticas de seguridad de nivel grueso
    4. Dentro del servidor, el decorador @authorize_tool(policy='…') aplica control de permisos fino (por ejemplo, get_revenue_metrics solo puede ser invocado por el grupo Ads-eng)
  • Control de acceso basado en grupos de negocio

    • En vez de permitir acceso indiscriminado a todas las personas autenticadas de Pinterest y contratistas, los servidores sensibles extraen del JWT la membresía a grupos de negocio y verifican si pertenecen a grupos aprobados
    • El servidor MCP de Presto puede ser técnicamente accesible desde superficies amplias, pero solo grupos aprobados como Ads, Finance y ciertos equipos de infraestructura pueden establecer sesión y ejecutar herramientas de alto privilegio
  • Flujo basado en SPIFFE exclusivo para servicios

    • En escenarios de bajo riesgo y solo lectura, se usa únicamente autenticación basada en SPIFFE (identidad de malla)
    • Solo se emplea cuando no hay un usuario final en el loop y el radio de impacto está estrictamente limitado

Diferencias con el estándar OAuth de MCP

  • La especificación oficial de MCP define un flujo de autenticación OAuth 2.0 por servidor (pantalla de consentimiento y gestión de tokens por servidor), pero Pinterest adoptó un enfoque que reutiliza la sesión existente
    • Cuando el usuario abre una superficie como el chat de IA, ya está autenticado en la pila interna de autenticación, por lo que no hacen falta prompts adicionales de login ni diálogos de consentimiento
    • Envoy y los decoradores de políticas manejan la autorización de forma transparente en segundo plano

Human-in-the-Loop

  • Como los servidores MCP habilitan acciones automatizadas, su radio de impacto es mayor que el de la operación manual
  • Siguiendo la guía para agentes, antes de acciones sensibles o costosas se exige aprobación humana: el agente propone la acción y la persona la aprueba o rechaza (también puede hacerlo en lote)
  • Se aprovecha elicitation para solicitar confirmación antes de acciones riesgosas (por ejemplo, sobrescribir datos de una tabla)

Observabilidad y métricas de resultados

  • A todos los servidores MCP se les aplican funciones de librería que proporcionan por defecto logging de entrada/salida, conteo de llamadas, rastreo de excepciones y telemetría
  • Métricas medidas a nivel de ecosistema: número de servidores y herramientas MCP registrados, total de llamadas a servidores y tiempo estimado ahorrado por llamada (calculado por los propietarios de cada servidor con base en retroalimentación ligera de usuarios y comparación con flujos manuales anteriores)
  • Métrica norte única: tiempo ahorrado (time saved), calculado de forma aproximada como número de llamadas × minutos ahorrados por llamada
  • 66,000 llamadas mensuales, 844 usuarios activos mensuales y un ahorro estimado de 7,000 horas al mes

Aún no hay comentarios.

Aún no hay comentarios.