# Seguridad

## Descripcion General

Neotask esta disenado con una arquitectura de seguridad primero. El Gateway se vincula a localhost por defecto, todos los datos sensibles se encriptan en reposo y la ejecucion de agentes puede aislarse en contenedores sandbox.

## Seguridad de Red

### Loopback por Defecto

El Gateway solo escucha en `127.0.0.1` (localhost) a menos que cambie explicitamente el modo de vinculacion. Sin exposicion de red externa por defecto.

### Autenticacion

Todas las conexiones WebSocket requieren autenticacion:

- **Autenticacion por token** -- Token bearer (UUID o cadena personalizada)
- **Autenticacion por contrasena** -- Contrasena con hash bcrypt
- **Proxy de confianza** -- Headers pre-autenticados de proxies inversos
- **Confianza local** -- Las conexiones loopback se confian implicitamente

### Seguridad de Acceso Remoto

Para acceso remoto, el enfoque recomendado es **VPN Tailscale** o **tunel SSH** -- nunca exponga el Gateway directamente a internet.

## Emparejamiento de Dispositivos

### Como Funciona el Emparejamiento

Todo cliente que se conecta al Gateway debe ser emparejado:

1. El dispositivo presenta su identidad (huella digital + clave publica)
2. El Gateway emite un desafio de emparejamiento (nonce)
3. El dispositivo firma el nonce con su clave privada
4. Usted aprueba el dispositivo a traves de la interfaz
5. El Gateway emite un token de dispositivo para futuras conexiones

### Modelo de Confianza

- **Dispositivos locales** (loopback) se aprueban automaticamente por conveniencia
- **Dispositivos no locales** requieren aprobacion explicita
- Los tokens de dispositivo se almacenan localmente y se reutilizan al reconectar
- Los dispositivos pueden revocarse en cualquier momento

## Encriptacion

### Datos en Reposo

- **AES-256-GCM** -- Todos los tokens, secretos y claves API se encriptan en reposo
- **Claves derivadas de la maquina** -- Claves de encriptacion derivadas via scrypt de la identidad del dispositivo
- **Sin almacenamiento en texto plano** -- Los tokens nunca se almacenan en texto plano

### Datos en Transito

- **TLS** -- HTTPS para comunicacion API
- **WSS** -- WebSocket Secure para conexiones al Gateway (cuando se usa Tailscale Serve o proxy inverso)
- **Firma HMAC** -- Integridad de solicitud con nonce y marca de tiempo

## Sandboxing

### Aislamiento Basado en Docker

La ejecucion de comandos de agentes puede aislarse en contenedores Docker:

- **Perfiles por agente** -- Cada agente puede tener su propia configuracion de sandbox
- **Limites de recursos** -- Limites configurables de CPU, memoria y tiempo de espera
- **Aislamiento de red** -- Los contenedores pueden aislarse de la red
- **Confinamiento del sistema de archivos** -- Los agentes solo acceden a su espacio de trabajo
- **Imagenes personalizadas** -- Use imagenes pre-construidas con herramientas especificas instaladas

### Alcances de Sandbox

| Alcance | Descripcion |
|-------|-------------|
| **Por sesion** | Contenedor nuevo para cada sesion |
| **Por agente** | Contenedor persistente por agente |
| **Compartido** | Contenedor compartido entre agentes |

### Acceso al Espacio de Trabajo

Los agentes en sandbox pueden acceder a su directorio de espacio de trabajo (montado en el contenedor) pero no pueden acceder al sistema de archivos del host fuera de su espacio de trabajo.

## Aprobaciones de Ejecucion

Controle que comandos pueden ejecutar los agentes en nodos y en el host del Gateway:

### Modos

| Modo | Descripcion |
|------|-------------|
| **Allowlist** | Solo se ejecutan comandos pre-aprobados |
| **Ask** | Los comandos desconocidos solicitan aprobacion del usuario |
| **Full** | Sin restricciones (usar con precaucion) |

### Configuracion por Nodo

Cada nodo (macOS, host headless) tiene su propia configuracion de aprobacion de ejecucion, almacenada localmente. Puede permitir binarios especificos (por ejemplo, `/usr/bin/docker`, `/usr/local/bin/terraform`) mientras bloquea todo lo demas.

## Modo Elevado

Algunas operaciones requieren ejecutarse directamente en el host del Gateway (no en un sandbox). El modo elevado esta:

- Controlado por permiso explicito en la configuracion del agente
- Solo disponible en el host del Gateway
- Deshabilitado por defecto
- Auditable a traves de logging

## Auditoria de Seguridad

La auditoria de seguridad integrada verifica:

- Permisos de archivos de configuracion (deben ser 600)
- Permisos de archivos de sesion
- Version de Node.js (parches de seguridad)
- Deteccion de secretos en texto plano
- Validacion de lista de permitidos de plugins
- Auditoria de interfaces de red abiertas
- Completitud de la configuracion de autenticacion

La auditoria puede corregir automaticamente muchos problemas cuando se le da permiso.

## Mejores Practicas

1. **Mantenga el Gateway en loopback** -- Use Tailscale o SSH para acceso remoto
2. **Habilite sandboxing** -- Ejecute comandos de agentes en contenedores Docker
3. **Use listas de permitidos de ejecucion** -- Restrinja que comandos pueden ejecutar los agentes en nodos
4. **Establezca tokens de autenticacion** -- Siempre configure autenticacion por token, incluso para loopback
5. **Revise permisos de agentes** -- Use perfiles de herramientas minimos donde sea posible
6. **Mantenga Neotask actualizado** -- Las actualizaciones incluyen parches de seguridad
7. **Audite regularmente** -- Ejecute auditorias de seguridad para detectar configuraciones incorrectas
8. **Restrinja la carga de plugins** -- Solo instale plugins de confianza