2026 Sécurité du sandbox Mac de DeepSeek Harness : liste Seatbelt

Le symptôme est simple : l’agent écrit dans le projet, mais personne ne sait encore ce qu’il ferait avec un chemin voisin, un fichier temporaire ou une permission élargie.

Le choix gagnant est Seatbelt sur Mac pour du code maîtrisé, à condition de valider les écritures, le mode fail-closed et chaque élévation de permission ; pour un dépôt non fiable ou un agent chargé de secrets, il faut passer sur un Mac distant dédié ou une isolation plus forte. La sécurité du sandbox Mac de DeepSeek Harness en 2026 protège surtout les effets sur le système de fichiers. Elle ne constitue pas, à elle seule, une isolation complète de l’hôte, du réseau, des processus ou des identifiants.

Cette page s’adresse aux développeurs qui veulent travailler dans leur répertoire courant, aux ingénieurs sécurité et plateforme qui doivent formaliser une réception technique, ainsi qu’aux responsables d’équipe qui hésitent entre Mac partagé, Mac distant dédié et environnement fortement isolé.

Dernière mise à jour : 21 août 2026. Les informations ont été vérifiées à partir de la page officielle de DeepSeek Harness, du dépôt officiel, de sa documentation des sous-systèmes et de la page des versions publiées.

Le périmètre réel de Seatbelt

DeepSeek Harness utilise un backend local macOS fondé sur Seatbelt et sandbox-exec. La documentation du projet précise que sandbox-exec est obsolète, tout en restant fourni par macOS à ce stade. Cette nuance compte : une dépendance encore disponible n’est pas une garantie de longévité. Le remplacement futur du backend n’est pas confirmé et ne doit pas être présenté comme un événement acquis.

Apple décrit les profils de sandbox comme des politiques qui contrôlent des opérations autorisées ou refusées. Cela ne transforme pas automatiquement chaque commande lancée par un agent en processus totalement cloisonné. La documentation officielle du sous-système sandbox doit donc rester la référence pour la sémantique actuelle des modes et des erreurs.

Le seuil minimal de mise en service est le suivant :

• le mode demandé est réellement appliqué au processus lancé ;
• une écriture dans le répertoire de travail fonctionne seulement quand elle est prévue ;
• une écriture hors périmètre est refusée ;
• une panne du lanceur arrête l’exécution au lieu de retirer silencieusement la protection ;
• une permission plus large exige une justification explicite et une décision d’approbation ;
• les secrets et l’endpoint de modèle ne dépendent pas d’un fichier que l’agent peut modifier.

Un projet personnel, connu et réversible peut rester sur un Mac local après cette validation. Un dépôt téléchargé depuis une source inconnue, un agent partagé par plusieurs personnes ou une tâche qui manipule des clés d’accès doit recevoir une séparation supplémentaire.

Read-only face à workspace-write

Les deux modes utiles pour une première réception ne répondent pas au même besoin.

read-only autorise l’agent à consulter les ressources prévues sans lui donner un espace de modification de travail. workspace-write ajoute l’écriture dans le répertoire de travail autorisé. Le mode danger-full-access, lui, neutralise la contrainte attendue du sandbox et doit rester une exception documentée, jamais une solution à des refus répétitifs. Les capacités exactes doivent être relues dans la documentation officielle des politiques, car un aperçu développeur peut modifier ses interfaces.

Mode	Effet attendu	Test d’acceptation	Décision
read-only	Lecture des ressources prévues, sans modification du projet	Une création, modification ou suppression dans l’espace de travail est refusée	Adapté à l’analyse, à la revue et à la génération de plans
workspace-write	Modification limitée au workspace autorisé	Écriture interne acceptée, écriture externe refusée	Adapté à un projet contrôlé et réversible
danger-full-access	Contraintes de fichiers fortement élargies ou contournées	Vérifier précisément la politique appliquée avant toute exécution	Exception temporaire, jamais mode par défaut

DeepSeek Harness peut-il modifier des fichiers en dehors du workspace sur Mac ?
La réponse ne doit pas être déduite d’un seul affichage dans l’interface. Il faut lancer une opération d’écriture vers un chemin situé hors du workspace, puis vérifier le résultat réel et le code ou message de refus. Le test doit aussi couvrir un chemin temporaire et un chemin obtenu après résolution, car un chemin apparent peut conduire à une autre cible après résolution symbolique, normalisation ou changement de répertoire.

