Les workflows Anthropic Cursor mettent les paramètres par défaut sécurisés et privés sous pression

Les workflows Anthropic Cursor font désormais face à une exigence directe des développeurs : faire des protections de sécurité et de confidentialité la norme avant que les agents d’IA ne reçoivent un accès étendu. Cette demande est importante, car ces outils ne se contentent plus de proposer des suggestions. Ils peuvent lire des dépôts, modifier des fichiers, exécuter des commandes, contacter des services externes et agir au moyen des identifiants d’un développeur.

La couverture de The Register place Anthropic, OpenAI, Cursor et leurs pairs sous les mêmes projecteurs. Leurs produits diffèrent, mais le conflit de fond est commun. Les fournisseurs veulent des agents capables d’agir avec moins de friction, tandis que les développeurs ont besoin de limites prévisibles sur la collecte de données et l’accès aux systèmes.

Cette tension est devenue plus difficile à écarter comme un simple problème de configuration avancée. Des chercheurs en sécurité ont découvert des vulnérabilités qui franchissent les frontières entre espaces de travail ou manipulent les validations des agents. Les fournisseurs ont également introduit des modes de confidentialité, des sandboxes, des invites d’autorisation et des contrôles d’entreprise. Le débat porte sur la nécessité pour les utilisateurs de découvrir et d’activer eux-mêmes ces protections.

Les développeurs veulent que les paramètres par défaut assument davantage le risque

L’exigence centrale est simple : un agent de codage devrait commencer avec des autorisations limitées, une conservation minimale des données et un consentement explicite pour les actions sensibles.

Cette norme paraît prudente jusqu’à ce que l’on considère l’environnement d’exécution de l’agent. Un outil d’autocomplétion classique propose du texte dans un éditeur. Un agent peut examiner plusieurs fichiers, appeler des programmes en terminal, installer des paquets, contacter des serveurs et modifier un projet en plusieurs étapes.

Ces capacités rendent le codage assisté par IA utile. Elles signifient aussi qu’une seule approbation erronée peut autoriser une chaîne d’actions que peu d’utilisateurs pourraient anticiper. Une boîte de dialogue d’autorisation peut nommer la première commande sans révéler toutes les conséquences qui s’ensuivent.

Le risque devient plus clair lorsqu’un dépôt contient lui-même des instructions hostiles. L’injection de prompt se produit lorsqu’un contenu non fiable influence un système d’IA afin qu’il suive les directives d’un attaquant. Dans un workflow de codage, ce contenu peut provenir de documentation, de descriptions de tickets, de fichiers source, de métadonnées de paquets ou d’outils connectés.

Un développeur n’a pas besoin de demander un malware. L’agent peut rencontrer des instructions lors de l’exécution d’une tâche légitime, puis les traiter comme du contexte de projet pertinent. S’il dispose aussi d’un accès au shell et au réseau, un document trompeur peut devenir une voie d’exécution.

Des recherches divulguées en juillet illustrent pourquoi la conception des autorisations est importante. La faille GhostApproval a touché plusieurs assistants de codage majeurs, dont Claude Code et Cursor. Les chercheurs ont indiqué que ce schéma pouvait amener les agents à atteindre des fichiers en dehors de leur espace de travail prévu.

Amazon, Cursor et Google ont traité le problème signalé comme critique ou de gravité élevée et ont publié des correctifs ou commencé à les suivre. D’autres fournisseurs concernés ont réagi différemment, selon le rapport. Rien n’indiquait publiquement que des attaquants avaient exploité cette faille dans la nature.

La divulgation a néanmoins révélé une faiblesse structurelle. L’approbation humaine ne garantit pas la sécurité lorsque l’interface décrit un objet alors que le système sous-jacent en atteint un autre. Un utilisateur peut approuver l’opération visible sans comprendre sa portée effective.

C’est pourquoi les développeurs contestent l’hypothèse selon laquelle les invites d’autorisation transfèrent la responsabilité à la personne qui clique dessus. Le consentement ne fonctionne que lorsqu’il est spécifique, éclairé et lié à l’action qui se produit réellement.

Le même principe s’applique à l’utilisation des données. Le code source peut révéler des produits non publiés, une architecture interne, des relations clients, des identifiants et des contrôles de sécurité. L’envoyer à un fournisseur de modèles externe n’équivaut pas à partager un message de chat ordinaire.

