Définir les autorisations de ton agent
6 min de lecture
Mis à jour le
Définir les autorisations de ton agent
Séparer consignes, permissions techniques et approbation, puis vérifier les limites sur une copie sans données sensibles.
Réponse directe
Une consigne décrit ce que tu autorises. Les permissions des outils, le compte connecté et le sandbox déterminent ce qui peut réellement être exécuté. Vérifie les deux avant de confier des fichiers ou un service à ton agent. Une autorisation accordée pour un outil ne suffit pas à établir les droits d’un autre connecteur ; relève la portée effective avant de poursuivre.
Glossary
Termes expliqués ici
Ouvre un terme pour lire sa définition courte, puis poursuis vers sa fiche sourcée si nécessaire.
01
Distingue quatre niveaux
« Lis ce dossier, demande avant de modifier » est une instruction au modèle. Elle ne retire aucun droit au compte connecté. Une permission d’outil autorise ou bloque une opération ; un sandbox restreint son environnement, par exemple les chemins accessibles ou le réseau. Une approbation autorise une opération dans le périmètre affiché.
Ces mécanismes se complètent, mais leur portée dépend du produit et de sa configuration. Un dossier protégé par le sandbox du terminal ne prouve pas qu’un connecteur de messagerie est limité. Consulte les permissions effectives de chaque outil et les droits du compte utilisé.
- Consigne : la limite que tu demandes au modèle de respecter.
- Permission effective : l’opération que l’outil et le compte peuvent exécuter.
- Sandbox : les ressources accessibles dans l’environnement concerné.
- Approbation : l’accord donné pour la portée affichée.
02
Écris une autorisation vérifiable
Exemple : lire seulement les copies du dossier « devis-test » ; proposer les corrections dans la conversation ; attendre mon accord pour modifier une copie précise ; ne rien envoyer. Pour chaque action, note la cible, le compte, les données accessibles, la durée et la preuve attendue.
Contre-exemple : « sois prudent » avec un compte administrateur et des outils autorisés à tout faire. La phrase exprime une préférence, sans établir une frontière technique. N’accorde que les accès nécessaires et retire les connexions inutiles.
03
Vérifie les réglages de ton produit
Ouvre la documentation officielle correspondant à ton produit et à sa version. Identifie les outils de lecture, d’écriture, de terminal et les connecteurs. Vérifie les règles héritées du compte ou de l’organisation, les autorisations mémorisées et la portée d’un accord ponctuel ou permanent.
Configure la lecture seule ou une demande d’approbation lorsqu’elles sont proposées. Si le produit ne permet pas la frontière voulue, utilise des copies et un compte moins privilégié, ou garde l’action manuelle. Ce guide ne fournit pas de parcours d’interface testé pour chaque fournisseur.
04
Observe un essai borné avant la vraie mission
Dans un dossier de test sans données sensibles, autorise explicitement un essai : lire une copie, puis tenter d’y écrire un marqueur inoffensif pour vérifier le contrôle. Avant l’essai, note son contenu. Refuse la demande d’écriture, si elle apparaît, puis contrôle que la copie est identique. Ne teste pas avec un vrai envoi, paiement ou effacement.
Si l’écriture se produit sans l’approbation attendue, arrête la mission et corrige les permissions. Une phrase de refus de l’agent ne prouve pas un blocage technique : vérifie le résultat d’outil ou le journal disponible. Un essai concluant couvre cette opération, pas tous les outils ni tous les chemins possibles.
05
Recontrôle la portée après un changement
Après un changement de compte, de connecteur, de dossier ou de règle enregistrée, reprends la vérification des accès concernés. Une réussite dans le dossier de test ne prouve pas le comportement du compte réel ; commence par constater ses réglages sans lancer d’action externe.
Avant un accord réel, compare la demande à la cible préparée : fichier exact, destinataire, contenu et effet attendu. Si elle inclut un autre accès ou une autorisation durable, refuse cette portée et reformule la demande. Conserve le résultat observé avec la configuration utilisée pour savoir ce qui a été vérifié.
À conserver
Checklist
- 01La demande réelle a la même cible et la même portée que celles examinées.
- 02La cible et le compte sont identifiés.
- 03Les réglages effectifs correspondent à la consigne.
- 04L’essai autorisé sur copie a produit la demande ou le refus attendu.
- 05Aucune modification n’a eu lieu après le refus.
- 06Une portée inconnue bloque l’action réelle.
Sources primaires
Les affirmations techniques de ce guide sont reliées aux spécifications et documentations first-party.
- Configure the sandboxed Bash tool (nouvel onglet)Anthropic · Isolation du système de fichiers et du réseau pour le terminal ; portée et limites distinctes des approbations.
- Authorization (2025-06-18) (nouvel onglet)Model Context Protocol · Autorisation d’accès aux serveurs MCP HTTP dans cette version du protocole ; ne garantit pas les permissions de chaque outil.
- Configure permissions (nouvel onglet)Anthropic · Source primaire pour les distinctions techniques ; procédure et exemples originaux SkillCodex.
Continuer
Guides et outils associés
Comprendre → Reconnaître → Choisir → Comparer
Pack pour ton agent
Instruction pré-écrite par SkillCodex — ta demande n’est ni envoyée ni utilisée pour adapter ce texte ; aucun contenu n’est généré et copier n’exécute rien.
Implémenter correctement
Applique « Définir les autorisations de ton agent » pas à pas
# Applique le guide « Définir les autorisations de ton agent » dans ton agent ## Objectif Une consigne décrit ce que tu autorises. Les permissions des outils, le compte connecté et le sandbox déterminent ce qui peut réellement être exécuté. Vérifie les deux avant de confier des fichiers ou un service à ton agent. Une autorisation accordée pour un outil ne suffit pas à établir les droits d’un autre connecteur ; relève la portée effective avant de poursuivre. ## Prérequis - Inspecte le dépôt, la documentation et les conventions existantes. - Confirme que le besoin correspond au périmètre du guide : Séparer consignes, permissions techniques et approbation, puis vérifier les limites sur une copie sans données sensibles. - Préserve les décisions correctes déjà en place. ## Étapes du guide - 1. Distingue quatre niveaux — « Lis ce dossier, demande avant de modifier » est une instruction au modèle. Elle ne retire aucun droit au compte connecté. Une permission d’outil autorise ou bloque une opération ; un sandbox restreint son environnement, par exemple les chemins accessibles ou le réseau. Une approbation autorise une opération dans le périmètre affiché. - 2. Écris une autorisation vérifiable — Exemple : lire seulement les copies du dossier « devis-test » ; proposer les corrections dans la conversation ; attendre mon accord pour modifier une copie précise ; ne rien envoyer. Pour chaque action, note la cible, le compte, les données accessibles, la durée et la preuve attendue. - 3. Vérifie les réglages de ton produit — Ouvre la documentation officielle correspondant à ton produit et à sa version. Identifie les outils de lecture, d’écriture, de terminal et les connecteurs. Vérifie les règles héritées du compte ou de l’organisation, les autorisations mémorisées et la portée d’un accord ponctuel ou permanent. - 4. Observe un essai borné avant la vraie mission — Dans un dossier de test sans données sensibles, autorise explicitement un essai : lire une copie, puis tenter d’y écrire un marqueur inoffensif pour vérifier le contrôle. Avant l’essai, note son contenu. Refuse la demande d’écriture, si elle apparaît, puis contrôle que la copie est identique. Ne teste pas avec un vrai envoi, paiement ou effacement. - 5. Recontrôle la portée après un changement — Après un changement de compte, de connecteur, de dossier ou de règle enregistrée, reprends la vérification des accès concernés. Une réussite dans le dossier de test ne prouve pas le comportement du compte réel ; commence par constater ses réglages sans lancer d’action externe. ## Critères d’acceptation — Checklist - La demande réelle a la même cible et la même portée que celles examinées. - La cible et le compte sont identifiés. - Les réglages effectifs correspondent à la consigne. - L’essai autorisé sur copie a produit la demande ou le refus attendu. - Aucune modification n’a eu lieu après le refus. - Une portée inconnue bloque l’action réelle. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
- Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes
Pourquoi ça marche
- Les étapes viennent d’un guide publié et sourcé, pas d’une improvisation.
- La checklist transforme le conseil en critères vérifiables.
- Le périmètre déclaré évite d’étendre le guide au-delà de ses preuves.
À essayer ensuite
Ancre le guide dans le projet
# Ancre le guide dans le projet ## Objectif Transforme les étapes appliquées en conventions durables du dépôt. ## Contrôles - Relie chaque décision prise à l’étape du guide qui la justifie. - Ajoute la checklist aux revues concernées. - Note les cas hors périmètre pour les guides voisins. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
sha256:4d949f50f8d749c3a5cc00c8a3335af2fab47a3442eb3c9202130867e5a1b154
Diagnostiquer un problème
Diagnostique un écart au guide « Définir les autorisations de ton agent »
# Diagnostique une application ratée du guide « Définir les autorisations de ton agent » ## Symptôme observé [DÉCRIS ICI LE SYMPTÔME] ## Contrôles observables - Rejoue les étapes dans l’ordre et note la première qui diverge : - 1. Distingue quatre niveaux — « Lis ce dossier, demande avant de modifier » est une instruction au modèle. Elle ne retire aucun droit au compte connecté. Une permission d’outil autorise ou bloque une opération ; un sandbox restreint son environnement, par exemple les chemins accessibles ou le réseau. Une approbation autorise une opération dans le périmètre affiché. - 2. Écris une autorisation vérifiable — Exemple : lire seulement les copies du dossier « devis-test » ; proposer les corrections dans la conversation ; attendre mon accord pour modifier une copie précise ; ne rien envoyer. Pour chaque action, note la cible, le compte, les données accessibles, la durée et la preuve attendue. - 3. Vérifie les réglages de ton produit — Ouvre la documentation officielle correspondant à ton produit et à sa version. Identifie les outils de lecture, d’écriture, de terminal et les connecteurs. Vérifie les règles héritées du compte ou de l’organisation, les autorisations mémorisées et la portée d’un accord ponctuel ou permanent. - 4. Observe un essai borné avant la vraie mission — Dans un dossier de test sans données sensibles, autorise explicitement un essai : lire une copie, puis tenter d’y écrire un marqueur inoffensif pour vérifier le contrôle. Avant l’essai, note son contenu. Refuse la demande d’écriture, si elle apparaît, puis contrôle que la copie est identique. Ne teste pas avec un vrai envoi, paiement ou effacement. - 5. Recontrôle la portée après un changement — Après un changement de compte, de connecteur, de dossier ou de règle enregistrée, reprends la vérification des accès concernés. Une réussite dans le dossier de test ne prouve pas le comportement du compte réel ; commence par constater ses réglages sans lancer d’action externe. ## Causes possibles - Une étape a été sautée ou exécutée hors ordre. - Le besoin réel sort du périmètre du guide. - Un critère de la checklist n’a jamais été vérifié. ## Corrections bornées - Reprends uniquement l’étape divergente et ce qui en dépend. - Documente l’écart si le périmètre du guide ne couvre pas le besoin. ## Vérification finale — Checklist - La demande réelle a la même cible et la même portée que celles examinées. - La cible et le compte sont identifiés. - Les réglages effectifs correspondent à la consigne. - L’essai autorisé sur copie a produit la demande ou le refus attendu. - Aucune modification n’a eu lieu après le refus. - Une portée inconnue bloque l’action réelle. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
- Prérequis · Le contexte réel du projet : dépôt, documentation et contraintes existantes
Pourquoi ça marche
- Le diagnostic rejoue des étapes ordonnées au lieu de chercher au hasard.
- Les corrections restent bornées à la première divergence réelle.
- La checklist sert de vérification finale reproductible.
À essayer ensuite
Préviens la prochaine dérive
# Préviens la prochaine dérive ## Objectif Fais de la première étape divergente un contrôle explicite du projet. ## Contrôles - Ajoute un contrôle ciblé sur l’étape qui a divergé. - Vérifie la checklist sur un second cas réel. - Documente la limite de périmètre rencontrée. ## Garde-fous - Montre d’abord les changements envisagés avant toute action externe. - Ne publie, n’envoie, ne supprime, ne paie et ne modifie aucun état distant sans autorisation explicite. - Préserve les changements sans rapport et arrête-toi si le périmètre devient ambigu. ## Format de sortie - Résultat obtenu ou verdict. - Fichiers ou actions concernés. - Vérifications exécutées et preuves observables. - Blocages ou limites restantes.
sha256:36e44d47a584685abfa1f1cda58f420e613a12841d6e0d09ca8f19766f7d8b60
Digest du Pack: sha256:08dc39d37af07bc91fda54da2864ac9808ef63bb5a7359dbcdcc3eb450d461d7