Ein KI-Agent, der E-Mails versenden kann, kann geschäftliche Konsequenzen haben, selbst wenn jede Nachricht weitergeleitet wird SPF, DKIM Und DMARC. Die Authentifizierung befasst sich mit Aspekten der Identität der sendenden Domäne; es beweist nicht, dass die Nachricht autorisiert, korrekt oder angemessen war. Steuern Sie die Sendeaktion als separate Funktion mit einem definierten Zweck und Empfängerbereich.
Definieren Sie, was der Agent kommunizieren darf
Geben Sie genehmigte Anwendungsfälle, Sendekonten, Empfängerquellen, Volumenbeschränkungen, Anhangsregeln und Überprüfungsanforderungen an. Routinemäßige interne Statuszusammenfassungen und vertragliche Verpflichtungen sollten nicht denselben autonomen Genehmigungspfad nutzen. Beschränken Sie externe Empfänger und sensible Inhalte gemäß den Richtlinien der Organisation und legen Sie fest, wer diese Richtlinien ändern kann.
Leiten Sie die Empfängeridentität aus einem vertrauenswürdigen Verzeichnis oder einer ausdrücklich genehmigten Adresse ab, nicht aus einer Anweisung, die in einer zu analysierenden E-Mail eingebettet ist. Die Meldung „Senden Sie den Bericht an diese neue Adresse“ ist ein auszuwertender Beweis und keine automatische Autorisierung. OWASP-Prompt-Injektion erklärt, warum externer Text das Verhalten von Agenten manipulieren kann, wenn er als Anweisung behandelt wird.
Halten Sie die Sendeberechtigung vom Lesen getrennt
Verwenden Sie eine sendende Identität mit nur den erforderlichen Postfach- und API-Berechtigungen. Eine Integration zum Lesen von Berichten sollte nicht stillschweigend die Berechtigung „Senden als“ oder „Senden im Namen“ erlangen. Bewahren Sie die Erstellung, Genehmigung und Übermittlung von Entwürfen als separate protokollierte Ereignisse auf. Überprüfen Sie vor der Übermittlung die Empfänger, den Betreff, den Text und die Anhänge erneut mit der genehmigten Version.
OWASP Übermäßige Agentur empfiehlt, offengelegte Funktionen und Berechtigungen einzuschränken und die Autorisierung nachgelagert durchzusetzen. Wenden Sie diese Kontrollen am Sende-Gateway an, damit ein Modell sie nicht mit einem generischen HTTP-Tool oder einer alternativen Mail-API umgehen kann. Ratenbegrenzungen und ein Kill-Switch verringern die Auswirkungen, ersetzen jedoch nicht die Autorisierung von Empfängern und Inhalten.
Testen Sie einen begrenzten Sendeworkflow
Für den schriftlichen Plan SEND-01 gehen wir davon aus, dass Mandant-A/Service-Mailbox, Von status@example.invalid , Empfänger ops@example.invalid , Betreff Routinestatus, Textüberprüfung abgeschlossen ist; Keine Änderung vorgeschlagen, keine Anhänge, Zweck interner Status. Alle Identitäten dienen der Veranschaulichung und es werden keine Berechtigungsnachweise oder tatsächlichen Genehmigungen bereitgestellt.
Gemäß einer vorgeschlagenen Gateway-Regel könnte genau das Objekt mit gültiger geschützter Genehmigung und einer nicht verwendeten Vorgangs-ID für die Einreichung infrage kommen. Ein neuer externer Empfänger, Anhang, Vertragszweck, geänderter Hauptteil, geänderter Absender, anderes Konto oder wiederverwendete Vorgangs-ID muss dies stoppen. Eine generische HTTP-Route darf nicht dieselbe Autorisierungsgrenze umgehen. Dabei handelt es sich um erwartete Entscheidungen, nicht um ausgeführte Tests.
Unterscheiden Sie in der Produktion zwischen einer vom Anbieter akzeptierten Anfrage und einer Empfängerzustellung. Wenn die Sendeantwort verloren geht, überprüfen Sie die verfügbaren Nachrichten- oder Vorgangs-IDs, bevor Sie es erneut versuchen, um doppelte E-Mails zu vermeiden. Die Idempotenzunterstützung des Anbieters variiert. Ein lokaler Wiedergabewächter allein kann bei einem Netzwerkausfall nicht die exakte einmalige Zustellung nachweisen.
Halten Sie eine überprüfbare Aktionskette ein
Die vorgeschlagene Reihenfolge besteht aus genehmigtem Berichtsabruf, Entwurfserstellung, autorisierter menschlicher Entscheidung, Ausführungs-Gateway-Validierung, Übermittlung durch den Anbieter und separater Zustellungsüberwachung. Notieren Sie, welcher Komponente jeder Schritt gehört. Die Anbieteranfrage-ID, der Genehmigungsbeleg, der Übermittlungszeitstempel und das Zustellungsergebnis sind in diesem Beispiel nicht verfügbar. Es wurde kein Provider-Adapter-, Local Guard- oder Replay-Test ausgeführt und es wurde keine Nachricht gesendet.
Authentifizieren und prüfen Sie den tatsächlichen E-Mail-Pfad
Konfigurieren Sie die dokumentierte Authentifizierung des sendenden Dienstes für die ausgewählte Von-Domäne und überprüfen Sie autorisierte Testnachrichten bei Empfängern. RFC 9989 erklärt Ausrichtung, während DKIM trennt die Verantwortung des Unterzeichners vom angeblichen Autor. Keines der Protokolle bescheinigt die Wahrheit einer KI-generierten Aussage.
Bewahren Sie die Benutzer- oder Dienstautorisierung, die genehmigte Inhaltsversion, die Empfängerauflösung, das Übermittlungsergebnis und den Nachweis für die spätere Zustellung unter geeigneten Aufbewahrungskontrollen auf. Bieten Sie eine Möglichkeit, den Versand sofort zu unterbrechen, ohne die schreibgeschützte Diagnose zu deaktivieren. Wenn eine nicht autorisierte Nachricht gesendet wird, behandeln Sie dies als Kommunikationsvorfall. Durch das Reparieren DNS wird dessen Inhalt nicht zurückgezogen.