Principios de seguridad

El modelo de seguridad del lab: qué protegemos, qué no, los trust boundaries, el threat model y los principios que guían las decisiones.

Propósito

Esta página es la referencia canónica del modelo de seguridad del lab. Documenta:

Los assets que protege el lab.
Las amenazas contra las que se defiende el lab.
Los trust boundaries que enforce el lab.
Los principios que guían las decisiones de seguridad.
Las prácticas que sigue el lab.

La capa de auditoría está documentada en Modelo de auditoría. Las decisiones están en Decisiones de arquitectura.

Qué protegemos

El lab protege:

Datos del usuario. Los ficheros, proyectos, notas y contexto personal del usuario.
Credenciales. API keys, tokens, passwords y cualquier otro secreto que use el lab.
Artefactos de research. Los reports, el estado de misión y el audit trail.
Configuración. Los ficheros de configuración del framework y la configuración del proyecto.
El propio lab. La integridad del framework, los agentes y las herramientas.

El lab NO protege:

La seguridad general de la máquina del usuario (el usuario es responsable del OS, el firewall, los backups).
La seguridad de los providers externos (fuera de scope).
La seguridad física del hardware (fuera de scope).

Qué no protegemos

Algunos assets están fuera de scope:

Outputs generados. Los outputs del Media Lab Server no están cifrados ni respaldados por defecto. El usuario es responsable de respaldarlos si le importa.
Media descargado. El torrent-finder y herramientas similares descargan contenido a un directorio público. El usuario es responsable de las implicaciones legales y éticas.
Estado en memoria. El session state no está cifrado en memoria. Un dump del proceso podría exponerlo.
Tráfico de red. El lab no cifra el tráfico a dispositivos locales. Un usuario en la misma LAN podría sniffear el tráfico.

El lab documenta estas limitaciones pero no intenta abordarlas. El threat model las excluye.

Threat Model

El threat model del lab considera:

Actor de amenaza	Capacidad	Probabilidad	Impacto	Mitigación
Usuario curioso en la LAN	Network sniffing	Low	Low	Servicios solo locales; sin puertos expuestos.
Extensión de browser comprometida	Leer contenido de página	Medium	Medium	El Web Agent no loguea el contenido de página.
Provider de modelo comprometido	Leer prompts	Low	High	Sin secretos en prompts; mínimos datos personales.
Provider de search comprometido	Leer queries	Low	Low	Sin PII en las queries.
Servicio de streaming comprometido	Leer playback	Low	Low	Sin datos de usuario en requests de playback.
Sandbox del sub-agent comprometida	Escapar del sandbox	Low	Critical	Sandbox estricto; prompts revisados.
Proceso local comprometido	Leer memoria, ficheros	Low	Critical	Permisos de filesystem; aislamiento de procesos.
Backup comprometido	Leer datos del usuario	Low	High	Backups cifrados (responsabilidad del usuario).
Request maliciosa del usuario	Bypass safeguards	Medium	High	Autorización del usuario para operaciones de alto riesgo.
Prompt injection en datos del usuario	Hijack del agente	Medium	High	Sanitización; I/O estructurado de herramientas.
Ataque de resource exhaustion	DoS al modelo	Low	Medium	Tracking de quota; rate limits.
Replay attack en la API	Replay de una request	Low	Low	Sin estado sensible en las requests.
Drift de configuración	Misconfig sutil	Medium	High	Review de configuración; auditoría.

El lab no tiene un documento de threat model formal. Esta tabla es el modelo de facto.

Trust Boundaries

El lab tiene los siguientes trust boundaries:

Boundary	Trust en el interior	Trust en el exterior	Enforcement
Coordinator ↔ Usuario	El usuario	El Coordinator	Sesión autenticada, sanitización de input del usuario.
Coordinator ↔ Scout	El Coordinator	El Scout	HTTP local; sin exposición externa.
Coordinator ↔ Coding sub-agent	El Coordinator	El sub-agent	Sandbox; prompts scoped.
Coordinator ↔ Web Agent	El Coordinator	El browser	Perfil de browser aislado.
Scout ↔ Providers externos	El Scout	Los providers	Token pool; request journal.
Media Lab Server ↔ Público	El Server	El público	Bind solo local (`127.0.0.1`).
Sub-agent ↔ Project workspace	El sub-agent	El sandbox	Modo `workspace-write`.
Memory layer ↔ Resto del sistema	El memory layer	Todo lo demás	Permisos de filesystem.

Los boundaries los enforcen:

Aislamiento de procesos. Cada gateway corre en un proceso separado.
Aislamiento de red. Servicios solo locales; sin puertos expuestos.
Sandboxing. El coding sub-agent corre en un sandbox.
Permisos de filesystem. Los directorios sensibles son solo del owner.
Configuración. La configuración del framework declara los boundaries.

Una violación de boundary es un bug. La capa de auditoría registra violaciones y el operator las revisa.