Le premier risque caché est donc la différence entre le chemin présenté à l’utilisateur et le chemin effectivement ouvert par le processus. Le second est l’existence d’outils auxiliaires qui écrivent ailleurs que la commande principale. Le troisième est la confusion entre accès en lecture et effet indirect : produire une archive, générer une miniature audio ou exporter un fichier vidéo peut créer une sortie dans un emplacement différent du dossier inspecté.

Pour les essais, le responsable de plateforme conserve quatre preuves :

1. la politique et le mode demandés ;
2. la commande effectivement transmise au shell ;
3. le chemin cible après résolution ;
4. le résultat observé, y compris le message d’erreur.

La documentation officielle du sous-système Shell complète ce contrôle. Elle aide à distinguer la commande demandée du comportement du lanceur.

La grille de test des chemins

Une réception sérieuse ne se limite pas à créer un fichier dans le projet. Elle vérifie des chemins positifs et négatifs, avec une commande inoffensive et un dossier de test réinitialisable.

Contrôle	read-only	workspace-write	Preuve attendue
Lecture d’un fichier du workspace	Autorisée si le fichier entre dans le périmètre	Autorisée	Sortie de lecture et chemin enregistré
Création dans le workspace	Refusée	Autorisée	Fichier créé uniquement dans le workspace
Modification hors workspace	Refusée	Refusée	Aucun fichier modifié et refus explicite
Écriture dans un dossier temporaire	À vérifier selon la politique effective	À vérifier selon la politique effective	Chemin résolu, résultat et politique
Chemin symbolique ou normalisé	Refusée si la cible finale est hors périmètre	Refusée si la cible finale est hors périmètre	Cible finale inspectée, pas seulement le texte initial

Le dossier temporaire mérite une attention particulière. Certains outils de compilation, de design ou de traitement vidéo y déposent des fichiers intermédiaires. Un refus peut être normal dans read-only, mais il peut aussi signaler que la tâche a été conçue avec une dépendance non déclarée. Il ne faut pas élargir toute la machine pour résoudre ce problème. Il vaut mieux définir un répertoire de travail temporaire précis, puis répéter le test.

Dans un atelier audio ou vidéo, par exemple, le projet peut être maîtrisé alors que les fichiers source résident sur un volume externe ou dans une bibliothèque partagée. Dans ce cas, workspace-write ne doit pas être accepté avant d’avoir cartographié les volumes, les caches et les exports. Pour un travail de design, le même problème apparaît avec les bibliothèques de polices, les fichiers liés et les aperçus générés par un outil tiers.

Rappel d’audit : un refus de fichier prouve seulement que cette opération a été refusée. Il ne prouve ni l’isolation réseau, ni la protection des variables d’environnement, ni la sécurité du fournisseur de modèle.

Le comportement fail-closed

Le point le plus important n’est pas seulement le refus d’un fichier. C’est le comportement de DeepSeek Harness lorsque le runner ne peut pas appliquer sa politique.

La documentation officielle indique un principe fail-closed pour le backend local : si sandbox-exec est absent, non exécutable ou incapable d’accepter la configuration, l’exécution doit échouer avec un état de type SANDBOX_UNAVAILABLE, sans basculer vers une commande non isolée. Cette règle doit être testée dans un environnement de préproduction. Il ne faut pas la remplacer par une intuition du type « une erreur signifie que tout est sûr ».

Trois résultats doivent être classés séparément :

• échec de commande : le programme lancé a renvoyé une erreur ;
• accès refusé : la politique a bloqué une opération de fichier ;
• échec du runner : le mécanisme chargé d’appliquer la politique n’a pas pu fonctionner.

Cette distinction est essentielle pour les tableaux de bord. Un grand nombre d’échecs de commande peut refléter un bug applicatif. Un grand nombre d’accès refusés peut refléter une politique trop étroite. Un runnerFailed ou un SANDBOX_UNAVAILABLE doit déclencher une alerte de plateforme, car la question n’est plus « l’agent a-t-il réussi ? », mais « l’agent a-t-il été lancé dans le cadre attendu ? ».

La procédure de validation comporte au moins cinq étapes :

1. enregistrer le mode demandé et le profil de politique ;
2. exécuter une commande sans effet dangereux pour confirmer le fonctionnement nominal ;
3. provoquer un refus contrôlé sur un chemin hors workspace ;
4. rendre le lanceur indisponible dans un environnement de test, sans toucher au Mac de production ;
5. vérifier que l’agent reçoit l’erreur d’indisponibilité et qu’aucune exécution de secours ne démarre hors sandbox.

