Comment configurer DeepSeek Super Agent en toute sécurité : comptes, autorisations et isolation

Ne commencez pas une expérimentation avec dsh-superagent depuis votre compte habituel ni sur un dépôt de production de valeur. Sa documentation de déploiement indique que les préréglages du routeur et de l’agent s’exécutent tous deux avec danger-full-access sous l’identité de l’utilisateur du système d’exploitation et peuvent lire le répertoire personnel de cet utilisateur. Un compte dédié et un dépôt jetable doivent précéder l’installation et les tests, et non venir après une première action inattendue.

Le dépôt public est un prototype de recherche, pas un produit DeepSeek officiel prêt pour la production. Ce guide transforme les paramètres par défaut documentés en un plan de configuration prudent : identités séparées, accès limité au dépôt, règles d’admission vérifiées, exécution contrôlée et procédure d’arrêt testée. Saisissez vos identifiants uniquement dans votre propre terminal approuvé ou selon votre processus de gestion des secrets, jamais dans une conversation de chat.

dsh-superagent est-il prêt pour la production ?

Le README précise explicitement qu’il s’agit de code de recherche et que l’implémentation publiée diffère du système interne et de certaines idées de l’article de conception associé. Ce statut doit être clairement mis en évidence lors d’une décision de déploiement. La disponibilité publique est l’occasion d’examiner la conception, pas une garantie que le code est prêt pour des opérations sensibles.

Ce guide a été vérifié à partir de la révision 8c32a9dc5d72c033816c6a8110b37f40cf94fba4 du 5 novembre 2026. Épinglez et consignez la révision que vous examinez réellement. Si vous mettez à jour la copie locale par la suite, vérifiez de nouveau les prérequis, les autorisations, les préréglages et les migrations de configuration avant de la réexécuter.

Le document de configuration décrit un processus interactif de planification et de confirmation. Examinez le plan avant l’exécution. Ne considérez pas l’instruction invitant à demander de l’aide à un agent de programmation pour la configuration comme une autorisation d’accéder à des identifiants sans rapport ou de l’installer dans votre profil de travail habituel.

Le premier objectif d’acceptation doit rester modeste : une requête sans risque produit une tâche compréhensible et un résultat vérifiable dans un dépôt jetable. Testez aussi le comportement de rejet et d’arrêt. Une démonstration réussie dans le meilleur des cas ne prouve pas la fiabilité en production et ne justifie pas d’élargir immédiatement les accès.

Pourquoi utiliser un compte dédié du système d’exploitation ?

Le guide de déploiement explicite l’hypothèse relative à l’accès de l’hôte. Des répertoires de session séparés et des enveloppes de gestion des identifiants n’isolent pas le processus. Un agent peut exécuter des programmes et accéder aux fichiers autorisés pour le compte qui l’exécute, y compris au répertoire personnel de ce compte.

Créez un compte dédié contenant uniquement les fichiers et les identifiants nécessaires à l’expérience. Gardez les clés SSH personnelles, les identifiants d’administrateur cloud, les profils de navigateur, la configuration de production et les dépôts sans rapport hors de son environnement accessible. Vérifiez l’appartenance aux groupes et les stockages montés, ainsi que le répertoire personnel du compte.

Pour une séparation plus stricte, envisagez une machine virtuelle dédiée et jetable ou un environnement hôte contrôlé de manière similaire. Ne supposez pas qu’un conteneur suffit simplement parce qu’il présente une vue différente du système de fichiers ; les montages, les privilèges, les sockets et le réseau déterminent la véritable limite d’isolation. Le choix de déploiement doit tenir compte de la valeur de l’hôte et du code exécuté.

Notre présentation de l’architecture explique pourquoi ces contrôles s’appliquent à différentes couches. En gardant les couches séparées, on évite de confondre une protection limitée, comme une courte liste de demandeurs, avec une isolation complète.

Couverture : dépôt du prototype dsh-superagent, carte du dépôt générée par GitHub. Les métadonnées du dépôt constituent une illustration datée, et non une affirmation concernant l’adoption ou les performances.

