Arquitectura MCP segura y escalable: reforzando el protocolo de contexto del modelo desde repositorio hasta ejecución • mcprepo.ai

La seguridad y la escalabilidad no se consiguen en producción; se diseñan desde el primer commit.

Por qué “MCP seguro y escalable” es una disciplina propia

El Model Context Protocol (MCP) cambia la naturaleza del riesgo en las aplicaciones. Las apps tradicionales ya lidian con identidad, secretos y acceso a datos, pero MCP añade una nueva capa: orquestación del contexto. El sistema deja de ser solo código que llama a APIs. Es una cadena de herramientas, prompts, fuentes de recuperación y llamadas a funciones que pueden comportarse de forma distinta ante entradas adversarias o simplemente desordenadas.

Una arquitectura MCP robusta trata el contexto como un activo gobernado. Eso significa que necesitas asegurar:

Cómo se selecciona el contexto (qué se incluye o se excluye)
Cómo se transporta el contexto (entre cliente, servidor y herramientas)
Cómo se ejecuta el contexto (llamadas a herramientas, efectos secundarios y operaciones de escritura)
Cómo se audita el contexto (quién lo solicitó, qué se usó, qué ocurrió)

Y necesitas hacer esto escalando horizontalmente, a través de repos, y entre equipos—sin convertir tus servidores MCP en “cajas mágicas” que nadie comprende.

Este artículo se centra de forma concreta en repositorios MCP y en la arquitectura de grado de producción a su alrededor: identidad, límites de herramientas, secretos, políticas, observabilidad y controles de la cadena de suministro.

Empieza con el modelo de amenazas: qué puede salir mal en sistemas MCP

Un diseño MCP seguro comienza nombrando los modos de fallo en lenguaje claro. En la práctica, la mayoría de incidentes encajan en unas pocas categorías:

Abuso impulsado por prompts y contexto

Inyección de contexto a través de documentos no confiables, páginas web, comentarios en issues o mensajes de chat que alteran el comportamiento de las herramientas.
Coerción de herramientas donde el modelo es inducido a llamar a una herramienta privilegiada (“delete”, “refund”, “rotate keys”) o a exfiltrar datos sensibles.
Fuga entre inquilinos cuando índices de recuperación, cachés o logs mezclan inquilinos por accidente.

Deriva de identidad y acceso

Tokens excesivamente amplios en adaptadores de herramientas.
Una “cuenta de servicio” compartida sin trazabilidad por usuario.
Falta de comprobaciones de autorización porque el modelo “decide” qué llamar.

Compromiso de la cadena de suministro

Actualizaciones maliciosas de dependencias en repositorios del servidor MCP.
Imágenes de contenedor o imágenes base inseguras.
Definiciones de herramientas sin revisar que amplían capacidades de forma encubierta.

Riesgo operativo a escala

Sin limitación de tasa, llevando a explosiones de costes y denegación por presupuesto.
Mala observabilidad que hace imposible reconstruir cadenas de llamadas a herramientas.
Sin rollback seguro de versiones de herramientas, prompts o reglas de recuperación.

Tu postura de seguridad mejora rápidamente cuando tratas MCP como un sistema distribuido con límites de confianza explícitos, no como una capa de integración ingeniosa.

Línea base arquitectónica: separa el plano de control del plano de datos

Una arquitectura MCP escalable se beneficia de una separación:

Plano de control: políticas, mapeo de identidad, registro de herramientas, versionado, aprobaciones y distribución de configuración.
Plano de datos: los servidores MCP en tiempo de ejecución y los ejecutores de herramientas que manejan el tráfico de usuarios y el procesamiento de contexto.

Este patrón es familiar desde gateways de API y service meshes. La clave es evitar “política dispersa en el código”. En su lugar, quieres la política definida centralmente y aplicada en tiempo de ejecución mediante ganchos consistentes.

Layout de referencia mínimo para repositorios MCP

Una topología común de repo para proyectos MCP que quieren escalar entre muchas herramientas se parece a esto:

