Sandbox Cursor Agent 2026 : Apple Container par rôle

Un réglage trop large copié pour toute l’équipe peut donner au développeur ordinaire un accès indirect aux scripts de construction, aux caches partagés et aux opérations de publication.

Solution la plus rapide : cette semaine, séparez les rôles dans une matrice, laissez les tâches courantes dans le sandbox natif de Cursor Agent, placez les installations et scripts risqués dans Apple Container, puis exigez une validation humaine et un Mac indépendant pour la signature et la publication.

Qui doit appliquer cette configuration du sandbox d’équipe de Cursor Agent ?

Cet article s’adresse aux responsables de recherche et développement qui doivent fixer une base commune et une procédure d’exception. Il concerne aussi les mainteneurs de dépôt et les ingénieurs de construction qui veulent conserver les dépendances, les tests et les caches sans ouvrir le répertoire personnel.

Les responsables de publication et de sécurité y trouveront surtout une règle de séparation : les certificats, les trousseaux, les jetons de production et les actions irréversibles ne doivent pas entrer dans une session Cursor Agent ordinaire.

Le calendrier de décision commence par quatre niveaux de confiance

Nous recommandons de ne pas choisir un outil unique pour toute l’équipe, mais de faire correspondre le niveau d’isolement à la tâche et à la personne qui en assume le risque.

• Niveau développement : génération de code, analyse statique, tests unitaires et modifications du dépôt courant dans le sandbox local de Cursor.
• Niveau maintenance : migration, génération massive, réécriture automatique et installation de scripts tiers dans une copie temporaire du dépôt, exécutée dans Apple Container.
• Niveau construction : dépendances, services de test et caches avec des exceptions réseau et des montages explicitement enregistrés, sans accès général au domicile.
• Niveau signature et publication : préparation et vérification isolées, puis signature, accès au trousseau et publication dans un environnement Mac contrôlé avec confirmation humaine.

La documentation Apple confirme qu’Apple Container exécute des charges Linux sur Apple Silicon et macOS 26 ; il ne s’agit donc pas d’un conteneur d’applications macOS. La présentation WWDC25 consacrée à Containerization est utile pour comprendre cette frontière. Les outils Xcode natifs, le simulateur, le trousseau et la signature ne peuvent pas être considérés comme automatiquement disponibles dans cette couche Linux.

Règles de décision à inscrire dans la politique d’équipe

• Si la tâche ne touche que le dépôt courant et ne télécharge pas de code arbitraire, choisissez le sandbox natif de Cursor Agent.
• Si elle installe une dépendance inconnue, exécute un script reçu d’un tiers ou réécrit un grand nombre de fichiers, choisissez une copie temporaire dans Apple Container.
• Si elle exige un cache partagé, un registre privé ou un service de test, conservez le sandbox, mais ajoutez seulement les domaines, chemins et variables nécessaires, avec une date d’expiration.
• Si elle lit un certificat, un trousseau, un jeton de production ou un identifiant de publication, refusez l’exécution automatique et transférez l’étape dans un Mac indépendant soumis à approbation.
• Si le résultat doit utiliser une API macOS native, ne forcez pas Apple Container : revenez à un environnement Mac isolé, éventuellement loué pour la durée du besoin.
• Si aucune personne n’est clairement responsable du retour arrière, bloquez l’exception avant le lancement.

Cette liste constitue le premier outil de décision de l’équipe : elle permet de choisir une frontière d’exécution à partir des propriétés de la tâche, et non du seul intitulé du poste.

Le développeur individuel conserve une base de droits minimale

Même lorsqu’il travaille seul, un développeur ne devrait pas activer une exécution sans approbation avec accès complet au système. Les modes d’exécution de Cursor permettent de choisir entre une exécution supervisée et des niveaux plus autonomes ; la documentation officielle des Run Modes doit servir de référence pour le profil par défaut.

Le profil de départ devrait autoriser :

• la lecture du dépôt de travail ;
• l’écriture dans les fichiers suivis du dépôt ;
• les commandes de compilation qui ne modifient pas l’hôte ;
• l’analyse statique ;
• les tests unitaires sans accès aux secrets ;
• les téléchargements vers des domaines de dépendances approuvés, lorsque le projet en a réellement besoin.

Il devrait refuser, ou demander une confirmation explicite pour :

