Saltar al contenido principal
El mayor cambio de paradigma de MCP a NMP es el concepto de Logic-on-Origin (Lógica en el Origen). Sin embargo, ejecutar lógica binaria arbitraria de agentes remotos en tu infraestructura introduce inmensas consecuencias de seguridad. Para solucionar esto, NMP confía plenamente en el aislamiento matemático a nivel de CPU proporcionado por WASI (WebAssembly System Interface), utilizando el motor Wasmtime de Bytecode Alliance.

​
¿Qué es WASI?

Cuando una herramienta Node.js o Python se ejecuta en MCP, depende del sandboxing general del sistema operativo (usualmente contenedores como Docker). Si una dependencia de Python se compromete, teóricamente podría intentar una escalada de red o escapar del contenedor. WASI invierte el modelo de seguridad. WebAssembly es un formato de computación seguro en memoria y puramente matemático. Por defecto, un módulo .wasm carece literalmente de instrucciones de CPU para hablar con el sistema operativo, disco, reloj o red. WASI es el puente estrictamente controlado que reintroduce estas funciones exacta y únicamente cuando se conceden de forma explícita.

​
El Ciclo de Vida del Sandbox NMP

Cuando un Nodo Agente inyecta un módulo WebAssembly en un Nodo de Datos, se activan las siguientes barreras de seguridad:
Límites de Ejecución WASM

​
1. Verificación de Capacidades

El Agente declara las capacidades que requiere por adelantado (ej., requires_capability: ["logs_read", "sql_readonly"]). El Nodo de Datos verifica su manifiesto local para ver si permite a este Agente específico acceder a esas capacidades.

​
2. Pre-aperturas (Preopens) Microscópicas

Si se aprueba, el Nodo de Datos no concede al módulo WASM acceso al sistema de archivos. En su lugar, “pre-abre” descriptores de archivos muy específicos y los mapea en el espacio virtualizado del módulo WASM. Si el agente pide leer /var/log/nginx/ y el servidor lo permite como /logs, el Agente solo ve /logs como la raíz absoluta de su universo. Intentar subir directorios con ../ se detiene en seco en el límite del Sandbox.

​
3. Límites de Ejecución y Memoria

Wasmtime arranca el motor con limitadores estrictos:
  • Tiempo Máximo de Ejecución: Si el módulo entra en un bucle infinito, el tiempo de ejecución lo mata por agotamiento de combustible (Out-Of-Fuel).
  • Límite de Memoria Máximo: Si el módulo intenta un desbordamiento de búfer o alojar memoria más allá de su límite (ej., 50MB), lanza un Trap de OOM (Out Of Memory) inalcanzable.
  • Cero Sockets: La lógica corre completamente offline dentro del Servidor. No puede abrir puertos ni conectarse a internet. Su única salida es lo que retorna al orquestador.
  • Paridad Node.js (Aislamiento V8): En desarrollo local o Demos del SDK (donde WebAssembly nativo no es un requisito), NMP implementa límites de contención absolutos e idénticos empleando el módulo node:vm (vm.createContext(Object.create(null))). Esto asegura un aislamiento rígido, despojando al entorno de ejecución de acceso a globales de Node (process, require, fs) y extinguiendo la posibilidad de manipulación del Sistema Anfitrión.
  • Pool No Bloqueante: Para evitar que los servidores Node.js se congelen, el @nekzus/neural-mesh aísla este ciclo dentro de worker_threads nativos (vía piscina), logrando un rendimiento paralelo idéntico al del Mesh-Node nativo.

​
Hacia el Modelo de Componentes (Preview 2)

NMP está adoptando WASI Preview 2 (The Component Model). Esto permitirá que los módulos compartan estructuras complejas y fuertemente tipadas de JSON y Protobuf a través de la frontera (Lenguaje del Agente -> Motor Rust), eliminando por completo la sobrecarga de parsing manual de strings entre el Sandbox y el Host.