mcp-server/
- transport (stdio/http), middleware de auth, validación de peticiones
- despachador de herramientas y capa de sandboxing de herramientas
tools/
- implementaciones de herramientas agrupadas por dominio (crm/, billing/, infra/)
- declaraciones de capacidad de herramientas (schema, scopes, efectos secundarios)
policies/
- reglas de acceso por tenant, rol, entorno, clasificación de datos
- listas de permitidos/denegados para la invocación de herramientas
prompts/
- system prompts, instrucciones de herramientas, restricciones de seguridad
- versionados, revisados por código, probados como código
infra/
- IaC para despliegue, secretos, políticas de red, logging, métricas
tests/
- tests unitarios para herramientas
- tests de contrato para el schema de las herramientas
- tests adversariales para inyección y fuga de datos

Esa estructura crea fricción en los puntos correctos: las definiciones de herramientas no pueden llegar a producción sin revisión, y la política no queda enterrada en la implementación.

Identidad primero: autentica al cliente y luego vincula las llamadas a herramientas a un actor

MCP suele situarse entre un cliente (IDE, agente de escritorio, portal interno) y sistemas privilegiados (alojamiento de Git, consolas cloud, sistemas de tickets). Si no vinculas las llamadas a una identidad real, pierdes la capacidad de aplicar el principio de menor privilegio.

Patrón de identidad recomendado

Autenticación del cliente: el cliente MCP se autentica con tu servidor MCP usando OIDC (preferido), mTLS o tokens firmados de corta duración.
Vinculación de actor: cada petición se asocia con:
- identidad del usuario (humano) o identidad de workload (servicio)
- límite de tenant/organización
- id de sesión e id de correlación
Autorización delegada: las llamadas a herramientas o bien:
- se ejecutan con un token delegado restringido para el usuario, o
- se ejecutan con un token de servicio pero con estrictas comprobaciones de autorización por usuario aplicadas en el servidor.

El primer enfoque (delegación) suele ser más seguro. El segundo puede ser necesario para sistemas legacy, pero exige comprobaciones server-side y logging a prueba de fallos.

No confíes en que el modelo haga la autorización

La autorización debe aplicarse en el despachador de herramientas del servidor MCP, no dentro del texto del prompt. Las reglas en prompts son útiles, pero no son una medida de cumplimiento. Quieres una puerta dura:

Valida que la herramienta esté permitida para el actor, tenant y entorno.
Valida los parámetros (tipos, rangos, enums permitidos).
Requiere aprobación adicional para efectos secundarios de alto riesgo.

Límites de herramientas: define “capacidades”, no solo funciones

En MCP, las “herramientas” son los filos. Son donde el modelo puede causar efectos secundarios, leer datos sensibles o disparar workflows. Una arquitectura escalable trata cada herramienta como una capacidad con:

Alcance: a qué puede acceder (sistemas, objetos, campos)
Nivel de efecto secundario: solo lectura, escritura, destructivo, financiero, admin privilegiado
Clasificación de datos: público, interno, confidencial, regulado
Clase de tasa y cuota: barato, caro, picos, lento
Modo de aprobación: auto, confirmación por usuario, revisión de dos personas, ventana de cambios

Un repositorio MCP maduro codifica esto en un formato legible por máquina junto al schema de la herramienta. El schema por sí solo no es suficiente: necesitas metadata para impulsar la política.

Una taxonomía práctica de riesgo de herramientas

Tier 0 (seguro): formateo, matemáticas, parsing local, sin red
Tier 1 (solo lectura): búsqueda, obtención de docs no sensibles, APIs públicas
Tier 2 (lectura sensible): tickets internos, info de clientes, búsqueda de código en repos privados
Tier 3 (escritura): crear tickets, abrir PRs, modificar registros
Tier 4 (destructivo/privilegiado): eliminar, deshabilitar, rotar credenciales, cambios en producción

Cada tier se mapea a controles más estrictos: validación, confirmación, aprobaciones y sandboxing en tiempo de ejecución.

