Pipeline de seguridad

MCP Fusion aplica la seguridad como un pipeline de capas, cada una con una posición clara en la solicitud. Esta página es el mapa técnico: qué se ejecuta, en qué orden, con qué garantías.

El orden, de extremo a extremo

1 contextFactory      tenant and identity resolution
2 rate limiter        sliding window, key from ctx
3 input firewall      LLM-as-Judge on the arguments
4 validate            strict Zod per action, unknown keys rejected
5 middleware chain    auth, audit, custom, precompiled and frozen
6 handler             your business logic
7 Presenter           schema shape → _select → redact → serialize
8 rules and UI        computed on the full object, never on the wire copy
9 egress guard        byte budget on the text response
10 audit + telemetry  every stage emits if a sink is configured

Capa por capa

Rate limiter

rateLimit({ windowMs, limit, keyFn }) es un middleware que usa una ventana deslizante sobre listas de timestamps. Dos llamadas importan: increment() cuenta sin registrar, y record() solo registra solicitudes aceptadas, así el tráfico rechazado no puede inflar su propia ventana. keyFn(ctx) es el gancho de identidad: limita por token, por tenant o por usuario. El store es una interfaz; el store en memoria está documentado como de un solo proceso, y producción usa tu Redis o KV detrás de la misma interfaz.

Firewall de entrada

inputFirewall({ judge }) se ejecuta después de la validación Zod y antes de tu handler. Los argumentos se serializan en un prompt de juez (backticks neutralizados para impedir el escape de fences) y un SemanticProbeAdapter intercambiable devuelve { safe, threats }. Con !safe el handler nunca se llama: la respuesta es un toolError('INPUT_REJECTED', ...) autorreparable. Esta capa es para entradas con forma de inyección: «ignora las instrucciones anteriores», cargas de exfiltración, rutas de archivo de contrabando.

Redacción del Presenter (el firewall de egreso)

.redactPII(paths, censor?) compila rutas fast-redact en una sola función, cacheada en el Presenter. El orden del pipeline dentro de Presenter.make() es preciso: truncar, validar, aplicar _select, clonar los datos del wire, enmascarar, convertirlos a string, y luego renderizar bloques de UI y reglas desde el objeto completo sin enmascarar. Consecuencias:

• el texto del modelo nunca contiene campos enmascarados; [REDACTED] ni siquiera está en el wire para claves ocultas por _select
• los bloques de ui.table() conservan los valores reales (se construyen desde el objeto completo en memoria, y el texto del wire ya está congelado)
• si structuredClone o el redactor lanza, el pipeline también lanza: Data withheld to prevent PII leak. La redacción es fail-closed en ese punto.

Firewall de prompts

Las propias reglas son superficie de ataque: las reglas dinámicas se generan a partir de datos, y los datos vienen del mundo del agente. presenter.promptFirewall({ judge }) envía las reglas de sistema acumuladas a un juez antes de que cualquiera de ellas llegue al modelo. La estrategia es fail-closed y por regla: si el juez marca el lote pero nombra algunas reglas, las no nombradas también se bloquean. El modo de consenso (todos los jueces coinciden) no tiene fail-open. Configurar un firewall fuerza la ruta asíncrona: make() lanza, makeAsync() es el contrato.

Sandbox

sandboxed() en una tool anuncia delegación de cómputo: el agente envía una función flecha JS, SandboxEngine la ejecuta dentro de un contexto isolated-vm nuevo con los datos inyectados como copia externa, y solo el valor devuelto regresa. Valores por defecto: timeout de 5s, isolate de 128MB, tope de salida de 1MB, tope de código de 64KB. process, require, fs, globalThis y Buffer no existen dentro del contexto; la guarda que rechaza patrones obvios es solo DX y explícitamente no es la frontera. A la cancelación, el engine descarta el isolate (o libera solo el contexto cuando otras solicitudes lo comparten) y lo recrea en la siguiente llamada.

Kill switch y halt

La parada de emergencia vive en la consola, mira Connector policy: el halt global y la política por conector. En el Edge, los conectores detenidos dejan de servir llamadas sin un nuevo deploy.

Lo que el framework no hace

Honestidad antes que márketing: el middleware de auditoría del framework emite eventos a tu sink (resúmenes de argumentos SHA-256, clasificación de estado, sin firmado, sin cadena). La cadena de auditoría firmada e infalsificable es una función del hosting de Vinkius Cloud: despliega con mcpfusion deploy y la plataforma la registra por ti. La misma división aplica a los stores de rate limit: la interfaz es tuya, el Edge la ejecuta.

Próximos pasos

• Runtime architecture: dónde se ubica cada capa en el motor
• Governance: probar que el pipeline se mantuvo bloqueado
• Tools: adjuntar guardas a una tool