CH 28 · Seguridad y cumplimiento

Recuento de palabras~3,490 palabrasTiempo~20 minRequisitosCH 04NivelEnfoque conceptual

Objetivo del capítulo

Dejar que un Agent que puede ejecutar comandos y escribir archivos trabaje en tu ordenador — ¿te preocuparás: borrará mis archivos al azar? ¿Enviará mis claves en secreto? ¿Cambiará la configuración de mi sistema?

Estas preocupaciones son válidas — un Agent sin límites de seguridad es una bomba de relojería. La respuesta de dsh son tres capas de protección: sandbox de archivos, aprobación de operaciones, claves de solo escritura. CH 04 mencionó algunas al hablar del modelo de permisos; este capítulo aclara los principios de cada capa — cómo realmente mantiene al Agent a raya, cuáles son límites duros imposibles de saltar y cuáles necesitan tu propio juicio. Una vez entiendas esto, sabrás qué puedes delegar con seguridad y qué debes vigilar tú mismo.

Primero aclarar: el pensamiento de seguridad de dsh

El núcleo del diseño de seguridad de dsh son ocho caracteres: restringido por defecto, permitir bajo demanda.

No "dar todos los permisos primero y luego confiar en tu prudencia", sino al revés — por defecto solo puede tocar el alcance que explícitamente le permites, y para cruzar la línea debe obtener tu consentimiento. Esta es una mentalidad completamente diferente a "dale la contraseña de admin y deja que se arregle".

Tres capas de protección, de fuera hacia dentro:

Capa	Qué gestiona	Cómo
Capa 1: sandbox de archivos	A qué archivos puede tocar	Tres niveles de permiso, aislamiento a nivel de kernel del SO
Capa 2: aprobación de operaciones	Si las operaciones sensibles se pueden ejecutar	Ventana emergente pidiéndote, dices que no y no se ejecuta
Capa 3: claves de solo escritura	Cómo se almacenan las API Keys	Solo escritura, no se muestran en la UI, almacenamiento local no subido

Cada capa a continuación.

Capa uno: sandbox de archivos

CH 04 cubrió los tres niveles de permiso; aquí está el principio detrás de ellos.

El sandbox no es un fragmento de JavaScript haciendo una comprobación if — "si la ruta no está en el workspace, error". Ese tipo de enfoque el modelo puede saltarlo (p. ej. con saltos de ruta relativa, con symlinks). El sandbox de dsh es a nivel de kernel del SO: en Windows usa job objects para limitar los recursos a los que un proceso puede acceder, en Linux/macOS usa namespaces y seccomp para filtrar llamadas al sistema. No importa qué trucos use el modelo, si no puede pasar el kernel, no puede pasar.

Los tres niveles de permiso, de estricto a laxo:

Modo	Qué puede escribir	Para qué escenarios es
read-only	Nada	Análisis de solo lectura, code review, Q&A puro — que vea pero no cambie
workspace-write (por defecto)	Solo el directorio del workspace actual + directorio temporal del sistema	Trabajo diario — puede cambiar archivos del proyecto, no puede tocar el sistema ni otros proyectos
danger-full-access	Sin restricciones	Solo cuando claramente necesites operación de disco completo, p. ej. mantenimiento del sistema, instalar software — el riesgo es tuyo

Un punto que se suele pasar por alto: el sandbox solo gobierna los efectos secundarios del sistema de archivos, no el aislamiento de red ni de procesos. Eso significa, bajo el modo workspace-write, el Agent no puede escribir archivos fuera del workspace, pero sí puede hacer peticiones de red, puede leer archivos fuera del workspace (solo lectura). Así que no pienses que activar workspace-write es absolutamente seguro — puede enviar el contenido de archivos sensibles de tu workspace a través de peticiones API (un modelo normal no hará esto, pero es un límite teórico).

El cambio se cubrió en CH 04: temporalmente para la sesión actual usa /permission, para cambiar el por defecto ve a Settings → General → Permission (solo afecta a las sesiones recién creadas).

Capa dos: aprobación de operaciones

El sandbox mantiene a raya "a qué archivos puede tocar", la aprobación mantiene a raya "si las operaciones sensibles se pueden ejecutar".

Cuando el Agent quiere hacer algo más allá del alcance de permiso actual — p. ej. escribir un archivo fuera del workspace en modo workspace-write, o ejecutar un comando que pueda cambiar el sistema — no lo ejecuta directamente, sino que primero inicia una solicitud de aprobación, la interfaz muestra un diálogo que te dice:

• Qué operación quiere ejecutar (el comando específico o la ruta del archivo)
• Por qué quiere hacer esto (la razón del modelo)

Entonces tienes tres opciones: Permitir una vez, Denegar, Cancelar.

Marcador de posición de imagen: pon aquí una captura de "El Agent solicita escribir un archivo fuera del workspace, aparece el diálogo de aprobación" — puedes ver la operación, la razón del modelo, los botones permitir/denegar.

Algunos detalles clave:

1. Permitir una vez significa una vez — no "siempre permitido en el futuro". La próxima vez que aparezca la misma operación, preguntará de nuevo.
2. Denegar significa denegar — una vez que el modelo recibe la denegación, buscará otro camino o te dirá que no puede hacerlo, no se escabullirá.
3. La aprobación es un punto de extensión a nivel de plugin — CH 11 cubrió el pipeline de llamadas a herramientas, la aprobación es una etapa. Puedes escribir tu propio plugin para personalizar la política de aprobación, p. ej. "auto-permitir algunos comandos, auto-denegar otros".

