Du copilote au collègue : ce que signifie une IA qui opère en autonomie

Un regard ancré dans la recherche sur le passage des moteurs de suggestion aux coéquipiers autonomes. Pourquoi cela arrive maintenant, ce qui se brise dans la transition, et comment déployer sans remettre les clés du royaume.

L'ère du copilote plafonne

Le 15 avril 2026, Sam Altman a publié sur X qu'OpenAI déployait des « mises à jour de Codex cette semaine axées sur les équipes et les grandes entreprises ».

Les réponses étaient révélatrices. Pour chaque développeur s'interrogeant sur la feuille de route, un autre posait une question plus difficile : pourquoi Codex a-t-il toujours besoin que je le surveille ? Six mois plus tôt, des chercheurs de BeyondTrust avaient publié une preuve de concept montrant qu'un nom de branche Git spécialement conçu pouvait tromper Codex pour exfiltrer le jeton GitHub de l'utilisateur. Un copilote que l'on peut piéger pour qu'il divulgue un jeton via un nom de branche n'est pas un collègue. C'est une arme chargée avec un cran de sûreté.

Cette tension sous-tend chaque conversation sur l'IA en entreprise en 2026. Les copilotes ont atteint leur plafond, et les chiffres le confirment :

L'initiative NANDA du MIT a rapporté en 2025 que 95 % des projets pilotes d'IA générative échouent à produire une valeur commerciale mesurable.
Une étude RAND régulièrement citée sur le r/ArtificialIntelligence de Reddit début 2026 a révélé que 80 à 90 % des projets d'agents IA échouent en environnement de production.
Les taux d'acceptation par les développeurs pour GitHub Copilot se sont stabilisés autour de 35 à 40 %, tandis que Cursor se situe à 42 à 45 % et que Claude Code a obtenu une note de 46 % « le plus apprécié » dans l'enquête 2026 sur le codage assisté par IA. Un renversement stupéfiant pour un outil lancé seulement en mai 2025.
Satya Nadella aurait qualifié le déploiement interne de Copilot chez Microsoft de « quasi inutilisable » fin 2025, et l'entreprise a annoncé ce que ses dirigeants ont décrit en interne comme une « remise à zéro à enjeux élevés » du produit.
Une étude arXiv publiée fin 2025 a constaté que l'autocomplétion façon Copilot augmentait en réalité la frustration chez les développeurs expérimentés, car elle interrompait leur flux avec des suggestions plausibles mais subtilement erronées.

Le plateau n'est pas un échec des modèles sous-jacents. C'est un échec du schéma d'interaction. Un copilote opère au niveau de la frappe ou de la question individuelle. Un collègue opère au niveau du flux de travail. Bits&Chips l'a bien formulé dans son essai d'avril 2026 « From copilot to colleague » : « Un copilote opère au niveau de l'interaction individuelle, tandis qu'un agent opère au niveau du flux de travail. Ce qui compte, car dans la plupart des organisations, le goulot d'étranglement n'est pas la tâche individuelle. C'est la coordination entre les tâches. »

C'est le virage que les entreprises tentent de prendre aujourd'hui. De façon inégale, imparfaite, et à une échelle significative.

Le spectre de l'autonomie

« Agent » est devenu un mot marketing, alors soyons concrets. Il existe quatre niveaux distincts d'autonomie de l'IA, et la plupart des déceptions de 2025 et 2026 sont venues d'une confusion entre l'un et l'autre.

Niveau 1 : copilote

Suggère. Demande la permission. Reste sur votre écran. L'autocomplétion de GitHub Copilot en est l'archétype. La valeur se mesure en frappes économisées.

Niveau 2 : assistant

Répond aux questions et compose des artefacts à la demande. ChatGPT, Claude dans un navigateur, le panneau de chat de Microsoft 365 Copilot. La valeur se mesure à la qualité des brouillons et à la synthèse du contexte.

Niveau 3 : agent

Accepte un objectif, planifie une séquence d'étapes, exécute à travers plusieurs outils, rend compte. Claude Code scannant un dépôt et ouvrant une PR. La Deep Research de ChatGPT effectuant 20 minutes de recherches et renvoyant un rapport sourcé. Anthropic a documenté une instance Claude accomplissant une tâche d'ingénierie autonome de 7 heures pour Rakuten. La valeur se mesure en flux de travail accomplis par heure humaine investie.

