Une seule idée : chaque tool call doit passer par une chaîne d’action gouvernée (identité, droits, preuves, sandbox, validation).
Ressource de travail réutilisable pour auditer un agent avant la mise en production.
Un agent qui appelle des outils n’est plus seulement un système de texte. Il peut déclencher des actions réelles via des APIs, des scripts, des tickets, ou des workflows.
Le risque principal n’est pas une mauvaise réponse. C’est une mauvaise action, lancée avec trop de droits, et sans preuve exploitable après coup.
Cloudflare décrit ce basculement comme un sujet d’infrastructure : il faut des primitives de stockage, d’exécution et de sécurité adaptées aux agents autonomes. Source : https://blog.cloudflare.com/agents-week-welcome/
Cette ressource se concentre sur un mécanisme unique : transformer chaque tool call en « action gouvernée » (authentifiée, autorisée, journalisée, isolée, et validée si besoin).
##Contrôles minimum avant production (à cocher)
- -Chaque tool call est authentifié et rattaché à une identité d’agent (pas un compte humain partagé).
- -Chaque tool call est autorisé par une règle explicite (action + périmètre + contexte), pas « si ça marche ».
- -Chaque tool call est journalisé avec : identité, action demandée, paramètres d’entrée, décision (allow/deny), résultat.
- -Accès aux données au strict nécessaire, et lecture seule par défaut quand c’est possible.
- -Exécution en environnement isolé (sandbox) sans secrets de prod, avec contrôle de l’egress réseau.
- -Actions irréversibles ou à fort impact : validation humaine obligatoire (suppression, paiement, changement de droits, changement de config).
- -Tests d’injection de prompt sur tous les chemins d’ingestion (web, documents, tickets, email) avant ouverture large.
##Audit rapide (ordre conseillé)
##Carte des contrôles (stockage, exécution, sécurité)
Groupe 1 : Sécurité : identité et moindre privilège
- ->Une identité dédiée par agent (ou par type d’agent), pas un token global.
- ->Permissions minimales par outil (scopes étroits), pas d’accès admin « par confort ».
- ->Rotation et révocation simples (si l’agent est compromis, vous coupez vite).
Groupe 2 : Sécurité : frontières d’outils (tool boundaries)
- ->Fonctions étroites (ex : « creer_ticket » limité) plutôt qu’API large (ex : « admin_all »).
- ->Paramètres validés côté serveur (schéma, types, bornes), pas seulement dans le prompt.
- ->Règles de blocage sur actions interdites, même si l’agent insiste.
Groupe 3 : Exécution : sandbox et egress
- ->Runtime isolé : filesystem restreint, pas d’accès aux secrets de prod par défaut.
- ->Réseau sortant contrôlé (allowlist, DNS, proxy, timeouts).
- ->Séparation claire préprod/prod (et interdiction d’escalade via variables ou métadonnées).
Groupe 4 : Stockage : mémoire, état, artefacts
- ->État persistant limité (durée, taille, contenus autorisés).
- ->Pas de stockage de secrets ou de données sensibles dans la « mémoire » de l’agent.
- ->Journaliser les artefacts produits (fichiers, requêtes, payloads) avec un identifiant de trace.
Groupe 5 : Preuves : logs structurés et chaînage
- ->Logs structurés : prompt, outil invoqué, paramètres, décision, résultat, erreurs.
- ->Corrélation : un identifiant unique par exécution (trace id) du début à la fin.
- ->Export SIEM possible et conservation suffisante pour investiguer.
Groupe 6 : Avant montée en charge : évaluations et échecs
- ->Jeux d’éval qui ciblent l’injection de prompt et les actions dangereuses.
- ->Catégoriser les échecs (exfiltration, action non autorisée, boucle infinie, contournement).
- ->Garder un pack de prompts de test rejouables à chaque changement.
##Flux opérationnel : où placer les garde-fous
Utilisez ce flux pour positionner vos contrôles au bon endroit : avant la décision d’action, au moment du tool call, et après l’exécution (preuve).
- ├─Règles de confiance : marquer les sources externes comme non fiables.
- ├─Nettoyage/normalisation : réduire les formats ambigus si possible.
- └─Tests d’injection de prompt sur chaque canal d’entrée avant ouverture.
- ├─Séparer « plan » et « décision d’action » (la décision doit passer par une politique).
- ├─Limiter les outils disponibles selon le contexte (pas de toolbox complète).
- └─Plafonds : nombre d’actions, temps max, et conditions d’arrêt.
- ├─Authentifier + autoriser chaque appel, avec identité d’agent et règles explicites.
- ├─Valider les paramètres côté serveur (schéma, bornes, interdits).
- └─Journaliser : action demandée, paramètres, décision (allow/deny), résultat.
- ├─Sandbox : secrets isolés, accès fichiers restreint, egress contrôlé.
- ├─Workflow d’approbation pour actions irréversibles ou à fort impact.
- └─Gestion des erreurs : retries bornés, pas de boucle silencieuse.
- ├─Chaîne de preuve : relier prompt → tool call → effet externe → résultat.
- ├─Alertes : action refusée, tentative d’action sensible, pics de tool calls, nouveaux endpoints.
- └─Rejouer les évals après tout changement (modèle, prompt, outils, permissions).
##Questions de décision (si vous devez trancher vite)
Qu’est-ce qui change quand un agent « agit » via des outils ?
Vous gérez une surface d’exécution. L’enjeu devient : qui agit, avec quels droits, sur quelles données, et avec quelles preuves après coup.
Quel contrôle mettre en place en premier si je manque de temps ?
Lier chaque tool call à une identité d’agent, puis appliquer autorisation + logs structurés. Sans ça, vous ne pouvez ni reconstruire l’action, ni limiter l’impact.
Où l’injection de prompt fait le plus de dégâts ?
Sur les contenus externes ingérés (pages web, documents, tickets, email). Traitez-les comme non fiables, et testez des scénarios d’injection sur chaque canal.
Quand imposer une validation humaine ?
Dès qu’une action est irréversible ou a un impact élevé : suppression, paiement, changement de droits, changement de configuration, ou propagation à grande échelle.
Source de départ (pour contexte)
Cloudflare pose le cadre « storage, execution, security primitives » pour un web adapté aux agents autonomes. À utiliser comme grille de lecture, puis à traduire en contrôles sur votre pipeline de tool calls.