Certaines organisations peuvent négocier des accords d’entreprise ou déployer des contrôles centralisés. Les développeurs indépendants et les petites équipes s’appuient généralement sur les paramètres grand public et la documentation publique. Ils portent donc une responsabilité plus grande pour déterminer quelles règles s’appliquent selon le produit, le compte et le fournisseur de modèles.

La demande de paramètres par défaut plus sûrs ne signifie pas que chaque agent doit rester passif. Elle signifie qu’une autorité plus étendue doit nécessiter une décision délibérée. Cela inverse la charge actuelle : le produit doit mériter l’accès au lieu d’obliger l’utilisateur à le retirer.

Les paramètres de confidentialité d’Anthropic Cursor dépendent toujours du contexte

Les libellés de confidentialité peuvent masquer plusieurs décisions distinctes concernant la collecte, la conservation, l’entraînement des modèles, l’indexation et le traitement par des tiers.

Cursor propose un Privacy Mode qui modifie la manière dont les données clients sont traitées. Son actuel aperçu de l’utilisation des données indique que les données ne sont pas utilisées pour l’entraînement par Cursor lorsque ce mode est activé. La page renvoie également les utilisateurs vers les fournisseurs de modèles pour obtenir des détails sur leurs pratiques de conservation.

Cette distinction est importante, car Cursor peut acheminer les requêtes vers des modèles fournis par des entreprises telles qu’Anthropic et OpenAI. L’éditeur, ses fournisseurs d’infrastructure et le fournisseur de modèle sélectionné peuvent chacun occuper une position différente dans le parcours des données.

Un utilisateur qui sélectionne un modèle Anthropic dans Cursor n’utilise pas nécessairement le même dispositif de données qu’un client commercial de l’API Anthropic. Le type de compte, le parcours produit, le paramètre de confidentialité et le contrat peuvent tous modifier la réponse.

Cursor indique également que la désactivation du Privacy Mode l’autorise à stocker ou utiliser des données de codebase, des prompts, des actions dans l’éditeur, des extraits de code et l’activité associée. Un développeur doit donc comprendre à la fois le paramètre et ses effets en aval avant d’ouvrir un dépôt sensible.

L’expression « mode de confidentialité » fournit un signal utile, mais elle ne peut pas expliquer toute la chaîne de traitement. Elle ne répond pas automatiquement à la question de l’existence de journaux temporaires, des sous-traitants qui reçoivent les données ou de la façon dont un fournisseur de modèles externe gère la surveillance des abus.

Anthropic applique de même des règles différentes selon ses produits grand public et commerciaux. Sa documentation sur la conservation indique que le contenu ordinaire des prompts et des sorties envoyé via son API commerciale n’est pas conservé par défaut, sous réserve des exceptions documentées.

Claude Code peut bénéficier d’une conservation zéro des données lorsqu’il est utilisé dans le cadre d’accords commerciaux éligibles. Les comptes Claude grand public sont soumis à des contrôles de confidentialité et à des conditions de conservation différents. Les environnements d’entreprise gérés peuvent appliquer des politiques à l’échelle de l’organisation que les utilisateurs individuels ne peuvent pas outrepasser.

Ces distinctions créent une charge de formation au moment même où les agents deviennent plus faciles à installer. Un développeur peut commencer à utiliser un agent de terminal en quelques minutes. Comprendre toutes les frontières de confidentialité applicables prend bien plus de temps.

Les paramètres de confidentialité interagissent également avec la télémétrie produit facultative. La documentation de Claude Code d’Anthropic identifie certaines métriques comme activées par défaut tout en fournissant des contrôles pour le trafic non essentiel. Les analyses produit ne sont pas équivalentes au contenu d’un dépôt, mais les utilisateurs ont tout de même besoin d’un inventaire clair des données sortantes.

L’interface idéale séparerait ces catégories. Elle indiquerait si l’outil envoie des prompts, des fichiers source, des chemins de fichiers, des sorties de commande, des journaux de plantage, des métriques d’utilisation ou des retours. Chaque catégorie préciserait sa destination et sa règle de conservation.

Un seul interrupteur communique rarement ce niveau de détail. Il peut aussi encourager une pensée binaire, dans laquelle un outil est étiqueté comme privé ou non privé. L’exposition réelle dépend de l’ensemble du workflow.

