Gobernanza MCP Empresarial: Cómo Controlar, Auditar y Proteger el Acceso a Servidores MCP a Escala

Pregunte a su equipo de seguridad cuántos servidores MCP se están ejecutando en su organización en este momento. Si pueden responder con confianza, usted está por delante de la mayoría de las empresas. Si no pueden, tiene un problema de gobernanza que ya está en producción.

La adopción de MCP avanzó rápidamente. Los equipos conectaron agentes a GitHub, Slack, bases de datos internas y API de terceros a través de servidores MCP, a menudo sin revisión de TI, sin una política de credenciales y sin ninguna forma de que el equipo de seguridad viera a qué podían acceder esos servidores. El protocolo es útil precisamente porque facilita las conexiones de herramientas. Esa facilidad es también lo que convierte las implementaciones de MCP sin gobernanza en una verdadera exposición de seguridad.

Los servidores MCP no son API pasivas. Dan a los agentes de IA acceso directo y programático a sistemas sensibles. Esos agentes actúan basándose en un razonamiento autónomo, no en rutas de código revisadas. Como dijo un líder de seguridad empresarial en Medtronic: "MCP abre muchas oportunidades para causar mucho daño muy rápidamente". Gartner proyecta que el 70% de los equipos de ingeniería de software que desarrollan aplicaciones multimodales utilizarán pasarelas de IA para 2028, frente al 25% en 2025. Los equipos que están construyendo la gobernanza ahora son los que podrán escalar de forma segura.

Esta guía cubre lo que requiere la gobernanza empresarial de MCP, por qué las herramientas de seguridad estándar se quedan cortas, cómo construir el marco de cuatro pilares en el que los equipos de cumplimiento pueden confiar y cómo TrueFoundry implementa todo esto dentro de su propia nube.

Lo que requiere la gobernanza empresarial de MCP

La gobernanza empresarial de MCP es el marco operativo completo para gestionar qué servidores MCP existen en su organización, quién puede acceder a ellos, qué se les permite hacer y qué se registra cuando se utilizan. No es un documento de política. Es infraestructura aplicada.

La mayoría de los equipos subestiman el alcance. La gobernanza cubre cada servidor MCP en el entorno: herramientas de terceros que los desarrolladores conectaron sin revisión de TI, herramientas internas que los equipos de producto construyeron e implementaron, y servidores MCP incrustados dentro de configuraciones de IDE en Cursor, Claude Code y herramientas similares. Si un servidor MCP puede alcanzar un sistema de producción, está dentro del alcance.

La gobernanza de MCP también es diferente de la gobernanza de API estándar de una manera que importa para cómo se construye. Una llamada a una API REST ejecuta una ruta de código determinista que un desarrollador escribió y revisó. Una invocación de herramienta MCP es una decisión autónoma tomada por un agente de IA en tiempo de ejecución basándose en su razonamiento. El modelo de amenazas, los requisitos de auditoría y los controles necesarios para mantener la rendición de cuentas son todos diferentes. Tratar MCP como una integración de API convencional es cómo las organizaciones terminan con brechas de auditoría que no pueden explicar a un regulador.

• Alcance: Todos los servidores MCP. Esto incluye servidores internos construidos por equipos de producto, servidores ejecutándose en pipelines de CI/CD y cualquier cosa que un desarrollador haya configurado localmente en su IDE.

• Mecanismo: Una pasarela centralizada entre todos los clientes y todos los servidores MCP. La pasarela aplica las políticas. Los servidores MCP individuales no implementan sus propios controles de acceso, lo que hace que este enfoque sea escalable a través de cientos de servidores.

• Resultado: Cada invocación de herramienta es autorizada contra una identidad verificada y registrada en un formato estructurado y consultable que resiste la revisión de cumplimiento y la investigación de incidentes.

Riesgos de seguridad de MCP que las empresas no pueden ignorar

Los servidores MCP operan dentro del bucle de razonamiento de un agente de IA. Una llamada a una API tradicional se activa de forma determinista mediante código de aplicación. Una invocación de herramienta MCP, por el contrario, se activa cuando un agente determina en tiempo de ejecución que una herramienta es apropiada para una tarea determinada. Esa decisión está influenciada por el razonamiento del modelo en lugar de un flujo de control explícitamente definido, lo que reduce la visibilidad que los desarrolladores suelen tener sobre cómo y por qué se invoca una herramienta. En este modelo, el razonamiento se convierte efectivamente en parte de la ruta de control, pero no es directamente observable a través de las herramientas de seguridad de aplicaciones estándar.