Comment créer une identité d’agent GitHub ?

Utilisez l’approche par compte utilisateur GitHub dédié exigée par le prototype actuel, plutôt que votre compte personnel. Le guide de déploiement indique que cette implémentation lit les notifications du compte et ne permet pas de remplacer l’identité de l’agent par une GitHub App. Il s’agit d’une contrainte d’implémentation, et non d’une recommandation générale contre les GitHub Apps dans d’autres systèmes.

N’accordez d’abord l’accès qu’au dépôt de test jetable. Gardez la configuration de connexion de l’agent séparée de la vôtre. Utilisez l’approche documentée avec un wrapper ou une configuration équivalente approuvée, et vérifiez quel compte la CLI utilise avant d’autoriser le processus à agir. Ne déduisez pas l’identité d’un nom affiché dans une conversation.

Les recommandations de GitHub concernant les jetons expliquent les options d’autorisations et d’expiration. Sélectionnez le niveau d’accès minimal pris en charge qui est nécessaire aux opérations documentées du prototype, vérifiez les exigences de compatibilité et prévoyez un moyen de révocation. Évitez d’accorder au compte des droits d’administration de l’organisation ou des capacités de déploiement en production par commodité.

Pour une première expérimentation, laissez les personnes s’occuper de la fusion. Un agent capable de pousser une branche et d’ouvrir une pull request n’a pas besoin d’être également autorisé à modifier les protections du dépôt ou à accepter son propre travail. L’identité doit clairement indiquer l’auteur tout en préservant une décision d’acceptation indépendante.

Comment fonctionnent les listes d’utilisateurs autorisés et les politiques d’admission ?

Le document d’autorisation distingue les demandes explicites, les candidats déduits et les entrées qui ne sont pas admises. Les identités autorisées et les paramètres d’admission propres à chaque périmètre comptent tous deux. Une liste d’autorisation courte est utile, mais elle doit être examinée conjointement avec le périmètre de réception et les règles, et non considérée comme l’unique contrôle.

Commencez avec un demandeur connu et un dépôt. Si Feishu n’est pas nécessaire pour le test, ne le configurez pas. Chaque source supplémentaire crée un autre endroit où vérifier l’identité, le périmètre de réception, le comportement du bot et l’autorisation de lancer un travail. N’ajoutez des sources qu’une fois le premier flux de travail compris.

Testez le comportement des règles avec des exemples sans risque. Vérifiez ce qui se passe lorsqu’une personne autorisée s’adresse à l’agent, lorsqu’une personne publie une discussion sans rapport et lorsqu’un suivi demande un travail qui dépasse la tâche existante. Consultez l’enregistrement de la décision au lieu de supposer que l’absence de réponse visible signifie qu’aucune action n’a eu lieu.

Le contenu des dépôts et les messages cités doivent rester des éléments de preuve, et non des mises à jour de la politique. Une instruction intégrée à une demande ou à un document ne doit pas accorder silencieusement un accès ni modifier les personnes autorisées à demander du travail. Notre comparaison avec proactive-agent explique pourquoi cette distinction est plus importante dans les flux de travail déclenchés par des événements que dans une session de chat unique supervisée.

Pourquoi commencer par le mode Observe ?

En mode observe par défaut, tel que documenté, le système évalue les candidats déduits et consigne ceux qui seraient acceptés sans les accepter automatiquement. Cela permet de comprendre le comportement des règles configurées. Ce mode n’empêche pas l’exécution de demandes explicites autorisées : il ne s’agit donc pas d’un mode global en lecture seule ou sans action.

Même pendant l’observation, limitez les autorisations techniques de l’expérience. Si l’objectif est d’examiner le routage sans permettre de modifications importantes, utilisez des ressources jetables et imposez cette limite dans la configuration de l’hôte et du dépôt. Ne vous fiez pas à l’intitulé d’un mode pour protéger des ressources auxquelles le processus a déjà accès.

