Guía · Actualizado el 10 de noviembre de 2026 · Por Cameron Voss y West Mao
Seguridad de DeepSeek SuperAgent: permisos, modo de observación y configuración segura (noviembre de 2026)
Una lista de verificación de seguridad práctica para evaluar el prototipo de investigación en un repositorio de GitHub.
Empieza con un repositorio de prueba, una cuenta de GitHub dedicada al agente, una lista reducida de solicitantes autorizados y un entorno de ejecución aislado. Mantén la revisión humana y la protección de ramas. El modo Observe limita las tareas inferidas, pero no impide las solicitudes explícitas ni aísla el worker en una sandbox.
DeepSeek SuperAgent es un prototipo de investigación creado en DeepSeek Harness, no un producto oficial de DeepSeek ni un software listo para producción. Necesita un proveedor de modelo configurado por separado. Esta guía sigue la documentación publicada; No hemos ejecutado una implementación de un extremo a otro para este artículo.
El prototipo público coordina el trabajo del agente en las conversaciones de GitHub. Un plan de seguridad debe tener en cuenta quién puede solicitar trabajo y a qué puede llegar el trabajador resultante. Este artículo explica el diseño documentado y recomienda una prueba limitada; no es una certificación de seguridad ni el resultado de una prueba de penetración.
¿A qué puede acceder el agente cuando se ejecuta?
La documentación de implementación publicada dice que sus ajustes preestablecidos de enrutador y trabajador se ejecutan con danger-full-access como usuario del sistema operativo del servicio. Un trabajador puede ejecutar programas y leer archivos disponibles para ese usuario. También puede utilizar las credenciales de GitHub del agente para interactuar con su repositorio configurado.
Una identidad de GitHub dedicada es útil para la atribución y limitar el acceso al repositorio, pero no aísla el proceso local. Un directorio por ticket o un árbol de trabajo de Git separa los cambios para la organización; no bloquea el sistema de archivos, la red o el acceso a credenciales.
¿Qué hace realmente el modo de observación?
| Modo de aceptación | Candidatos inferidos | Solicitud autorizada explícita |
|---|---|---|
off | La actividad inferida no se convierte en candidato. | Aún puede ser aceptado. |
observe | Evaluado; un resultado positivo se registra como "aceptaría" sin iniciar el trabajo inferido. | Aún se puede aceptar. |
auto | Una evaluación positiva puede aceptar el trabajo cuando una regla habilitada coincide. | Aún se puede aceptar. |
Comience en observe para inspeccionar si las reglas generarían trabajo útil o ruidoso. Es una configuración de política para la actividad inferida, no un cambio de prueba para todas las acciones del agente. La solicitud dirigida a una persona permitida puede crear un ticket y ejecutar un trabajador en cualquiera de estos modos.
¿Quién puede empezar a trabajar y quién puede continuar una conversación?
El host aplica políticas de origen y listas permitidas al decidir si admite una nueva solicitud. Una persona autorizada que se dirija al agente puede realizar una solicitud explícita. Otros mensajes pueden evaluarse como candidatos inferidos según la política de origen.
Una vez que un ticket se suscribe a un hilo, los mensajes de ese hilo pueden llegar a él como contexto, incluidos los mensajes de bot y CI. No otorgan nueva autoridad por sí solos: el mandato del boleto aún define su alcance. La documentación también dice que el mensaje de una persona en el hilo de un ticket finalizado puede reanudar ese trabajo, independientemente del remitente. Para un repositorio público, tenga en cuenta quién puede publicar o influir en el material en los hilos suscritos; una lista corta de solicitantes permitidos por sí sola no hace que todas las entradas posteriores sean confiables.
¿Qué protege frente a la inyección de prompts?
Ninguna configuración lo elimina. Los cuerpos de problemas, comentarios, registros y archivos de repositorio pueden contener instrucciones de personas que no deberían controlar el agente. El modelo de autorización documentado trata esos mensajes como entradas en lugar de cambios de permisos, pero un modelo aún puede malinterpretar el contenido hostil o actuar dentro de los privilegios que ya tiene.
- Utilice un repositorio de prueba privado y limite quién puede contribuir o comentar durante la prueba.
- Ejecute con una identidad de sistema operativo dedicada y solo las credenciales y archivos que necesita la prueba. Considere una máquina virtual administrada por separado o un aislamiento equivalente con acceso restringido a la red.
- No coloque secretos de producción, credenciales de implementación o repositorios privados no relacionados en el entorno del trabajador.
- Proteja la rama predeterminada y solicite que un humano inspeccione las diferencias y las pruebas antes de fusionar.
- Supervise la cuenta del agente y esté preparado para revocar sus credenciales y detener el servicio.
Estas son medidas de reducción de riesgos, no una garantía. Los controles adecuados dependen del repositorio, el entorno de alojamiento y las consecuencias de un error.
¿Cómo se debe configurar la primera prueba?
- Limite el objetivo. Elija un repositorio de prueba de bajo riesgo y una pequeña tarea de documentación.
- Identidades separadas. Utilice un usuario de GitHub y una configuración CLI de solo agente. Otorgue a ese usuario acceso solo al repositorio de prueba.
- Reduzca el acceso al host. Utilice una cuenta de sistema operativo dedicada y revise los montajes, los servicios accesibles, las variables de entorno y el acceso a la red.
- Establezca una política. Permita solo al solicitante previsto y comience con la aceptación inferida en
observe. - Mantenga la revisión humana. Deshabilite la fusión automática; use protección de ramas y revise cada PR y verifique el resultado.
- Pruebe los límites. Inspeccione el estado del ticket, los archivos reales modificados y las credenciales disponibles para el tiempo de ejecución. Registre comportamientos inesperados y deténgase si el alcance no está claro.
¿El cambio de política detiene inmediatamente el trabajo existente?
No necesariamente. La documentación dice que los cambios de política notifican los tickets en vivo afectados pero no revocan inmediatamente todos los mandatos activos. Si necesita detener el trabajo, utilice los controles de parada del proyecto, inspeccione los tickets activos y los procesos en ejecución, y revoque las credenciales o el acceso, según corresponda. Verifique el resultado en lugar de asumir que una edición de configuración detuvo a todos los workers.
¿Puede SuperAgent fusionar sus propias Pull Requests?
El proyecto recomienda comenzar con la fusión humana. Describe una disposición opcional de fusión automática con controles adicionales; No asuma que un aviso por sí solo hace cumplir la política de su repositorio. Mantenga la combinación automática desactivada durante la prueba y utilice los controles del repositorio de GitHub para solicitar las revisiones y comprobaciones que su equipo necesita.
¿Qué debes comprobar antes de ampliar el acceso?
| Pregunta | Evidencia a buscar |
|---|---|
| ¿Puede el agente tocar solo los repositorios previstos? | Permisos de repositorio y membresía de la cuenta del agente. |
| ¿Puede un trabajador acceder a secretos no relacionados? | OS cuenta, montajes, entorno, almacenes de credenciales y reglas de red. |
| ¿Son comprensibles las decisiones? | Candidatos observados, solicitantes permitidos, mandatos de tickets y registros. |
| ¿Se revisarán todos los cambios? | Protección de sucursales, requisitos de revisor y un proceso de fusión manual. |
| ¿Puede el equipo detenerse y ¿Recuperar? | Detener procedimiento, revocación de credenciales, copia de seguridad y un operador nombrado. |
Para conocer los requisitos y costos operativos, lea la guía de costos y configuración de SuperAgent. Para conocer el flujo interno entre fuentes, tickets y trabajadores, consulte la guía de arquitectura.
Preguntas frecuentes
¿Es seguro usar el modo de observación con credenciales de producción?
El modo Observar no protege las credenciales de una tarea explícita ni aísla a los workers. Mantenga las credenciales de producción fuera de una prueba.
¿Un usuario dedicado de GitHub protege al worker?
No. Separa la identidad de GitHub; Los controles del sistema operativo y de la infraestructura rigen lo que el proceso puede alcanzar.
¿Está el prototipo listo para producción?
Los mantenedores lo describen como código de investigación para revisar y adaptar, no como software listo para producción.