Idée en 30 secondes
Agent governance est une couche de contrôle au-dessus du runtime qui vérifie chaque étape de l'agent : accès aux tools, limites, budgets et décisions policy avant exécution des actions.
Quand c'est nécessaire : quand l'agent a accès à des tools, APIs, ou exécute des actions réelles en production.
Problème
Sans governance, un agent en production paraît souvent "presque normal" jusqu'au moment de la panne. Il peut appeler des tools à répétition, consommer du budget sans progrès et exécuter des actions que personne n'a explicitement autorisées.
Le pire : ce n'est pas visible immédiatement. Vu de l'extérieur, le run "continue", alors qu'à l'intérieur les risques, coûts et bruit dans les logs augmentent déjà. Sans governance, l'agent est une boucle non contrôlée avec accès aux tools.
Analogie : c'est comme un autopilote de voiture sans limite de vitesse, freins, ni journal d'événements. Tant que la route est droite, tout semble correct. Quand quelque chose part mal, arrêter et comprendre devient bien plus difficile.
C'est exactement pour cela que la governance est nécessaire : pour que le système ait des limites avant l'incident, et pas après.
Solution
La solution est d'ajouter dans le runtime une policy layer dédiée qui prend une décision technique avant chaque action.
La policy layer retourne une des trois décisions : allow, deny ou approval_required.
C'est un niveau séparé du système, pas une partie du prompt ni de la logique du modèle.
Comme RBAC, ces vérifications s'exécutent avant chaque action de l'agent.
La governance est ce qui se place entre l'agent et les actions réelles. Autrement dit, c'est le control plane pour les agents IA.
👉 Governance ne force pas l'agent à se comporter correctement, elle limite ce que l'agent peut réellement faire.
Elle s'implémente comme middleware / policy layer (par exemple dans LangGraph ou un tool gateway custom). Dans cet article, la policy layer (tool gateway) est le composant qui vérifie et contrôle tous les tool calls.
Governance != Safety
Ce sont deux niveaux de contrôle différents :
- Safety : si la décision proposée par l'agent est correcte.
- Governance : si l'agent a le droit d'exécuter cette action en runtime.
Si safety se trompe, governance limite quand même le dommage au niveau runtime.
Exemple
Un agent de support sans governance peut, à cause d'une hallucination, appeler l'API de remboursement des dizaines de fois.
Avec governance :
max_tool_calls = 3max_usd = 100→ l'agent s'arrête à la limite, pas après la perte d'argent.
Governance stoppe l'incident au niveau exécution, sans dépendre du bon comportement du modèle.
Niveaux de contrôle (governance layers)
Ces niveaux fonctionnent ensemble à chaque étape de l'agent.
| Niveau | Ce qu'il contrôle | Mécaniques clés | Pourquoi |
|---|---|---|---|
| Access control | Accès aux actions et tools | RBAC allowlist / denylist | Vérifié avant chaque tool call, bloque les actions non autorisées |
| Execution control | Déroulé d'exécution du run | max_steps rate limiting limites sur les tool calls | Stoppe les boucles et le tool spam |
| Cost control | Dépenses | max_tokens max_tool_calls max_usd | Limite le budget et les dépenses runaway |
| Human control | Intervention humaine | human approval kill switch | Permet de confirmer ou d'arrêter en urgence |
| Observability | Visibilité des événements | audit logs traces métriques alerts (Slack / PagerDuty) | Permet de détecter et analyser rapidement les incidents |
| Lifecycle control | Mises à jour de l'agent | versioning rollback | Permet des releases sûres et un rollback rapide |
Exemple d'alerte :
Slack alert: 🛑 Agent Support-Bot hit max_usd limit ($100). Run stopped at step 12.
En production, cela ressemble généralement à un dashboard de métriques : runs, tool calls, cost, errors.
Comment cela se place dans l'architecture
Agent governance est insérée entre le runtime de l'agent et le monde externe :
Aucun tool call n'est exécuté sans passer par la policy layer.
La policy layer (tool gateway) agit comme gateway / middleware entre runtime et tools.
Chaque appel d'outil passe par :
- Policy layer -> vérification des accès et limites
- Execution -> exécution seulement si allow
- Logs -> écriture dans audit / trace
Stack governance minimale
- allowlist (default deny) — limite l'accès aux tools
- max_steps — stoppe les boucles
- budgets — limitent les dépenses
- retry policy — évite le chaos de retries
- audit logs — permettent l'analyse d'incident
- stop reasons — expliquent pourquoi l'agent s'est arrêté
- kill switch — permet l'arrêt d'urgence pendant incident
C'est le minimum, sans lequel un agent n'est pas un système de production.
Exemple
L'agent appelle un tool :
- allowlist est vérifiée
- RBAC est vérifié
- budget est vérifié
- approval est vérifiée
→ l'action n'est exécutée qu'après ces checks.
Flow policy minimal :
if not policy.allow(tool, args):
return deny("tool_not_allowed")
if not limits.steps_ok():
return stop("max_steps_exceeded")
if not budget.ok():
return stop("budget_exceeded")
result = tool.execute(args)
audit.log(tool, args, result)
return result
Erreurs fréquentes
- s'appuyer uniquement sur le prompt au lieu du contrôle runtime
- absence de policy layer centralisée
- absence de default-deny allowlist
- absence de budgets et limites
- logique de retry dispersée sur plusieurs couches
- audit logs absents
- aucun moyen d'arrêter l'agent
Au final, le système semble contrôlé alors qu'il ne l'est pas.
Auto-vérification
Vérification rapide avant le lancement en production :
Progression: 0/8
⚠ Les contrôles de governance de base manquent
Avant la production, il faut au minimum le contrôle d'accès, des limites, des audit logs et un arrêt d'urgence.
FAQ
Q: Pourquoi governance ne peut pas être remplacée par un seul system prompt ?
A: Le prompt décrit le comportement souhaité. Governance impose les limites d'action réelles en runtime.
Q: Quel est le minimum de governance avant production ?
A: Minimum : default-deny allowlist, limites (max_steps, budgets), stop reason, audit logs et kill switch. Sans cela, l'agent reste non contrôlé sous charge.
Q: Que faut-il implémenter d'abord : approval ou budgets ?
A: D'abord les limites runtime et les budgets pour limiter immédiatement le risque de base sur chaque run. Ensuite, ajouter approval pour les actions risquées et irréversibles (opérations write, changements financiers, suppression de données).
Q: Le kill switch suffit-il pour la sécurité ?
A: Non. Le kill switch est un frein d'urgence, mais ne remplace pas le contrôle d'accès continu, les budgets, les rate limits et l'audit des actions.
Q: Comment le kill switch est-il implémenté techniquement ?
A: En général, c'est un simple flag global (par exemple dans Redis), vérifié par la policy layer avant chaque étape pour stopper l'exécution.
Pages liées
Pour continuer :
- Access Control (RBAC) — comment limiter ce que l'agent a le droit de faire.
- Budget Controls — comment contenir dépenses de tokens, tool calls et $.
- Rate limiting pour agents — comment se protéger du tool spam et des pics de charge.
- Human approval — où une validation humaine est nécessaire pour les actions critiques.
- Audit logs pour agents — comment reconstruire la chaîne d'événements et analyser les incidents.