Manejo seguro del contexto: trata la recuperación como un canal de entrada no fiable

Los flujos con recuperación aumentada (retrieval-augmented) pueden convertirse silenciosamente en tu superficie de ataque más grande. Los documentos pueden incluir instrucciones, secretos incrustados o contenido diseñado para inducir un mal uso de herramientas.

Controles de higiene de contexto que escalan

Proveniencia del documento: almacena fuente, autor, timestamp y puntuación de confianza en metadata.
Partición de índices: aísla tenants y entornos; nunca mezcles staging y prod.
Filtrado de contenido:
- elimina fragmentos ejecutables cuando no son necesarios
- redacta secretos obvios antes de indexar
- ignora secciones “instruccionales” de fuentes no confiables
Presupuestos de contexto: limita cuánto contenido recuperado puede incluirse y prefiere resúmenes de fuentes confiables.
Recuperación basada en política: los resultados de recuperación deben filtrarse por el mismo modelo de acceso que las herramientas.

Un patrón sutil pero importante: convierte la recuperación en una herramienta con autorización explícita. “Buscar en la base de conocimiento” no es neutral si la base incluye runbooks confidenciales.

Secretos: sácalos de los repos, y luego sácalos de la memoria de las herramientas

Los repos MCP suelen comprometerse a la vieja usanza: credenciales en ficheros de entorno, tokens filtrados en logs de CI, o API keys hardcodeadas “temporalmente” en el código.

Postura básica de secretos para repos MCP

Usa un gestor de secretos real (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault).
Impone credenciales de corta duración (OIDC a cloud, credenciales dinámicas de BD).
Nunca permitas que las herramientas devuelvan secretos en texto plano a menos que el actor esté explícitamente autorizado y el evento sea auditado.
Configura el logging para redactar credenciales y campos sensibles en la ingestión.

Un error común: una herramienta obtiene un secreto para llamar a una API y el modelo ve el secreto en la salida de la herramienta o en logs verbosos. Las herramientas nunca deben devolver credenciales en bruto; deben devolver solo estado.

Aislamiento de red y runtime: asume que eventualmente abusarán de cada herramienta

Un runtime MCP escalable suele estar containerizado. Eso está bien, pero solo si usas el aislamiento por el que ya pagas.

Controles de runtime que importan

Política de egress: las herramientas solo deberían alcanzar hosts conocidos; deny por defecto en salidas.
Políticas de red por herramienta: herramientas de facturación no deberían acceder a endpoints de infra.
Restricciones de sistema de ficheros: root FS en solo lectura; montajes escribibles explícitos.
Sandboxing para herramientas de alto riesgo: pools de workers separados para herramientas Tier 3/4.
Límites de recursos: caps de CPU/memoria para evitar ejecuciones descontroladas.

El objetivo es hacer que el mal uso sea soportable. Cuando una herramienta es coaccionada para hacer algo estúpido, el radio de explosión debe ser pequeño.

Motor de políticas: centraliza autorización y puertas de seguridad

Para escalar, necesitas una capa de políticas que sea:

consistente (las mismas reglas en todas partes),
auditable (quién cambió qué y cuándo),
testable (tests unitarios para las políticas),
desplegable (versionado, con rollbacks).

Muchos equipos adoptan un enfoque de policy-as-code (por ejemplo, OPA/Rego o Cedar). El motor exacto importa menos que estas propiedades:

Las herramientas declaran capacidades y scopes requeridos.
Las peticiones llegan con identidad del actor y contexto (tenant, env, sensibilidad).
La política decide: allow/deny/allow-with-conditions.

Aprobaciones condicionales y controles de escalado

Las operaciones de alto riesgo no deberían bloquearse para siempre, pero deben estar enturbiadas:

Confirmación del usuario: mostrar un diff legible o un resumen de la acción.
Step-up auth: requerir reautenticación para acciones destructivas.
Regla de dos personas: para cambios en producción, requerir un segundo aprobador.
Ventanas de cambio: permitir herramientas Tier 4 solo durante periodos programados.

