Un agent de programmation peut généralement respecter les consignes du dépôt tout en détenant plus d'autorité que nécessaire. Mozilla AI souligne cette lacune : intention écrite et permission techniquement imposée diffèrent. Un modèle plus capable améliore les décisions sans créer la frontière qui subsiste lorsqu'il se trompe.
L'argument d'infrastructure concerne les agents inspectant dépôts, modifiant fichiers, exécutant commandes et tests et préparant des pull requests. La délégation comprime les points de contrôle humains en boucle observer–agir–réviser. La question porte donc aussi sur ce que le système empêche, enregistre et sait reprendre.
Les instructions ont un rôle, mais ne sont pas la frontière d'exécution
Trois responsabilités doivent rester distinctes : les instructions décrivent le comportement, le modèle interprète, l'infrastructure détermine les actions possibles. Accorder d'abord un vaste accès puis demander de la retenue inverse la hiérarchie : le travailleur devient son propre contrôleur principal.
AGENTS.md facilite la coordination en gardant commandes, tests, conventions et contexte de sécurité près du code. Le site rapportait, au moment du récit, plus de 60 000 projets ouverts. Des instructions partagées et versionnées passent entre produits ; des fichiers imbriqués décrivent les besoins de chaque service d'un grand dépôt.
L'agent doit néanmoins trouver le fichier, résoudre les chevauchements, appliquer les règles et s'en souvenir longtemps. Lacunes, contexte tronqué, contradictions imbriquées et exceptions trop généralisées affaiblissent cette chaîne. Markdown ne restreint ni shell, ni réseau, ni compte cloud, registre de paquets ou base de production.
« Ne pas publier depuis une branche de fonctionnalité », « approuver les changements d'authentification » et « lire seulement ce répertoire » expriment l'intention. Frontières de fichiers, règles réseau et services d'approbation imposent les limites. Cela ne dévalue pas les instructions : certaines décisions demandent un contexte qu'une simple règle de fichiers n'exprime pas. Les rôles sont différents.
L'autonomie utile accroît les conséquences des erreurs ordinaires
Réparer un test d'intégration peut conduire aux fichiers d'environnement, services, dépendances et snapshots. Une tâche vague dépasse son périmètre sans malveillance : nettoyage destructeur pris pour maintenance, identifiant considéré comme jetable ou texte d'un ticket et d'une dépendance traité comme guide fiable.
L'injection renforce ce problème en plaçant des ordres hostiles dans les données à traiter. Les avertissements aident, mais le même modèle juge la fiabilité d'un autre texte. Une frontière extérieure limite les conséquences d'un jugement raté.
L'architecture de sandbox citée par la source sépare un harnais de confiance de l'environnement des commandes pilotées par le modèle. Approbations, traces, reprise et état peuvent rester hors du conteneur. Le travailleur n'hérite pas automatiquement de tous les identifiants et ressources de l'organisation.
La documentation n'exige pas de clés de publication, la réparation d'un service d'autres dépôts, ni l'écriture de tests la base productive. Ce sont des capacités d'exécution et ressources atteignables, pas seulement des choix de prompt. Un portable local peut aussi contenir code, sessions de navigateur, identifiants cloud, documents personnels et clés de signature. Un seul accès excessif compte même sans administration.
La qualité du contrôle devient une partie du produit. Plateforme et sécurité doivent permettre la délégation sans pouvoir illimité. Fournisseurs et développeurs individuels affrontent identité, identifiants, approbations, journaux et reprise auxquels les benchmarks ne répondent pas.
Politiques et autorisation hors du récit du modèle
Le plan de contrôle de confiance gère accès, routage, budgets, règles et état opérationnel. Le modèle propose ; une autre couche décide de l'exécution. Des identités par exécution distinguent agents, humain et autres automatismes. Les droits sur fichiers, commandes, services et destinations nommés doivent expirer avec la tâche, pas s'accumuler.
Les consignes de sandbox de la source décrivent isolation, sortie restreinte, identifiants séparés et accès intermédiaire. Un proxy de confiance fournit les identifiants seulement aux destinations autorisées sans exposer de secret réutilisable à l'exécutant. Afficher l'environnement ne doit pas révéler des clés productives durables ; la révocation peut intervenir au courtier plutôt que dans chaque espace.
La médiation vérifie arguments, refuse chemins dangereux, limite débits et demande approbation. Les plugins de politique mcpd placent authentification, validation, limites et journaux entre agent et serveur. Model Context Protocol exposant fichiers, bases et applications externes, un intermédiaire applique uniformément sans compter sur la reproduction correcte par chaque agent.
L'approbation exige aussi une identité habilitée et un état externe que le modèle ne fabrique pas. Une simple consigne contextuelle peut être imitée par un contenu non fiable. « Économiser les tokens » conseille ; un budget imposé reste un plafond dans une boucle prolongée. Des sous-agents dépensent plus vite qu'une personne observe un chat, d'où les limites par tâche, équipe, fournisseur ou résultat.
Toute étape ne demande pas validation. Lecture et écriture dans une branche temporaire peuvent être courantes ; publication, déploiement, droits et contact client demander une autorisation explicite. Une commande acceptable en test isolé peut être interdite en production ; documentation réseau permise, destinations inconnues bloquées. Interrompre constamment le faible risque nuit à la délégation, ne rien bloquer laisse les décisions importantes au modèle.
Audit et reprise doivent supporter un travail incomplet
L'explication de l'agent ne documente pas automatiquement entrées, droits, modifications, relances et refus. L'audit doit lier indépendamment l'action à l'exécution, aux versions de règle et d'outil, à l'approbation, l'identité, l'entrée et au résultat. Trois essais interdits avant une voie autorisée ne valent pas un bon choix immédiat.
Après un incident, règles et identifiants ont pu changer. Les preuves contemporaines permettent de reconstituer l'autorité et révèlent interventions récurrentes, faux positifs et dépassements pour améliorer les processus. Une transcription ou le résultat final seul ne suffit pas.
L'état compte aussi. Une action externe peut réussir avant l'échec de son enregistrement. Tout relancer risque de dupliquer pull request, paiement ou message client. L'infrastructure doit séparer étapes achevées, relances sûres et réconciliation. Un effet extérieur n'est pas une lecture locale répétable.
Otari relie gouvernance, routage, budgets, accès, déploiement et basculement entre fournisseurs. Le routage exprime aussi confidentialité, latence et capacités, pas seulement coût. Sortir ces décisions du code dispersé aide à conserver règles, traces et état lors d'un changement de modèle ou d'environnement.
La connaissance informe, la politique contraint, l'audit enregistre, la reprise gère l'incomplet. L'agent devient un composant remplaçable du système contrôlé par l'organisation, pas l'unique dépositaire de ses règles.
La propriété ouverte entraîne des devoirs opérationnels
Une pile inspectable limite la dépendance, autorise des intégrations propres et garde les composants sensibles dans un environnement contrôlé. Hôpitaux, banques, administrations et logiciels ont des approbations et rétentions différentes ; un défaut hébergé ne les couvre pas tous. L'ouverture reste un modèle de propriété, pas une sécurité automatique.
L'auto-hébergement exige mises à jour, revues d'accès, sauvegardes, supervision et reprise testée. Vieux composants, défauts permissifs, identifiants partagés, logs incomplets et réseau libre restent vulnérables avec du code public. Des traces riches capturent code propriétaire, données personnelles, prompts et résultats. La conservation doit établir les responsabilités sans copier définitivement chaque donnée sensible.
Plus de règles n'aide pas toujours. Les exceptions superposées créent des trous, la rigueur excessive pousse vers des outils non autorisés et la politique opaque crée un pouvoir interne problématique. De petits contrôles testables ont besoin d'un responsable, d'une raison et d'une vérification. Les modifications exigent revue, tests et versions ; les dérogations urgentes doivent expirer, rester visibles et expliquer refus et procédures d'exception.
L'infrastructure ne garantit pas non plus du code utile. Un agent peut respecter ses droits en se trompant ou en oubliant un besoin. Tests et humains restent nécessaires, avec cas privés ou indépendants révélant l'optimisation des seuls contrôles visibles et revue des responsables du code sensible. Un journal détaillé prouve le déroulement, pas le succès de la prévention.
Droits temporaires par tâche, preuves durables d'action et d'autorité et portabilité les préservant éprouveront la thèse. Les frictions quotidiennes comptent aussi. Un meilleur raisonnement reste précieux ; déléguer de manière fiable demande des frontières qui ne disparaissent pas lorsqu'il échoue.
À lire aussi : bases techniques et conservation du contexte d'ingénierie.