Inmersión Profunda en la Arquitectura de NemoClaw

Inmersión Profunda en la Arquitectura de NemoClaw

NemoClaw no es un producto único — es una arquitectura de seguridad por capas diseñada para hacer que los agentes de IA autónomos sean seguros para el despliegue en producción. Este artículo recorre cada capa, explica cómo interactúan y proporciona el contexto técnico necesario para evaluar NemoClaw en tu propia infraestructura.

Visión General de la Arquitectura

El stack de NemoClaw consta de cuatro capas principales, cada una abordando una dimensión diferente de la seguridad de los agentes:

┌─────────────────────────────────────────────┐
│              Agent Application               │
│         (OpenClaw Agent Framework)           │
├─────────────────────────────────────────────┤
│             Privacy Router                    │
│    (Local vs. Cloud Model Routing)           │
├─────────────────────────────────────────────┤
│           Nemotron Policy Engine              │
│    (120B MoE Intent Classification)          │
├─────────────────────────────────────────────┤
│             OpenShell Runtime                 │
│    (Kernel-Level Sandbox + Isolation)        │
├─────────────────────────────────────────────┤
│          Host OS / Hardware (DGX)             │
└─────────────────────────────────────────────┘

Cada capa opera de forma independiente y puede desplegarse de manera autónoma, pero el stack completo proporciona seguridad en profundidad que ninguna capa individual puede lograr por sí sola.

Capa 1: Entorno de Ejecución de Seguridad OpenShell

OpenShell es la base del modelo de seguridad de NemoClaw. Proporciona sandboxing a nivel de kernel para la ejecución de agentes, asegurando que incluso un agente comprometido no pueda escapar de su límite de seguridad.

Cómo Funciona OpenShell

OpenShell utiliza una combinación de espacios de nombres del kernel de Linux, filtros seccomp-BPF y programas eBPF personalizados de NVIDIA para crear entornos de ejecución aislados para cada tarea del agente:

# openshell-policy.yaml
apiVersion: openshell.nvidia.com/v1
kind: SandboxPolicy
metadata:
  name: customer-support-agent
spec:
  isolation:
    network: restricted
    filesystem: read-only
    syscalls: minimal
  resources:
    maxMemory: 4Gi
    maxCPU: 2
    gpuAccess: inference-only
  permissions:
    allowedAPIs:
      - crm.read
      - crm.update
      - ticket.create
      - ticket.resolve
    deniedAPIs:
      - admin.*
      - billing.*
      - user.delete
  auditLog:
    enabled: true
    destination: siem://security-events

Cada llamada al sistema realizada por el agente es interceptada por la capa eBPF de OpenShell, clasificada según la política y luego permitida, denegada o escalada para aprobación humana. Todo el proceso de decisión se ejecuta en el espacio del kernel, añadiendo menos de 50 microsegundos de latencia por llamada al sistema.

Flujos de Aprobación del Operador

Para operaciones de alto riesgo — eliminar datos, modificar infraestructura, enviar comunicaciones externas — OpenShell puede pausar la ejecución del agente y enrutar la acción a un operador humano para su aprobación:

// Approval workflow configuration
const approvalPolicy = {
  triggers: [
    { action: 'data.delete', threshold: 'always' },
    { action: 'infra.modify', threshold: 'always' },
    { action: 'email.send', threshold: 'external-only' },
    { action: 'payment.process', threshold: 'above-100-usd' },
  ],
  channels: ['slack', 'teams', 'pagerduty'],
  timeout: '15m',
  defaultAction: 'deny',
};

Esto asegura que los agentes puedan operar de forma autónoma en tareas rutinarias mientras se mantiene la supervisión humana para acciones consecuentes.

Capa 2: Motor de Políticas Nemotron 120B MoE

El modelo Nemotron 120B Mixture-of-Experts sirve como el motor inteligente de evaluación de políticas de NemoClaw. A diferencia de los sistemas de seguridad tradicionales basados en reglas, Nemotron puede comprender la intención detrás de las acciones del agente y evaluarlas según políticas de seguridad expresadas en lenguaje natural.

Clasificación de Intenciones

Cuando un agente solicita una acción, Nemotron clasifica la intención a través de múltiples dimensiones:

• •Sensibilidad: ¿Cuán sensibles son los datos involucrados? (público, interno, confidencial, restringido)
• •Reversibilidad: ¿Se puede deshacer esta acción? (totalmente reversible, parcialmente reversible, irreversible)
• •Alcance: ¿Cuántos sistemas o usuarios se ven afectados? (individual, equipo, organización, externo)
• •Cumplimiento: ¿Esta acción cae bajo algún marco regulatorio? (GDPR, HIPAA, SOC 2, PCI-DSS)

La clasificación se ejecuta en menos de 200ms en una sola GPU A100 y en menos de 50ms en un DGX Spark con la variante del modelo cuantizado.

Políticas en Lenguaje Natural