Estos controles son normales en plataformas de infraestructura; MCP solo necesita aplicarlos en el despachador de herramientas.

Probar repositorios MCP como si fuera código crítico de seguridad

Los repos MCP no deberían depender de “parece bien en el chat”. Quieres cobertura automatizada para los modos de fallo que realmente temes.

Qué probar (y cómo)

Tests de contrato de schema: las herramientas aplican tipos y rechazan campos inesperados.
Tests de autorización: deny-by-default; verifica el menor privilegio por rol.
Tests de inyección: inyecta documentos recuperados con contenido adversarial y verifica que el sistema se niega a elevar privilegios.
Tests de redacción: asegúrate de que campos sensibles nunca aparezcan en salida de herramientas o logs.
Tests de reproducción: graba una sesión y verifica decisiones de política deterministas en llamadas a herramientas.

Un patrón productivo es mantener un corpus de “documentos malos” en el repo: fragmentos diseñados para manipular el uso de herramientas, pedir secretos o anular el comportamiento del sistema. Los tests deben afirmar que el despachador de herramientas aplica política independientemente del texto.

Versionado y disciplina de releases: escala haciendo que el cambio sea seguro

Los sistemas MCP evolucionan rápido: nuevas herramientas, nuevas instrucciones de prompt, nuevas fuentes de recuperación. Sin disciplina de release, obtienes deriva y regresiones silenciosas.

Versiona todo lo que pueda cambiar comportamiento

Schemas de herramientas y metadata de capacidades
Bundles de políticas
Plantillas de prompts y reglas del sistema
Configuración de recuperación (índices, filtros, ajustes de ranking)
Umbrales de seguridad y patrones de redacción

También quieres garantías de compatibilidad. Si un cliente fija v1 de un schema de herramienta, el servidor debe respetarlo o negociarlo explícitamente.

Pipeline de promoción por entorno

Una arquitectura segura y escalable promueve cambios:

dev (iteración rápida, datos sintéticos)
staging (integraciones reales, alcance restringido)
prod (política estricta, aprobaciones, auditoría)

Cada etapa debe tener defaults de política distintos y listas de permitidos para herramientas distintas. Es normal que staging permita más introspección mientras prod esté cerrada.

Observabilidad: reconstruir la cadena sin loguear secretos

La observabilidad en MCP no es solo latencia y tasas de error. Necesitas responder:

¿Quién invocó qué herramienta?
¿Con qué parámetros (redactados)?
¿Qué fuentes de datos se recuperaron?
¿Qué decisión de política se aplicó?
¿Qué efectos secundarios ocurrieron en sistemas externos?

Esto requiere logs de eventos estructurados con IDs consistentes.

Conjunto mínimo de telemetría viable

Request id, session id, actor id, tenant id
Nombre de la herramienta, versión de la herramienta, tier de capacidad
Decisión de política (allow/deny/condiciones)
Hashes de parámetros o mapa de parámetros redactado
Metadatos de llamadas externas (host, clase de endpoint, duración, estado)
Fuentes de recuperación e IDs de documentos (no el contenido bruto)

Un beneficio sorprendente: la buena telemetría facilita mucho la gestión de costes. Puedes ver qué herramientas generan llamadas al modelo caras, qué tenants generan carga y dónde es seguro cachear.

_{Photo by Microsoft Copilot on Unsplash}

Estrategias de escalado: cuando un servidor MCP se convierte en muchos

Un único servidor MCP puede ser suficiente para herramientas internas pequeñas, pero la escala introduce nuevas limitaciones: concurrencia, vecinos ruidosos, cuotas por tenant y propiedad operativa.

Escalado horizontal sin perder gobernanza

Para escalar runtimes MCP, da preferencia a servidores sin estado:

Almacena el estado de sesión en un store compartido si es necesario (pero mantenlo mínimo).
Pon políticas y registros de herramientas en un store de config distribuido.
Usa una cola para tareas largas o de alto riesgo.

