DeepSeek Harness Seatbelt : impact sur Mac en 2026

Verdict : DeepSeek Harness Seatbelt est le meilleur point de départ pour limiter les effets de fichiers d’un Agent sur macOS, à condition de le traiter comme une contrainte de processus et non comme une isolation complète. Avant d’autoriser un dépôt réel, il faut vérifier le backend utilisé, le chemin de travail, les processus enfants, les connexions réseau et les sources de secrets dans un dépôt sans données sensibles.

Cet article s’adresse aux développeurs qui veulent laisser DeepSeek Harness exécuter des commandes sur un Mac, aux ingénieurs sécurité qui évaluent la frontière d’un Agent, ainsi qu’aux responsables techniques qui définissent le périmètre d’un essai sur Mac distant.

Dernière mise à jour : 18 août 2026. Les informations ont été vérifiées dans le dépôt officiel de DeepSeek Harness, sa documentation des sous-systèmes et les ressources officielles consacrées à la sécurité de macOS.

Ce que Seatbelt protège, et ce qu’il ne promet pas

Le dépôt officiel présente le sous-système sandbox comme une capacité de confinement de processus. Le backend local sélectionne notamment Seatbelt sur macOS. La documentation décrit aussi des modes liés aux effets de fichiers : lecture seule, écriture dans l’espace de travail et accès complet. Elle précise que le réseau et la visibilité des processus ne font pas partie de ce vocabulaire de contrôle. (documentation officielle du sous-système sandbox)

Cette distinction est déterminante. Un Agent peut être limité dans sa capacité à écrire en dehors d’un répertoire tout en conservant plusieurs possibilités opérationnelles :

• lancer des commandes autorisées par la politique ;
• démarrer des processus enfants ;
• lire les variables d’environnement accessibles au processus ;
• utiliser un outil externe ou un serveur MCP autorisé ;
• écrire des sorties dans les journaux ou les fichiers temporaires ;
• tenter une connexion réseau si aucune politique réseau indépendante ne l’interdit.

Le backend Seatbelt est donc une barrière technique parmi plusieurs autres. Il ne détermine pas si une commande est pertinente pour le projet. Il ne sait pas, à lui seul, si une modification de code est acceptable. Il ne remplace pas les approbations humaines, la séparation des comptes, le filtrage réseau ou la rotation des clés.

DeepSeek Harness active-t-il automatiquement Seatbelt sur macOS ?

La réponse prudente est : il ne faut pas le déduire du nom du paquet ou de la présence du dossier sandbox. Le dépôt officiel expose une architecture qui prévoit un backend Seatbelt et documente sa sélection côté exécution locale. Toutefois, l’état effectif dépend de la version utilisée, du profil chargé, du preset, de la disponibilité de l’outil système et de la manière dont l’application a été installée.

La bonne vérification consiste à relever :

1. la version exacte de DeepSeek Harness ;
2. le preset ou la configuration active ;
3. le mode de sandbox demandé ;
4. le backend effectivement sélectionné ;
5. le résultat du test fonctionnel de confinement ;
6. le comportement observé lors d’une écriture refusée.

Le dépôt indique que les backends locaux doivent échouer de manière fermée lorsqu’aucun mécanisme utilisable n’est disponible, plutôt que de continuer silencieusement sans confinement. Cette propriété doit néanmoins être confirmée dans la version déployée, et non seulement supposée à partir du code source. (README du backend local)

Espace de travail contre processus : deux contrôles différents

Le premier piège concerne la confusion entre le répertoire choisi par Harness et la politique appliquée au processus.

L’espace de travail répond à une question fonctionnelle : dans quel dossier l’Agent doit-il chercher et modifier les fichiers du projet ? La politique Seatbelt répond à une question système : quels effets de fichiers le processus lancé peut-il produire ?

Ces contrôles se complètent, mais ils ne sont pas identiques. Un mauvais chemin de travail peut exposer le mauvais dépôt. Une mauvaise politique peut autoriser des écritures plus larges que prévu. Un lien symbolique, un répertoire temporaire mal placé ou un outil qui utilise son propre dossier de cache peuvent également modifier le résultat réel.

