Définir les autorisations de ton agent

# 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.
- 6. Vérifie la règle effective après un changement d’outil — Après remplacement d’un outil de fichiers ou ajout d’un connecteur, compare son nom technique à la règle configurée. Dans un espace jetable, répète les essais de lecture autorisée et d’écriture bloquée ; conserve règle et résultat ensemble.

## 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

# 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:ae7f078aefa95b740bc40eb8b565a5e8e468072baae57aac828575d807f6de22

# 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.
- 6. Vérifie la règle effective après un changement d’outil — Après remplacement d’un outil de fichiers ou ajout d’un connecteur, compare son nom technique à la règle configurée. Dans un espace jetable, répète les essais de lecture autorisée et d’écriture bloquée ; conserve règle et résultat ensemble.

## 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

# 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:11341f3515c7e36864fd4557fb4526e19a351827b4e0fcea5a7925aa9585a81d