Niveau 4 : collègue

Un agent qui opère à l'intérieur de votre modèle de permissions existant, participe aux canaux de communication de votre équipe, conserve le contexte sur des jours et des semaines, et est responsable devant la même piste d'audit qu'un employé humain. C'est la frontière.

La communauté r/ChatGPT de Reddit a mis en avant un test pragmatique pour distinguer ces niveaux, paraphrasé : la chose prend-elle l'initiative, ou attend-elle chaque instruction ? Gère-t-elle les situations imprévues, ou plante-t-elle en vous obligeant à reformuler ? Se souvient-elle du contexte au fil d'une tâche en plusieurs étapes, ou devez-vous vous répéter ? La plupart des produits commercialisés comme « agents IA » en 2025 échouaient à chacune de ces questions. Ceux qui les réussissaient correspondent à ce que les gens entendent désormais par « collègue ».

Computer use ou skills : pourquoi la plomberie compte

Une IA de calibre collègue doit agir dans le monde. Il existe deux approches architecturales pour cela, et elles présentent des profils de risque très différents.

Computer use

L'IA pilote une souris et un clavier simulés. Elle voit littéralement un écran et clique sur des boutons. Anthropic a livré Computer Use fin 2024, et l'Operator d'OpenAI a suivi. L'attrait est l'universalité : tout logiciel doté d'une interface graphique devient adressable.

Le coût est le rayon d'impact. Un agent qui utilise l'ordinateur hérite de chaque permission dont dispose l'utilisateur connecté. En octobre 2025, l'équipe de sécurité de BeyondTrust a démontré que l'agent Codex d'OpenAI pouvait être trompé, via un nom de branche Git malveillant contenant des commandes shell, pour lire et exfiltrer le GITHUB_TOKEN de l'utilisateur. L'agent faisait exactement ce qu'un développeur humain ferait (récupérer une branche), mais il n'avait aucune intuition que le nom de la branche lui-même était une entrée hostile. Dans cet incident, le modèle d'autorité était du tout ou rien. C'est le mode d'échec par défaut de computer use.

Skills

L'IA invoque des skills discrètes. Chaque skill est une fonction explicite et typée avec un contrat étroit : « rechercher dans Slack les messages correspondant à q », « créer un ticket Linear avec title et body », « lire ce fichier GitHub ». Contrairement à computer use, une skill a une forme préapprouvée. L'agent ne peut l'appeler qu'avec des paramètres conformes au contrat, et la plateforme peut autoriser, refuser ou demander confirmation sur cet appel avant qu'il ne quitte le bac à sable.

La différence, en termes de sécurité, se résume au principe du moindre privilège. C'est une idée fondatrice de la sécurité de l'information : un processus ne devrait avoir accès qu'aux ressources nécessaires à l'exécution de sa fonction, et rien de plus. Les skills permettent d'imposer le moindre privilège appel par appel. Computer use ne le permet pas.

Un déploiement de calibre collègue utilise les skills pour les actions structurées (écrire dans un CRM, ouvrir un ticket) et réserve computer use à la frange étroite d'applications qui refusent d'exposer une API. Le ratio compte. Si chaque action de votre déploiement d'agent passe par une souris simulée, vous avez une démo de productivité, pas un système de production.

L'architecture de confiance dont les entreprises ont vraiment besoin

Le passage du copilote au collègue n'est pas une mise à niveau de modèle. C'est une mise à niveau d'infrastructure. Trois éléments séparent un collègue déployable d'un passif.

1. Isolation des permissions

Chaque agent opère à l'intérieur de sa propre limite de permissions, avec des identifiants que l'agent lui-même ne peut pas extraire de son bac à sable. L'expérience virale autoresearch d'Andrej Karpathy en mars 2026, où il a laissé un agent exécuter 700 expériences d'entraînement sans surveillance sur deux jours, est instructive par ce qu'elle n'a pas fait. Le propre dépôt de Karpathy enjoint aux utilisateurs de « désactiver toutes les permissions » en mode autonome. C'est acceptable pour un ordinateur portable de recherche personnel. C'est un motif de licenciement au sein d'une entreprise réglementée.