Examinez les décisions positives comme négatives. Une règle trop permissive peut déclencher des tâches indésirables, tandis qu’une règle trop restrictive peut faire passer discrètement à côté des tâches attendues. Consignez la raison pour laquelle le résultat attendu diffère du résultat observé avant de modifier les règles. Élargir sans cesse les règles jusqu’à ce qu’une démonstration fonctionne est une mauvaise façon d’établir une valeur par défaut sûre.

Ne passez pas à auto comme étape d’installation habituelle. Ce mode accroît la capacité du système à lancer des tâches déduites lorsque des règles correspondantes s’appliquent. Toute extension ultérieure doit avoir un responsable désigné, un ensemble de règles examiné, un dossier d’évaluation contrôlée et un moyen testé d’arrêter ou de révoquer les accès.

Comment protéger les jetons, les secrets et les fichiers locaux ?

Gardez les identifiants hors des prompts, des fichiers du dépôt, des captures d’écran et des journaux ordinaires. Utilisez la connexion CLI ou le stockage de secrets approuvés dans l’environnement dédié. Les recommandations de l’OWASP sur la gestion des secrets fournissent des informations sur le contrôle des accès et le cycle de vie, mais l’exigence immédiate est simple : l’environnement de l’agent ne doit contenir aucun identifiant sans rapport avec sa tâche.

Examinez le parcours vers le fournisseur du modèle ainsi que l’identité GitHub. Le code et les prompts peuvent être traités par le fournisseur configuré, et les outils peuvent introduire d’autres destinations. Un clone local ne signifie pas que l’inférence ou le traitement se font uniquement en local. Vérifiez que le fournisseur sélectionné et la configuration de journalisation sont approuvés pour les données du test.

Évitez de copier un répertoire personnel ou une configuration shell dans le compte dédié pour simplifier la configuration. Vous pourriez y importer des gestionnaires d’identifiants, des variables d’environnement, une configuration cloud et un historique privé. Recréez délibérément le minimum de dépendances et tenez un inventaire non secret des éléments ajoutés.

Notre liste de contrôle des accès de l’agent personnel fournit une étape de préparation complémentaire. Avant la première exécution, vérifiez depuis l’environnement réel de l’agent quels répertoires, identifiants, services et destinations réseau sont accessibles. Si l’accès est plus étendu que nécessaire pour le test, corrigez les limites avant de poursuivre.

Comment isoler le dépôt et examiner les modifications ?

Utilisez un dépôt temporaire contenant des exemples synthétiques et aucun secret de production. La documentation de configuration indique les prérequis, notamment une version compatible de Node.js, pnpm, Git, tmux, Python, GitHub CLI et DeepSeek Harness. Vérifiez les versions exactes compatibles dans le package.json actuel et le guide de configuration au lieu d’installer des versions arbitraires tirées d’une ancienne liste de commandes.

Suivez cette séquence de préparation avant d’exécuter le plan d’installation :

1. Préparez le compte dédié ou l’hôte temporaire et confirmez les limites de ses accès.
2. Créez l’identité GitHub dédiée et le dépôt de test avec des permissions limitées appropriées.
3. Récupérez le prototype, consignez sa révision et examinez ses documents de configuration et de déploiement.
4. Examinez le plan d’installation proposé, le fournisseur de modèles, le profil, l’emplacement de l’état et le mécanisme d’identifiants.
5. Pour le premier essai, configurez la réception des demandes depuis GitHub uniquement, une courte liste de demandeurs, le mode observe et aucune fusion automatique.
6. Lancez la configuration vérifiée et inspectez l’état de santé et les prérequis de configuration.
7. Soumettez une tâche autorisée sans risque et vérifiez l’état obtenu ainsi que la modification proposée.
8. Testez une entrée sans rapport, un élargissement du périmètre et une procédure d’arrêt avant d’envisager un accès plus étendu.

La commande d’état documentée est utile après la configuration :

scripts/dsh-superagent status

Exécutez-le depuis la copie de travail vérifiée, dans l’environnement dédié. Interprétez sa sortie à l’aide du guide de déploiement actuel ; un processus en cours d’exécution n’est pas nécessairement une source saine et correctement configurée, ni une politique conforme.