L’indexation des dépôts fournit un autre exemple. Un éditeur IA a besoin d’une carte de la base de code pour récupérer le contexte pertinent. Ce processus peut rester local, transmettre des informations dérivées, téléverser du contenu sélectionné ou combiner ces méthodes.

Le hachage et l’obfuscation des chemins peuvent réduire l’exposition, mais leur valeur dépend de l’implémentation et des hypothèses de menace. Ils n’éliminent pas la sensibilité du code sélectionné ultérieurement pour une requête d’IA.

La relation entre Anthropic et Cursor rend ces frontières particulièrement importantes. Une entreprise peut fournir l’interface et l’orchestration, tandis qu’une autre fournit le modèle. La responsabilité devient répartie, même si le développeur perçoit une seule fonctionnalité dans une seule fenêtre.

OpenAI Codex et d’autres agents soulèvent des questions similaires. Le secteur a donc besoin de divulgations comparables, et non d’une nouvelle collection de libellés de confidentialité incompatibles. Un développeur devrait pouvoir comparer les produits sans devoir d’abord traduire la terminologie de chaque fournisseur.

Un paramètre privé significatif par défaut minimiserait le contenu stocké, exclurait les données clients de l’entraînement et expliquerait les traitements inévitables avant l’activation. Il préserverait également ces garanties lorsque les utilisateurs changent de modèle dans la même application.

Les invites d’autorisation ne peuvent pas corriger un modèle d’exécution non sécurisé

Un paramètre sécurisé par défaut doit limiter ce qu’un agent peut faire après approbation, et non simplement demander s’il peut commencer.

Anthropic indique que Claude Code demande une autorisation avant les commandes et les modifications de fichiers selon son modèle d’autorisations standard. Sa description du mode auto présente une autonomie plus large comme une option explicite plutôt que comme l’état initial.

Le mode auto utilise un classificateur pour examiner les appels d’outils à la recherche d’actions potentiellement nuisibles. Anthropic indique que le classificateur recherche des comportements tels que des opérations destructrices sur les fichiers, l’exfiltration de données et l’exécution de commandes malveillantes.

Cette conception reconnaît un fait important. Les utilisateurs ne peuvent pas superviser chaque action de bas niveau une fois qu’un agent commence une tâche longue. Un second contrôle technique doit continuer à vérifier le comportement après la demande initiale.

Toutefois, un classificateur reste une protection probabiliste. Il peut mal interpréter le contexte, manquer une opération déguisée ou bloquer un travail légitime. Il doit compléter l’isolation du système d’exploitation et des identifiants limités, et non les remplacer.

Le sandboxing offre une frontière plus robuste en limitant les fichiers, processus et destinations réseau accessibles à un agent. Une sandbox efficace peut limiter les dégâts même lorsque le modèle suit des instructions hostiles.

La difficulté consiste à rendre cette frontière utile. Les tâches de codage ont souvent besoin de registres de paquets, de services de test, de documentation, de contrôle de version et de ressources cloud. Chaque exception étend l’environnement accessible par l’agent.

Une autorisation réseau étendue peut rendre une restriction sur les fichiers moins pertinente. Un agent peut ne pas lire directement un répertoire protégé, mais les sorties de commande ou les outils connectés peuvent exposer des informations similaires. Les contrôles de sécurité doivent suivre les données tout au long de la chaîne d’outils.

Les identifiants constituent un autre point faible. Les développeurs conservent souvent des jetons d’accès dans des variables d’environnement, des fichiers de configuration, des gestionnaires de mots de passe, des historiques de commandes ou des outils cloud. Un agent opérant avec l’identité de l’utilisateur peut rencontrer ces secrets lors de l’exécution d’un travail ordinaire.

Le principe du moindre privilège consiste à n’accorder à l’agent que l’autorité nécessaire à une tâche donnée. En pratique, cela pourrait signifier un identifiant temporaire limité à un dépôt, une branche et une courte durée de vie.

Cette approche entre en conflit avec la commodité. Les identifiants persistants réduisent le temps de configuration, et un accès étendu évite que les tâches ne s’arrêtent pour demander une approbation supplémentaire. Ces mêmes caractéristiques augmentent aussi l’impact d’une session compromise.

Les agents d’IA intensifient un compromis de sécurité ancien plutôt que d’en créer un entièrement nouveau. Les scripts shell, outils de build, extensions de navigateur et gestionnaires de paquets disposent depuis longtemps d’autorisations importantes. La différence est que les agents choisissent leurs actions de façon dynamique à partir d’un contexte en langage naturel.