Le dépôt officiel indique que la racine de travail est résolue par appel et que le répertoire courant de la session peut devenir la frontière d’écriture du mode workspace-write. La racine est aussi canonisée avant l’application de la politique, ce qui compte lorsqu’un chemin contient des liens symboliques ou des segments ... (référence officielle de la politique de sandbox)

Seatbelt peut-il empêcher l’Agent d’accéder à d’autres répertoires ?

Il peut limiter certains effets de fichiers, mais cette affirmation doit être prouvée par des essais négatifs. Dans la description actuelle du backend local, le mode workspace-write autorise l’écriture sous la racine de travail ainsi que dans certaines zones temporaires prévues par la politique. Le mode read-only réduit encore les écritures explicites. La documentation précise cependant que le contrôle décrit concerne les effets de fichiers, pas une promesse générale sur tous les accès, tous les descripteurs déjà ouverts ou toutes les capacités d’un outil externe.

Un test utile ne doit pas seulement créer un fichier dans le dépôt. Il doit tenter :

printf 'dans-espace-travail\n' > ./preuve-interne.txt
printf 'hors-espace-travail\n' > ../preuve-externe.txt
printf 'dans-temporaire\n' > "${TMPDIR:-/tmp}/preuve-temporaire.txt"

Un résultat exploitable doit indiquer le chemin réel, le mode appliqué et le statut de chaque opération. Une écriture refusée par Seatbelt peut apparaître avec une signature EPERM selon la documentation du sous-système. Ce détail permet de distinguer un refus de confinement d’une erreur ordinaire du programme. (signatures de refus documentées)

workspace-write
./preuve-interne.txt        : autorisée
../preuve-externe.txt       : refusée
/tmp/preuve-temporaire.txt : selon la zone temporaire déclarée
stderr                      : Operation not permitted

Le test ne doit jamais utiliser le dossier personnel réel, un dépôt de production ou une clé active. Les chemins témoins doivent être artificiels et dépourvus de contenu confidentiel.

Première étape : vérifier la chaîne de processus

Le contrôle devient plus délicat dès que DeepSeek Harness lance une commande qui lance elle-même un script, un compilateur ou un outil de développement.

Un appel apparemment simple peut produire une chaîne comparable à celle-ci :

DeepSeek Harness
└── shell
    └── script de construction
        ├── gestionnaire de dépendances
        ├── compilateur
        └── outil auxiliaire

Chaque enfant peut lire sa propre configuration, créer des fichiers temporaires, interpréter des paramètres et communiquer avec d’autres services locaux. Une politique appliquée au processus parent ne doit donc pas être évaluée uniquement avec une commande inoffensive exécutée directement.

Les scénarios à vérifier incluent :

• un script qui appelle un autre script ;
• un gestionnaire de dépendances qui utilise un cache hors dépôt ;
• un compilateur qui écrit dans un répertoire de sortie distinct ;
• un outil audio ou vidéo qui crée des fichiers temporaires volumineux ;
• un utilitaire de design qui tente d’accéder à des ressources utilisateur ;
• une commande qui démarre un serveur local ;
• un serveur MCP lancé en sous-processus.

Le risque n’est pas nécessairement une faille du backend. Il vient souvent de l’écart entre la commande visible dans l’interface et les opérations réellement effectuées par toute la chaîne.

L’approbation des commandes reste-t-elle nécessaire après activation de la sandbox ?

Oui, dès qu’une commande peut modifier l’état du projet, installer un outil, lancer un service ou manipuler une donnée sensible. La sandbox limite une classe d’effets. Elle ne comprend pas la finalité du changement.

Une commande autorisée à écrire dans l’espace de travail peut supprimer des fichiers importants. Elle peut également remplacer une configuration, modifier un script de publication ou produire un artefact qui sera utilisé ensuite par une autre étape. La permission technique et l’approbation métier répondent à deux risques différents.

