Outil d’équipe · Modèle

Fiche d’autorisation d’un agent

Une fiche par agent partagé : finalité, accès et actions possibles, approbations requises, limites et moyen de l’arrêter.

Télécharger

Modèle vierge (.md)Exemple fictif (.md)

Principes concernés

Vue d’ensemble

Avant que votre équipe utilise un agent partagé, consignez qui peut l’arrêter et ce qu’il peut faire seul. Si un champ reste sans réponse, réglez la question avant d’activer l’agent.

Moindre privilège

Commencez avec un accès en lecture seule ou limité aux brouillons. Ajoutez une autorisation à la fois lorsqu’une tâche réelle le nécessite. Fixez les limites dans le système pour qu’elles s’appliquent même si l’agent comprend mal un prompt. Évitez de donner simultanément à un même agent accès à des données privées, à du contenu d’inconnus et à un moyen d’envoyer des informations vers l’extérieur, sauf si votre équipe informatique l’a conçu ainsi délibérément.

Le modèle

Chaque champ comprend des instructions et un exemple provenant d’une équipe fictive.

Exemple fictif : l’agent de rapprochement des factures de l’équipe financière de Lumen, un éditeur de logiciels fictif.

01Agent et finalité: Nommez l’agent et son unique tâche.

Exemple fictif

Rapprochement des factures : rapproche les factures fournisseurs des bons de commande.
02Responsable: Désignez la personne responsable de l’agent et de sa fiche.

Exemple fictif

Le responsable de la comptabilité fournisseurs.
03Peut lire: Listez les systèmes et données qu’il peut lire.

Exemple fictif

La boîte des factures fournisseurs (lecture seule), les bons de commande et le référentiel fournisseurs.
04Peut faire seul: Listez les actions qu’il effectue sans approbation.

Exemple fictif

Rapprocher les factures des commandes et signaler les écarts.
05Nécessite une approbation: Listez les actions qui attendent l’intervention d’une personne.

Exemple fictif

Marquer une facture comme approuvée pour paiement.
06Jamais: Listez les actions qu’il ne doit jamais effectuer, avec des restrictions imposées par ses autorisations.

Exemple fictif

Modifier les coordonnées bancaires d’un fournisseur, effectuer des paiements ou envoyer des e-mails aux fournisseurs.
07Limites: Fixez des limites de montant, de destinataires, de volume et de durée.

Exemple fictif

Factures jusqu’à 10 000 €. Arrêt après 200 factures par jour.
08Contenu externe lu: Listez les contenus non fiables qu’il lit, comme des e-mails ou pages web, et la manière de les traiter.

Exemple fictif

E-mails et PDF des fournisseurs. Les instructions qu’ils contiennent sont ignorées et toute demande de modification est signalée à une personne.
09Moyen de l’arrêter: Précisez qui peut le suspendre et comment.

Exemple fictif

Tout responsable de l’équipe financière, avec le bouton de pause des paramètres d’automatisation.
10Moyen d’annuler son travail: Précisez comment revenir sur ses actions.

Exemple fictif

Les rapprochements peuvent être réinitialisés depuis le journal d’audit.
11Date de révision: Précisez quand la fiche et ses autorisations sont vérifiées.

Exemple fictif

Chaque trimestre et à chaque modification d’autorisation.

Sources

Ces sources étayent les faits présentés sur cette page. Pour chacune, nous précisons ce qu’elle établit et les questions qu’elle laisse ouvertes. Les recommandations sont les nôtres. Voir toutes nos sources.

OWASP Top 10 for LLM Applications, 2026 edition OWASP Gen AI Security Project · 3 août 2026 · Recommandations de sécurité Énumère les principaux risques de sécurité des applications d’IA, dont l’injection de prompt (LLM01), qui ne peut pas encore être empêchée de manière fiable, et l’autonomie excessive (LLM03) : plus de fonctions, d’autorisations ou d’autonomie que nécessaire. Recommande le moindre privilège et la confirmation humaine des actions privilégiées, irréversibles ou visibles à l’extérieur. Limites : Recommandations communautaires, pas une norme formelle.
Least privilege (glossary entry) NIST Computer Security Resource Center · Définition issue du NIST SP 800-53 Rev. 5 · Définition normalisée Définit le moindre privilège comme le fait d’accorder à chaque entité uniquement les ressources système et autorisations minimales nécessaires à sa fonction. Limites : Glossaire réunissant des définitions de publications du NIST.
Prompt injection is not SQL injection (it may be worse) UK National Cyber Security Centre · 8 décembre 2025 · Recommandations officielles Explique que les modèles d’IA n’ont pas de frontière fiable entre données et instructions. L’injection de prompt pourrait donc ne jamais être entièrement résolue. Préconise des limites fixes indépendantes de l’IA sur les actions des systèmes, le moindre privilège et la journalisation. Limites : Destinées aux professionnels de la sécurité.
The lethal trifecta for AI agents Simon Willison · 16 juin 2025 · Analyse d’un praticien Identifie la combinaison de l’accès aux données privées, de l’exposition à du contenu non fiable et de la capacité de communication externe comme la condition permettant le vol de données par des agents IA. Précise qu’aucune technique connue ne l’empêche de façon fiable. Limites : Cadre d’un praticien, non évalué par les pairs.
Model AI Governance Framework for Agentic AI Infocomm Media Development Authority, Singapore · Version 1.5 du 20 mai 2026 (première publication le 22 janvier 2026) · Cadre volontaire Les organisations et les personnes chargées de la supervision répondent des actions des agents. Le cadre préconise une approbation humaine aux étapes importantes, par exemple avant une suppression de données, un envoi de messages ou un paiement. Lorsque c’est possible, le système doit imposer cette approbation. Des examens très rapides ou de très rares interventions pour annuler une décision peuvent signaler des validations par habitude. Limites : Recommandations volontaires, pas une loi. Les études de cas ont été fournies par les entreprises elles-mêmes.