Accueil › Guide
Empêcher un agent IA d'envoyer le mauvais email
Les agents IA rédigent et envoient de plus en plus d'emails tout seuls. Pratique — jusqu'à ce qu'un message divulgue un secret, promette une remise non validée, ou parte au mauvais destinataire. Voici pourquoi ça arrive et le garde-fou le plus simple pour l'éviter. English version →
Le problème : l'envoi autonome est rapide, mais sans garde-fou
Dès qu'un agent LLM peut appeler un outil « envoyer un email », il le fera — parfois avec un contenu qu'un humain n'aurait jamais approuvé. Trois modes d'échec reviennent sans cesse :
- Fuite de secret / de données. L'agent colle une clé API, un mot de passe, un document interne ou des données personnelles dans le corps.
- Engagement non validé. Il promet une remise de 30 %, un remboursement ou une clause qui exigeait un accord.
- Mauvais destinataire. Il envoie du contenu sensible à une adresse externe, mal saisie ou non prévue.
Chacun est peu coûteux pour l'agent et cher pour l'entreprise. Un filtre anti-spam ne les attrape pas : l'email est « bien écrit », il est juste dangereux à envoyer.
Le schéma : un point de contrôle avant chaque envoi
La vraie solution n'est pas un meilleur prompt — c'est un point de contrôle entre l'agent et l'envoi réel. Avant d'envoyer, l'agent pose une question et obéit à la réponse :
La plupart des emails passent (send). Les cas risqués mais légitimes sont mis en pause pour validation humaine en un clic (request_human_confirmation). Les dangers clairs sont bloqués (do_not_send). Chaque décision est tracée pour l'audit.
Filtres par mots-clés vs. lecture de l'intention
Les listes de mots cassent dans les deux sens : elles ratent un engagement paraphrasé (« je vous assure qu'on annulera ces frais ») et sur-bloquent des mentions anodines (« le prix du parking est désormais gratuit »). Un bon garde-fou lit l'intention dans n'importe quelle langue, avec une détection par motifs des vrais secrets (sk_live_…, clés AWS, clés privées) comme filet déterministe — et un repli sur des règles si le modèle est indisponible.
Comment l'ajouter en pratique
Avec Qorami, l'agent fait un appel API avant l'envoi et obéit à nextAction.type :
curl -X POST https://qorami.fr/api/verify-email \
-H "x-qorami-api-key: VOTRE_CLE" -H "content-type: application/json" \
-d '{"recipient":"client@example.com","subject":"Offre","body":"...","policyProfile":"sales"}'
# -> { "nextAction": { "type": "send | request_human_confirmation | do_not_send" } }Deux lignes avec le SDK JS/Python ou l'outil LangChain. Quand un humain est nécessaire, le propriétaire est notifié et valide dans le dashboard ; l'agent connaît le résultat par polling ou webhook signé. Détails dans la documentation API. Voir aussi les cas d'usage.
FAQ
Est-ce que le garde-fou envoie l'email ?
Non. Il décide ; c'est votre agent qui envoie. C'est le point de contrôle avant l'envoi, jamais l'expéditeur.
Combien coûte un test ?
Qorami offre des crédits pour tester ; 1 vérification tracée = 1 crédit, et un blocage est gratuit. Créez un compte pour obtenir une clé.
Et la confidentialité des emails ?
Les contenus d'emails sont rédigés puis supprimés selon une politique de rétention ; seules les métadonnées de décision sont conservées pour l'audit.