Une équipe que j'ai accompagnée en T1 2026 a brûlé 23 000 € de tokens Claude en 4 heures un week-end. Un agent en boucle. Une boucle déclenchée par une condition d'arrêt mal codée. Personne en garde. Détection au lundi matin via un mail de l'admin Anthropic.
Ce n'est pas un cas extrême. Sur 14 missions WeeSec depuis octobre 2025, j'ai vu deux incidents similaires. Le cost runaway est devenu un risque opérationnel sérieux. Il mérite des garde-fous au même titre que la sécurité technique.
Trois mécanismes qui causent un runaway
1. La boucle d'agent
L'agent appelle un outil, n'obtient pas le résultat attendu, retente. Et retente. Et retente. Sans condition d'arrêt. Sur des sous-tâches longues qui retournent en streaming, l'agent peut boucler des heures sans qu'un humain ne le remarque.
Causes typiques :
- Tool qui retourne un format non attendu : l'agent croit avoir échoué.
- Condition d'arrêt formulée vaguement ("jusqu'à ce que tu sois satisfait du résultat").
- Bug dans la logique de planning.
2. L'amplification multi-agent
Système avec planificateur + workers. Le planificateur décide pour chaque sous-tâche de demander une "validation" à un autre agent. Le validateur, sous prompt injection, demande "plus d'information". Le planificateur appelle d'autres workers pour fournir plus d'information. Boucle exponentielle.
3. L'abus utilisateur
Un utilisateur (ou un attaquant qui se fait passer pour) lance des requêtes en parallèle massif, ou des requêtes qui demandent à l'agent de "tout analyser" sur un corpus énorme. Le coût explose sans intention malveillante côté agent — c'est l'utilisateur qui force.
Les défenses, par couche
Couche 1 — Limites au niveau du LLM provider
Tous les providers majeurs (Anthropic, OpenAI, Google, Mistral) proposent des rate limits et des spending caps au niveau du compte. À configurer dès l'ouverture du compte :
- Spending cap mensuel : valeur cohérente avec le budget annuel / 12 + marge 30%.
- Notifications par seuils (50%, 75%, 90%, 100% du cap).
- Rate limit sur le nombre de requêtes par minute.
C'est la ceinture de sécurité minimale. Beaucoup d'équipes l'ignorent parce qu'elles ne veulent pas être "bloquées". Le bon paramétrage évite le pic catastrophique sans gêner le quotidien.
Couche 2 — Limites par session et par utilisateur
Au niveau de votre application :
- Tokens / session : limite stricte. Si la session dépasse, fin propre + alerte.
- Tokens / utilisateur / jour : protège contre les abus d'un compte compromis.
- Tokens / endpoint : différencier les endpoints peu coûteux (chat simple) des endpoints coûteux (research mode avec multi-tool).
Couche 3 — Limites par agent
Pour les agents autonomes en background :
- Max steps par tâche : nombre maximal de tool calls avant timeout. Typique : 30-100 selon la complexité.
- Max tokens cumulés : indépendant du nombre de steps. Couvre le cas des contextes qui gonflent.
- Wall clock timeout : limite en secondes.
Au déclenchement d'une limite : arrêt propre, log du contexte, escalade à un humain ou notification claire à l'utilisateur.
Couche 4 — Détection statistique d'anomalie
Au-delà des limites dures :
- Suivre la consommation par session, par utilisateur, par version d'agent.
- Détecter les écarts (un user qui consomme 10x sa moyenne en 1h).
- Alerter sur les sessions qui dépassent les bornes statistiques.
C'est ce qui rattrape les runaways "lents" — pas une boucle frénétique mais un grignotage anormal sur plusieurs heures.
Couche 5 — Kill-switch budget
Une feature flag globale : "désactiver tous les agents non essentiels". Utile en cas de pic de coût détecté et non encore investigué. Pouvoir actionner ça en 30 secondes peut sauver 5 chiffres en heures sup.
Les patterns à coder
Pattern graceful degradation
Quand un agent atteint 80% de sa limite tokens, basculer sur un modèle moins coûteux :
- Claude Opus → Claude Sonnet → Claude Haiku.
- Avec dégradation visible côté utilisateur ("je passe en mode résumé court").
Pattern cost-aware planning
Pour les agents avec planificateur explicite, intégrer le coût comme contrainte du plan :
- "Tu as un budget de 50 000 tokens pour cette tâche."
- Le modèle adapte la profondeur de ses investigations.
Approche utilisée dans certains frameworks 2026 (notamment LangGraph custom). Pas magique mais utile.
Pattern cache agressif
Cache des outputs de tools coûteux (recherche web, requêtes RAG) pendant quelques minutes ou heures. Si l'agent re-demande la même info dans la session, retour cache plutôt que ré-appel.
Coût mémoire faible, économie tokens potentiellement importante sur les agents qui itèrent.
La règle de calcul à se rappeler
Avant de déployer un agent, faire l'exercice :
- Coût moyen par session de l'agent : X tokens × Y € = Z€.
- Sessions / jour attendues : N.
- Coût attendu / jour : N × Z €.
- Coût catastrophe / jour : N × Z × 100 (si runaway non détecté pendant 24h).
Si "coût catastrophe / jour" est supérieur à votre seuil de douleur (pertes définitivement acceptable), il faut des garde-fous matériels, pas juste des bonnes intentions.
Les indicateurs à mettre sur le dashboard du jour 1
- Tokens consommés (jour, semaine, mois) vs budget.
- Distribution des sessions par coût (utile pour spotter les outliers).
- Top 10 des sessions les plus coûteuses du jour.
- Évolution du coût moyen par session (alerte si dérive lente).
C'est aussi simple que ça. Mais sans ces indicateurs visibles, le runaway arrive en silence.
Le contre-exemple instructif
L'équipe qui a brûlé 23 000 € avait :
- Aucune limite par session côté app.
- Aucun spending cap côté Anthropic.
- Aucun dashboard de coût en temps réel.
- Une alerte mail configurée chez Anthropic mais sur le compte facturation, pas le compte opérationnel — la personne qui l'a reçue était en week-end.
Quatre points faibles. Aucun individuellement n'était dramatique. Les quatre ensemble ont fait 23 000 €. La défense en profondeur dans le FinOps IA, c'est exactement ça : pas de point unique, beaucoup de points raisonnables.
Pour le confinement runtime, Confinement d'un agent. Pour la traçabilité, Audit log d'un agent.