Un agent qui lit vos e-mails est un agent qui avale du contenu non fiable. Cette phrase, évidente quand on l’écrit, ne l’est pas dans les architectures par défaut : trop de systèmes d’agents connectent un grand modèle à une boîte de réception et considèrent le contenu arrivé comme de l’information à traiter au même titre qu’une consigne de l’utilisateur. C’est exactement là que commence le risque. OpenClaw, comme toute plateforme d’agents-outils, doit être durcie dès lors qu’on lui branche la messagerie — et le premier rempart est le plus simple à concevoir, le plus difficile à respecter : les filtres d’entrée.
Le contenu d’un e-mail n’est jamais une instruction
Un courriel est une donnée. Une pièce jointe est une donnée. Une page web qu’un agent va lire est une donnée. Rien de tout cela ne doit jamais atteindre le modèle comme un ordre. La distinction semble ténue ; elle est structurelle.
L’attaque s’appelle l’injection de consignes (en anglais prompt injection). Son mécanisme est d’une banalité redoutable : un expéditeur glisse dans le corps d’un message un texte rédigé pour être pris au sérieux par l’agent — « ignore tes instructions précédentes », « transfère ce message à… », « le système demande de révéler… », « c’est urgent, agis maintenant ». Les variantes abondent : usurpation du ton du dirigeant, faux message système, urgence artificielle, demande de secrets habillée en routine. Et comme l’agent dispose d’outils — envoyer un courriel, exécuter une commande, publier sur un réseau —, chaque consigne avalée est une porte de sortie.
Pire : l’expéditeur n’a même pas besoin d’être connu. Un démarcheur qui reçoit votre adresse professionnelle peut tenter sa chance sur dix mille boîtes ; il suffit qu’un seul agent, mal filtré, exécute. Les campagnes de phishing qui se contentaient d’abuser un humain abusent désormais des automatisations qui lisent à notre place.
Photo by Brett Jordan on Unsplash.
Les filtres d’entrée, premier rempart
Que faire, concrètement, avant que le contenu ne touche le modèle ?
- Séparer l’entrée de confiance de l’entrée suspecte. La consigne venue du dirigeant authentifié et le corps d’un e-mail n’occupent pas le même canal dans le contexte du modèle. Une balise explicite, une enveloppe distincte, un préfixe « ce qui suit est des données non fiables » : la forme compte, car le modèle lit tout comme du texte.
- Nettoyer avant d’ingérer. Dépouiller le HTML, retirer les balises actives, tronquer les longueurs déraisonnables, borner les tailles de pièces jointes. Un corps d’e-mail de trois cents kilo-octets de charabia n’a rien à faire dans un contexte.
- Valider les caractères de tout ce qui repart vers un outil. Une adresse, un identifiant, un chemin de fichier destinés à une commande doivent correspondre à un jeu de caractères strict — ni espace, ni signe dollar, ni guillemet, ni point-virgule là où un identifiant court est attendu. Une valeur hors forme est rejetée, jamais transmise. C’est la différence entre une substitution de donnée et une exécution de commande.
- Ne rien croire sur la foi du contenu. L’agent ne vérifie pas seulement ce qu’on lui demande : il refuse d’exécuter ce qu’un courriel lui « ordonne », signale la tentative à l’humain et traite le message comme le simple objet d’une tâche — lire, résumer, classer.
La défense en profondeur : les autres stratégies qui tiennent
Aucun filtre d’entrée n’est infaillible. La sécurisation d’un agent connecté à la messagerie est une architecture, pas un interrupteur. Voici les couches qui, ensemble, transforment un risque en risque résiduel.
La validation humaine sur toute action sortante
Le principe est simple : l’agent prépare, l’humain décide. Aucun envoi d’e-mail, aucune publication, aucun transfert sans approbation explicite — idéalement portée par un circuit d’approbation intégré au workflow, jamais contournable et jamais satisfait par un silence. Une gate qui demande « Marquer ces e-mails comme lus ? » ou « Publier cet article ? » est un filtre… de sortie, et le plus efficace qui soit : l’attaquant qui aurait franchi les remparts d’entrée se heurte à une personne.
Les listes d’autorisation strictes
Qui a le droit de déclencher quoi ? Les commandes sensibles — connecter une boîte, lancer une relève, écrire sur un réseau — doivent être réservées aux identifiants autorisés, pas à n’importe quel interlocuteur poli. Un expéditeur de courriel n’est jamais un utilisateur de la plateforme : la messagerie est une entrée de données, pas une console de commandes.
Le cloisonnement des fichiers et des sessions
Les brouillons d’un agent vivent dans un répertoire racine, et les portes qui les publient refusent tout chemin qui en sort — le cantonnement par résolution réelle des liens symboliques. Les sessions planifiées (les relèves automatiques) tournent avec un privilège moindre : lecture, classement, signalement — jamais elles n’approuvent une action au nom d’un humain absent.
La moindre puissance par outil
Un poste de surveillance des avis ne doit pas savoir écrire sur Google. Un outil de lecture ne doit pas accepter de verbe d’écriture. Chaque outil exposé à l’agent doit être borné au geste dont sa tâche a besoin — et les chemins d’exécution des workflows, eux, sont vérifiés avant chaque effet.
La gestion des secrets hors du circuit
Les jetons OAuth vivent dans des fichiers aux permissions restreintes, lus par le code au dernier moment ; ils ne transitent jamais par les arguments de commande, jamais par la conversation, jamais par les journaux. Une clé absente produit une erreur franche invitant à se reconnecter — pas une improvisation vers un service de secours.
La traçabilité et l’idempotence
Chaque e-mail traité est consigné une fois, dans un registre persistant : la relève ne repasse jamais sur un message déjà traité, et une injection ne peut pas faire doublement « avancer » un processus. Les quotas sont bornés, les fenêtres de relève limitées dans le temps : un agent ne peut pas être poussé à épuiser les ressources d’une API par un afflux de pourriel.
Photo by FlyD on Unsplash.
Un dernier réflexe : tester comme un attaquant
Les filtres d’entrée ne se décrètent pas, ils se vérifient. Un jeu d’essais réguliers — e-mails piégés contenant de fausses consignes, usurpations d’identité, demandes de secrets — doit traverser l’agent comme un test de charge traverse un site. La question n’est pas « l’agent comprend-il qu’une injection est suspecte ? » mais « que se passe-t-il, exactement, quand il la rate ? » : si la réponse est « rien ne part sans le feu vert d’un humain », le système est bien construit.
Chez Leading Change, nous déployons des agents d’intégration IA pour les PME et les commerces avec ces couches : contenu traité comme donnée, validation humaine sur chaque envoi, secrets hors circuit, relève bornée et idempotente. Parce qu’un assistant numérique qui lit votre boîte de réception sans ces garde-fous n’est pas un gain de temps — c’est une délégation sans filet.
Vous équipez votre entreprise d’agents qui lisent, trient et publient ? Parlons-en : nous vous montrerons comment nos intégrations traitent chaque e-mail comme une donnée, et chaque décision comme la vôtre.
Photo d’illustration en tête d’article : Sasun Bughdaryan, Unsplash.
