Un agent IA capable d'envoyer du courrier peut avoir des conséquences commerciales même lorsque chaque message passe SPF, DKIM et DMARC. L'authentification aborde les aspects de l'identité du domaine d'envoi ; il n'établit pas que le message était autorisé, exact ou approprié. Gérez l’action d’envoi en tant que fonctionnalité distincte avec un objectif et une portée de destinataire définis.
Définir ce que l'agent peut communiquer
Spécifiez les cas d'utilisation approuvés, le compte d'envoi, les sources des destinataires, les limites de volume, les règles de pièce jointe et les exigences de révision. Les résumés de statut internes de routine et les engagements contractuels ne doivent pas partager le même processus d’approbation autonome. Restreignez les destinataires externes et les contenus sensibles conformément à la politique de l’organisation, et déterminez qui peut modifier cette politique.
Dérivez l’identité du destinataire à partir d’un répertoire fiable ou d’une adresse explicitement approuvée, et non d’une instruction intégrée dans un e-mail en cours d’analyse. Un message indiquant d'envoyer le rapport à cette nouvelle adresse constitue une preuve à évaluer et non une autorisation automatique. Injection rapide OWASP explique pourquoi un texte externe peut manipuler le comportement de l'agent s'il est traité comme une instruction.
Gardez l'autorité d'envoi séparée de la lecture
Utilisez une identité d'envoi avec uniquement les autorisations de boîte aux lettres et d'API nécessaires. Une intégration de lecture de rapports ne doit pas obtenir silencieusement l’autorité d’envoi en tant que ou d’envoi pour le compte. Conservez la génération, l'approbation et la soumission de brouillons en tant qu'événements enregistrés distincts. Avant de soumettre, vérifiez à nouveau les destinataires, le sujet, le corps et les pièces jointes par rapport à la version approuvée.
OWASP agence excessive recommande de limiter les fonctions et autorisations exposées et d’appliquer l’autorisation en aval. Appliquez ces contrôles au niveau de la passerelle d'envoi afin qu'un modèle ne puisse pas les contourner avec un outil HTTP générique ou une autre API de messagerie. Les limites de débit et un kill switch réduisent l'impact mais ne remplacent pas l'autorisation du destinataire et du contenu.
Tester un workflow d'envoi limité
Pour le plan écrit SEND-01, supposez tenant-A/service-mailbox, From status@example.invalid , destinataire ops@example.invalid , sujet Statut de routine, corps Révision terminée ; aucun changement proposé, aucune pièce jointe, objectif statut interne. Toutes les identités sont illustratives et aucune information d’identification ou approbation réelle n’est fournie.
Selon une règle de passerelle proposée, l'objet exact avec une approbation protégée valide et un ID d'opération inutilisé pourrait devenir éligible pour la soumission. Un nouveau destinataire externe, une pièce jointe, un objet contractuel, un corps modifié, un expéditeur modifié, un compte différent ou un identifiant d'opération réutilisé doivent l'arrêter. Une route HTTP générique ne doit pas contourner la même limite d'autorisation. Ce sont des décisions attendues et non des tests exécutés.
En production, distinguez une demande acceptée par le fournisseur de la livraison au destinataire. Si la réponse d'envoi est perdue, inspectez les identifiants de message ou d'opération disponibles avant de réessayer pour éviter les messages en double. La prise en charge de l'idempotence du fournisseur varie ; un agent de relecture local ne peut à lui seul prouver une livraison unique en cas de panne de réseau.
Conserver une chaîne d'action inspectable
La séquence proposée est la récupération du rapport approuvé, la création d'un brouillon, la décision humaine autorisée, la validation de la passerelle d'exécution, la soumission du fournisseur et l'observation séparée de la livraison. Enregistrez quel composant possède chaque étape. L’ID de demande du fournisseur, le reçu d’approbation, l’horodatage de soumission et le résultat de la livraison ne sont pas disponibles dans cet exemple. Aucun adaptateur de fournisseur, aucun test de garde locale ou de relecture n'a été exécuté et aucun message n'a été envoyé.
Authentifier et auditer le chemin de messagerie réel
Configurez l'authentification documentée du service d'envoi pour le domaine From choisi et vérifiez les messages de test autorisés chez les destinataires. RFC 9989 explique alignement, alors que DKIM sépare la responsabilité du signataire de celle de l'auteur présumé. Aucun des deux protocoles ne certifie la véracité d’une déclaration générée par l’IA.
Conservez l'autorisation de l'utilisateur ou du service, la version du contenu approuvée, la résolution du destinataire, le résultat de la soumission et les preuves de livraison ultérieure sous des contrôles de conservation appropriés. Fournit un moyen de suspendre l'envoi immédiatement sans désactiver le diagnostic en lecture seule. Si un message non autorisé est envoyé, traitez-le comme un incident de communication ; la réparation DNS ne retirera pas son contenu.