Investigadores de seguridad han documentado esto en producción. Los ataques de inyección de prompts entregados a través de descripciones de herramientas MCP redirigen el comportamiento del agente sin tocar una línea de código. La exposición de credenciales a través de servidores MCP mal configurados crea rutas de acceso que los controles perimetrales nunca fueron diseñados para monitorear. Estos no son escenarios de ataque teóricos de artículos de investigación. Son incidentes documentados de implementaciones empresariales reales.

Las implementaciones de servidores MCP en la sombra pueden eludir el control de acceso estándar

Cuando los desarrolladores implementan o se conectan a servidores MCP sin la revisión de TI, omiten todos los controles que normalmente se aplican a una nueva integración de sistema: evaluación de seguridad del proveedor, clasificación de acceso a datos y flujos de trabajo de aprovisionamiento de acceso. El servidor entra en producción sin ninguna de la documentación, monitoreo o restricciones que cualquier otro sistema empresarial conlleva.

Sin un registro central, las preguntas básicas de seguridad no tienen respuestas fiables. ¿Qué servidores MCP están en funcionamiento? ¿Qué credenciales poseen? ¿Qué bases de datos pueden consultar? ¿Qué servicios externos pueden invocar? Esa invisibilidad mantiene a estos servidores completamente fuera del alcance de las evaluaciones de vulnerabilidad, las revisiones de riesgo de proveedores y las pruebas de penetración.

Un único servidor MCP no aprobado con acceso de lectura a un CRM interno o repositorio de código es una ruta de datos no auditada que los controles perimetrales no detectarán. El tráfico se origina desde dentro de la red, desde una máquina de desarrollador que se supone que debe estar allí.

Envenenamiento de la Descripción de Herramientas Elude las Defensas de la Capa de Red

Cuando un agente se conecta a un servidor MCP e invoca tools/list, el servidor responde con nombres de herramientas, descripciones y esquemas de parámetros. El agente utiliza esos metadatos para decidir qué herramientas invocar y cómo llamarlas. Manipule esos metadatos y redirigirá el comportamiento del agente sin explotar ninguna vulnerabilidad de código.

El envenenamiento de la descripción de herramientas incrusta instrucciones maliciosas dentro de los metadatos de las herramientas que hacen que el agente realice acciones no deseadas: exfiltrar datos, invocar herramientas fuera de su alcance previsto o eludir las comprobaciones de seguridad mientras parece ejecutar su tarea asignada. El contenido malicioso viaja dentro del cuerpo de la respuesta HTTP desde el servidor MCP, específicamente dentro de la carga útil de tools/list. Los firewalls de aplicaciones web estándar y las herramientas de seguridad de API tienen visibilidad de los cuerpos de respuesta HTTP, pero no pueden detectar este ataque porque el contenido malicioso es lenguaje natural semánticamente incrustado, no una anomalía sintáctica como una firma de exploit conocida o un encabezado mal formado. El ataque tiene éxito en la capa de razonamiento, donde el agente interpreta las descripciones de las herramientas como instrucciones legítimas y actúa en consecuencia.

Las salvaguardas Pre Tool de MCP de TrueFoundry inspeccionan los parámetros de las herramientas y los argumentos de llamada antes de la ejecución utilizando la detección de inyección de prompts basada en modelos. Si los argumentos de llamada de la herramienta contienen instrucciones redirigidas, la ejecución se bloquea antes de que la herramienta se ejecute y la detección se registra en el seguimiento de la solicitud.

Las Credenciales Compartidas del Servidor MCP Eliminan la Responsabilidad de Cumplimiento

Los servidores MCP que utilizan claves API compartidas o tokens de cuenta de servicio no pueden producir los registros de auditoría atribuibles que requieren los marcos de cumplimiento. Si diez agentes comparten un conjunto de credenciales, no hay forma de vincular una llamada de herramienta específica a un usuario, instancia de agente o equipo específico. En un entorno regulado, esa brecha no es un inconveniente. Es un fallo directo de cumplimiento.