Le contre-exemple est Moltbook, le réseau social réservé aux IA devenu brièvement viral fin janvier 2026 avec 1,5 million d'agents autonomes. Karpathy l'avait salué comme « la chose la plus incroyable, proche d'un décollage de science-fiction, que j'aie vue récemment ». Puis des chercheurs en sécurité de Wiz ont découvert une clé d'API de base de données exposée côté frontal, accordant un accès complet en lecture/écriture à toute la base de données de production, y compris les jetons d'authentification des 1,5 million d'agents. Karpathy a fait volte-face en moins de 24 heures : « C'est un désastre. Je déconseille vraiment aux gens d'exécuter ce truc sur leurs ordinateurs. » La leçon n'est pas « les agents sont dangereux ». La leçon est que les agents déployés sans isolation des permissions par identité s'effondrent en un seul rayon d'impact partagé.

2. Pistes d'audit

Chaque action journalisée, chaque décision traçable. Le cadre IMDA de Singapour, publié à Davos en janvier 2026, le codifie avec une matrice de risque à deux axes qui cartographie l'espace d'action d'un agent (lecture vs écriture, réversible vs irréversible) face à son autonomie (le degré d'indépendance de ses décisions). Plus l'un ou l'autre des axes s'élève, plus l'exigence d'audit s'enrichit. Ce cadre est étudié de près par les régulateurs européens et américains car il est l'un des premiers à traduire la gouvernance de principes abstraits en un outil de calibrage opérationnel.

Simon Willison a plaidé en parallèle pour une journalisation unifiée afin que les agents puissent surveiller leurs propres opérations et se remettre des erreurs : « Les agents disposant d'un accès complet au système sont puissants, et dangereux. » Le point pratique : si votre déploiement d'agent n'a pas de journal unifié qu'un responsable de la conformité peut lire dans l'ordre, vous êtes à un seul incident de perdre le privilège de déployer.

3. Accès aux skills à portée restreinte

Pas « accès aux e-mails ». L'accès à rechercher dans la boîte de réception où from:@customer.com AND within last 7 days. Les plateformes d'agents modernes évoluent vers des portées paramétrées, où la permission d'un agent d'invoquer une skill est bornée par des arguments qu'un administrateur préapprouve, et non par la portée OAuth brute qu'utiliserait l'humain.

Assemblez ces trois pièces et elles répondent à la question que chaque RSSI se pose en ce moment : que fait cet agent lorsqu'il a tort, et comment le saurai-je ? L'enquête State of AI 2026 de McKinsey a révélé que 72 % des répondants en entreprise citaient la cybersécurité comme une préoccupation liée à l'IA générative, et la sécurité a été désignée comme le frein n°1 à la mise à l'échelle des flux de travail agentiques par environ deux tiers des répondants. L'isolation des permissions, les pistes d'audit et l'accès aux skills à portée restreinte ne relèvent pas du théâtre de conformité. C'est l'infrastructure qui conditionne le passage à l'échelle.

Pourquoi cela compte maintenant : trois forces qui convergent

Le passage du copilote au collègue en 2026 n'est pas porté par une seule percée. C'est le résultat de trois courbes qui se croisent.

Force 1 : l'intégration a cessé d'être sur mesure

En 2024, brancher un agent dans une pile SaaS d'entreprise signifiait écrire un connecteur personnalisé par outil. Début 2026, les contrats de skills typés et les connecteurs préemballés ont réduit ce travail. Un agent qui nécessitait six semaines d'intégration en 2024 ne demande qu'un après-midi en 2026. La surface d'une entreprise de taille moyenne typique (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, calendriers) est désormais couverte par des bibliothèques de connecteurs open source matures, livrées avec des permissions typées intégrées.

Force 2 : le multi-agent devient réel

