Un agent autonome est un système qui prend une intention de haut niveau (ex: "prépare le rapport hebdo, envoie-le aux équipes concernées"), planifie les étapes, appelle des outils (lecture de bases, génération de fichiers, envoi d'emails) et boucle jusqu'à la complétion. C'est l'archétype d'application IA en 2026 — adopté massivement avec l'arrivée du MCP (Model Context Protocol) et des frameworks comme LangGraph, AutoGen, Anthropic's claude-agent-sdk.
C'est aussi la forme d'application IA avec la plus grande surface d'attaque et le rayon d'impact le plus large. Un agent compromis ne fait pas juste du contenu douteux : il peut écrire dans une base de production, envoyer des emails au nom de l'entreprise, dépenser de l'argent. La sécurisation ne ressemble pas à celle d'un chatbot.
Le modèle de menace propre aux agents
Au-delà des risques LLM classiques (prompt injection, jailbreak, data leakage — voir Threat modeling LLM), les agents accumulent :
- Hijack par prompt injection indirecte : une instruction cachée dans un document que l'agent lit déclenche un appel d'outil malveillant.
- Boucle d'auto-corruption : la sortie d'un outil (compromise) pollue le tour suivant. L'agent finit par exécuter une chaîne d'actions divergentes.
- Persistance : l'agent écrit des instructions dans un emplacement (fichier, base, ticket) qu'il relira plus tard, créant une porte dérobée.
- Escalade par enchaînement : chaque outil seul est limité dans ses privilèges, mais la combinaison de plusieurs outils permet de passer outre.
- Dépendance fournisseur : l'agent appelle Claude/GPT/Gemini, qui appelle MCP, qui appelle vos systèmes. Un maillon corrompu de cette chaîne suffit.
Le principe de design : moindre privilège agent-spécifique
Le moindre privilège est connu en sécurité depuis les années 1970. Pour les agents, son application requiert quelques spécificités :
1. Privilèges scopés par mission
Un agent qui doit "préparer le rapport hebdo" n'a pas besoin du même périmètre qu'un agent qui doit "répondre aux candidats". Les privilèges sont scopés par mission (cas d'usage) plutôt que par identité de l'agent.
Implémentation :
- Tokens d'authentification courts (15 min — 1h max), renouvelés par cas d'usage.
- Périmètre déclaré explicitement : quels outils, sur quelles données, avec quelle écriture.
- Refus par défaut : si un outil ou une donnée n'est pas explicitement allowlisté, l'agent ne peut pas y accéder.
2. Read vs. Write strict
La majorité des agents lisent beaucoup, écrivent peu. La séparation des deux niveaux de privilège est critique :
- Read-only par défaut, sur la majorité des cas.
- Write seulement quand strictement nécessaire à la tâche, sur le périmètre minimal.
- Confirmation humaine systématique pour toute action à effet de bord externe (envoi email, paiement, modification client).
3. Sandbox d'exécution
Pour les agents qui peuvent exécuter du code (eval Python, scripts shell, requêtes SQL libres) :
- Conteneur éphémère par tour d'agent (Docker, gVisor, microVM).
- Filesystem isolé : pas d'accès à l'host, pas de partage entre tours.
- Réseau bridé : allowlist explicite des destinations autorisées.
- Quotas : CPU, mémoire, temps d'exécution.
- Pas d'identifiants dans l'environnement du sandbox au-delà du strict nécessaire.
Solutions matures en 2026 : E2B, Modal, Claude Code's tool-use sandbox, AWS Lambda éphémères.
4. Kill-switch architectural
Tout agent doit pouvoir être arrêté immédiatement et globalement :
- Un opérateur humain peut désactiver le kill-switch en 1 clic depuis une console (avec MFA).
- L'arrêt invalide les tokens en cours, bloque les tours suivants.
- Le kill-switch est testé périodiquement (table-top trimestriel).
C'est aussi une exigence implicite de la surveillance humaine dans l'AI Act.
Architecture type d'un agent sécurisé
`` [Utilisateur / déclencheur] ↓ [Agent orchestrator] ← politique d'autorisation, kill-switch ↓ [LLM (Claude / GPT)] ← system prompt durci, output filter ↓ [Outil 1] [Outil 2] ← chacun en sandbox, scope minimal ↓ ↓ [Système A] [Système B] ← logs forensiques, alerting ``
Chaque flèche est instrumentée pour le logging et l'audit.
Le pattern de confirmation humaine — quand et comment
Tout n'a pas besoin de confirmation humaine — sinon l'agent perd son intérêt. Mais certaines actions doivent toujours être confirmées :
- Envois externes (email, SMS, notification).
- Mouvements financiers (paiement, virement, ajustement de facture).
- Modifications irréversibles (suppression, mise à jour client visible).
- Actions à fort coût computationnel ou financier (>seuil défini).
Patterns d'implémentation :
- Synchronous confirmation : l'agent bloque, attend la confirmation utilisateur dans l'UI.
- Notification + délai : l'agent prévoit l'action dans 5 minutes, l'utilisateur peut annuler dans la fenêtre.
- Approval queue : l'agent crée des actions "pending" qu'un humain peut valider en batch.
Le rôle du logging forensique
Pour chaque tour d'agent, conservez :
- Le système prompt et la version utilisée.
- L'input utilisateur ou le déclencheur.
- Le contexte récupéré (RAG, conversations passées).
- Le raisonnement de l'agent (chain of thought si exposé).
- Les outils appelés, avec leurs paramètres et leurs réponses.
- Les actions à effet de bord effectivement exécutées.
Conservation : 6 mois à 5 ans selon votre exposition réglementaire.
Ce log est votre principal outil pour :
- Détecter des comportements anormaux (volume, patterns).
- Investiguer post-incident (qu'est-ce que l'agent a fait, à partir de quoi).
- Démontrer la conformité.
- Améliorer le système (corrections de prompts, tunings d'outils).
Le piège : faire confiance au modèle
Une erreur classique : penser que parce que Claude est "bien aligné" ou que GPT-4 est "responsable", on peut relâcher les guardrails. Faux. L'alignement du modèle base ne protège pas contre :
- Les prompt injections indirectes (le modèle exécute parce qu'il ne sait pas que c'est malveillant).
- Les chaînes d'outils où chaque appel individuel est légitime mais leur combinaison est nuisible.
- Les bugs de votre système d'orchestration.
- Les compromissions amont (clé API volée, dépendance corrompue).
La sécurité de l'agent est un système — pas une propriété du modèle.
Roadmap pratique pour un agent en production
- Threat model spécifique : quelles actions, quels outils, quel rayon d'impact maximal ?
- Périmètre minimal : quels outils sont vraiment nécessaires ? (Souvent, la moitié de la liste initiale est superflue.)
- Authent et autorization stricts : tokens scopés, courts, par mission.
- Sandbox pour tout outil d'exécution.
- Confirmation humaine sur les actions à effet de bord.
- Logging forensique complet.
- Kill-switch opérationnel testé.
- Monitoring runtime : volumes d'appels, taux d'erreur, anomalies.
- Itération : la première version d'agent en prod n'est jamais la dernière. Plan d'amélioration mensuel.
Pour les particularités d'une intégration enterprise de Claude (qui inclut souvent un agent), voir Claude (Anthropic) en entreprise.