Las decisiones de seguridad del lab se guían por estos principios.

1. La documentación es un deliverable

Cada proyecto debe tener documentación. La documentación incluye una sección de seguridad (si el proyecto tiene alguna implicación de seguridad). Un proyecto sin documentación está incompleto.

Esto está documentado como regla hard en Decisiones de arquitectura → ADR-009.

2. El Coding Assistant nunca escribe código directamente

El Coding Assistant delega toda la escritura de código a un sub-agent sandboxed. El Assistant revisa el código, lo integra y lo testea. El Assistant nunca escribe código a mano.

Esto está documentado como regla hard en ADR-002.

3. El main agent y los specialized agents están aislados

El Coordinator y los specialized agents corren en procesos separados. Se comunican a través de interfaces definidas. No comparten memoria ni ficheros excepto a través de la capa de artefactos.

Esto está documentado como regla hard en ADR-001.

4. Los secretos nunca se loguean

API keys, tokens, passwords y otros secretos nunca se escriben a logs, journals o artefactos. La capa de logging del framework redacta secretos. La capa de auditoría verifica que los secretos no se filtran.

5. El usuario autoriza las operaciones de alto riesgo

Algunas operaciones son de alto riesgo (enviar un email, modificar un sistema de producción, exponer un servicio). El usuario las autoriza explícitamente. El Coordinator surface la request de autorización y espera la respuesta del usuario.

6. El sistema falla en cerrado

Cuando un componente falla, el default es detener la operación, no continuar. Un fallo en el coding sub-agent detiene al Coding Assistant. Un fallo en una fase de research detiene la misión. El usuario decide si reintentar.

7. El sistema es auditable

Cada request, cada response, cada llamada externa, cada cambio de configuración se registra. El audit trail es la base del modelo de seguridad del lab.

8. El sistema es recuperable

Una misión fallida se puede reanudar. Un gateway con crash se puede reiniciar. Un artefacto corrupto se puede regenerar a partir de los inputs. El lab está diseñado para recuperarse del fallo, no para ser perfecto.

9. El usuario es el operator

El lab tiene un único usuario. El usuario es el operator. El usuario autoriza operaciones, revisa auditorías y toma decisiones de seguridad. El lab no tiene múltiples usuarios u operators.

10. La documentación refleja la realidad

La documentación del lab se actualiza para matchear el estado real del sistema. Una discrepancia entre la documentación y el sistema es un bug. La capa de auditoría marca las discrepancias.

Prácticas

El lab sigue estas prácticas de seguridad.

Autenticación

Los servicios locales no tienen autenticación. El usuario asume que la máquina local es de confianza.
Los servicios externos usan API keys o tokens. Las keys se almacenan en ficheros de configuración con permisos solo del owner.
El coding sub-agent usa OAuth o auth local según lo configure el framework.

Autorización

El usuario autoriza las operaciones de alto riesgo explícitamente. El Coordinator surface la request de autorización y espera la respuesta del usuario.
El sandbox del coding sub-agent se configura por proyecto. El default es workspace-write.
La capa de auditoría registra cada decisión de autorización.

Auditoría

Cada request se loguea. El Coordinator loguea la request y la response.
Cada llamada externa se registra en el request journal. El journal es append-only.
Cada cambio de configuración se registra en el audit log.
El audit log se revisa semanalmente.

Backup

Los datos críticos se respaldan diario. El usuario es responsable del destino del backup.
El backup está cifrado (el usuario escoge el cifrado).
El backup se verifica con un checksum.

Incident Response

Los incidentes los detecta el heartbeat, los health checks o el usuario.
Los incidentes los triage el usuario.
Los incidentes los contiene el usuario.
Los incidentes los mitiga siguiendo el runbook relevante.
Los incidentes los recupera el usuario.
Los incidentes se post-morteman en un documento bajo {workspace-root}/security/incidents/.

Configuration Management

La configuración está en ficheros, no en código.
Los cambios de configuración los revisa el usuario.
Los cambios de configuración se loguean en el audit log.
Los secretos están en variables de entorno o secret managers, no en ficheros de configuración.

Lo que el lab no hace

El lab no:

Opera sistemas de producción. El lab es un entorno personal de research y development.
Expone servicios a internet. El lab es local-first.
Maneja procesamiento de pagos. El lab no procesa pagos.
Maneja datos personales a escala. El lab maneja los datos personales del usuario, pero no a escala.
Prove autenticación multi-usuario. El lab tiene un único usuario.
Prove control de acceso basado en roles. El lab tiene un único rol.
Cifra datos en reposo. El usuario es responsable del full-disk encryption.
Cifra datos en tránsito a dispositivos locales. El usuario es responsable de la seguridad de la LAN.
Prove una certificación de seguridad formal. El lab no está certificado.

El scope del lab es intencionalmente limitado. Las limitaciones están documentadas para que el usuario sepa qué esperar.

Trabajo futuro de seguridad