Gartner a désigné les systèmes multi-agents comme une tendance technologique stratégique majeure pour 2026. Le VP Analyst émérite Gene Alvarez a proposé la métaphore désormais reprise sur chaque diapositive d'IA d'entreprise : « Pensez à une équipe de stands de Formule 1. Chaque membre a un rôle spécialisé (changeur de pneus, ravitailleur, opérateur de cric) mais ils sont chorégraphiés autour d'un objectif unique. Voilà la forme des déploiements d'agents en entreprise en 2026. » Les systèmes mono-agents atteignent des plafonds de raisonnement sur les tâches à long horizon. Les systèmes multi-agents, avec des rôles spécialisés et des passations explicites, sont la façon dont les équipes contournent ces plafonds aujourd'hui.

Force 3 : les budgets d'entreprise se débloquent

G2 a rapporté dans sa recherche State of Software 2026 que 57 % des entreprises ont des agents IA en production (contre environ 20 % un an plus tôt).
McKinsey a constaté que 23 % des entreprises font activement passer l'IA agentique à l'échelle, avec 62 % en phase d'expérimentation. Cela ne laisse qu'environ 15 % des grandes organisations encore en marge.
L'enquête 2026 de Deloitte auprès de 3 235 dirigeants d'entreprise a identifié les services financiers comme le secteur de pointe pour l'adoption, avec une étude de cas documentée d'un agent IA capturant et exploitant les résultats de réunions à travers un pipeline d'affaires qui nécessitait auparavant trois analystes.
Le Enterprise AI Playbook de Stanford, publié début 2026, a catalogué 51 déploiements en production, un cas de migration ETL dans la fintech devenant l'implémentation de référence pour les équipes des secteurs réglementés.
L'investissement déclaré dans l'infrastructure d'IA d'entreprise a dépassé 600 milliards de dollars sur le cycle 2025.
Dario Amodei d'Anthropic, s'exprimant lors de la conférence Code with Claude, a donné une probabilité de 70 à 80 % de l'émergence en 2026 de la première entreprise milliardaire à une seule personne, propulsée par des forces de travail d'agents.

L'argent est là, le protocole est là, et l'architecture est là. Ce qui se négocie désormais dans chaque conseil d'administration, c'est quelle quantité d'autonomie, sous quelle gouvernance, et pour quels flux de travail.

Le dossier du sceptique : ce que disent Reddit, arXiv et les rapports d'incidents

Un examen responsable de ce virage doit s'engager sérieusement avec ceux qui pensent que tout cela est survendu.

Sur Reddit, le consensus sur r/LocalLLaMA, r/ClaudeCode et r/ChatGPT est pragmatique : les agents de codage sont arrivés et sont utiles. La plupart des autres « agents » sont des flux d'automatisation déguisés en chatbot. La phrase citée dans des dizaines de fils de 2026, « Utilisez Copilot quand vous voulez des suggestions. Utilisez Claude Code ou Cursor quand vous voulez qu'il fasse réellement quelque chose », capture cette répartition productive. Ces mêmes communautés sont sans ménagement à l'égard des benchmarks. Même les meilleurs agents obtiennent environ 60 % au global sur Terminal-Bench et tombent à 16 % sur les tâches difficiles. Claude Opus 4.5 domine SWE-bench à 80,9 %, ce qui signifie tout de même qu'une tâche sur cinq échoue.

Le scepticisme académique est plus difficile à écarter. Vishal Sikka (ancien CTO de SAP, élève de John McCarthy) et son collaborateur ont publié Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, soutenant mathématiquement que les LLM de type transformeur sont fondamentalement limités dans leur capacité à exécuter des tâches computationnelles et agentiques au-delà d'un certain plafond de complexité. La conclusion de Sikka, « Il n'y a aucun moyen qu'ils soient fiables » pour des opérations hautement critiques, circule en ce moment dans chaque Slack de RSSI. L'article ne prétend pas que les agents sont inutiles. Il affirme qu'il existe une classe de problèmes où l'on ne peut pas sortir l'humain de la boucle, aussi bon que devienne le modèle.

Des incidents réels appuient le scepticisme. Un responsable de l'expérience client dans le commerce de détail, cité dans l'enquête 2026 de Yellow.ai : « Nous avons dû retirer notre support IA après seulement deux semaines, car il a commencé à citer des politiques de retour incorrectes et à inventer des offres de réduction dans environ 1,35 % des tickets. Le coût d'honorer ces erreurs dépassait de loin ce que nous espérions économiser. » À grande échelle, même un taux d'erreur inférieur à 2 % devient vite coûteux.