La règle opérationnelle peut être formulée ainsi :

• lecture et inspection d’un dépôt synthétique : automatisation possible ;
• modification de code dans un dépôt de test : approbation ponctuelle ;
• installation ou mise à jour d’une dépendance : approbation obligatoire ;
• lancement d’un serveur, d’un outil MCP ou d’un script de publication : approbation obligatoire ;
• accès à une ressource contenant un secret : refus par défaut.

Le dépôt officiel distingue la politique de sandbox de la couche d’interaction et d’approbation. Cette séparation confirme qu’un mode de confinement n’a pas vocation à supprimer la gouvernance humaine. (architecture et couches d’interaction)

Réseau et extensions : ne pas confondre les frontières

Le deuxième conflit fréquent concerne le réseau. La présence de Seatbelt ne permet pas d’affirmer que toutes les connexions externes sont bloquées. La documentation actuelle définit les modes de sandbox autour des effets de fichiers et place le réseau en dehors de cette terminologie.

Il faut donc séparer trois questions :

1. le processus local peut-il lire ou écrire le chemin ciblé ?
2. le système ou le pare-feu autorise-t-il la destination réseau ?
3. l’outil externe, le serveur MCP ou le plugin possède-t-il son propre comportement d’accès ?

Un plugin peut recevoir des paramètres, transformer une requête et transmettre une sortie sans que Seatbelt décide si cette action est légitime. Un serveur MCP exécuté à l’extérieur du processus principal peut aussi avoir une politique différente. La frontière doit être testée au niveau du composant réellement lancé.

Pour une première validation, le dépôt de test peut contenir une chaîne sans secret et utiliser deux cibles contrôlées :

curl --fail --silent --show-error https://example.invalid/denied-test
curl --fail --silent --show-error https://example.com/allowed-test

L’objectif n’est pas de démontrer qu’un domaine particulier est autorisé. Il s’agit de vérifier si le comportement observé dépend de Seatbelt, du réseau du Mac, d’un proxy, d’un pare-feu ou de la configuration du plugin.

Rappel : un test réseau qui réussit ne prouve pas que la sandbox est absente, et un test qui échoue ne prouve pas que Seatbelt est responsable. Le journal doit conserver le processus, la commande, la destination, le code de sortie et la règle réseau appliquée.

Pour les workflows audio, vidéo et design, cette nuance est importante. Un Agent peut avoir besoin de récupérer une dépendance, d’appeler un service de conversion ou de transmettre un aperçu. La limitation des écritures locales ne suffit pas à établir la confidentialité du contenu envoyé.

Clés API et journaux : la sandbox ne remplace pas la gestion des secrets

La troisième frontière est celle des identifiants. Une clé API injectée dans l’environnement du processus peut devenir visible à une commande enfant, à un script de diagnostic ou à un journal mal configuré. Une clé placée dans un fichier de configuration peut aussi être lue si ce fichier se trouve dans une zone accessible.

La sandbox ne résout pas automatiquement :

• la portée de la clé ;
• la durée de validité ;
• l’exposition dans env ou les traces ;
• la copie dans un fichier de sortie ;
• la transmission à un outil externe ;
• la rotation après un essai ;
• la différence entre secret de développement et secret de production.

Le dépôt officiel distingue d’ailleurs une capacité de gestion des références de credentials de la capacité de sandbox. Cette séparation doit guider la conception : les secrets sont un contrôle indépendant, pas une conséquence de l’activation de Seatbelt. (package officiel consacré aux credentials)

Pour un essai, la procédure recommandée est la suivante :

export DSH_TEST_TOKEN='valeur-factice-invalide'
env | sed -E 's/(TOKEN|KEY|SECRET)=.*/\1=[REDACTED]/'

Le test doit employer une valeur factice, invalide et facilement révocable. Les journaux doivent être inspectés après l’exécution, notamment dans les sorties d’erreur, les fichiers temporaires, les rapports de session et les artefacts produits par les outils.