Luego aplica separación de cargas:

Gateway MCP frontal: auth, enrutamiento, comprobaciones de política, shaping de peticiones
Pools de ejecución de herramientas: segregados por tier de riesgo
Servicios de recuperación: aislados, particionados por tenant, con ACLs estrictas

Esto te permite escalar el hot path (gateway) de forma distinta al slow path (ejecución). También habilita seguridad más estricta para herramientas Tier 3/4 sin penalizar las llamadas Tier 1.

Limitación de tasa y cuotas como controles de primera clase

La denegación por presupuesto es real en MCP. Necesitas:

Límites de tasa por tenant
Cuotas de llamadas a herramientas por usuario
Límites de concurrencia por herramienta
Alarmas de presupuesto y circuit breakers

Las cuotas deberían aplicarse antes de llamadas caras al modelo cuando sea posible. Por ejemplo, rechaza una llamada a una herramienta de alto riesgo temprano en vez de generar primero un plan largo.

Gobernanza de datos: clasificación, residencia y retención

MCP a menudo toca datos sensibles de forma indirecta: documentos recuperados, adjuntos de tickets, código interno, registros de clientes. La gobernanza no es opcional, especialmente a escala.

Aplica clasificación de extremo a extremo

Etiqueta fuentes y documentos con clasificación.
Etiqueta herramientas con a qué pueden acceder y qué pueden emitir.
Aplica la regla de “no rebajar”: entradas confidenciales no deben llevar a salidas públicas sin una excepción de política explícita.

Reglas de retención para logs y trazas MCP

Los logs pueden convertirse en un almacén de datos oculto. Define retención por entorno y por clase de datos:

Conserva logs operativos mínimos por el menor periodo necesario.
Almacena trazas sensibles solo cuando es necesario, con acceso restringido.
Soporta flujos de “borrar mis datos” cuando proceda.

Esto requiere disciplina también en los repos: no almacenes transcripciones de conversaciones como fixtures de test si contienen datos reales.

Seguridad de la cadena de suministro para repositorios MCP

Los repos MCP son objetivos atractivos porque están cerca de credenciales, integraciones y automatización. Un compromiso en la cadena puede convertir silenciosamente herramientas en puertas traseras.

Medidas prácticas de endurecimiento de repos

Exige commits firmados para ramas críticas.
Requiere revisiones de code owners para:
- metadata de capacidades de herramientas
- bundles de políticas
- middleware de auth y logging
Fija dependencias y usa lockfiles.
Ejecuta SAST y escaneo de dependencias en cada PR.
Construye contenedores desde imágenes base mínimas; escanea imágenes en CI.
Conserva la procedencia de builds (metadatos estilo SLSA) si tu org lo soporta.

Trata las definiciones de herramientas como cambios de infraestructura. Una actualización de una línea en el schema puede ampliar el acceso más que cien líneas de código.

Componentes de producto que aparecen comúnmente en stacks MCP seguros

Diferentes equipos ensamblan arquitecturas MCP a partir de un conjunto de bloques. Aquí hay componentes comunes, descritos por su rol más que por promesas de marketing.

Motor de políticas (OPA/Cedar)
Decisiones centralizadas de allow/deny basadas en identidad del actor, tier de herramienta, tenant y entorno; policies versionadas y testeables.
Gestor de secretos (Vault/Cloud secrets)
Credenciales de corta duración, logs de acceso a secretos y rotación automática; reduce la proliferación de credenciales en repos MCP.
API gateway/service mesh
mTLS, shaping de peticiones, límites de tasa y telemetría consistente entre servidores MCP y pools de ejecución de herramientas.
Base de datos vectorial con partición por tenant
Recuperación con límites estrictos de acceso, filtros de metadata y controles de retención; crítico para evitar fugas entre tenants.
SIEM + pipeline de logging estructurado
Correlación central de eventos para llamadas a herramientas, decisiones de política y efectos secundarios externos—sin almacenar contexto sensible bruto.
Sandboxing de runtime de contenedores (gVisor/Kata)
Aislamiento más fuerte para herramientas de alto riesgo; reduce el radio de explosión cuando una herramienta es coaccionada.