HIPAA requiere pistas de auditoría atribuibles a un usuario o servicio identificable para cada acceso a información de salud protegida. SOC2 CC6 requiere controles de acceso con evidencia de aplicación. El principio de responsabilidad del GDPR requiere que las organizaciones demuestren que el procesamiento de datos fue autorizado y documentado. Las implementaciones de MCP con credenciales compartidas no pueden satisfacer ninguna de estas. TrueFoundry reemplaza las credenciales compartidas con Tokens de Acceso Personal vinculados a usuarios individuales y Tokens de Cuenta Virtual para acceso a nivel de aplicación, de modo que cada llamada de herramienta lleva una identidad verificable.

Los Cuatro Pilares de la Gobernanza Empresarial de MCP

Un marco completo de gobernanza empresarial de MCP requiere cuatro capacidades que funcionan en conjunto: un catálogo centralizado, controles de acceso basados en identidad, registro de auditoría estructurado y aplicación de políticas en tiempo real. Cada una depende de las otras. No se pueden aplicar políticas de acceso antes de saber qué servidores existen. No se puede construir una pista de auditoría sin atribución de identidad. Y los registros de auditoría post-mortem sin aplicación en tiempo real son registros forenses, no controles de seguridad.

Cuatro Pilares: Función Principal, Implementación de TrueFoundry y Cobertura de Cumplimiento

Pilar 1: Un Catálogo Centralizado de Servidores MCP

El catálogo es el registro autorizado de cada servidor MCP aprobado en su organización. Cada entrada contiene la información que los equipos de seguridad de la información necesitan para evaluar el riesgo: nombre del servidor, equipo propietario, alcance del acceso a los datos, método de autenticación, estado de aprobación, parámetros de conexión y cualquier restricción de uso, como grupos de usuarios aprobados o límites de velocidad.

Los nuevos servidores entran a través de un flujo de trabajo de verificación. La revisión de la descripción de la herramienta detecta riesgos de envenenamiento antes de que el servidor llegue a los entornos de desarrollo. La evaluación del acceso a los datos determina a qué puede acceder el servidor. Una aprobación explícita autoriza la distribución. Nada de esto requiere cambios en el propio servidor MCP. Sucede en la capa del catálogo, y las implementaciones individuales de los servidores permanecen intactas.

El catálogo también gestiona la distribución. Los desarrolladores extraen configuraciones de servidor preaprobadas directamente en sus integraciones de IDE en lugar de configurar servidores manualmente. Solo los servidores aprobados por el catálogo llegan a las máquinas de los desarrolladores. La función de Servidor MCP Virtual de TrueFoundry amplía esto: los equipos de plataforma componen subconjuntos de herramientas seleccionados de múltiples servidores registrados, exponiendo solo lo que un equipo o caso de uso específico requiere, sin implementar nueva infraestructura.

Pilar 2: SSO y Control de Acceso al Servidor MCP en la Capa de Pasarela

El acceso a MCP debe pasar por el mismo proveedor de identidad que rige todo lo demás en la organización. TrueFoundry es compatible con los flujos de OAuth2 de dos y tres patas, SAML 2.0, y la integración directa con Okta, Azure Active Directory, Auth0, Cognito y cualquier IdP compatible con JWKS. El acceso a MCP se aprovisiona y desaprovisiona a través de los mismos flujos de trabajo de incorporación y desvinculación que cubren el correo electrónico, los repositorios y las consolas en la nube. Cuando un desarrollador se va, el acceso a MCP se desactiva automáticamente.

La pasarela admite tres métodos de autenticación de entrada, según quién realice la llamada. Los Tokens de Acceso Personal (PAT) se generan desde Configuración > Claves API en la interfaz de usuario de TrueFoundry, están vinculados a usuarios individuales y son la opción estándar para los flujos de trabajo de desarrollo. Los Tokens de Cuenta Virtual (VAT) son cuentas de servicio con permisos definidos, apropiados para agentes de producción y flujos de trabajo de servidor a servidor. Los tokens de IdP externos permiten a los usuarios sin cuentas de TrueFoundry autenticarse utilizando su propio proveedor de identidad, cubriendo implementaciones de SaaS B2B y agentes orientados al cliente.