Los equipos de seguridad pueden definir políticas en español (o inglés) llano, que Nemotron interpreta y aplica:

Policy: "Customer support agents may access customer records for active tickets only.
         They may not access financial data, modify account settings, or communicate
         with customers outside of the ticketing system. All PII must be redacted
         from internal logs."

Nemotron convierte estas políticas en lenguaje natural en reglas de seguridad ejecutables, cerrando la brecha entre la intención del equipo de seguridad y la aplicación técnica.

Capa 3: Privacy Router

El Privacy Router es la capa inteligente de enrutamiento de modelos de NemoClaw. Determina si cada tarea del agente debe ser procesada por un modelo local (Nemotron ejecutándose en las instalaciones) o enrutada a un endpoint de modelo en la nube, según la clasificación de sensibilidad de los datos.

Lógica de Enrutamiento

# Simplified Privacy Router logic
def route_request(request: AgentRequest) -> ModelEndpoint:
    sensitivity = classify_sensitivity(request.context)

    if sensitivity in ['restricted', 'confidential']:
        # Highly sensitive data stays local
        return local_nemotron_endpoint

    if sensitivity == 'internal':
        # Internal data can use cloud with encryption
        return cloud_endpoint_with_e2e_encryption

    if sensitivity == 'public':
        # Public data can use any endpoint for best performance
        return optimal_cloud_endpoint

    # Default: local processing
    return local_nemotron_endpoint

El Privacy Router mantiene una caché de clasificación en tiempo real, de modo que las solicitudes repetidas con contexto similar se enrutan sin reevaluación. En las pruebas de rendimiento, el enrutador añade menos de 5ms de latencia al flujo de solicitudes.

Cumplimiento de Residencia de Datos

Para organizaciones que operan bajo requisitos de residencia de datos (GDPR de la UE, PIPL de China, etc.), el Privacy Router puede aplicar restricciones de enrutamiento geográfico:

privacyRouter:
  residencyRules:
    - region: EU
      dataTypes: [personalData, financialData]
      allowedEndpoints: [eu-west-1-local, eu-central-1-local]
    - region: CN
      dataTypes: [all]
      allowedEndpoints: [cn-north-1-local]
  fallback: local-only

Capa 4: Motor de Políticas de Red

El Motor de Políticas de Red controla a qué recursos externos puede acceder un agente. Opera como un proxy transparente, inspeccionando y filtrando todas las solicitudes de red salientes desde los sandboxes de los agentes.

Definición de Políticas

networkPolicy:
  name: sales-ops-agent
  egress:
    allow:
      - domain: "*.salesforce.com"
        methods: [GET, POST, PATCH]
      - domain: "api.hubspot.com"
        methods: [GET]
      - domain: "smtp.company.com"
        ports: [587]
    deny:
      - domain: "*"  # deny all other outbound traffic
  ingress:
    allow:
      - source: "webhook.salesforce.com"
        path: "/api/v1/events"
  inspection:
    tlsDecrypt: true
    logPayloads: false
    scanForPII: true

El Motor de Políticas de Red soporta la interceptación TLS para solicitudes salientes (con gestión adecuada de certificados), lo que permite escanear los payloads de las solicitudes en busca de fugas accidentales de PII.

Uniendo Todo

Cuando un agente de OpenClaw recibe una tarea, la solicitud fluye a través del stack de NemoClaw de la siguiente manera:

1. 1.OpenClaw recibe la tarea y construye un plan de ejecución
2. 2.Privacy Router clasifica la sensibilidad de los datos y selecciona el endpoint de modelo apropiado
3. 3.Nemotron evalúa el plan de ejecución contra las políticas de seguridad y clasifica la intención
4. 4.OpenShell crea un sandbox aislado para la ejecución de la tarea
5. 5.Motor de Políticas de Red configura el acceso a la red del sandbox según el rol del agente
6. 6.El agente se ejecuta dentro del sandbox, con cada acción auditada
7. 7.Las acciones de alto riesgo se escalan a operadores humanos para su aprobación
8. 8.Los resultados se devuelven a través del Privacy Router, con PII redactado de los registros

Todo este flujo añade aproximadamente 300ms de latencia a la primera solicitud de una sesión, y menos de 100ms para las solicitudes posteriores (gracias al almacenamiento en caché). Para la mayoría de las cargas de trabajo empresariales, esta sobrecarga es despreciable en comparación con el tiempo de inferencia del modelo.

Pruebas de Rendimiento

En un solo DGX Spark:

En un clúster DGX H100 (8 GPUs):

Primeros Pasos

La documentación de la arquitectura de NemoClaw está disponible en GitHub en nvidia/nemoclaw. Cada capa puede desplegarse de forma independiente, por lo que puedes adoptar NemoClaw de manera incremental — comenzando con el sandboxing de OpenShell y añadiendo las demás capas a medida que evolucionen tus requisitos de seguridad.

En el próximo artículo, recorreremos un tutorial práctico para desplegar el stack completo de NemoClaw en un DGX Spark.