Respectez les exigences relatives aux branches protégées et maintenez la vérification humaine. Inspectez le diff, les révisions initiale et finale, les tests et les hypothèses non résolues. Utilisez des copies indépendantes pour les données importantes ; notre guide des fichiers récupérables explique pourquoi la récupération doit être planifiée avant d’accorder un accès en écriture.

Comment arrêter l’agent et révoquer les accès ?

Documentez la procédure d’arrêt avant la première tâche. Le guide de déploiement actuel fournit une commande d’arrêt normal :

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

Un arrêt normal peut attendre la fin de l’exécution ; cela ne prouve pas que tous les effets externes ont été annulés. Inspectez les travaux en cours et l’activité pertinente du dépôt. Ne remplacez pas la compréhension du fonctionnement du processus par l’arrêt forcé de sessions sans rapport.

En cas d’incident d’accès ou d’expérience abandonnée, révoquez les identifiants dédiés et l’accès au dépôt via les commandes appropriées du fournisseur. Arrêtez les nouvelles demandes et inspectez les processus ou services d’arrière-plan encore actifs. Conservez une trace non confidentielle de la tâche concernée, de la révision et de l’activité pertinente afin que l’équipe puisse reconstituer l’événement.

Le nettoyage et la récupération sont deux tâches différentes. Supprimer un répertoire local ne révoque pas un jeton, ne ferme pas une demande de tirage distante et n’annule pas une modification envoyée. Décidez séparément du sort de chaque artefact et conservez les éléments nécessaires avant leur suppression. N’étendez l’expérience qu’une fois que l’arrêt, la révocation et la récupération sont aussi compréhensibles que son démarrage.

Pour le résultat lui-même, suivez la procédure d’examen d’agentic-autofix. Un processus opérationnel et une tâche acceptée sont des indicateurs opérationnels ; ils ne prouvent pas que sa modification proposée doit être fusionnée.

FAQ

Puis-je lancer le prototype depuis mon compte de développeur habituel ?

Cela expose les fichiers et les identifiants accessibles au compte au processus. Pour la première expérience, utilisez un environnement dédié et aux accès limités, en particulier compte tenu des configurations prédéfinies à accès complet documentées.

Le mode d’observation rend-il le prototype accessible en lecture seule ?

Non. Cela limite l’acceptation des candidats déduits, tandis que les demandes explicites autorisées peuvent toujours être exécutées. Si l’objectif du test est d’imposer l’absence d’écriture, faites respecter cette limite par les autorisations.

Puis-je utiliser une GitHub App au lieu d’un compte utilisateur dédié ?

Le guide de déploiement du prototype examiné nécessite un compte utilisateur en raison de son workflow de notifications. Vérifiez les révisions ultérieures avant de supposer que cette contrainte de compatibilité n’a pas changé.

Dois-je coller les jetons de configuration dans la conversation avec l’agent assistant ?

Non. Utilisez l’authentification CLI approuvée ou le stockage de secrets dans votre propre environnement contrôlé. Le processus de configuration ne nécessite pas de révéler des secrets dans la conversation.

Qu’est-ce qui prouve que l’essai initial peut être étendu en toute sécurité ?

Aucun test isolé ne prouve une sécurité générale. Examinez les décisions de réception, les limites des autorisations, les modifications proposées, le comportement à l’arrêt et les éléments attestant de la récupération, puis n’autorisez qu’un périmètre supplémentaire précis.

Conclusion

Pour configurer dsh-superagent en toute sécurité, commencez par ses véritables hypothèses de fonctionnement : statut de recherche, exécution avec accès complet sous le compte utilisateur de l’hôte, et mode d’observation qui permet tout de même d’effectuer des tâches explicites. Des identités dédiées, des ressources jetables et un examen indépendant sont indispensables pour comprendre le comportement du prototype.

Limitez la première tâche, testez délibérément le rejet et l’arrêt autant que la réussite, et conservez les éléments justifiant chaque modification acceptée. Ne transformez pas une expérience de recherche utile en déploiement de production en accumulant progressivement des identifiants et des autorisations sans nouvel examen.