Cómo configurar DeepSeek Super Agent de forma segura: cuentas, permisos y aislamiento

No empiece a probar dsh-superagent con su cuenta habitual ni en un repositorio de producción valioso. La documentación de implementación indica que tanto los ajustes preestablecidos del enrutador como los del trabajador se ejecutan con danger-full-access como usuario del sistema operativo y pueden leer el directorio de inicio de ese usuario. Cree una cuenta dedicada y un repositorio desechable antes de instalar y probar el sistema, no después de la primera acción inesperada.

El repositorio público es un prototipo de investigación, no un producto oficial de DeepSeek listo para producción. Esta guía convierte sus valores predeterminados documentados en un plan de configuración prudente: identidades separadas, acceso limitado al repositorio, reglas de admisión revisadas, ejecución controlada y un procedimiento de detención probado. Introduzca las credenciales únicamente mediante su propia terminal aprobada o su flujo de gestión de secretos; nunca en una conversación de chat.

¿Está dsh-superagent listo para producción?

El README afirma explícitamente que es código de investigación y que la implementación publicada difiere del sistema interno y de algunas ideas del artículo de diseño asociado. Este estado debe ocupar un lugar destacado al decidir si se implementa. La disponibilidad pública ofrece la oportunidad de inspeccionar el diseño, pero no garantiza que el código esté listo para operaciones sensibles.

Esta guía se verificó con la revisión 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 del 5 de noviembre de 2026. Fije y registre la revisión que realmente haya revisado. Si más adelante actualiza la copia de trabajo, vuelva a comprobar los requisitos previos, los permisos, los ajustes preestablecidos y las migraciones de configuración antes de volver a ejecutarla.

El documento de configuración describe un flujo interactivo de planificación y confirmación. Revise el plan antes de ejecutarlo. No interprete la instrucción de permitir que un agente de programación ayude con la configuración como permiso para acceder a credenciales ajenas al proceso o instalarse en su perfil de trabajo habitual.

El primer objetivo de aceptación debe ser modesto: una solicitud inocua produce una tarea comprensible y un resultado que se puede revisar en un repositorio desechable. Pruebe también el rechazo y el comportamiento al detenerse. Una demostración exitosa del flujo ideal no demuestra fiabilidad en producción ni justifica ampliar el acceso de inmediato.

¿Por qué usar una cuenta dedicada del sistema operativo?

La guía de implementación deja explícito el supuesto sobre el acceso del anfitrión. Los directorios de sesión separados y los envoltorios de credenciales no aíslan el proceso. Un trabajador puede ejecutar programas y acceder a los archivos permitidos a la cuenta que lo ejecuta, incluido el directorio de inicio de esa cuenta.

Crea una cuenta dedicada que contenga solo los archivos y las credenciales necesarias para el experimento. Mantén fuera de su entorno accesible las claves SSH personales, las credenciales de administrador de la nube, los perfiles del navegador, la configuración de producción y los repositorios que no guarden relación. Revisa también la pertenencia a grupos y el almacenamiento montado, además del directorio personal de la cuenta.

Para lograr una separación más estricta, considera usar una máquina virtual desechable dedicada o un entorno de host con controles similares. No des por sentado que un contenedor es suficiente solo porque presenta una vista distinta del sistema de archivos; los montajes, los privilegios, los sockets y la red determinan el límite real. La decisión de implementación debe tener en cuenta el valor del host y del código que se ejecutará.

Nuestro recorrido por la arquitectura explica por qué estos controles se aplican en distintas capas. Mantener las capas separadas evita confundir una medida de protección limitada, como una breve lista de solicitantes, con un aislamiento integral.

Portada: repositorio del prototipo dsh-superagent, tarjeta de repositorio generada por GitHub. Los metadatos del repositorio son una ilustración fechada, no una afirmación sobre adopción ni rendimiento.

¿Cómo crear una identidad de agente de GitHub?