Playbooks operativos: respuesta a incidentes para sistemas guiados por herramientas

Cuando algo falla en MCP, a menudo parece “el asistente hizo algo”. Una arquitectura escalable hace que ese “algo” sea trazable y reversible.

Qué necesitas listo antes del incidente

Un interruptor de emergencia para deshabilitar una herramienta globalmente o por tenant.
Una forma de hacer rollback rápido de versiones de herramientas y bundles de política.
Un rastro de auditoría que ate llamadas a herramientas con actores y sesiones.
Un modo de cuarentena para fuentes de recuperación (detener indexado, dejar de servir).
Backpressure y circuit breakers para detener cascadas.

Flujos típicos de incidentes

Sospecha de exfiltración: deshabilitar herramientas de lectura sensibles (Tier 2), aumentar la redacción, rotar credenciales comprometidas, revisar logs por patrones anómalos de recuperación.
Escrituras no autorizadas: deshabilitar pools Tier 3/4, forzar confirmaciones obligatorias, verificar que bundles de política y schemas de herramientas no hayan sido modificados.
Alerta de cadena de suministro: congelar despliegues, verificar procedencia de builds, bloquear actualizaciones de dependencias y reconstruir desde commits conocidos buenos.

La diferencia entre un mal día y una crisis suele ser si puedes deshabilitar una herramienta en segundos sin redeplegar todo.

Diseñar para el control humano sin romper la velocidad de los desarrolladores

La tentación en MCP es o bien bloquearlo todo (y matar la utilidad) o permitirlo todo (y aceptar el caos). El punto medio sostenible es el control escalonado.

Un modelo de gobernanza práctico

Los desarrolladores pueden añadir herramientas Tier 0/1 con revisión estándar.
Las herramientas Tier 2 requieren revisión de seguridad y declaraciones de alcance explícitas.
Las herramientas Tier 3/4 requieren:
- workflow de aprobación
- aislamiento en tiempo de ejecución
- campos de observabilidad obligatorios
- ownership on-call

Este modelo escala porque ajusta controles al riesgo. También crea un camino claro: prototipar como Tier 1 y luego promover con salvaguardas adicionales.

Haz que lo “seguro” sea el valor por defecto en plantillas

Si proporcionas plantillas internas de repos MCP, incorpora:

políticas deny-by-default
logging estructurado con redacción
helpers de validación de entrada
andamiaje de metadata de capacidad
harnesses de test para inyección y autorización

Los equipos avanzan más rápido cuando la vía segura es también la más fácil.

La arquitectura que aguanta bajo presión

Una arquitectura MCP segura y escalable no es un patrón único, pero tiene rasgos recurrentes:

peticiones ligadas a identidad y autorización delegada
herramientas tratadas como capacidades con controles por niveles de riesgo
política centralizada, versionada y aplicada en el dispatcher
recuperación tratada como entrada no confiable con proveniencia y particionamiento
secretos manejados con credenciales de corta duración y redacción estricta
aislamiento en runtime, controles de egress de red y límites de recursos
observabilidad pensada para reconstrucción sin fuga de datos
controles de cadena de suministro aplicados a definiciones de herramientas y políticas con la misma seriedad que al código

Cuando construyes MCP así, el sistema sigue siendo comprensible incluso cuando los repos se multiplican, las herramientas proliferan y el tráfico crece. Esa es la verdadera prueba de escala: no solo manejar más peticiones, sino seguir siendo gobernable cuando el contexto, el código y la organización cambian a la vez.

External Links

Build Secure and Scalable MCP Servers | Blogpost How to build secure and scalable remote MCP servers Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP Scaling MCP: A simpler, safer enterprise architecture - Cloudflare TV How to Design Secure MCP Deployments - Curity at Platform Summit 2025 | Videos