Il ne faut jamais publier une vraie clé dans une capture d’écran, un extrait de terminal ou un dépôt de reproduction. Si une clé réelle a été utilisée par erreur, la rotation doit intervenir avant toute nouvelle analyse.

Mac distant : séparation utile, sécurité non automatique

Un Mac distant peut réduire le risque de mélange avec le poste personnel : moins de documents privés dans le même profil, moins d’extensions quotidiennes, moins de sessions ouvertes et moins de dépendances historiques difficiles à inventorier. Cela ne transforme toutefois pas le Mac en environnement sécurisé par défaut.

La responsabilité doit être répartie entre plusieurs plans :

• accès distant : comptes, authentification, ports et durée d’exposition ;
• compte système : privilèges, trousseau, répertoires personnels et sessions ouvertes ;
• espace de travail : dépôt de test, chemins montés et caches ;
• plugins : outils MCP, scripts et services persistants ;
• processus : mode de sandbox, enfants et tâches en arrière-plan ;
• secrets : variables, fichiers, journaux et rotation ;
• récupération : arrêt rapide, suppression du dépôt et retour à une image propre.

Pour documenter les conditions d’accès avant un essai, il est utile de consulter la vue d’ensemble des solutions Mac proposées par SFTPMAC, puis de traiter séparément l’audit de DeepSeek Harness. Ces informations servent à cadrer l’environnement ; elles ne remplacent pas la vérification du compte système, des accès, des extensions et des journaux.

Lorsqu’une équipe doit distinguer la disponibilité d’un poste, son emplacement et ses conditions d’accès, elle peut comparer les caractéristiques d’un environnement Mac distant avec les exigences du projet, sans confondre cette comparaison avec l’audit de sécurité. Pour les essais temporaires, un Mac indépendant peut toutefois limiter le mélange avec le poste de travail habituel. Les conditions opérationnelles générales peuvent être vérifiées dans la présentation des environnements Mac disponibles, tandis que la décision de sécurité doit rester fondée sur les tests de fichiers, de processus, de réseau et de secrets.

Pour un projet peu sensible, un Mac partagé peut convenir avec un compte séparé et un dépôt éphémère. Pour un projet contenant du code propriétaire, un environnement indépendant est préférable. Pour un projet soumis à une exigence réglementaire ou à une politique réseau stricte, l’essai doit être suspendu tant que les preuves de confinement ne sont pas disponibles.

Cinquième étape : conduire la première validation sans données sensibles

Une première campagne peut rester courte, mais elle doit produire des preuves réutilisables. La séquence suivante évite de commencer par un dépôt important.

1. Figer la version et la configuration

Consignez la version de macOS, la version de DeepSeek Harness, le profil chargé, le mode demandé et le chemin de travail. La mention « Seatbelt disponible » n’est pas suffisante. Il faut identifier le backend effectivement utilisé.

2. Préparer un dépôt témoin

Créez un dépôt contenant un fichier lisible, un fichier modifiable et un chemin externe artificiel. N’y placez ni clé, ni historique confidentiel, ni données client.

3. Tester les fichiers

Exécutez une lecture interne, une écriture interne, une écriture externe et une écriture dans la zone temporaire. Conservez les sorties complètes et les codes de retour.

4. Tester les processus enfants

Utilisez un script qui appelle une seconde commande. Vérifiez que la politique observée reste cohérente dans l’arbre de processus et que l’outil enfant ne contourne pas la procédure d’approbation.

5. Tester le réseau séparément

Employez une destination sans donnée sensible et comparez le résultat avec les règles réseau du Mac. Ne concluez pas sur Seatbelt à partir d’un simple échec de connexion.

6. Tester les secrets avec des valeurs factices

Inspectez l’environnement, les journaux et les artefacts. Vérifiez que les valeurs sont masquées ou absentes des sorties persistantes.

7. Préparer le retour arrière

Avant d’élargir les droits, définissez l’action de repli : arrêter l’outil externe, désactiver le plugin, supprimer le dépôt témoin, révoquer la clé factice ou restaurer une machine propre.