Usa el enfoque de cuenta de usuario de GitHub dedicada que exige el prototipo actual, en lugar de tu cuenta personal. La guía de implementación indica que esta implementación lee las notificaciones de la cuenta y no admite sustituir la identidad del agente por una GitHub App. Se trata de una limitación de la implementación, no de una recomendación general contra las GitHub Apps en otros sistemas.

Concede acceso inicialmente solo al repositorio de prueba desechable. Mantén la configuración de inicio de sesión del agente separada de la tuya. Usa el enfoque de envoltorio documentado o una configuración equivalente aprobada, y verifica qué cuenta está usando la CLI antes de permitir que el proceso actúe. No deduzcas la identidad a partir del nombre visible en un chat.

La guía de GitHub sobre tokens explica las opciones de permisos y caducidad. Selecciona el acceso mínimo admitido que se necesite para las operaciones documentadas del prototipo, revisa los requisitos de compatibilidad y conserva una vía para revocarlo. Evita conceder a la cuenta permisos de administración de la organización o capacidades de despliegue en producción por comodidad.

Para un experimento inicial, deja que las personas se encarguen de fusionar los cambios. Un agente capaz de subir una rama y abrir una solicitud de cambios no necesita también autoridad para modificar las protecciones del repositorio ni aceptar su propio trabajo. La identidad debe dejar clara la autoría y, al mismo tiempo, preservar una decisión de aceptación independiente.

¿Cómo funcionan las listas de usuarios autorizados y las políticas de admisión?

El documento de autorización distingue entre solicitudes explícitas, candidatos inferidos y entradas que no se admiten. Importan tanto las identidades autorizadas como la configuración de admisión específica de cada ámbito. Una lista de permitidos breve es útil, pero debe revisarse junto con el ámbito receptor y las reglas, en lugar de tratarse como el único control.

Empieza con una persona solicitante conocida y un repositorio. Si Feishu no es necesario para la prueba, no lo configures. Cada fuente adicional crea otro lugar donde verificar la identidad, el ámbito receptor, el comportamiento del bot y los permisos para iniciar trabajo. Añade fuentes solo cuando entiendas el primer flujo de trabajo.

Prueba el comportamiento de las políticas con ejemplos inofensivos. Confirma qué ocurre cuando una persona autorizada se dirige al agente, cuando alguien publica una conversación no relacionada y cuando una solicitud de seguimiento pide trabajo ajeno a la tarea existente. Inspecciona el registro de decisiones en lugar de dar por hecho que no hubo ninguna acción porque no se vea una respuesta.

El contenido del repositorio y los mensajes citados deben seguir siendo pruebas, no actualizaciones de políticas. Una instrucción incluida en un issue o documento no debe conceder acceso de forma silenciosa ni cambiar quién puede solicitar trabajo. Nuestra comparación de proactive-agent explica por qué esa distinción es más importante en los flujos de trabajo conectados a eventos que en una sola sesión de chat supervisada.

¿Por qué empezar con el modo de observación?

En el modo predeterminado documentado observe, el sistema evalúa los candidatos inferidos y registra cuáles serían aceptados, sin aceptarlos automáticamente. Esto resulta útil para conocer el comportamiento de las reglas configuradas. No impide que se ejecuten solicitudes explícitas autorizadas, por lo que no es un modo global de solo lectura ni un modo sin acciones.

Mantén limitados los permisos técnicos del experimento mientras lo observas. Si el objetivo es inspeccionar el enrutamiento sin permitir cambios valiosos, usa recursos desechables y aplica ese límite mediante la configuración del host y del repositorio. No confíes en la etiqueta de un modo para proteger recursos a los que el proceso ya puede acceder.

Revisa tanto las decisiones positivas como las negativas. Una regla demasiado permisiva puede generar trabajo no deseado, mientras que una demasiado restrictiva puede pasar por alto en silencio tareas previstas. Antes de modificar la política, registra por qué el resultado previsto difiere del observado. Ampliar las reglas una y otra vez hasta que funcione una demostración no es una buena forma de establecer una configuración predeterminada segura.

