Les agents IA ne doivent pas être un cauchemar de sécurité

SECTION 1

Pourquoi l'autonomie des agents IA change la donne en sécurité

Les agents IA ne se contentent plus de générer du texte : ils lisent des bases de données, appellent des API, exécutent du code, envoient des emails et enchaînent des dizaines d'actions sans validation humaine à chaque étape. Cette autonomie, qui fait toute leur valeur, supprime le point de contrôle traditionnel de la sécurité informatique : l'humain qui approuve chaque opération sensible avant qu'elle ne s'exécute.

En 2026, la question n'est plus théorique. Les agents sont en production dans le support client, les opérations IT, la finance et le développement logiciel, connectés aux systèmes internes via le Model Context Protocol (MCP) et orchestrés par des frameworks arrivés à maturité comme LangGraph 1.0 ou Microsoft Agent Framework, le successeur unifié d'AutoGen et de Semantic Kernel. Thoughtworks en a même fait un thème de son Technology Radar d'avril 2026 : sécuriser des agents « avides de permissions ».

Chez Adservio, nous avons développé un framework de sécurité pour l'IA agentique fondé sur des principes éprouvés, défense en profondeur, moindre privilège, fail secure, adaptés aux spécificités des LLM. Cet article détaille les menaces à connaître, les six couches de défense à mettre en place et la gouvernance qui les fait vivre dans la durée.

SECTION 2

Les sept menaces majeures, de la prompt injection aux rogue agents

Avant de sécuriser, il faut comprendre ce qui menace. Le projet OWASP GenAI Security a publié en 2026 son Top 10 des risques pour les applications agentiques, qui confirme ce que les équipes de terrain observaient déjà : la prompt injection reste la vulnérabilité la plus exploitée, impliquée dans la majorité des incidents agentiques recensés en production.

### La prompt injection, menace numéro un

Un attaquant injecte des instructions malveillantes dans les entrées de l'agent, requête utilisateur, document traité, page web récupérée, message Slack ou Teams, pour détourner son comportement. L'OWASP parle désormais de détournement d'objectif (agent goal hijack) : l'agent poursuit un but qui n'est plus celui de son propriétaire, en conservant toutes ses permissions légitimes. C'est ce qui rend l'attaque si dangereuse : elle ne casse rien, elle retourne l'outil contre son organisation.

