Conceptos del Servidor

Arquitectura de protección de recursos y ejecución de lógica en Nodos de Datos LIOP

En el Logic-Injection-on-Origin Protocol, un “Servidor” es técnicamente denominado un Nodo de Datos (Data Node). A diferencia de un servidor web tradicional que responde pasivamente con JSON, un Servidor LIOP es un Motor de Ejecución activo. Su deber principal es recibir lógica foránea inyectada, aislarla estrictamente y permitirle operar sobre datos locales.

Para lograr esto de forma segura, los Servidores LIOP exponen tres primitivas fundamentales: Módulos, Capacidades y Watchdogs.

​

1. Módulos WebAssembly (La Lógica)

En protocolos heredados (como MCP), los servidores definen “Herramientas” estáticas (ej., calculate_sum, read_log), y la IA instruye al servidor para ejecutarlas con parámetros fijos.

En LIOP, el Servidor no necesita pre-programar infinitas herramientas. En su lugar, expone una Interfaz de Ejecución. El Agente envía un Módulo WebAssembly (.wasm) completamente dinámico que contiene la lógica requerida para su tarea.

​

Cómo funciona:

• El Agente compila su razonamiento (ej., “Encontrar todos los logs de error con la IP 192.168.1.1 y agruparlos”) en un binario WASM multiplataforma.
• El Servidor LIOP recibe este bloque inyectado vía gRPC.
• En lugar de ejecutarlo nativamente, el Servidor levanta un WASI Sandbox efímero e inyecta el módulo WASM en él.
• Escalabilidad y Concurrencia: Tanto el backend en Rust como el SDK en TS aprovechan modelos de hilos avanzados (Native OS Threads y piscina en Node.js) para procesar miles de sandboxes concurrentemente.

Esto proporciona amplia flexibilidad analítica sin requerir que el administrador del servidor escriba continuamente nuevos endpoints.

​

2. Capacidades (Los Recursos)

Las Capacidades aplican límites de seguridad mediante un modelo estricto basado en capacidades. Por defecto, un módulo WASM en ejecución opera sin privilegios ni acceso implícito al sistema:

• Sin lectura/escritura en el sistema de archivos local.
• Sin acceso a sockets de red.
• Sin variables de entorno del host.
• Sin acceso al reloj del sistema.

​

Asignación de Permisos

Cuando un Agente envía un Módulo, debe especificar las Capacidades que requiere para funcionar. El Servidor verifica estas peticiones contra su manifiesto. Si se aprueban, el Servidor mapea dinámicamente los recursos específicos directamente en el espacio de memoria del Sandbox.

Por ejemplo, una Capacidad podría ser: READ_ONLY_ACCESS: /var/logs/nginx/. El módulo WASM puede leer los logs dentro de los límites asignados de memoria. Si el código intenta acceder a rutas no autorizadas (como /etc/passwd), el motor Wasmtime dispara un WASI Trap e interrumpe la ejecución de inmediato.

​

3. Watchdogs (Eventos Asíncronos Persistentes)

Una de las características más potentes de LIOP son los Watchdogs, que superan el concepto de prompts simples o polling manual.

Las aplicaciones de IA a menudo necesitan monitorear un servidor (ej., “Avísame cuando el uso de CPU exceda el 90%”). En HTTP/REST, la IA debe enviar peticiones manuales cada 5 segundos, desperdiciando ancho de banda y tokens.

La arquitectura push de LIOP soluciona esto:

• El Agente inyecta un Módulo WASM Watchdog en el Nodo de Datos.
• El Servidor lo procesa y lo deja “dormir” en un hilo de fondo pasivo de bajos recursos.
• El módulo WASM se conecta localmente a los flujos del sistema.
• En el momento en que se cumple la condición, el módulo WASM se despierta y empuja un evento asíncrono directamente a través de la conexión multiplexada abierta de vuelta al Agente.

​

4. Confianza y Evidencia (Entorno de Ejecución Seguro TEE)