No cambies a auto como paso habitual de instalación. Ese modo aumenta la capacidad del sistema para iniciar tareas inferidas que coincidan con las reglas. Toda ampliación posterior debe tener una persona responsable explícita, un conjunto de reglas revisado, un registro de evaluación controlado y un método probado para detener o revocar el acceso.

¿Cómo proteger los tokens, los secretos y los archivos locales?

Mantén las credenciales fuera de las indicaciones, los archivos del repositorio, las capturas de pantalla y los registros habituales. Usa el inicio de sesión aprobado mediante CLI o un sistema de almacenamiento de secretos en el entorno dedicado. La guía de OWASP sobre gestión de secretos ofrece información sobre el control de acceso y el ciclo de vida, pero el requisito inmediato es sencillo: el entorno del agente no debe contener credenciales que no estén relacionadas con su tarea.

Revisa también la ruta del proveedor del modelo, además de la identidad de GitHub. El código y las indicaciones pueden procesarse en el proveedor configurado, y las herramientas pueden introducir destinos adicionales. Tener una copia local no implica que la inferencia sea local ni que el procesamiento se limite al entorno local. Confirma que el proveedor seleccionado y la configuración de registro estén aprobados para el material de prueba.

Evita copiar un directorio personal o la configuración del shell a la cuenta dedicada para facilitar la configuración. Podrías incluir herramientas auxiliares para credenciales, variables de entorno, configuración de la nube e historial privado. Vuelve a crear deliberadamente las dependencias mínimas y lleva un inventario no confidencial de lo que se añadió.

Nuestra lista de verificación de acceso del agente personal ofrece un paso de preparación relacionado. Antes de la primera ejecución, comprueba desde el entorno real del agente a qué directorios, credenciales, servicios y destinos de red se puede acceder. Si el acceso es más amplio de lo necesario para la prueba, ajusta los límites antes de continuar.

¿Cómo aislar el repositorio y revisar los cambios?

Usa un repositorio desechable con ejemplos sintéticos y sin secretos de producción. La documentación de configuración enumera requisitos previos, entre ellos una versión compatible de Node.js, pnpm, Git, tmux, Python, GitHub CLI y DeepSeek Harness. Consulta el package.json actual y la guía de configuración para comprobar la compatibilidad exacta, en lugar de instalar versiones arbitrarias basándote en una lista antigua de comandos.

Sigue esta secuencia de preparación antes de ejecutar el plan de instalación:

1. Aprovisiona la cuenta específica o el host desechable y confirma los límites de acceso.
2. Crea la identidad específica de GitHub y el repositorio de prueba con los permisos limitados adecuados.
3. Obtén el prototipo, registra su revisión y revisa sus documentos de configuración y despliegue.
4. Revisa el plan de instalación propuesto, el proveedor del modelo, el perfil, la ubicación del estado y el mecanismo de credenciales.
5. Configura la recepción exclusiva desde GitHub, una lista breve de solicitantes, observe y ninguna fusión automática para la primera prueba.
6. Inicia la configuración revisada e inspecciona el estado y los requisitos de configuración.
7. Envía una tarea autorizada e inocua y revisa el estado resultante y el cambio propuesto.
8. Prueba una entrada irrelevante, una ampliación del alcance y un procedimiento de parada antes de considerar un acceso más amplio.

El comando de estado documentado resulta útil después de la configuración:

scripts/dsh-superagent status

Ejecútalo desde la copia de trabajo revisada, en el entorno específico. Interpreta su resultado según la guía de despliegue actual; que haya un proceso en ejecución no significa que el origen y la política estén en buen estado y configurados correctamente.