Les logiciels traditionnels exécutent normalement un chemin écrit et revu avant leur publication. Un agent construit son chemin pendant la tâche. Son comportement peut changer lorsqu’il lit un nouveau fichier ou reçoit un résultat d’un outil externe.

Cette exécution adaptative rend les listes d’autorisation statiques nécessaires, mais incomplètes. Une commande peut être autorisée tandis que ses arguments restent dangereux. Un programme de confiance peut également devenir nuisible lorsqu’il est dirigé vers un répertoire inattendu ou reçoit une entrée contrôlée par un attaquant.

L’approbation humaine a sa place, en particulier avant des opérations irréversibles. Pourtant, un excès de demandes entraîne une fatigue d’approbation. Les utilisateurs commencent à accepter automatiquement les requêtes habituelles, transformant ainsi un mécanisme de sécurité en obstacle muni d’un bouton de confirmation.

De meilleurs paramètres par défaut classifieraient les actions selon leurs conséquences. La lecture d’un fichier source public ne devrait pas recevoir le même traitement que l’exportation de variables d’environnement. L’exécution de tests unitaires devrait se distinguer du déploiement de code ou de la modification d’une base de données de production.

L’agent devrait également expliquer pourquoi une action est nécessaire et quelles données elle peut toucher. Cette explication doit provenir de la couche d’application des règles, et non uniquement du modèle qui demande l’autorisation.

Les journaux d’audit sont tout aussi importants. Les équipes ont besoin d’un historique durable des commandes, modifications de fichiers, appels d’outils, requêtes réseau, approbations et usages d’identité. Sans cet historique, l’enquête sur un incident se réduit à une reconstitution à partir d’un historique de terminal incomplet.

Un historique consultable améliore également les revues de routine. Les équipes d’ingénierie peuvent conserver les décisions des agents aux côtés de leur documentation technique locale dans une base de connaissances consultable. Cela ne remplace pas la journalisation de sécurité, mais aide à relier les changements au contexte du projet.

L’objectif n’est pas d’entourer chaque suggestion d’avertissements. Il est de faire du comportement sûr le chemin qui oppose le moins de résistance. Un accès plus large doit rester possible, mais sa portée et ses conséquences doivent être visibles.

Les fournisseurs ajoutent des contrôles, mais la responsabilité reste fragmentée

Anthropic, Cursor et OpenAI répondent à la pression en matière de sécurité, mais leurs contrôles laissent toujours aux clients le soin d’assembler une défense complète.

Cursor a publié de la documentation sur la sécurité et la confidentialité, corrigé des vulnérabilités signalées et ajouté des contrôles pour les organisations traitant du code sensible. L’entreprise s’est également associée à la société de chaîne d’approvisionnement logicielle Chainguard en 2026.

Selon des informations publiées sur l’initiative de sécurité de Cursor, ce partenariat vise à orienter le code généré vers des composants open source validés. Cela répond à une couche différente de l’injection de prompt ou de la rétention des données.

Le risque lié à la chaîne d’approvisionnement logicielle apparaît lorsqu’un agent recommande une dépendance vulnérable, abandonnée ou malveillante. Les noms de paquets peuvent comporter des fautes de frappe, être inventés ou être délibérément conçus pour ressembler à des projets légitimes.

Un agent peut installer un tel paquet plus rapidement qu’un développeur ne pourrait le trouver et l’évaluer manuellement. Un catalogue validé réduit cette exposition, mais ne contrôle pas ce que l’agent installé peut lire ni les destinations auxquelles il peut se connecter.

Anthropic a étendu la documentation de sécurité de Claude Code, ses options de sandboxing, ses paramètres gérés et ses modes d’autorisation. L’entreprise avertit également les utilisateurs d’appliquer les pratiques de sécurité habituelles autour des outils d’IA.

OpenAI et d’autres fournisseurs proposent des contrôles comparables autour des environnements Codex, des approbations et de l’administration en entreprise. Les fonctionnalités exactes continuent d’évoluer, ce qui rend la documentation actuelle plus précieuse que les paramètres par défaut dont on se souvient.

Ces efforts affaiblissent la critique la plus simple selon laquelle les fournisseurs ignorent la sécurité. Ils consacrent du temps d’ingénierie au confinement, aux classificateurs, à la surveillance et à la réponse aux vulnérabilités. Plusieurs ont corrigé des problèmes graves après une divulgation responsable.