Une sortie minimale peut prendre cette forme :

Version macOS              : consignée
Version DeepSeek Harness   : consignée
Backend                    : Seatbelt confirmé / non confirmé
Mode                       : read-only ou workspace-write
Écriture interne           : autorisée / refusée
Écriture externe           : autorisée / refusée
Processus enfant           : testé / non testé
Réseau                     : politique séparée
Secret                     : valeur factice uniquement
Action de repli            : définie / absente
Décision                   : poursuivre / réduire / suspendre

Cette séparation permet de comparer l’environnement local et l’environnement distant sans transformer le choix matériel en conclusion de sécurité. Le compte, le dépôt, les plugins et les processus doivent chacun faire l’objet d’une preuve distincte.

Le choix dépend du niveau de risque

Le résultat de la campagne doit conduire à une décision explicite :

• Poursuivre sur Mac local si le dépôt est peu sensible, le backend est confirmé et les refus attendus sont reproductibles ;
• Poursuivre sur Mac indépendant si l’Agent doit fonctionner longtemps ou si le poste personnel contient trop de données mélangées ;
• Réduire les permissions si les chemins, les processus enfants ou les journaux restent mal compris ;
• Suspendre l’essai si le backend n’est pas confirmé, si une clé réelle a été exposée ou si les outils externes ont un comportement non documenté.

Le mode danger-full-access, documenté comme un contournement du confinement, ne doit pas devenir la solution par défaut à un échec de construction. Si un compilateur ou un outil audio ne fonctionne pas dans l’espace autorisé, il faut d’abord identifier le chemin manquant, le cache nécessaire ou la permission précise. Élargir toute la machine transforme un problème de compatibilité en risque permanent.

Pour les équipes qui veulent aller plus loin, une procédure dédiée au déploiement et à l’exécution distante de DeepSeek Harness sur Mac peut être consultée après la validation des limites de fichiers, de processus, de réseau et de credentials. La séquence compte : choisir la machine avant de comprendre la politique conduit souvent à déplacer le risque sans le réduire.

Ce que cette évolution change réellement pour les développeurs Mac

Seatbelt donne à DeepSeek Harness une base native pour encadrer certaines actions de processus sur macOS. C’est un progrès utile pour les essais de code, les tâches de génération d’artefacts, les pipelines créatifs et les Agents capables d’exécuter des outils locaux.

Mais la valeur réelle ne se mesure pas à la présence du mot « sandbox ». Elle se mesure à la qualité des preuves :

• le backend est-il actif dans la version installée ;
• le chemin d’écriture correspond-il au dépôt prévu ;
• les enfants héritent-ils de la contrainte attendue ;
• le réseau est-il traité par une règle distincte ;
• les secrets sont-ils absents des journaux ;
• l’équipe peut-elle arrêter ou réinitialiser l’environnement rapidement ?

Un Mac local conserve plusieurs inconvénients pour un Agent autorisé à agir : mélange avec les documents personnels, historiques de credentials difficiles à nettoyer et dépendances déjà installées dont la portée est mal connue. Un Mac distant partagé ajoute souvent d’autres défauts : configuration initiale incertaine, comptes qui se chevauchent et responsabilité moins claire sur les extensions et les journaux. Dans ce contexte, un Mac indépendant loué pour un essai temporaire peut offrir une expérience plus propre, à condition de demander une validation séparée de l’accès distant, du compte système, de l’espace de travail et de la politique de processus. Ce n’est pas une garantie automatique ; c’est un moyen de réduire le mélange avec l’environnement personnel avant d’appliquer la même méthode d’acceptation.

La décision raisonnable pour le 18 août 2026 reste donc progressive : confirmer Seatbelt, tester un dépôt sans risque, conserver les approbations, traiter réseau et secrets séparément, puis seulement décider si DeepSeek Harness peut fonctionner sur un Mac partagé, un Mac indépendant ou pas encore.