La synthèse : l'IA de calibre collègue est réelle dans le codage, la recherche, les opérations structurées et les flux de support restreints. Elle n'est pas encore réelle dans les interactions ouvertes orientées client sans relecteur humain. Les entreprises qui en tirent de la valeur en 2026 sont celles qui sont honnêtes sur la catégorie à laquelle appartient un flux de travail.

Implication pratique : cinq questions avant de déployer

Si votre équipe évalue un coéquipier IA (développé en interne ou tiers), voici les questions qui séparent un déploiement en production d'un quasi-accident.

Quel est le rayon d'impact de la pire action unique que cet agent peut entreprendre ? Cartographiez-le littéralement. Si le pire cas est « envoyer un brouillon d'e-mail à la mauvaise personne », la barre de gouvernance est basse. Si c'est « modifier des données de production » ou « envoyer des instructions de virement », la barre est d'un ordre de grandeur supérieure. Cartographiez-le avant de déployer, pas après le premier incident.
Comment l'agent obtient-il ses identifiants, et peut-il jamais lire le jeton brut ? Il y a trois réponses, et une seule est sûre. Si l'agent dispose d'une copie du jeton OAuth de l'utilisateur dans son environnement, vous avez en pratique donné votre portefeuille au LLM. Si l'agent dispose de « sa propre » identité via un OAuth de compte de service distinct, vous devez le suivre et le révoquer comme un principal réel. La troisième réponse, qui est ce que vous voulez réellement : le jeton n'atteint jamais l'agent. Il réside sur la plateforme, chiffré, et est injecté au niveau du proxy réseau juste à temps, uniquement pour les appels ayant passé un contrôle de politique, uniquement jusqu'au retour de l'appel.
Chaque action est-elle journalisée quelque part qu'un responsable de la conformité peut lire dans l'ordre ? Unifiée, interrogeable, infalsifiable. Si votre réponse est « nous avons quelques journaux quelque part dans CloudWatch », vous n'êtes pas prêt.
Pouvez-vous restreindre l'accès aux skills aux paramètres spécifiques dont ce flux de travail a besoin ? Par appel, pas par intégration. Lecture vs écriture. Par identifiant de ressource. Par fenêtre temporelle. Les permissions de l'agent devraient être un rectangle dessiné au plus près de la tâche, et non l'entrepôt entier.
Quel est le scénario de retour arrière si quelque chose tourne mal ? Comment annulez-vous une action ? À quelle vitesse ? Qui est alerté ? Les actions irréversibles (transferts d'argent, e-mails orientés client, déploiements en production) nécessitent une étape de confirmation ou une fenêtre de délai. Les actions réversibles peuvent s'exécuter de façon autonome.

Répondez aux cinq. Si vous pouvez répondre à toutes, vous avez déjà dépassé l'ère du copilote et atteint la partie qui change réellement la façon dont votre équipe livre. Si vous pouvez répondre à deux ou trois, c'est là qu'il faut concentrer vos efforts ensuite, et non une raison d'attendre. Le coéquipier de calibre collègue que votre feuille de route cherche à atteindre tourne déjà en production quelque part aujourd'hui. L'écart entre vous et lui est un écart d'infrastructure, pas un écart d'IA de pointe. Et les écarts d'infrastructure se comblent vite.

Vous n'avez pas besoin d'attendre la prochaine sortie de modèle. Vous devez choisir une plateforme qui répond déjà à ces cinq questions pour vous, et commencer à confier un vrai travail à votre agent.

Foire aux questions

Quelle est la vraie différence entre un copilote et un collègue IA ?

Un copilote suggère, demande la permission et vit à l'intérieur d'un seul outil. Un collègue accepte des objectifs, planifie à travers les systèmes, exécute avec des permissions à portée restreinte, et est responsable devant la même piste d'audit qu'un humain. Bits&Chips l'a dit clairement : les copilotes opèrent au niveau de l'interaction, les collègues au niveau du flux de travail.

Comment les agents devraient-ils gérer les identifiants des utilisateurs ?

Aucune des deux options évidentes n'est la bonne. Copier le jeton OAuth de l'utilisateur dans l'environnement de l'agent place un identifiant actif à l'intérieur du contexte du LLM. Frapper une identité distincte par agent fait de chaque agent un principal que vous devez suivre, révoquer et auditer comme un humain. Le schéma qui fonctionne en pratique est l'accès courtier : le jeton réside sur la plateforme, chiffré ; le proxy réseau sortant du bac à sable rappelle la plateforme au moment de la requête ; la plateforme déchiffre le jeton et ne renvoie que les en-têtes d'authentification résolus pour les appels ayant passé un contrôle de politique ; l'agent lui-même ne lit, ne journalise ni ne demande jamais confirmation sur le jeton brut.

Computer use ou skills, lequel choisir ?

Les skills par défaut, pour tout ce qui dispose d'une API. Computer use uniquement lorsque le système cible n'a pas d'interface programmable. L'incident Codex de BeyondTrust est le récit édifiant : computer use hérite des permissions complètes de l'utilisateur, et une entrée malveillante n'importe où dans le champ de vision de l'agent peut devenir un exploit.

Quel degré d'autonomie devrions-nous réellement accorder aux agents ?

Utilisez le cadre à deux axes de l'IMDA de Singapour : espace d'action × autonomie. Un espace d'action restreint (lecture seule, réversible) tolère une autonomie élevée. Un espace d'action large (écritures, irréversible, orienté client) exige une confirmation humaine, ou une fenêtre à délai pour intervenir. La pire configuration est une autonomie élevée sur des actions à enjeux élevés sans piste d'audit.

Comment mesurer le ROI ?

Arrêtez de mesurer les frappes économisées. Mesurez les flux de travail accomplis par heure humaine investie, le temps de résolution des incidents d'exploitation, et le taux d'échappement (tâches que l'agent a renvoyées à un humain). Les conclusions 2026 de Deloitte suggèrent que les adoptants de pointe suivent trois métriques : le taux d'achèvement des flux de travail, le taux d'erreur et le taux d'intervention humaine, en optimisant le ratio entre elles.

Que faire face au taux d'échec de 95 % des projets pilotes ?

Lisez attentivement l'analyse de MIT NANDA. Les projets pilotes qui ont échoué reposaient surtout sur du « RAG bête » (tout déverser dans le contexte), des « connecteurs fragiles » (intégrations API cassées) et aucune architecture pilotée par les événements. Les projets pilotes qui ont réussi avaient une couche opérationnelle autour du LLM : mémoire, E/S et permissions. Le noyau LLM n'est pas le goulot d'étranglement. C'est l'infrastructure qui l'entoure.

Où VM0 s'inscrit

Nous avons conçu Zero autour d'un pari architectural : l'agent ne devrait jamais détenir l'identifiant. Ni dans son environnement, ni dans son prompt, ni dans sa mémoire. Le jeton reste sur la plateforme. Chaque appel sortant de l'agent est courté par un proxy réseau qui décide, appel par appel, d'injecter ou non un en-tête d'authentification ou de bloquer la requête.

C'est un choix inhabituel. Les schémas courants en 2026 consistent soit à donner à l'agent sa propre identité OAuth (vous avez alors un second principal à auditer et révoquer), soit à lui remettre une copie du jeton de l'utilisateur dans une variable d'environnement (le LLM peut alors lire votre portefeuille). Nous ne faisons ni l'un ni l'autre. Voici comment cela fonctionne réellement.

Le jeton n'atteint jamais l'agent. Lorsque vous connectez un connecteur à Zero (GitHub, Slack, Gmail, Linear, Notion, HubSpot, et ainsi de suite), le jeton OAuth est stocké chiffré sur la plateforme. Les jetons de rafraîchissement restent dans la base de données et n'en sortent jamais. À l'intérieur du bac à sable, il n'y a aucune variable d'environnement GITHUB_TOKEN à lire, aucun fichier de secrets à ouvrir, aucun outil qui renvoie le jeton.

Un proxy réseau courte chaque appel. Chaque requête HTTP qui quitte le bac à sable passe par un module complémentaire basé sur mitmproxy. Le proxy identifie le connecteur à partir du nom d'hôte de la requête, recherche la politique de pare-feu pour cet agent, et vérifie si la méthode et le chemin sont autorisés. Si c'est le cas, le proxy rappelle le webhook de la plateforme. La plateforme déchiffre le jeton, le rafraîchit s'il a expiré, résout les éventuels modèles d'en-tête (${{ secrets.GITHUB_TOKEN }} devient la vraie valeur) et ne renvoie au proxy que les en-têtes d'authentification résolus. Le proxy injecte ces en-têtes dans la requête sortante. Une fois l'appel terminé, les en-têtes disparaissent de la mémoire du proxy. L'agent ne les a jamais vus.

Les permissions sont par agent, par connecteur, et typées au niveau du point de terminaison. Chaque agent porte un objet de politique qui associe chaque connecteur à un ensemble de groupes de permissions nommés. github:repo-read n'est pas une portée vague. C'est un ensemble de règles spécifiques de méthode et de chemin, par exemple GET /repos/{owner}/{repo}/pulls. Accorder l'accès à GitHub n'accorde pas GitHub. Cela accorde une forme d'intention à l'intérieur de GitHub.

Trois états de politique, pas deux. Chaque permission se résout en allow, deny ou ask. Le dernier demande confirmation à un humain avant le déclenchement de l'action. Tout ce que le pare-feu ne correspond pas explicitement retombe sur une unknownPolicy par connecteur, dont la valeur par défaut est deny. Le moindre privilège est la valeur par défaut, pas l'option à activer.

Un bac à sable par exécution. Chaque exécution d'agent tourne dans sa propre micro-VM Firecracker avec un espace de noms réseau isolé. Quand l'exécution se termine, l'espace de noms est démantelé. Deux exécutions du même agent sont deux bacs à sable distincts avec deux pistes d'audit distinctes.

Une piste d'audit par requête. Le même proxy qui décide d'autoriser ou de refuser écrit aussi un journal JSONL par exécution avec des métadonnées de pare-feu attachées à chaque requête : le connecteur, le groupe de permissions correspondant, la règle spécifique correspondante, la décision, l'horodatage. Ces journaux sont renvoyés à la plateforme. Si un RSSI a besoin de savoir ce que l'agent a fait le 14 avril entre 15h et 17h CST, c'est une seule requête.

Une CLI qui explique ses propres refus. Lorsqu'une permission bloque un appel, l'agent (ou l'humain assis à côté) peut exécuter zero doctor permission-deny <connector> --method <M> --path <P> et récupérer le groupe de permissions exact qui a bloqué la requête, ainsi qu'un lien de remédiation. zero doctor permission-change permet aux administrateurs d'activer directement une permission, ou permet à un membre de soumettre une demande écrite (limitée à 500 caractères, pour que le raisonnement soit réellement lisible) qui est acheminée vers un administrateur. Les permissions à haut risque comme slack:chat:write ou gmail.send déclenchent un avertissement supplémentaire qui oriente vers une alternative plus sûre, à portée de bot.

Deux rôles, un seul flux d'approbation. Les propriétaires et administrateurs modifient les permissions directement. Les membres soumettent une demande avec un motif, qui est acheminée vers un administrateur. Il n'y a pas de troisième palier « semi-administrateur ». Le flux est suffisamment simple pour que les gens l'utilisent réellement, ce qui est tout l'intérêt.

Nous réservons computer use à l'ensemble restreint de systèmes hérités qui refusent d'exposer une API. Tout le reste passe par les skills. Chaque action est contrôlée par politique. Chaque identifiant reste sur la plateforme. Chaque décision est journalisée.

Si vous avez dépassé le stade « encore une autocomplétion IA » et voulez essayer un coéquipier IA que votre équipe de sécurité approuvera, découvrez comment Zero gère les flux de travail planifiés, trie les incidents de production, ou exécute un briefing produit matinal.

L'ère du copilote ne se termine pas. Elle est absorbée dans quelque chose de plus grand. Les équipes qui gagneront le prochain cycle sont celles qui comprennent la différence.