Conceptos del Servidor

Entendiendo cómo un Nodo de Datos LIOP protege los recursos y ejecuta lógica

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 su propia lógica innovadora.

​

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 Industrial: 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 permite capacidades infinitas sin requerir que el administrador del servidor escriba constantemente nuevos endpoints de herramientas.

​

2. Capacidades (Los Recursos)

Si el servidor ejecuta código arbitrario vía WASM, ¿cómo es seguro? A través de la Seguridad Basada en Capacidades.

Las Capacidades son el equivalente LIOP a los “Recursos” de MCP, pero radicalmente más seguras. Por defecto, un módulo WASM en ejecución en LIOP tiene acceso cero absoluto a todo:

• 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.

​

Otorgando Acceso

When 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 ahora leer los logs a una velocidad asombrosa, pero si la lógica maliciosa intenta leer archivos no autorizados, el motor de Sandboxing disparará un WASI Trap inmediato, terminando instantáneamente la ejecución.

​

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 (Industrial TEE Execution Sandbox)

En entornos de Nivel-0 (Tier-0), el Servidor LIOP evoluciona más allá del sandboxing estándar. El servidor proporciona evidencia matemática 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 ilegal, el payload es purgado. Tras la ejecución, un Filtro Anti-Exfiltración (Egress Filter) analiza matemáticamente el buffer saliente para prevenir la fuga de PII antes de su transmisión.

​

2. Hardware Isolated Enclave (TEE)

La computación central se empuja a un Enclave de Hardware físico (como AWS Nitro Enclaves). Esto garantiza la Computación Ciega: la RAM del Host está encriptada por hardware, por lo que ni siquiera el administrador del sistema puede volcar la memoria para robar el razonamiento del Agente.

​

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 un bucle infinito por error o malicia. El Monitor de Combustible (Fuel Monitor) defiende contra esto; si el combustible se agota, el motor mata la ejecución.

​

4. ZK Prover (Certeza Matemática)

Cuando el .wasm termina, el resultado pasa al Zero-Knowledge Prover. Este módulo genera un Recibo matemático. El paquete devuelto prueba incondicionalmente al Agente que la lógica específica se ejecutó perfectamente y el resultado es íntegro.

​

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

Mientras que el plano de datos en Rust domina el sandboxing pesado, 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 impecablemente los endpoints de recursos, permitiendo el Descubrimiento Zero-Shot de esquemas de datos.
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 garantiza que los desarrolladores puedan adoptar inmediatamente el protocolo y servir sus herramientas existentes en la red LIOP con cero modificaciones de código.

​

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–8.0	US Census, Google RAPPOR

Consulte Seguridad Zero-Trust § Motor de Privacidad Diferencial para la inmersión técnica completa.

​

Estructura Dinámica de Retorno (Auto-i18n Nativo) [PLANIFICADO]

LIOP introduce un patrón arquitectónico donde la fricción por traducción no existe. Esta funcionalidad está en el roadmap.

Cuando un Nodo de Datos registra sus capacidades, incrusta una directiva estructural dentro del payload. Esto obliga al agente a generar esquemas JSON que utilizan llaves mapeadas al idioma exacto hablado por el usuario en el prompt.

• Si el usuario consulta “¿Cuántos pacientes tienen hipertensión?”, el Nodo recibe naturalmente una respuesta con taxonomía en Español (ej., {"cantidad": 25}).
• Esto elimina la necesidad de librerías de internacionalización, dejando la localización de datos directamente en el Origen de forma segura.