• les suppressions récursives ;
• les modifications hors du dépôt ;
• la lecture du répertoire personnel ;
• l’accès aux répertoires de configuration et d’identifiants ;
• la modification des réglages globaux du système ;
• l’envoi de données vers un domaine qui n’est pas prévu par le projet.

Un dossier de travail « inscriptible » n’est pas synonyme de données récupérables. Avant toute session autonome, nous demandons donc de créer une branche réversible ou une copie vérifiée du dépôt. La protection du système de fichiers et les confirmations de terminal sont décrites dans la documentation Cursor sur le terminal et ses mécanismes de protection. La branche ne protège toutefois pas les fichiers ignorés, les bases locales, les fichiers de configuration ou les données situées hors du dépôt ; ces éléments doivent être sauvegardés séparément.

Pour une application audio ou vidéo, cette distinction est déterminante : les médias sources, les bibliothèques de sons et les projets de montage peuvent être volumineux et situés hors du dépôt. Le modèle sûr consiste à monter une copie de travail limitée, jamais l’ensemble du volume de production.

Les membres chargés du développement utilisent une politique de dépôt

La question de savoir si tous les membres doivent utiliser le même sandbox.json appelle une réponse nuancée : ils peuvent partager une base versionnée, mais ils ne doivent pas recevoir exactement les mêmes exceptions.

La configuration utilisateur répond aux besoins personnels d’un poste ; la configuration du projet formalise la politique de l’équipe. La priorité effective, les champs disponibles et les règles de fusion doivent être vérifiés dans la référence officielle de sandbox.json, car une règle locale ne doit pas neutraliser silencieusement une restriction imposée par l’organisation.

Un modèle de dépôt devrait séparer quatre catégories :

1. Répertoire de travail : lecture et écriture limitées au dépôt courant, sans inclusion automatique du domicile.
2. Partages en lecture seule : documentation interne, jeux de données de test ou bibliothèques nécessaires à une vérification, montés à un chemin dédié.
3. Cache en écriture : uniquement le cache déclaré par le gestionnaire de paquets ou l’outil de construction.
4. Réseau : domaines de téléchargement et services de test identifiés, plutôt qu’un accès général.

Ne montez pas le répertoire personnel complet. Il contient souvent des fichiers de configuration, des historiques de commandes, des clés privées, des jetons et des paramètres d’outils qui n’ont aucun rapport avec la tâche. Le même raisonnement s’applique aux répertoires de type ssh, aux gestionnaires de secrets, aux profils d’infonuagique et aux fichiers d’environnement.

Un extrait de politique lisible peut accompagner le dépôt, même si les noms exacts des champs doivent être contrôlés dans la version de Cursor déployée :

{
  "description": "Politique de développement sans secrets",
  "workspace": {
    "readWrite": ["./"],
    "deny": [
      "~/.ssh",
      "~/.config",
      "~/.aws",
      ".env",
      "secrets"
    ]
  },
  "network": {
    "allow": [
      "registry.npmjs.org",
      "pypi.org"
    ],
    "default": "prompt"
  }
}

Ce fragment n’est pas une autorisation de copier aveuglément une syntaxe : il sert de contrat d’équipe à valider avec les champs documentés. L’équipe doit versionner le fichier, le tester dans un dépôt sans valeur et enregistrer toute différence entre politique attendue et comportement observé.

Les mainteneurs déplacent les scripts à haut risque dans Apple Container

Une migration, une génération de code, une réécriture en masse ou un installateur tiers peut sortir du périmètre du dépôt même si la commande est lancée depuis le bon dossier. Le script peut suivre des liens symboliques, écrire dans un cache global, télécharger un exécutable ou interpréter des paramètres inattendus. Un sandbox de fichiers seul ne fournit pas nécessairement la séparation opérationnelle recherchée pour ce type de tâche.

Le mainteneur doit alors créer une copie temporaire du dépôt, supprimer de cette copie les fichiers inutiles, puis ouvrir uniquement les entrées et sorties nécessaires. Le déroulement recommandé est le suivant :

1. créer une branche ou une archive de référence et vérifier qu’elle peut être restaurée ;
2. fabriquer un répertoire temporaire hors du dépôt original ;
3. copier uniquement les sources et les données de test nécessaires ;
4. lancer Apple Container avec un montage du projet temporaire ;
5. monter les résultats dans un emplacement de sortie distinct, de préférence en lecture seule pour les entrées ;
6. exécuter la migration ou la génération sans certificat, jeton ni répertoire personnel ;
7. comparer les différences, lancer les tests et détruire l’environnement temporaire après validation.