Si le test quatre déclenche une exécution non isolée, le déploiement est rejeté. Si le résultat est ambigu, le déploiement est également suspendu jusqu’à inspection du code et reproduction. L’absence de preuve n’est pas une preuve de fail-closed.

Les permissions élargies

Un agent peut rencontrer un refus légitime et demander une politique plus large. Le danger commence lorsque cette demande devient automatique, vague ou persistante.

Chaque demande de sandbox_permissions doit comporter une justification concrète : fichier ciblé, opération prévue, durée de l’autorisation et raison pour laquelle le workspace déclaré ne suffit pas. Une formulation générale comme « nécessaire au fonctionnement » ne permet pas une décision de sécurité.

La réception vérifie quatre comportements :

• une demande refusée n’exécute pas la commande ;
• une demande annulée n’exécute pas la commande ;
• un service d’approbation indisponible ne provoque pas d’exécution de secours ;
• une approbation ponctuelle ne s’applique pas automatiquement à l’appel suivant.

danger-full-access est particulièrement sensible. Il peut résoudre un blocage opérationnel, mais il supprime précisément la contrainte que l’équipe cherche à valider. Il doit donc être réservé à une intervention courte, enregistrée, supervisée et suivie d’une restauration du mode restreint.

Les équipes qui partagent un Mac doivent aussi empêcher qu’un utilisateur transforme une approbation ponctuelle en privilège permanent. La console, les journaux d’approbation et les fichiers de configuration doivent être traités comme des éléments de contrôle. Un projet modifiable par l’agent ne doit pas pouvoir réécrire la règle qui décide de ses propres permissions.

Les identifiants et l’endpoint V4

Le sandbox concerne principalement les effets locaux. Il ne suffit pas à sécuriser une requête adressée à un modèle ou une clé placée dans l’environnement.

DeepSeek Harness permet de configurer un fournisseur compatible avec l’interface OpenAI. La documentation officielle des fournisseurs doit être utilisée pour vérifier les noms de champs, l’identifiant du fournisseur, le base URL et la source des identifiants. Un endpoint auto-hébergé DeepSeek V4 doit être considéré comme un composant distinct du Mac qui exécute l’agent.

L’architecture de référence sépare donc :

• le Mac hôte et son système de fichiers ;
• le runtime DeepSeek Harness ;
• le workspace modifiable ;
• le service d’approbation des permissions ;
• l’endpoint d’inférence auto-hébergé ;
• le coffre ou mécanisme qui fournit les identifiants ;
• les journaux et leur durée de conservation.

Comment éviter qu’une configuration de projet détourne la clé API ou l’endpoint auto-hébergé ?
La configuration modifiable par l’agent ne doit pas être la source d’autorité pour une clé sensible. Le base URL utilisé par un fournisseur de confiance doit être fixé hors du workspace, validé avant l’appel et journalisé sans exposer le secret. Une modification de fichier de projet doit produire une demande d’approbation, pas changer silencieusement le serveur ou le fournisseur.

Il faut ensuite vérifier les journaux. Une clé ne doit pas apparaître dans la sortie de commande, les traces de débogage, les messages d’erreur ou les artefacts générés. Le fait que Harness soit distribué sous licence MIT ne signifie pas que l’appel au modèle, l’inférence auto-hébergée ou le Mac d’exécution sont gratuits. La licence du runtime et le coût ou le contrôle du service de modèle sont deux sujets différents. La page officielle de DeepSeek Harness décrit le positionnement du produit, mais la configuration effective doit rester alignée sur la documentation technique actuelle.

Le choix entre Mac local et Mac distant

Le bon environnement dépend moins de la puissance brute que de la confiance accordée au code et de la capacité à réinitialiser l’environnement.

Situation	Mac local contrôlé	Mac distant dédié	Isolation supérieure
Code personnel et connu	Possible après les tests Seatbelt	Utile pour une exécution continue	Généralement disproportionnée
Dépôt externe non fiable	Déconseillé	Minimum préférable, avec accès limité	Recommandée si l’exposition est forte
Plusieurs utilisateurs	Risque de mélange des profils et secrets	Séparation par machine et compte	À envisager pour des projets sensibles
Agent actif sur une longue durée	Dépend de la supervision et du nettoyage	Plus simple à réinitialiser et surveiller	Préférable si la reprise doit être garantie
Endpoint V4 et identifiants sensibles	À séparer strictement du workspace	Plus facile à isoler dans une machine dédiée	Adaptée aux exigences de conformité élevées
Besoin d’interface physique locale	Avantage au Mac local	Possible seulement si l’environnement distant l’expose	À étudier selon le matériel requis