Para la autenticación saliente a los servidores MCP descendentes, TrueFoundry gestiona el ciclo de vida completo de las credenciales a través de seis patrones. Los flujos de código de autorización OAuth gestionan el acceso por usuario a servicios como GitHub y Slack, con la pasarela gestionando el consentimiento, el almacenamiento de tokens y la actualización automática. Los flujos de credenciales de cliente OAuth gestionan el acceso de servidor a servidor. Los modos de clave API compartida e individual cubren casos más sencillos en los que la pasarela inyecta la credencial correcta por solicitud. El paso de token (Token Passthrough) reenvía el token entrante sin cambios cuando el servidor MCP puede validarlo directamente. El reenvío de token (Token Forwarding) a través del encabezado x-tfy-mcp-headers gestiona escenarios en los que el servidor MCP utiliza un sistema de credenciales independiente.

Control de Acceso a Servidores MCP: Patrones de Autenticación en Escenarios Empresariales Comunes

Las políticas RBAC determinan qué equipos o individuos pueden invocar qué servidores y herramientas. Estas políticas residen en la pasarela, no dentro de los servidores MCP individuales, por lo que una actualización de política surte efecto en todos los clientes inmediatamente sin necesidad de volver a desplegar el servidor. Un equipo de ciencia de datos obtiene acceso a herramientas de análisis, pero no a servidores de despliegue. Un equipo de seguridad obtiene acceso de solo lectura a todos los servidores con fines de auditoría.

Pilar 3: Registro de Auditoría Estructurado Vinculado a Cada Llamada de Herramienta

Cada llamada a una herramienta MCP necesita una entrada de registro que capture el contexto completo de la invocación: marca de tiempo, identidad del llamante, identificador del servidor MCP, nombre de la herramienta, parámetros de entrada, resumen de la respuesta, decisión de política con su razón, resultados de las barreras de seguridad por hook mostrando el tiempo de ejecución y los hallazgos, y latencia total. Estos campos deben ser JSON estructurado para que los sistemas SIEM y las herramientas de informes de cumplimiento puedan consultarlos.

TrueFoundry controla el registro en dos niveles. A nivel de solicitud, el encabezado X-TFY-LOGGING-CONFIG con enabled: true captura la solicitud completa. A nivel de pasarela en despliegues autoalojados, la variable de entorno REQUEST_LOGGING_MODE establece el comportamiento global: ALWAYS registra cada solicitud independientemente de los encabezados, lo cual es la configuración correcta para entornos de producción regulados. HEADER_CONTROLLED se remite a la configuración por solicitud. NEVER suprime todo el registro para entornos donde esto sea apropiado.

Los registros de solicitudes son visibles en la interfaz de usuario de TrueFoundry en AI Gateway > Monitor > Requests. Los tramos de ejecución individuales de las barreras de seguridad aparecen en AI Gateway > Monitor > Request Traces, mostrando qué barreras de seguridad se ejecutaron en qué hook, el estado de aprobación/fallo, el tiempo de ejecución y las mutaciones aplicadas. Para las organizaciones que enrutan los registros a su propia infraestructura, TrueFoundry exporta a través de OpenTelemetry a Grafana, Datadog, Splunk y cualquier destino compatible con OTLP. En despliegues autoalojados, los datos de registro se escriben en su propio almacenamiento AWS S3, GCS o Azure Blob en formato Parquet, consultable a través de Spark, DuckDB o Athena.

HIPAA exige la retención de documentación relacionada con la seguridad durante seis años. En la práctica, los registros de auditoría a menudo se retienen por una duración similar para respaldar el cumplimiento y la investigación de incidentes. Muchos registros financieros siguen un estándar de retención de siete años. Los registros deben ser a prueba de manipulaciones, con controles de acceso que impidan su modificación por parte de los equipos que los generan. Las opciones de despliegue autoalojado de TrueFoundry mantienen todos los datos de registro dentro de la cuenta en la nube del cliente, lo que respalda los requisitos tanto de retención como de evidencia de manipulación.

Pilar 4: Aplicación de Políticas MCP en Tiempo Real Antes de la Ejecución de la Herramienta

Registrar lo que sucedió no es lo mismo que prevenirlo. La aplicación de políticas debe actuar en el momento de la invocación, antes de que la llamada a la herramienta llegue al servidor MCP, para que el acceso no autorizado sea bloqueado en lugar de documentado a posteriori.