La critique plus incisive concerne l’architecture et les incitations. Les fournisseurs se disputent sur la quantité de travail qu’un agent accomplit sans interruption. Les équipes de sécurité mesurent leur succès en limitant les accès non approuvés et en préservant les éléments de preuve.

Une démonstration de produit récompense la rapidité. Elle montre rarement le périmètre des identifiants, la vérification de la rétention, la reconstitution d’incidents ou le travail administratif nécessaire avant un déploiement. Les acheteurs peuvent donc évaluer les capacités avant de comprendre leur exposition.

Les clients d’entreprise peuvent combler certaines lacunes grâce aux contrôles d’endpoint, aux espaces de travail isolés, aux politiques réseau et aux passerelles de modèles approuvées. Ils peuvent interdire les comptes grand public et imposer des configurations gérées dans l’ensemble des équipes.

Les petites organisations ne peuvent souvent pas construire cette couche. Elles dépendent davantage des choix initiaux du fournisseur. Un paramètre par défaut acceptable dans un environnement d’entreprise géré peut être dangereux sur un ordinateur portable non géré.

Le marché fragmenté encourage également le changement d’outils. Un développeur peut utiliser Cursor pour l’édition, Claude Code pour le travail en terminal et Codex pour une tâche isolée. Chaque outil peut maintenir des autorisations, instructions, historiques et règles de confidentialité distincts.

La configuration au niveau du projet aide à standardiser les comportements au sein d’un dépôt. Pourtant, les paramètres personnels, politiques d’organisation, plugins et services connectés peuvent encore modifier l’environnement effectif.

Cela fait de la configuration elle-même une partie de la surface d’attaque. Les chercheurs qui étudient les outils de codage agentiques ont documenté un ensemble croissant de formats d’instructions au niveau des dépôts. Ces fichiers peuvent améliorer la cohérence, mais des instructions non fiables peuvent également influencer le comportement d’un agent.

Les équipes de sécurité ont besoin d’une couche de politiques indépendante des outils. Elle devrait définir les dépôts auxquels un agent peut accéder, les destinations qu’il peut contacter et les actions nécessitant une autorisation humaine.

Les fournisseurs pourraient résister à une couche commune si elle affaiblit la différenciation de leurs produits. Les clients devraient néanmoins exiger des journaux portables, des informations explicites sur les flux de données et des paramètres applicables en dehors d’une interface unique.

Le marché dispose de précédents historiques. Les navigateurs web ont fini par normaliser les demandes d’autorisation, le sandboxing, l’isolation des sites et des contrôles de confidentialité visibles. Les systèmes d’exploitation mobiles ont placé les accès sensibles derrière des catégories d’autorisation standardisées.

Ces systèmes restent imparfaits. Leur évolution montre néanmoins à quoi ressemblent des paramètres par défaut matures. Les applications demandent des capacités précises, les systèmes d’exploitation appliquent la limite, et les utilisateurs peuvent examiner ou révoquer l’accès ultérieurement.

Les agents de codage ont besoin d’un modèle équivalent pour les dépôts, terminaux, secrets, réseaux, déploiements et outils externes. Un simple réglage propre à un fournisseur ne peut pas fournir toute cette structure.

Le moment actuel n’est donc pas un choix entre Anthropic et Cursor, ni entre Claude Code et Codex. L’opposition plus profonde est celle entre une autonomie guidée par la commodité et des limites applicables.

La concurrence peut aider si les clients récompensent l’entreprise qui offre des frontières plus claires. Elle peut nuire si les benchmarks et démonstrations valorisent la vitesse d’exécution tout en traitant les étapes de sécurité comme des frictions.

Ce que le codage IA sécurisé doit démontrer ensuite

Le prochain test sera de savoir si les fournisseurs transforment des contrôles facultatifs en paramètres par défaut mesurables sans rendre leurs agents inutilisables.

Le premier signal viendra des changements d’autorisations dans les versions de produits. Les développeurs devraient surveiller si les agents commencent à opérer dans des espaces de travail restreints, avec l’accès réseau et les chemins sensibles bloqués jusqu’à leur activation explicite.

Un paramètre par défaut plus robuste lierait l’approbation à la ressource exacte consultée. Il invaliderait cette approbation lorsqu’un lien symbolique, un changement de configuration ou une mise à jour du dépôt modifie la signification de cette ressource.