Un Mac partagé cumule plusieurs coûts invisibles : état résiduel des projets, profils d’utilisateurs mélangés, clés oubliées dans l’environnement, approbations difficiles à attribuer et restauration manuelle après un échec. Un Mac distant dédié réduit ces mélanges, mais il ne dispense pas de tester Seatbelt. Il améliore surtout la séparation opérationnelle, la rotation de l’environnement et la traçabilité.

Le score de décision peut rester qualitatif. Classez chaque projet selon cinq axes : confiance dans le code, nombre d’utilisateurs, durée d’exécution, sensibilité des identifiants et exigence de reprise après incident. Si un seul axe est élevé, un Mac local n’est acceptable qu’après une preuve complète. Si plusieurs axes sont élevés, un Mac distant dédié devient le choix raisonnable. Si l’équipe ne peut pas démontrer le périmètre effectif ou si le dépôt est franchement non fiable, le déploiement doit être suspendu au profit d’une isolation plus forte.

Les tâches créatives illustrent bien cette limite. Un agent qui prépare des pistes audio, encode une vidéo ou produit des variantes de design peut avoir besoin de caches et de volumes supplémentaires. Cela ne justifie pas de lui ouvrir toute la machine. Le périmètre doit être étendu à des répertoires explicitement identifiés, avec des fichiers de sortie séparés et une purge contrôlée.

Le statut de la version

Au 21 août 2026, DeepSeek Harness est toujours présenté comme un developer preview. Le projet avertit que des changements incompatibles peuvent survenir. La page des versions officielles disponibles indique comme version visible la plus récente v0.1.0-rc.8, publiée le 19 août 2026, en préversion.

Cette information change la méthode d’exploitation. Une équipe ne doit pas traiter la politique actuelle comme un contrat stable. Elle doit conserver un test de non-régression pour les quatre familles de chemins, le fail-closed, les permissions et les fournisseurs. Après une version candidate, une version stable, un changement de backend sandbox ou une modification du statut de sandbox-exec, les tests sont relancés avant remise en service.

Un contrôle de confidentialité et de gestion des données doit également compléter l’audit technique lorsque l’agent traite des fichiers de clients ou des productions audio, vidéo et graphiques. La politique locale du sandbox ne remplace pas les règles de conservation et de partage des données.

La décision de mise en service

La validation peut être donnée uniquement lorsque les quatre preuves suivantes sont archivées :

• read-only bloque les modifications prévues ;
• workspace-write autorise l’écriture interne sans élargir la cible réelle ;
• l’indisponibilité du runner bloque l’exécution ;
• toute permission plus large est ponctuelle, justifiée et refusée par défaut en cas d’ambiguïté.

À cela s’ajoutent deux conditions d’architecture : le projet ne peut pas réécrire les paramètres de confiance du fournisseur, et les secrets ne résident pas dans une zone modifiable par l’agent. Si ces éléments manquent, le problème n’est pas corrigé par une simple modification de commande.

Dans la pratique, le Mac local reste pertinent pour un projet personnel, peu sensible et surveillé. Le Mac partagé devient difficile à défendre dès que plusieurs utilisateurs, des tâches longues ou des secrets d’équipe entrent en jeu. Le Mac distant dédié prend l’avantage lorsque la réinitialisation, l’accès limité et la continuité d’exécution comptent davantage que la proximité physique. Pour un dépôt non fiable, aucune case Seatbelt ne doit être utilisée pour prétendre à une isolation complète.

Un Mac local ou partagé impose souvent une disponibilité intermittente, conserve un état résiduel entre les projets et mélange plus facilement fichiers de travail, caches et identifiants. Il demande aussi une surveillance et une remise à zéro manuelles. Lorsque ces limites empêchent de fournir une machine dédiée, persistante et réinitialisable, louer un Mac distant auprès de ProxyMac offre un cadre plus propre pour exécuter l’agent, séparer le workspace du poste quotidien et maintenir l’endpoint de modèle hors des fichiers modifiables. Les conditions d’utilisation de l’environnement peuvent être vérifiées dans les conditions de ProxyMac.

Avant toute demande, l’équipe devrait copier cette grille dans son registre de changement, joindre les résultats des essais de chemins et préciser si le projet est contrôlé ou non fiable. Pour un besoin temporaire de calcul, de test d’agent ou de validation d’un endpoint auto-hébergé, la console ProxyMac permet ensuite d’évaluer un Mac distant sans confondre l’outil de location avec la preuve de sécurité : celle-ci reste le résultat des tests Seatbelt, du contrôle des permissions et de la séparation des identifiants.