Mantén los requisitos de ramas protegidas y la revisión humana. Inspecciona el diff, las revisiones inicial y final, las pruebas y las suposiciones sin resolver. Usa copias independientes para los datos importantes; nuestra guía de archivos recuperables explica por qué hay que planificar la recuperación antes de conceder acceso de escritura.

¿Cómo detener el agente y revocar el acceso?

Documenta el procedimiento de parada antes de la primera tarea. La guía de despliegue actual proporciona un comando de parada ordenada:

scripts/dsh-superagent stop
scripts/dsh-superagent status

Una parada ordenada puede esperar a que termine la ejecución; no demuestra que se hayan revertido todos los efectos externos. Inspecciona el trabajo pendiente y la actividad pertinente del repositorio. No sustituyas la comprensión de lo que hace el proceso por la terminación forzada de sesiones no relacionadas.

Ante un incidente de acceso o un experimento abandonado, revoca las credenciales específicas y el acceso al repositorio mediante los controles del proveedor correspondiente. Detén la recepción de tareas e inspecciona los procesos o servicios en segundo plano restantes. Conserva un registro sin secretos de la tarea afectada, la revisión y la actividad pertinente para que el equipo pueda reconstruir lo ocurrido.

La limpieza y la recuperación son tareas distintas. Eliminar un directorio local no revoca un token, no cierra una solicitud de incorporación de cambios remota ni deshace un cambio enviado. Decide por separado qué debe ocurrir con cada artefacto y conserva las pruebas necesarias antes de eliminarlo. Amplía el experimento solo cuando detenerlo, revocar accesos y recuperarse sean procesos tan comprensibles como iniciarlo.

Para el resultado en sí, usa el procedimiento de revisión de agentic-autofix. Un proceso saludable y una tarea admitida son señales operativas; no demuestran que deba integrarse el parche propuesto.

Preguntas frecuentes

¿Puedo ejecutar el prototipo desde mi cuenta habitual de desarrollo?

Eso expone al proceso los archivos y las credenciales a los que puede acceder la cuenta. Usa un entorno dedicado y limitado para el primer experimento, especialmente dados los ajustes preestablecidos documentados de acceso completo.

¿El modo de observación hace que el prototipo sea de solo lectura?

No. Limita la aceptación de candidatos inferidos, mientras que las solicitudes explícitas y autorizadas aún pueden ejecutarse. Si el objetivo de la prueba es impedir las escrituras, hazlo cumplir mediante los permisos.

¿Puedo usar una GitHub App en lugar de una cuenta de usuario dedicada?

La guía de implementación del prototipo inspeccionado requiere una cuenta de usuario por su flujo de notificaciones. Vuelve a revisar las versiones posteriores antes de suponer que esa restricción de compatibilidad no ha cambiado.

¿Debería pegar tokens de configuración en el chat del agente de asistencia?

No. Usa la autenticación CLI aprobada o el almacenamiento de secretos en tu propio entorno controlado. El proceso de configuración no requiere que expongas valores secretos en la conversación.

¿Qué demuestra que es seguro ampliar la prueba inicial?

Ninguna prueba por sí sola demuestra la seguridad general. Revisa las decisiones de admisión, los límites de permisos, los cambios propuestos, el comportamiento al detenerse y las pruebas de recuperación; luego autoriza únicamente un alcance adicional específico.

Conclusión

La configuración segura de dsh-superagent comienza por entender sus supuestos operativos reales: estado de investigación, ejecución con acceso completo bajo el usuario anfitrión y un modo de observación que aún permite realizar tareas explícitas. Las identidades dedicadas, los recursos desechables y la revisión independiente son requisitos previos para aprender cómo se comporta el prototipo.

Mantén la primera tarea acotada, prueba deliberadamente tanto el rechazo como la detención, y conserva las pruebas que respaldan cada cambio aceptado. No conviertas un experimento de investigación útil en un despliegue de producción acumulando gradualmente credenciales y permisos sin una nueva revisión.