En entornos corporativos de alta seguridad (Tier-0), el Servidor LIOP evoluciona más allá del sandboxing a nivel de sistema operativo. El servidor proporciona evidencia criptográfica y física utilizando un TEE (Trusted Execution Environment) Sandbox.

El pipeline de ejecución TEE procesa lógica foránea bajo asunciones de cero-confianza:

​

1. Host Bounds & Checks (Guardian AST y Egress Filter)

Antes de que la lógica toque el motor de ejecución, el interceptor del Host descifra el payload. El Guardian AST Sentinel analiza el Árbol de Sintaxis Abstracta del WebAssembly. Si detecta intentos de importación no autorizados, el payload se descarta antes de su ejecución. Tras la ejecución, un Filtro de Egreso (Egress Filter) analiza matemáticamente el buffer de salida para prevenir la fuga de datos confidenciales o PII antes de su transmisión.

​

2. Hardware Isolated Enclave (TEE)

La computación central se ejecuta en un Enclave de Hardware físico (como AWS Nitro Enclaves o Intel SGX). Esto garantiza la Computación Ciega: la memoria RAM del host está cifrada por hardware, impidiendo que administradores del sistema o proveedores cloud inspeccionen la memoria durante el procesamiento.

​

3. Motor de Ejecución y Monitor de Combustible

Dentro del sandbox, el motor arranca el contexto WASI. Dado que WebAssembly es Turing Completo, podría ejecutar bucles no controlados. El Monitor de Combustible (Fuel Monitor) defiende contra esto consumiendo unidades de combustible por instrucción; si el límite se agota, el motor aborta la ejecución para prevenir ataques de denegación de servicio.

​

4. ZK Prover (Certeza Matemática)

Cuando el módulo termina su salida, el resultado pasa al Zero-Knowledge Prover. Este módulo genera un Recibo criptográfico verificable. El paquete devuelto prueba de forma determinista al Agente que la lógica solicitada se ejecutó sin alteraciones por parte del nodo.

​

5. Servidor TypeScript y MCP Bridge (El Nodo SDK)

Mientras que el plano de datos en Rust gestiona el sandboxing de alta exigencia, el ecosistema LIOP también proporciona una implementación completa de servidor en TypeScript (@nekzus/liop).

Este servidor actúa como una capa de adopción rápida para desarrolladores de Node.js.

​

Cómo el Bridge maneja Clientes MCP Heredados:

1. Intercepción JSON-RPC: Las herramientas heredadas envían peticiones JSON-RPC 2.0 estándar.
2. LiopMcpBridge Adapter: El SDK intercepta estos payloads y los traduce internamente. También expone los endpoints de recursos, permitiendo el descubrimiento de esquemas de datos para modelos de lenguaje.
3. Validación Zod en LiopServer: Antes de la ejecución, el LiopServer impone validaciones estrictas de esquema Zod en el hilo principal.
4. Respuesta Transparente: El resultado se devuelve formateado como un bloque estándar de MCP.

Esto permite a los desarrolladores adoptar el protocolo e integrar sus herramientas existentes en la red LIOP sin necesidad de modificar su código base.

​

6. Seguridad Avanzada y Diccionario de Datos

Para asegurar el mayor nivel de Autonomía Zero-Shot, los Servidores LIOP proporcionan metadatos sobre sus estructuras internas.

​

Diccionario de Datos (Anti-Hallucination)

Cuando un Agente ejecuta lógica foránea, podría “alucinar” campos que no existen. Para prevenir esto, los desarrolladores deben usar el método dataDictionary:

server.dataDictionary({
  id: "string (Anonymized PII)",
  age: "number",
  condition: "string (Healthy, Hypertension...)"
});

El motor del SDK inyectará automáticamente este esquema directamente en el System Prompt maestro (liop_blind_analyst), forzando a la IA a adoptar una política de Adherencia Estricta al Esquema.

​

Inyección de Datos en el Sandbox

Mientras que el diccionario enseña al Agente cómo se ven los datos, debes inyectar los datos reales dentro del sandbox para su procesamiento local.

Utiliza el método setSandboxData para cargar tu contexto en la memoria protegida del servidor:

const records = await db.fetchPatients();
server.setSandboxData(records); // Expuesto como 'env' dentro del Sandbox

​

Claves Prohibidas (PII Forbidden Keys)

Es posible restringir campos específicos para que nunca abandonen el servidor. Pase el array forbiddenKeys durante la instanciación:

const server = new LiopServer({
  security: {
    forbiddenKeys: ["id", "ssn", "password", "email"]
  }
});

El Filtro de Egreso escaneará cada objeto devuelto y bloqueará cualquier clave que coincida con estos términos prohibidos.

​

Claves Sensibles y Presupuesto Estratificado (NIST SP 800-226)

Para proteger campos críticos del dominio (como saldos bancarios o diagnósticos médicos) sin bloquear su salida de forma absoluta como ocurre con las claves prohibidas, puedes clasificarlos como Claves Sensibles (Sensitive Keys).

LIOP impone automáticamente un Presupuesto de Consultas de 3 Tiers por cliente en cada sesión:

• Tier Prohibido (3 consultas/sesión): Se aplica a todos los campos declarados en forbiddenKeys.
• Tier Sensible (8 consultas/sesión): Se aplica a todos los campos declarados en sensitiveKeys.
• Tier Público (25 consultas/sesión): Se aplica a cualquier otro campo no clasificado que sea consultado.

Puedes declarar claves sensibles de manera global a nivel de servidor, o localmente en el registro de cada herramienta:

​

Configuración Global del Servidor

const server = new LiopServer(
  { name: "financial-vault", version: "1.0.0" },
  {
    security: {
      forbiddenKeys: ["ssn"],
      sensitiveKeys: ["balance"] // Claves sensibles globales
    }
  }
);

​

Configuración a Nivel de Herramienta (Tool-Level)

Puedes añadir claves sensibles adicionales al registrar una herramienta específica. El servidor fusionará estas claves dinámicamente con la lista global:

server.tool(
  "analyze_transactions",
  "Analiza transacciones de cuentas",
  { payload: z.string() },
  async (args) => { ... },
  {
    enforceAggregationFirst: true,
    sensitiveKeys: ["accountType"] // Fusionado con la clave global 'balance'
  }
);

​

Presupuesto Uniforme Heredado (Legacy)

Si necesitas mantener límites uniformes para todos los campos por compatibilidad con sistemas anteriores en lugar del presupuesto estratificado, define queryBudgetPerField en las opciones de la herramienta:

server.tool(
  "legacy_analyzer",
  "Analiza registros heredados",
  { payload: z.string() },
  async (args) => { ... },
  {
    enforceAggregationFirst: true,
    queryBudgetPerField: 5 // Límite uniforme: exactamente 5 consultas para cualquier campo
  }
);

​

Persistencia del Presupuesto (budgetStorePath)

Para persistir y compartir los presupuestos de consultas a través de reinicios del servidor y múltiples procesos en ejecución, configure la propiedad budgetStorePath. Esta propiedad se puede definir de manera global en el constructor de LiopServer, o localmente dentro de la política de una herramienta específica:

import path from "path";

// 1. Configuración de Persistencia Global
const server = new LiopServer(
  { name: "financial-vault", version: "1.0.0" },
  {
    budgetStorePath: path.join(__dirname, "../data/query-budgets.json"),
    security: {
      sensitiveKeys: ["balance"]
    }
  }
);

// 2. Sobrescritura de Persistencia a Nivel de Herramienta
server.tool(
  "analyze_records",
  "Analiza registros de base de datos de forma segura",
  { payload: z.string() },
  async (args) => { /* ... */ },
  {
    enforceAggregationFirst: true,
    budgetStorePath: path.join(__dirname, "../data/tool-specific-budgets.json")
  }
);

Autogeneración de Directorios y Base de Datos

• Creación Automática de Directorios: El SDK detecta automáticamente si las carpetas contenedoras de la ruta budgetStorePath no existen y las crea recursivamente (mediante fs.mkdirSync(..., { recursive: true })) durante la primera escritura.
• Estructura Jerárquica del JSON: El archivo se inicializa de forma automática como una base de datos estructurada en un esquema JSON de 3 niveles que rastrea clientId (o agentDid), el nombre de la herramienta (toolName), y el contador del campo (field) consultado:

{
  "mcp-client": {
    "analyze_records": {
      "ssn": 2,
      "balance": 5
    }
  }
}

El bloqueo atómico de archivos (.lock) se gestiona automáticamente bajo el capó para sincronizar las escrituras concurrentes. Si la escritura en disco falla por falta de permisos o bloqueos persistentes, el motor realiza un fallback silencioso al rastreo de presupuestos en memoria aislado por sesión.

Vinculación de Identidad de Cliente y Restablecimiento de Presupuestos (Anti-Bypass)

• Anclaje de Identidad Persistente: Los límites de presupuesto están vinculados a la identidad criptográfica persistente del cliente (agentDid derivado de su PeerID Ed25519 o clientId de los JSON Web Tokens de OAuth 2.1) en lugar de tokens de transporte efímeros (como el session_token de gRPC). Esto evita que clientes maliciosos omitan sus presupuestos de consulta simplemente reconectándose o negociando nuevos intents de gRPC.
• Restablecimiento del Presupuesto mediante Rotación de Sesión PQC: Para clientes legítimos o entornos sin persistencia basada en archivos, el presupuesto de la sesión se puede restablecer iniciando un nuevo handshake efímero de ML-KEM-768 (Kyber), el cual rota las claves de sesión post-cuánticas. Si el presupuesto se agota y no hay persistencia configurada, el SDK devuelve un error explícito: Rotate PQC session to reset budget.

​

Política de Privacidad Diferencial

Para datasets por debajo del dpSmallDatasetThreshold (por defecto: 50 registros), el servidor aplica automáticamente ruido Laplace calibrado a todas las salidas numéricas. Configure el perfil de privacidad en la política a nivel de herramienta al registrarla:

server.tool(
  "analyze_records",
  "Analiza registros de base de datos de forma segura",
  { payload: z.string() },
  async (args) => {
    // implementación del manejador
  },
  {
    enforceAggregationFirst: true,
    dpEpsilon: 2.0,                  // Presupuesto de privacidad (mayor = menos ruido)
    dpSensitivity: 1000.0,           // Cambio máximo por registro para campos SUM
    dpSmallDatasetThreshold: 50      // Aplica ruido solo cuando el dataset < este umbral
  }
);

El motor deriva automáticamente la sensibilidad por campo basándose en el nombre de la clave:

• Claves de conteo (count, length, size, num): sensibilidad = 1
• Claves de promedio (avg, mean): sensibilidad = dpSensitivity / recordCount
• Claves de suma/otras: sensibilidad = dpSensitivity

Referencia industrial para calibración de ε:

Dominio	ε	Referencia
Salud (HIPAA)	2.0	Apple Health Data
Finanzas (SOX/PCI)	2.0	Directrices PET del DOJ
Datos Públicos	4.0 a 8.0	US Census, Google RAPPOR

Consulte Seguridad Zero-Trust: Motor de Privacidad Diferencial para la especificación técnica detallada.

​

Estructura Dinámica de Retorno (Localización de Datos en Origen)

Especificación en Hoja de Ruta. La Estructura Dinámica de Retorno está programada para una versión futura del protocolo y aún no está disponible en el runtime activo del SDK.

Cuando un Nodo de Datos registra sus capacidades, incrusta una directiva estructural dentro del payload (DYNAMIC RETURN STRUCTURE). Esto instruye al agente ejecutor a generar esquemas JSON con claves mapeadas al idioma detectado en la consulta inicial del usuario.

• Si el usuario consulta “¿Cuántos pacientes tienen hipertensión?”, el Nodo devuelve una respuesta con claves en español (como {"cantidad": 25, "edad_promedio": 45}).
• Esto elimina la necesidad de capas cliente de internacionalización (i18n), resolviendo la taxonomía de los datos en el Origen sin requerir re-traducción de prompts.