Les possibilités de montage et de volume doivent être contrôlées dans la documentation Apple Container sur les volumes. La conception technique de la couche de virtualisation est également détaillée dans l’architecture officielle de Containerization.

Une commande d’exécution ne doit jamais contenir une vraie clé ou un domaine de production. Nous recommandons des variables factices, des registres de test et un répertoire de sortie sans valeur sensible. Le mainteneur doit aussi documenter le cas de retour arrière : si la migration échoue, la copie est abandonnée et la branche de référence reste intacte.

Apple Container exécute Linux. Il convient donc aux outils portables, aux chaînes de compilation Linux, aux scripts de transformation et à de nombreux services auxiliaires, mais il ne remplace pas une étape qui exige Xcode, un simulateur iOS, une extension macOS, une signature ou un accès au trousseau.

Les ingénieurs de construction encadrent les caches et le réseau

Le rôle de construction est souvent celui qui pousse une équipe à relâcher toutes les protections. Un gestionnaire de paquets a besoin de télécharger des archives, une construction peut contacter un registre privé, les tests peuvent appeler un service local et un cache peut accélérer plusieurs tâches. Ces besoins sont légitimes, mais ils ne justifient ni l’accès global au réseau ni le montage du domicile.

Pour chaque exception, l’ingénieur doit consigner quatre éléments :

• le domaine ou le service précis ;
• le chemin monté et son mode lecture seule ou écriture ;
• le propriétaire de l’exception ;
• la durée pendant laquelle cette ouverture est nécessaire.

La configuration réseau d’Apple Container doit être vérifiée dans son guide officiel du réseau. Nous déconseillons de transformer une indisponibilité du registre en accès illimité permanent. Le pipeline doit prévoir deux replis : l’utilisation d’un cache local déjà validé, ou l’arrêt propre de la tâche avec un rapport indiquant la dépendance manquante.

Le cache doit rester séparé des identifiants. Un répertoire de paquets peut être monté en écriture si la tâche le requiert ; le dossier contenant les jetons du gestionnaire ne doit pas l’être. Pour les projets de design, audio et vidéo, les fichiers lourds doivent aussi être distingués des caches reproductibles : un cache peut être supprimé et reconstruit, alors qu’une source multimédia originale doit rester hors de portée de l’agent.

Nous ne promettons aucun gain de performance sans mesure reproductible. Les documents Apple décrivent l’architecture et les capacités de la solution, mais ils ne constituent pas une mesure universelle de temps de compilation ou de consommation. Toute comparaison interne doit donc préciser le modèle de Mac, la version des outils, la taille du projet et le mode de cache ; sans ces informations, il faut parler d’un comportement observé, pas d’un avantage garanti.

La signature et la publication restent hors de la session ordinaire

Les quatre actions suivantes ne doivent pas être confondues :

• préparer le code ;
• vérifier la construction ;
• signer les artefacts ;
• publier vers un environnement externe.

Les deux premières peuvent être réalisées dans le sandbox Cursor ou dans Apple Container selon le risque. Les deux dernières doivent rester dans un Mac contrôlé, avec approbation humaine et journalisation. Un certificat, une clé privée, un trousseau, un jeton de publication ou un accès de production ne doit pas être monté dans un conteneur générique ni injecté dans le contexte courant de Cursor Agent.

Apple Container ne remplace pas la chaîne macOS native. Même si une construction Linux valide le code, elle ne prouve pas qu’un projet Xcode sera signé correctement, qu’un profil sera accepté ou qu’un paquet pourra être publié. Pour les équipes qui doivent vérifier un flux de publication, notre liste de contrôle de validation des webhooks et d’App Store Connect peut compléter la séparation des responsabilités.

L’étape de publication doit exiger une confirmation portant sur l’artefact exact, la cible, l’identité de signature et le résultat attendu. L’agent peut préparer le manifeste et produire les contrôles, mais il ne doit pas décider seul de l’utilisation d’un secret de production. Si plusieurs personnes publient, la responsabilité du compte et celle de la validation doivent être distinctes.

La plateforme gouverne les exceptions avec une matrice évolutive

Le responsable de plateforme ou de sécurité doit transformer ces règles en profils maintenus, et non en fichier oublié après la première installation.

Pour chaque profil, consignez :

