Sécuriser un agent IA connecté à Gmail ou Outlook

Pourquoi un agent connecté à la messagerie est-il à haut risque ?

Parce qu'une boîte mail réunit les trois ingrédients d'une attaque par injection de prompt : des données privées, du contenu écrit par des tiers et un moyen de communiquer vers l'extérieur. Le développeur Simon Willison appelle cette combinaison la « lethal trifecta » : un agent qui accède à des données privées, lit du contenu non fiable et peut communiquer avec l'extérieur peut être manipulé pour fuiter ces données.

N'importe qui peut vous envoyer un e-mail. Si votre agent le lit et dispose d'un outil d'envoi, de transfert ou de recherche dans la boîte, un message piégé peut lui donner des instructions. C'est l'injection de prompt indirecte (LLM01:2025 chez l'OWASP), que nous détaillons sur notre page injection de prompt.

Exemples de ce qu'un e-mail malveillant peut tenter :

• demander à l'agent de transférer les derniers messages contenant « facture » ou « mot de passe » vers une adresse externe ;
• lui faire répondre à un fil avec un lien piégé, depuis l'adresse légitime de l'utilisateur ;
• lui faire créer une règle de transfert ou supprimer des messages ;
• lui faire résumer une pièce jointe contenant des instructions cachées.

Quels scopes OAuth donner à l'agent ?

Donnez le scope le plus étroit qui permet la tâche, et rien d'autre. Un agent qui trie ou résume n'a pas besoin d'envoyer ; un agent qui rédige des brouillons n'a pas besoin de supprimer.

Côté Google, la documentation Gmail API classe les scopes en catégories de sensibilité :

Retenez deux points. D'abord, le scope mail.google.com donne un accès complet : à éviter pour un agent. Ensuite, un scope de lecture seule suffit pour la plupart des agents de tri, de résumé ou de réponse suggérée, tant que l'envoi passe par un circuit séparé.

Côté Microsoft, les permissions Graph équivalentes sont Mail.ReadBasic (lecture hors corps, aperçu, pièces jointes), Mail.Read, Mail.ReadWrite (sans envoi) et Mail.Send. Le point critique : en mode application (sans utilisateur connecté), Mail.Read ouvre la lecture de toutes les boîtes de l'organisation et Mail.Send permet d'envoyer comme n'importe quel utilisateur.

Comment limiter l'agent à certaines boîtes sous Microsoft 365 ?

Utilisez RBAC for Applications dans Exchange Online, qui permet d'associer une permission à une portée de boîtes (étendue de gestion ou unité administrative). Microsoft indique que cette fonction remplace les Application Access Policies.

Le piège documenté par Microsoft mérite d'être testé : les permissions accordées dans Microsoft Entra ID et celles de RBAC for Applications s'additionnent. Si l'application garde un Mail.Read non restreint dans Entra ID, votre étendue RBAC ne sert à rien. Il faut retirer l'octroi organisationnel dans Entra ID. La commande Test-ServicePrincipalAuthorization permet de vérifier, boîte par boîte, ce que l'application peut réellement faire.

Pour un agent qui agit au nom d'un utilisateur, préférez les permissions déléguées : l'agent n'accède alors qu'à la boîte de la personne qui a donné son accord.

Comment traiter le contenu des e-mails ?

Traitez chaque e-mail, objet, corps et pièce jointe comme une entrée non fiable, jamais comme une consigne. Le modèle ne distingue pas fiablement une instruction légitime d'un texte qui en a l'apparence ; la séparation doit venir de l'architecture.

Mesures concrètes :

1. Balisez le contenu. Passez le message dans un bloc explicitement marqué comme donnée, et dites au modèle de ne jamais exécuter d'ordre qui s'y trouve. C'est une aide, jamais une protection suffisante.
2. Réduisez ce que l'agent lit. Si l'objet et l'expéditeur suffisent pour trier, n'envoyez pas le corps.
3. Traitez les pièces jointes à part. Un document converti en texte peut contenir des instructions invisibles à l'écran (texte blanc, métadonnées, commentaires).
4. Ignorez les messages externes pour les actions sensibles. Les consignes d'un expéditeur hors domaine n'ont aucune autorité.
5. Séparez lecture et action. Un premier composant lit et produit une sortie structurée (catégorie, résumé, brouillon). Un second, sans accès au texte brut, décide de l'action.

Comment encadrer l'envoi et les actions d'écriture ?

Exigez une validation humaine pour tout envoi, tout transfert et toute suppression, et appliquez ces limites dans le code, hors du modèle. L'OWASP le formule pour l'Excessive Agency (LLM06:2025) : appliquer l'autorisation dans les systèmes en aval et demander l'approbation d'un humain pour les actions à fort impact.

Contrôles utiles :

• Brouillon uniquement. L'agent crée un brouillon ; l'utilisateur relit et clique sur envoyer.
• Liste blanche de destinataires ou de domaines autorisés, vérifiée par le code qui appelle l'API.
• Aucun lien ni image externe généré par l'agent dans les messages sortants sans contrôle.
• Plafond d'envoi par heure et par jour, pour limiter les dégâts d'un détournement.
• Interdiction des règles de transfert et des modifications de paramètres de boîte.
• Journal complet : chaque lecture, chaque brouillon, chaque envoi, avec l'identifiant du message qui l'a déclenché.

Quels tests faut-il faire avant la mise en service ?

Envoyez-vous des e-mails piégés depuis un compte externe et regardez ce que l'agent fait, dans les journaux d'API plutôt que dans sa réponse. La liste ci-dessous couvre les cas les plus rentables.

Utilisez uniquement des comptes de test et des boîtes que vous contrôlez. Notre méthode détaille la façon dont nous structurons ces scénarios.

Comment surveiller et révoquer les accès ?

Surveillez les actions de l'agent séparément de celles de l'utilisateur, et prévoyez un moyen de couper l'accès en quelques minutes. Utilisez un compte ou une application dédiée, de sorte que les journaux distinguent clairement ce que fait l'agent.

• Stockez les jetons OAuth dans un gestionnaire de secrets, jamais dans le prompt ni dans le contexte du modèle.
• Alertez sur les volumes anormaux : nombre de lectures, d'envois, nouveaux destinataires.
• Documentez la procédure de révocation : où retirer le consentement, qui peut le faire, en combien de temps.
• Revoyez les consentements à chaque changement de fonctionnalité de l'agent.

Que retenir ?

Le risque d'un agent de messagerie ne dépend pas de la qualité du modèle mais de ce qu'il a le droit de faire. Réduisez les scopes, bornez les boîtes accessibles, isolez le contenu des e-mails et gardez un humain devant l'envoi. Pour le panorama complet, voyez notre guide de la sécurité des agents IA.

Si vous voulez qu'un tiers attaque votre agent de messagerie avant vos utilisateurs, le Red Team Agent Express cartographie ses accès et teste ces scénarios sur 5 jours pour 1 900 €.