El sistema de barreras de seguridad de TrueFoundry implementa dos hooks por cada llamada a herramienta. Las barreras de seguridad MCP Pre Tool se ejecutan antes de que la herramienta se ejecute. Si alguna de ellas falla, la herramienta nunca se ejecuta, evitando por completo el costo, los efectos secundarios y la exposición de datos de una llamada incorrecta. Las barreras de seguridad pre-herramienta integradas incluyen: SQL Sanitizer, que detecta DROP, TRUNCATE, DELETE y UPDATE sin WHERE, y patrones de interpolación de cadenas que indican riesgo de inyección; detección de inyección de prompts (Prompt Injection) utilizando análisis basado en modelos para intentos de jailbreak e inyección en los parámetros de llamada de la herramienta; detección de secretos (Secrets Detection) que identifica claves API, credenciales de AWS, tokens JWT y claves privadas antes de que lleguen a los servicios de backend; y barreras de seguridad de políticas Cedar y OPA para un control de acceso declarativo y granular hasta argumentos específicos de la herramienta.

Las barreras de seguridad MCP Post Tool se ejecutan después de que la herramienta devuelve un resultado, antes de que este llegue al agente. Las barreras de seguridad post-herramienta integradas incluyen: Code Safety Linter, que señala llamadas a eval, exec, os.system, subprocess y comandos de shell peligrosos en la salida de la herramienta; detección de PII (PII Detection), que encuentra y anonimiza información personal con categorías de entidades configurables; y coincidencia de patrones Regex (Regex Pattern Matching) para patrones personalizados que cubren tarjetas de pago, identificadores internos y datos sensibles específicos del dominio. Proveedores externos como AWS Bedrock Guardrail, Azure Content Safety, Azure Prompt Shield, CrowdStrike y Google Model Armor se integran a través del mismo sistema de hooks.

Las estrategias de aplicación son configurables por barrera de seguridad. 'Enforce' bloquea en caso de violación y en caso de error de la barrera de seguridad. 'Enforce But Ignore On Error' bloquea en caso de violación, pero permite que las solicitudes pasen si el proveedor de la barrera de seguridad no está disponible, lo cual es el valor predeterminado recomendado para producción. 'Audit' registra las violaciones sin bloquear, el modo correcto durante el despliegue inicial. La secuencia recomendada es 'Audit' primero, luego 'Enforce But Ignore On Error', y finalmente 'Enforce' completo a medida que aumenta la confianza.

Despliegue de una Pasarela MCP Empresarial: Un Plan de Implementación de Cuatro Pasos

La gobernanza de MCP es un programa secuenciado. Cada paso se basa en el anterior. No se pueden aplicar políticas de acceso antes de saber qué servidores existen. No se puede construir una pista de auditoría significativa antes de que la atribución de identidad esté establecida.

Paso 1: Inventariar Todos los Despliegues MCP Existentes

Comience con una auditoría completa de cada servidor MCP en ejecución en entornos de desarrollo, pipelines de CI/CD, despliegues de agentes de producción y configuraciones de IDE. Esto incluye servidores que los desarrolladores configuraron localmente en Cursor o Claude Code sin la participación de TI. La combinación de escaneo automatizado de entornos en la nube con un proceso de autoinforme para configuraciones de desarrolladores locales proporciona la imagen más completa para grandes organizaciones.

Registre para cada servidor: nombre y propósito, equipo propietario, alcance de acceso a datos, método de autenticación (si lo hay) y cuánto tiempo lleva en funcionamiento. El objetivo es obtener una imagen precisa de lo que existe antes de que la gobernanza estuviera establecida, no una lista seleccionada de elementos ya aprobados.

Paso 2: Construir el Catálogo de Servidores MCP Aprobados

Antes de migrar cualquier servidor, defina el esquema de metadatos y el flujo de trabajo de aprobación. Decisiones clave: quién tiene autoridad de aprobación para los diferentes niveles de riesgo, qué cubre la lista de verificación de revisión y qué hallazgos bloquean el registro en el catálogo. Establezca estos criterios antes de categorizar los servidores para que se apliquen de manera consistente.

Revisa el inventario y clasifica cada servidor como aprobado para el catálogo, pendiente de revisión o bloqueado a la espera de remediación. Establece una fecha límite estricta para que todos los servidores de producción estén registrados en el catálogo y comunica claramente que los servidores no catalogados serán bloqueados en la pasarela después de esa fecha. La fecha límite crea la urgencia necesaria para que los equipos se involucren.