• les commandes et ressources autorisées par défaut ;
• les tâches qui exigent une copie dans Apple Container ;
• les actions interdites à l’exécution automatique ;
• les étapes qui exigent un Mac indépendant ;
• le propriétaire de l’approbation ;
• le test de destruction à effectuer ;
• la procédure de restauration ;
• la date d’expiration de toute exception.

La version du modèle doit être liée au dépôt ou à l’environnement concerné. Une revue régulière doit supprimer les ouvertures devenues inutiles ; sans cette étape, une politique gagne des droits mais n’en perd jamais. Les changements de Cursor concernant les modes d’exécution, la structure de sandbox.json, les stratégies d’équipe, ainsi que les nouvelles versions stables d’Apple Container et de macOS 26, doivent déclencher une nouvelle vérification des champs, des montages, du réseau et des limites de compatibilité.

La procédure d’implantation peut suivre ces sept étapes :

1. inventorier les rôles réels plutôt que les titres administratifs ;
2. classer chaque tâche selon les fichiers, le réseau, les secrets et la réversibilité ;
3. appliquer le profil Cursor minimal au dépôt ;
4. créer une copie de test sans donnée sensible ;
5. tester séparément une dépendance, un script de réécriture, un cache et un échec réseau ;
6. faire valider les exceptions par une personne nommée ;
7. documenter le retour arrière et supprimer les montages après la tâche.

Avant l’activation en production, le responsable peut faire compléter cette liste par chaque équipe :

• [ ] le propriétaire du profil et son remplaçant sont nommés ;
• [ ] le dépôt est récupérable sans dépendre du poste de l’agent ;
• [ ] les répertoires personnels et les identifiants sont refusés ;
• [ ] les domaines réseau autorisés sont documentés ;
• [ ] les caches sont séparés des jetons ;
• [ ] les scripts à haut risque ont un parcours Apple Container ;
• [ ] la signature et la publication exigent une approbation humaine ;
• [ ] l’exception possède une date de fin ;
• [ ] le test de destruction et le retour arrière ont été exécutés ;
• [ ] la suppression des montages a été vérifiée après la tâche.

Si plusieurs équipes travaillent en parallèle sur des dépôts sensibles, un environnement Mac indépendant peut être préférable à l’empilement d’exceptions locales. Pour étudier la gestion des droits dans ce type d’organisation, consultez aussi notre page consacrée à la gestion d’un environnement Mac de développement en équipe, puis vérifiez les conditions réellement disponibles avant toute migration.

Le choix économique dépend de la durée et de la sensibilité

Le sandbox local reste le meilleur choix pour les tâches quotidiennes lorsque le dépôt est récupérable et qu’aucun secret n’est nécessaire. Apple Container ajoute une frontière utile pour les scripts et dépendances à risque, mais il ne résout pas la disponibilité des outils macOS natifs. Enfin, un Mac isolé apporte une séparation plus adaptée à la signature, à la publication, aux dépôts confidentiels et aux tâches parallèles, au prix d’une gestion d’environnement supplémentaire.

Si la charge est permanente, lourde et stable, l’achat et l’administration d’un Mac dédié peuvent être plus cohérents qu’une location ponctuelle. Si elle est temporaire, liée à une version, à une équipe externe, à une campagne de tests ou à une procédure de publication contrôlée, la location d’un Mac peut éviter de mélanger les secrets et les outils critiques avec les postes quotidiens. Il faut alors comparer la durée, la conservation des données, l’accès physique requis et la procédure de restitution, plutôt que comparer uniquement le tarif affiché sur la page de location de Mac de JexMac.

Une configuration unique pour toute l’équipe paraît simple, mais elle cumule trois défauts réels : elle donne aux profils peu risqués des exceptions prévues pour la construction, elle augmente la surface d’exposition des secrets et elle rend les audits difficiles lorsque personne ne sait pourquoi un montage a été ajouté. La combinaison sandbox Cursor pour le quotidien, Apple Container pour les scripts isolables et Mac indépendant pour la signature ou la publication est donc plus facile à expliquer, à révoquer et à restaurer.

Commencez par remplir la matrice de rôles de cet article, puis comparez chaque exception avec la durée et la sensibilité de la tâche. Si votre équipe possède des dépôts sensibles, signe régulièrement des applications ou fait travailler plusieurs agents en parallèle, examinez ensuite une procédure d’environnement Mac indépendant et son contrôle de livraison avant de déplacer le périmètre à haut risque hors des postes des collaborateurs.