Guide · Mis à jour le 10 novembre 2026 · Par Cameron Voss et West Mao
Sécurité DeepSeek SuperAgent : autorisations, mode observation et configuration sécurisée (novembre 2026)
Une liste de contrôle de sécurité pratique pour évaluer le prototype de recherche sur un référentiel GitHub.
Commencez avec un dépôt de test, un compte GitHub dédié à l’agent, une liste restreinte de demandeurs autorisés et un environnement d’exécution isolé. Gardez la revue humaine et la protection des branches. Le mode Observe limite les tâches déduites, mais ne bloque pas les demandes explicites et ne place pas le worker dans un bac à sable.
DeepSeek SuperAgent est un prototype de recherche construit sur DeepSeek Harness, et non un produit DeepSeek officiel ou un logiciel prêt pour la production. Il nécessite un fournisseur de modèles configuré séparément. Ce guide suit la documentation publiée ; nous n'avons pas exécuté de déploiement de bout en bout pour cet article.
Le prototype public coordonne le travail des agents dans les conversations GitHub. Un plan de sécurité doit tenir compte à la fois de qui peut demander du travail et de ce que le worker qui en résulte peut atteindre. Cet article explique la conception documentée et recommande un essai restreint ; il ne s'agit pas d'une certification de sécurité ni du résultat d'un test d'intrusion.
À quoi l'agent peut-il accéder lors de son exécution ?
La documentation de déploiement publiée indique que ses préréglages de routeur et de travail s'exécutent avec danger-full-access en tant qu'utilisateur du système d'exploitation du service. Un travailleur peut exécuter des programmes et lire des fichiers disponibles pour cet utilisateur. Il peut également utiliser les informations d'identification GitHub de l'agent pour interagir avec son référentiel configuré.
Une identité GitHub dédiée est utile pour l'attribution et la limitation de l'accès au référentiel, mais elle n'isole pas le processus local. Un répertoire par ticket ou un arbre de travail Git sépare les modifications pour l'organisation ; il ne bloque pas l'accès au système de fichiers, au réseau ou aux informations d'identification.
Que fait réellement le mode observation ?
| Mode d'acceptation | Candidats déduits | Demande autorisée explicite |
|---|---|---|
off | L'activité déduite ne devient pas un candidat. | Peut toujours être accepté. |
observe | Évalué ; un résultat positif est enregistré comme « accepterait » sans commencer le travail déduit. | Peut toujours être accepté. |
auto | Une évaluation positive peut accepter un travail lorsqu'une règle activée correspond. | Peut toujours être accepté. |
Démarrez dans observe pour vérifier si les règles généreraient un travail utile ou bruyant. Il s’agit d’un paramètre de stratégie pour l’activité déduite, et non d’un commutateur à sec pour toutes les actions de l’agent. La demande adressée par une personne autorisée peut créer un ticket et exécuter un travailleur dans l'un de ces modes.
Qui peut commencer à travailler et qui peut poursuivre une conversation ?
L'hôte applique les politiques sources et les listes autorisées lorsqu'il décide d'admettre ou non une nouvelle demande. Une personne autorisée s'adressant à l'agent peut faire une demande explicite. D'autres messages peuvent être évalués en tant que candidats déduits conformément à la politique source.
Une fois qu'un ticket s'abonne à un fil de discussion, les messages de ce fil de discussion peuvent l'atteindre en tant que contexte, y compris les messages de bot et de CI. Ils n’accordent pas eux-mêmes une nouvelle autorité : le mandat du ticket définit toujours sa portée. La documentation indique également que le message d’une personne sur le fil de discussion d’un ticket terminé peut reprendre ce travail, quel que soit l’expéditeur. Pour un référentiel public, indiquez qui peut publier ou influencer le contenu des fils de discussion auxquels vous êtes abonné ; une courte liste d'autorisation du demandeur ne suffit pas à elle seule à garantir la confiance de toutes les entrées ultérieures.
Comment se protéger contre l’injection de prompt ?
Aucun paramètre ne l'élimine à lui seul. Les corps de problèmes, les commentaires, les journaux et les fichiers du référentiel peuvent contenir des instructions provenant de personnes qui ne doivent pas contrôler l'agent. Le modèle d'autorisation documenté traite ces messages comme des entrées plutôt que comme des modifications d'autorisation, mais un modèle peut toujours mal interpréter un contenu hostile ou agir dans le cadre des privilèges dont il dispose déjà.
- Utilisez un référentiel de test privé et limitez le nombre de personnes pouvant contribuer ou commenter pendant l'essai.
- Exécutez avec une identité de système d'exploitation dédiée et uniquement les informations d'identification et les fichiers dont l'essai a besoin. Envisagez une VM gérée séparément ou une isolation équivalente avec un accès réseau limité.
- Ne placez pas de secrets de production, d'identifiants de déploiement ou de référentiels privés non liés dans l'environnement du travailleur.
- Protégez la branche par défaut et demandez à un humain d'inspecter les différences et les tests avant la fusion.
- Surveillez le compte de l'agent et soyez prêt à révoquer ses identifiants et à arrêter le service.
Ce sont des mesures de réduction des risques, pas une garantie. Les contrôles appropriés dépendent du référentiel, de l'environnement d'hébergement et des conséquences d'une erreur.
Comment configurer le premier essai ?
- Limitez la cible. Choisissez un référentiel de test à faible risque et une petite tâche de documentation.
- Identités séparées. Utilisez un utilisateur GitHub et une configuration CLI réservés aux agents. Accordez à cet utilisateur l'accès uniquement au référentiel de test.
- Réduisez l'accès à l'hôte. Utilisez un compte de système d'exploitation dédié et examinez les montages, les services accessibles, les variables d'environnement et l'accès au réseau.
- Définissez la stratégie. Autorisez uniquement le demandeur prévu et commencez par l'acceptation déduite dans
observe. - Conservez l'examen humain. Désactivez la fusion automatique ; utilisez la protection des branches, examinez chaque PR et vérifiez le résultat.
- Testez les limites. Inspectez l'état du ticket, les fichiers réels modifiés et les informations d'identification disponibles pour le runtime. Enregistrez un comportement inattendu et arrêtez-vous si la portée n'est pas claire.
La modification de la politique arrête-t-elle immédiatement le travail en cours ?
Pas nécessairement. La documentation indique que les changements de politique informent les billets en direct concernés mais ne révoquent pas immédiatement chaque mandat actif. Si vous devez arrêter le travail, utilisez les contrôles d'arrêt du projet, inspectez les tickets actifs et les processus en cours, et révoquez les informations d'identification ou l'accès, le cas échéant. Vérifiez le résultat plutôt que de supposer qu'une modification de configuration a arrêté chaque travailleur.
Le SuperAgent peut-il fusionner ses propres Pull Requests ?
Le projet recommande de commencer par la fusion humaine. Il décrit un arrangement de fusion automatique en option avec des contrôles supplémentaires ; ne présumez pas qu’une invite à elle seule applique la politique de votre référentiel. Gardez la fusion automatique désactivée pendant la période d'essai et utilisez les contrôles du référentiel GitHub pour exiger les révisions et les vérifications dont votre équipe a besoin.
Que devez-vous vérifier avant d'étendre l'accès ?
| Question | Preuves à rechercher |
|---|---|
| L'agent peut-il toucher uniquement aux référentiels prévus ? | Adhésion au compte de l'agent et autorisations du référentiel. |
| Un travailleur peut-il accéder à des secrets sans rapport ? | Compte du système d'exploitation, les montages, l'environnement, les magasins d'informations d'identification et les règles du réseau. |
| Les décisions sont-elles compréhensibles ? | Candidats observés, demandeurs autorisés, mandats et journaux de tickets. |
| Chaque modification sera-t-elle examinée ? | Protection des succursales, exigences des réviseurs et processus de fusion manuelle. |
| L'équipe peut-elle s'arrêter et récupérer ? | Procédure d'arrêt, révocation des informations d'identification, sauvegarde et opérateur nommé. |
Pour connaître la configuration requise et les coûts de fonctionnement, lisez le Guide de configuration et de coûts de SuperAgent. Pour le flux interne entre les sources, les tickets et les nœuds de calcul, consultez le guide d'architecture.
Questions fréquemment posées
Le mode observation peut-il être utilisé en toute sécurité avec les informations d'identification de production ?
Le mode Observation ne protège pas les informations d'identification d'une tâche explicite et n'isole pas les workers. Conservez les informations d'identification de production en dehors d'un essai.
Un utilisateur GitHub dédié effectue-t-il un sandbox pour le worker ?
Non. Il sépare l'identité GitHub ; Les contrôles du système d'exploitation et de l'infrastructure déterminent ce que le processus peut atteindre.
Le prototype est-il prêt pour la production ?
Les responsables le décrivent comme un code de recherche à réviser et à adapter, et non comme un logiciel prêt pour la production.