Paso 3: Despliega la pasarela MCP y aplica el SSO

Dirige todo el tráfico MCP a través de la pasarela antes de aplicar las políticas de bloqueo. Comienza con REQUEST_LOGGING_MODE configurado en ALWAYS. Todo el tráfico pasa, todas las invocaciones se registran, pero aún no se bloquea nada. Ejecutar en este modo durante dos a cuatro semanas te proporciona una base de patrones de tráfico reales antes de que comience la aplicación de las políticas.

Integra la pasarela con tu IdP empresarial a través de Acceso > Autenticación externa > Proveedor de identidad en la interfaz de usuario de TrueFoundry. Para Okta, utilizando el servidor de autorización predeterminado, la URI de JWKS es https://your-org.okta.com/oauth2/v1/keys. Las organizaciones que utilicen un servidor de autorización de Okta personalizado deben usar https://your-org.okta.com/oauth2/{authServerId}/v1/keys en su lugar. Para Azure AD, es https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys, con el ID de inquilino y el ID de cliente configurados como emisor y audiencia. Verifica que cada invocación en el registro de auditoría muestre una identidad de usuario o agente específica antes de pasar a la aplicación de las políticas. Las identidades de cuentas de servicio compartidas en los registros significan que la atribución de identidad es incompleta.

Paso 4: Habilita la aplicación de políticas y configura las alertas

Después del período de referencia, habilita la aplicación de políticas: bloquea los servidores MCP no catalogados, activa las políticas RBAC y aplica límites de velocidad. Comunica la fecha de aplicación a los equipos de desarrollo con suficiente antelación para agilizar el registro en el catálogo de herramientas legítimas.

Configura alertas sobre los datos exportados de OpenTelemetry para patrones anómalos: volúmenes de llamadas inusuales desde una única identidad de agente, acceso a herramientas de alta sensibilidad fuera del horario aprobado, violaciones de políticas por parte de identidades que no deberían tener acceso a MCP. Los resultados de las barreras de seguridad en AI Gateway > Monitor > Request Traces te proporcionan el detalle necesario para ajustar los umbrales con el tiempo. Revisa las reglas de alerta trimestralmente a medida que tu implementación de MCP crezca.

Requisitos de seguridad empresarial de MCP por sector

Tres requisitos aparecen consistentemente en todos los entornos regulados: registros de acceso atribuibles vinculados a identidades verificadas, controles de residencia de datos que mantienen la información sensible dentro de límites definidos, y documentación de riesgo de proveedores para la propia infraestructura de gobernanza.

• Sector sanitario (HIPAA): Cualquier servidor MCP que pueda recibir información de salud protegida en parámetros o respuestas requiere una pasarela aislada por VPC. Las invocaciones de herramientas que involucren PHI necesitan registros con identificadores de pacientes reemplazados por tokens de referencia, y el acceso debe ser aprovisionado a través de la gestión de identidad clínica. La implementación autohospedada de TrueFoundry en AWS GovCloud es compatible con cargas de trabajo alineadas con HIPAA. Innovaccer procesa aproximadamente 17 millones de solicitudes de inferencia de IA clínica al mes, completamente dentro de su límite de AWS GovCloud utilizando TrueFoundry, con OpenTelemetry alimentando los paneles de Grafana y sin que ningún dato sensible salga de su perímetro de nube.

• Servicios financieros (SOC2, FINRA): La infraestructura de gobernanza de MCP está dentro del alcance de las auditorías SOC2 Tipo II si maneja datos financieros o tiene acceso a sistemas de registro. Los controles requeridos incluyen cifrado en tránsito y en reposo, revisiones de acceso trimestrales con evidencia documentada, y procedimientos de respuesta a incidentes que cubran los modos de fallo específicos de MCP. TrueFoundry posee la certificación SOC2 Tipo II y exporta registros de auditoría MCP estructurados en el formato que los auditores requieren para producir evidencia de control CC6.