Cela renforcerait l’argument selon lequel les fournisseurs acceptent la responsabilité de l’application des règles. Une nouvelle vague de vulnérabilités permettant de contourner les approbations l’affaiblirait, même si les correctifs arrivaient rapidement.

Le deuxième signal sera constitué d’informations comparables sur la confidentialité. Les utilisateurs ont besoin d’une vue unique indiquant quelles données quittent l’appareil, qui les reçoit, pourquoi elles sont traitées et quand elles sont supprimées.

Le changement de modèle devrait mettre à jour cette vue avant l’exécution d’une requête. Une interface ne devrait pas laisser entendre qu’une garantie de confidentialité s’applique automatiquement à tous les fournisseurs proposés dans son menu.

Les clients devraient également vérifier si les pratiques privées restent cohérentes entre les produits grand public, d’équipe, d’entreprise et d’API. Les différences contractuelles sont inévitables, mais des revirements surprenants entre types de comptes créent un risque évitable.

Le troisième signal viendra de l’adoption en entreprise et du signalement des incidents. Les équipes de sécurité révéleront si les contrôles des agents fonctionnent en conditions réelles, y compris avec des dépôts mixtes, des identifiants anciens et des systèmes cloud connectés.

Les travaux évalués par les pairs vont déjà au-delà des avertissements abstraits. L’étude IssueTrojanBench évalue la manière dont les principaux agents de codage répondent à des demandes malveillantes dans des issues. Les résultats de tels benchmarks peuvent vérifier si les garde-fous résistent à un contenu de projet adversarial.

Les évaluations utiles devraient mesurer davantage que le simple refus par l’agent d’un prompt manifestement malveillant. Elles devraient examiner les instructions indirectes, les attaques en plusieurs étapes, les mouvements de données, l’ambiguïté des autorisations et la récupération après le début d’une action dangereuse.

La transparence sur les incidents compte autant que les performances aux benchmarks. Les fournisseurs devraient divulguer quel contrôle a échoué, quelles versions étaient concernées et si les journaux permettent d’identifier l’exposition. Les clients ne peuvent pas améliorer leurs défenses à partir d’un simple avis de correctif.

Les développeurs ont également des responsabilités pendant que le marché mûrit. Les dépôts sensibles devraient utiliser des comptes approuvés, des paramètres de rétention documentés, des environnements isolés et des identifiants à portée étroite.

La sortie de l’agent devrait passer par les mêmes contrôles de revue, de test et de déploiement que les changements écrits par des humains. L’aisance rédactionnelle n’établit pas la justesse, et des tests réussis ne prouvent pas qu’un changement est sécurisé.

Les équipes devraient supposer que le contenu d’un dépôt peut être hostile. Les projets externes, textes d’issues, documentation générée et instructions de paquets méritent la même prudence que du contenu web non fiable.

Ce modèle opérationnel est exigeant, mais il ne devrait pas devenir la réponse permanente. Les fournisseurs sont mieux placés pour imposer des conditions initiales sûres à travers des millions de sessions.

La pression exercée sur les flux de travail Anthropic Cursor reflète ce déséquilibre. Les utilisateurs font actuellement des choix de produits, consultent plusieurs documents de politique, configurent les autorisations et surveillent les résultats. Les fournisseurs contrôlent l’architecture qui détermine si ces étapes sont efficaces.

Les développeurs devraient désormais poser des questions directes avant d’étendre l’accès des agents. L’outil conserve-t-il le code ou les prompts ? Une politique d’organisation peut-elle remplacer les paramètres personnels ? L’approbation couvre-t-elle une action ou une capacité continue ? Les administrateurs peuvent-ils auditer chaque requête réseau et appel d’outil ?

Les réponses devraient être visibles avant l’installation, et non découvertes après un incident. Si Anthropic, Cursor, OpenAI et leurs pairs rendent ces réponses claires, l’autonomie pourra s’étendre sans exiger une confiance aveugle.

Dans le cas contraire, les équipes de sécurité répondront par des passerelles plus strictes, des espaces de travail isolés ou des interdictions pures et simples. La plateforme de codage IA gagnante ne se contentera pas d’accomplir le plus de tâches. Elle montrera exactement ce qu’elle a touché, pourquoi elle l’a touché et quelle limite elle ne pourra jamais franchir.