La aprobación y el sandbox trabajan juntos: el sandbox es un límite duro (a nivel de kernel, no se puede saltar), la aprobación es un límite blando (a nivel de política, puede dejar pasar). El uso diario de workspace-write + ventana emergente de aprobación es el equilibrio de "seguro por defecto, permitir manualmente cuando sea necesario".

Capa tres: claves de solo escritura

La API Key es lo más sensible — si se pierde, otros pueden usar tu cuota, incluso usar tu identidad para llamar a las APIs. El tratamiento de dsh para las claves es solo escritura.

¿Qué significa solo escritura? Tras rellenar la API Key en Settings → Models y hacer clic en guardar, la Key en la interfaz "desaparece", dejando solo un descriptor redactado (p. ej. deepseek://sk-...x8f2). Nunca podrás leer la Key completa en texto plano desde la interfaz.

Esto no es un bug, es diseño deliberado:

• La Key en texto plano solo aterriza en el $DSH_HOME/.credentials.yaml local (en Windows: C:\Users\<tu-usuario>\.dsh\.credentials.yaml)
• La interfaz y settings.yaml solo almacenan una referencia (como el campo apiKeyEnv), no texto plano
• La memoria del navegador, los logs de red, el estado del front-end no expondrán secundariamente la Key completa

Marcador de posición de imagen: pon aquí una captura de "Página Settings → Models, la tarjeta de DeepSeek tras guardar solo muestra el descriptor redactado" — puedes ver que el campo de la clave se ha convertido al formato deepseek://sk-...xxxx.

Prioridad de la clave (de alta a baja):

1. Variable de entorno del proceso (export DEEPSEEK_API_KEY=sk-xxx)
2. Archivo $DSH_HOME/.credentials.yaml
3. Archivo .env del directorio del proyecto

La variable de entorno tiene la prioridad más alta, adecuada para uso temporal; el método de archivo es el más usado, adecuado para configuración a largo plazo.

Recordatorio de seguridad: el archivo .credentials.yaml tiene permisos 0600 (solo tú puedes leer/escribir), pero si haces backup de todo el directorio ~/.dsh en la nube o lo compartes con otros, las claves van con él. Ten cuidado de redactar al hacer backup.

Privacidad de datos

Además de las claves, todos los datos que produce dsh también son locales:

Dato	Dónde se almacena	¿Se sube?
Registros de sesión	~/.dsh/sessions/	No
Trajectory	Embebido en los registros de sesión	No
Configuración de plugins	~/.dsh/profiles/	No
API Key	~/.dsh/.credentials.yaml	No
Archivos del workspace	Tu directorio de workspace seleccionado	No

dsh no tiene sincronización en la nube, ni sistema de cuentas, ni reporte de telemetría. El contenido de tu conversación con el modelo solo se envía al proveedor del modelo (DeepSeek, etc.) cuando envías la petición, dsh en sí no guarda una copia en la nube.

Esto significa:

• Beneficio: los datos están completamente en tus manos, la privacidad es controlable
• Coste: cambiar de ordenador requiere migrar manualmente el directorio ~/.dsh, sin sincronización con un clic

Buenas prácticas de seguridad

Poniendo los mecanismos anteriores en uso diario, recuerda esto:

1. Usa workspace-write a diario, no mantengas full access activado — bajo full access el sandbox efectivamente desaparece, el Agent puede tocar todo tu disco duro. Solo actívalo temporalmente cuando claramente necesites operación a nivel de sistema, y vuelve a cambiarlo cuando termines.
2. No subas el directorio ~/.dsh directamente a GitHub — hay una clave en texto plano .credentials.yaml en él. Si necesitas hacer backup de la configuración, exporta settings.yaml por separado (sin claves), y gestiona las claves por separado.
3. Despliegue Docker en equipo: ten en cuenta que no hay aislamiento multiusuario — CH 27 cubrió, en la versión actual todos usan el mismo Basic Auth para iniciar sesión y ven la misma sesión y configuración. Cuando lo comparta el equipo, no almacenes información sensible en él, o que cada persona despliegue una instancia independiente.
4. Elige un directorio limpio como workspace — no establezcas todo C:\Users o el directorio home como workspace. Elige un directorio de proyecto dedicado, y el alcance que el Agent puede tocar se limitará a allí.

Lo que aprendiste en este capítulo

Apruebas si puedes completar los puntos siguientes:

• [ ] Conoces la idea central del diseño de seguridad de dsh: restringido por defecto, permitir bajo demanda
• [ ] Sabes cuáles son las tres capas de protección: sandbox de archivos, aprobación de operaciones, claves de solo escritura
• [ ] Sabes que el sandbox es a nivel de kernel del SO, no comprobación if en JS, el modelo no puede saltarlo
• [ ] Puedes enunciar claramente las diferencias entre los tres niveles de permiso (read-only / workspace-write / danger-full-access) y los escenarios aplicables
• [ ] Sabes que la aprobación es "permitir una vez", no permanente
• [ ] Sabes que la API Key es de solo escritura, tras guardar la interfaz no la muestra, el texto plano está solo en el .credentials.yaml local
• [ ] Sabes que todos los datos de dsh son locales, sin sincronización en la nube
• [ ] Puedes enunciar al menos 3 buenas prácticas de seguridad diaria