Viennent ensuite l'exfiltration de données sensibles (PII, secrets, propriété intellectuelle divulgués dans les réponses ou les logs), l'escalade de privilèges (chaînage d'outils individuellement autorisés pour atteindre un objectif interdit), le déni de service et son variant financier, le cost DoS, un agent manipulé peut générer des dizaines de milliers d'euros d'appels API en quelques heures, et l'empoisonnement des données ou de la mémoire : corruption du RAG, des embeddings ou de la mémoire long terme de l'agent, qui érode silencieusement la fiabilité de ses décisions.

### Chaîne d'approvisionnement et agents devenus incontrôlables

Deux familles complètent le tableau : les actions non autorisées (suppression de données, transaction, commit malveillant, email envoyé au nom d'un dirigeant) et les attaques sur la chaîne d'approvisionnement, bibliothèques d'agents, serveurs MCP tiers, modèles pré-entraînés compromis. Les incidents récents sur des packages populaires de l'écosystème agentique ont montré qu'une seule dépendance vérolée suffit à propager une charge malveillante dans des milliers de déploiements. L'OWASP y ajoute le rogue agent : l'agent qui dérive de son comportement attendu et devient une menace interne autorisée, de confiance, mais désalignée.

@cite:comment-le-prompt-fencing-peut-contrer-les-attaques-par

SECTION 3

Un framework de défense en profondeur en six couches

Face à ces menaces, aucune mesure isolée ne suffit. Nous appliquons chez Adservio un framework en six couches, où chaque couche part du principe que la précédente peut être contournée, c'est la définition même de la défense en profondeur.

Ces couches ne sont pas réservées aux grands groupes : elles se déploient progressivement, en commençant par l'IAM et le filtrage des sorties, qui offrent le meilleur rapport protection/effort. L'erreur classique consiste à tout miser sur un seul contrôle, un filtre anti-injection réputé intelligent, en négligeant les permissions : c'est la combinaison des couches qui rend une attaque coûteuse, pas la perfection d'une seule.

### Identité, accès et moindre privilège

Chaque agent dispose d'un compte de service dédié, de permissions RBAC granulaires définies au niveau action et ressource (« read:customers », jamais « admin »), de credentials à rotation automatique gérés par un secrets manager et de tokens à durée de vie courte. La règle est simple : un agent ne doit jamais pouvoir faire plus que ce que sa mission exige, et ses permissions doivent expirer d'elles-mêmes si elles ne servent pas.

### Filtrer les entrées et les sorties

En entrée : validation de longueur et de format, détection de patterns d'injection connus et scoring de malveillance par un modèle de classification dédié, sans jamais considérer ce filtrage comme étanche, car la prompt injection est une faille structurelle des LLM : on la limite, on ne l'élimine pas. En sortie : détection et masquage automatiques des PII avec des outils comme Presidio, scanning de secrets et filtrage de contenu avant toute livraison à l'utilisateur, pour qu'une injection réussie ne se transforme pas en fuite de données.

### Sandboxing, monitoring et gouvernance

L'exécution est isolée dans des conteneurs ou des fonctions serverless à ressources limitées, avec une liste blanche d'outils, une validation des paramètres de chaque appel et des quotas par outil. Le monitoring journalise toutes les actions au format structuré, entrées, sorties, appels d'outils, centralisées dans le SIEM, avec détection d'anomalies par rapport à une baseline comportementale. La sixième couche, la gouvernance, orchestre l'ensemble : validation humaine, kill switches et audits, détaillés plus bas.

SECTION 4

Sécuriser MCP et le tool-calling : l'identité machine au premier plan

Le Model Context Protocol s'est imposé comme le standard de connexion des agents aux outils et aux données de l'entreprise. Bonne nouvelle : sa spécification a considérablement mûri sur le plan sécurité. Un serveur MCP protégé agit désormais comme un resource server OAuth 2.1, et les clients doivent implémenter les Resource Indicators (RFC 8707), qui lient chaque token à sa cible et empêchent sa réutilisation d'un service à l'autre.

Reste que l'autorisation MCP demeure optionnelle et que le scoping fin reste à la charge des équipes. Concrètement : n'exposer que le minimum d'outils nécessaires, exiger des scopes distincts pour chaque outil sensible, valider côté serveur chaque paramètre reçu, et traiter tout contenu renvoyé par un serveur MCP tiers comme une entrée non fiable, donc soumise aux mêmes filtres anti-injection que les inputs utilisateurs.

L'identité machine devient ainsi un sujet de premier plan : chaque agent doit être identifiable, auditable et révocable individuellement, exactement comme un collaborateur. C'est la condition pour appliquer le moindre privilège à des flottes entières d'agents plutôt qu'à quelques prototypes isolés.

@cite:resoudre-les-defis-de-securite-mcp-avec-le-modele

SECTION 5

Supervision humaine, kill switches et conformité continue

La gouvernance transforme les couches techniques en système vivant. Le human-in-the-loop se pilote par une matrice de criticité plutôt qu'au cas par cas : lire une fiche client, à risque faible, ne requiert aucune validation ; envoyer un email, à risque moyen, demande l'approbation d'un manager ; modifier des données de facturation, à risque élevé, exige l'approbation conjointe du manager et de la finance ; supprimer une base de données, critique, ne se fait pas sans le CTO. L'agent escalade aussi automatiquement dès que son score de confiance passe sous un seuil défini.

### Kill switches et rollback

Tout déploiement d'agent doit pouvoir être stoppé en quelques secondes : circuit breaker accessible aux équipes métier, désactivation automatique sur comportement anormal détecté, configurations versionnées en GitOps pour un rollback immédiat. Ces mécanismes se testent régulièrement, comme un exercice incendie, un kill switch jamais actionné est un kill switch présumé cassé.

S'y ajoutent le red teaming périodique des agents, la mise à jour du threat model à chaque nouvel outil connecté, et la conformité réglementaire : l'AI Act européen, dont les obligations montent en charge en 2026, impose documentation des risques, supervision humaine effective et traçabilité pour les systèmes à haut risque, autant d'exigences que ce framework couvre nativement plutôt qu'en rattrapage.

SECTION 6

Cas concret : un agent de support client sécurisé en production

Illustrons le framework avec un cas réel : un agent de support qui répond aux clients 24/7, accède à une base de plusieurs millions d'enregistrements et peut créer ou modifier des tickets, via Slack et web chat. Les menaces prioritaires identifiées : exfiltration de données clients par prompt injection, modification non autorisée de tickets, déni de service par flood de requêtes et divulgation de PII dans les réponses.

Les mesures déployées déclinent les six couches : compte de service en lecture seule sur les clients et en création/mise à jour sur les seuls tickets, sans aucune permission de suppression ; entrées limitées à 2 000 caractères avec scoring de malveillance et rate limiting à 10 requêtes par minute et par utilisateur ; masquage automatique des PII et vérification d'ownership avant toute réponse, pour qu'un client ne voie jamais les données d'un autre ; exécution en conteneur avec une liste blanche de cinq outils contraints ; dashboard temps réel avec alertes sur les coûts, la latence et le taux de tentatives d'injection ; enfin, validation humaine dans Slack pour les envois d'emails et kill switch aux mains des managers support.

Après six mois de production : zéro incident de sécurité majeur, quinze tentatives de prompt injection bloquées, 70 % de tickets en moins traités par des humains, satisfaction client stable et coûts maîtrisés sous le budget. La sécurité n'a pas bridé la valeur de l'agent : elle l'a rendue durable.

@cite:l-ia-agentique-au-travail-comment-les-agents-autonomes

SECTION 7

Faire des agents IA un atout sécurisé, pas un cauchemar

Les agents IA ne doivent pas être un cauchemar de sécurité. Cinq principes résument la démarche : défense en profondeur, moindre privilège, fail secure, en cas de doute ou d'erreur, bloquer plutôt que permettre, observabilité totale de chaque action, et contrôle humain maintenu sur les décisions critiques.

C'est un processus continu, pas un projet ponctuel : les menaces évoluent aussi vite que les capacités des modèles, et chaque nouvel outil connecté élargit la surface d'attaque. Chez Adservio, nous accompagnons nos clients de l'audit de leurs premiers agents jusqu'à l'industrialisation de flottes sécurisées, avec une méthodologie éprouvée en production. L'IA agentique est l'avenir du travail : construisons-le sur des fondations sécurisées et résilientes.

Note : les déclarations et opinions exprimées dans cet article sont celles de l'auteur et ne reflètent pas nécessairement les positions d'Adservio.

FAQ

Questions fréquentes