Assistants, agents et permissions

Identifiez comment le système agit

Un assistant peut expliquer du code, proposer un plan ou suggérer une implémentation. Un agent peut aussi utiliser des outils et agir sur l’environnement. Les noms des produits ne constituent pas une limite fiable. Certaines interfaces de conversation exécutent des commandes. Certains outils de programmation ne proposent que du texte.

Inspectez les outils disponibles. Une description utile précise ce que le système peut lire, modifier, exécuter et publier. Elle indique aussi les identifiants et l’environnement utilisés pour chaque action.

Anthropic distingue les workflows prédéfinis des agents qui choisissent eux-mêmes leur séquence d’utilisation des outils. Cette distinction aide à expliquer le déroulement du travail. Elle ne détermine pas si une action donnée est sûre. Les deux approches exigent des limites explicites de permissions.

Distinguez l’objectif de la permission

Prenons une demande fictive : « Corrigez l’export des factures. » Un agent peut inspecter le dépôt, reproduire le défaut, modifier une branche et exécuter des contrôles. Il pourrait aussi trouver dans son environnement des identifiants de la base de production.

L’objectif n’autorise pas toutes les actions disponibles. Lire une table de production, modifier des factures et déployer une version ont des conséquences différentes. Une consigne générale comme « terminez la tâche » ne précise pas lesquelles sont permises par l’organisation.

Définissez les limites avant de commencer. Dans cet exemple, l’agent peut utiliser des données inventées et une base locale. Il peut créer une pull request. Il ne peut ni accéder aux enregistrements de production ni déployer la modification. Un processus de livraison distinct prend en charge ces actions.

Faites respecter les permissions par des contrôles techniques

Les instructions aident l’agent à comprendre la tâche. Les identifiants et les contrôles d’accès déterminent ce qu’il peut réellement faire. Utilisez les deux.

Une tâche en lecture seule ne doit pas recevoir des identifiants d’écriture par simple commodité. Un environnement de test ne doit pas hériter silencieusement des accès de production. Examinez les liens entre outils, identités et ressources. Une commande apparemment anodine peut avoir des conséquences étendues lorsqu’elle utilise une identité très privilégiée.

Définissez quand le travail doit s’arrêter

Un agent a besoin d’une condition d’arrêt lorsque l’action suivante dépasse ses droits. Il en a aussi besoin lorsque les preuves sont insuffisantes.

Dans l’exemple des factures, arrêtez le travail si le défaut exige une correction des données de production. Arrêtez-le si le comportement demandé contredit la règle comptable documentée. Signalez le conflit avec les preuves pertinentes et la décision attendue d’un responsable.

Une limite de temps ou de coût est utile pour les tentatives répétées. Elle ne remplace pas une limite de permissions. Dix tentatives autorisées et un déploiement non autorisé sont deux problèmes différents.

Évaluez le résultat et la trace des actions

À la fin, ne vous limitez pas à la réponse finale. Examinez les fichiers modifiés, les contrôles exécutés et les incertitudes restantes. Vérifiez que les actions sont restées dans le périmètre convenu.

Un agent performant peut réduire le travail manuel. L’organisation doit toujours définir les actions permises, vérifier les résultats importants et assumer la décision de livraison. Plus l’autonomie augmente, plus ces responsabilités comptent.