• Seguros y empresas globales (RGPD, residencia de datos): Las organizaciones cubiertas por el RGPD deben mantener un Registro de Actividades de Procesamiento según el Artículo 30 que cubra el procesamiento asistido por IA, incluidas las invocaciones de herramientas MCP. Este registro es un documento de cumplimiento estructurado que describe los propósitos del procesamiento, las categorías de datos, las transferencias y las salvaguardias. Los registros de auditoría de la pasarela MCP proporcionan los datos de eventos subyacentes que alimentan este registro, pero el propio RoPA debe ser mantenido por separado por la función de protección de datos de la organización. Los registros de la pasarela también deben capturar metadatos suficientes para respaldar las solicitudes de acceso de los interesados y para documentar cualquier transferencia transfronteriza que ocurra a través de las invocaciones de herramientas. Los requisitos de residencia de datos pueden prohibir que el tráfico MCP salga de regiones geográficas específicas, lo que requiere implementaciones de pasarelas regionales.

Cómo TrueFoundry ofrece gobernanza MCP empresarial

El Gateway MCP de TrueFoundry ofrece los cuatro pilares de gobernanza desde un único plano de control implementado en la propia cuenta en la nube del cliente. Los equipos de plataforma gestionan la pila de gobernanza completa a través de una única interfaz sin modificar las implementaciones individuales del servidor MCP. Ningún tráfico MCP sale del perímetro de la empresa.

Empresas como NVIDIA, Zscaler, Siemens Healthineers y Automation Anywhere utilizan TrueFoundry para pasar de implementaciones MCP ad-hoc a entornos controlados y gobernados. Para las empresas que ejecutan cargas de trabajo de agentes de IA a escala, los controles de costos aplicados por políticas, los límites presupuestarios y la capa de almacenamiento en caché de TrueFoundry han logrado reducciones significativas en el gasto mensual de inferencia e invocación de herramientas. Póngase en contacto con TrueFoundry para obtener cifras específicas de su caso, basadas en su volumen de invocación real y su combinación de modelos.

• Catálogo MCP centralizado con flujo de trabajo de verificación: El plano de control de TrueFoundry mantiene el registro autorizado de servidores MCP aprobados con metadatos, estado de aprobación y parámetros de conexión. Los nuevos servidores entran a través de un proceso de verificación que incluye la revisión de la descripción de la herramienta para detectar riesgos de envenenamiento antes de su distribución a las configuraciones IDE del desarrollador. La función de Servidor MCP Virtual permite a los equipos de plataforma componer subconjuntos de herramientas seleccionados a partir de múltiples servidores registrados, exponiendo solo lo que un equipo específico necesita sin implementar nueva infraestructura.

• OAuth2 y RBAC en cada llamada a herramienta: Cada invocación de MCP se autentica mediante OAuth2 con la identidad empresarial del llamante. El gateway gestiona los seis patrones de autenticación saliente y administra el ciclo de vida completo del token para flujos de Código de Autorización, flujos de Credenciales de Cliente e inyección de claves API. Las políticas RBAC aplicadas en el gateway se aplican inmediatamente a todos los clientes cuando se actualizan, sin necesidad de volver a implementar el servidor.

• Políticas de metadatos configurables por invocación: TrueFoundry aplica el enmascaramiento de datos mediante Detección de PII y barreras Regex, límites de tasa por equipo, topes de costos por sesión de agente y reglas de bloqueo para categorías de herramientas restringidas a través de políticas Cedar u OPA. Todo configurado en la interfaz de gestión. No se requieren cambios en el código del servidor MCP.

• Registros de auditoría transmitidos a su SIEM: Los registros de auditoría JSON estructurados para cada invocación de MCP se exportan a través de OpenTelemetry a Grafana, Datadog, Splunk o cualquier destino compatible con OTLP. En implementaciones autoalojadas, los registros se escriben en su propio almacenamiento AWS S3, GCS o Azure Blob en formato Parquet, consultables a través de Spark, DuckDB o Athena. REQUEST_LOGGING_MODE: ALWAYS garantiza una captura completa para entornos regulados.

• Implementación aislada en VPC con cuatro opciones: SaaS totalmente gestionado sin sobrecarga de infraestructura; gateway SaaS con almacenamiento de datos propiedad del cliente; plano de gateway autoalojado con plano de control de TrueFoundry a un costo de infraestructura de aproximadamente $600 al mes; plano de control y gateway totalmente autoalojados a un costo de aproximadamente $800 a $1,000 al mes. Las dos últimas opciones garantizan que ningún tráfico de invocación de MCP salga de su perímetro para llegar a la infraestructura de TrueFoundry.

‍