Agent AI, który może wysyłać pocztę, może mieć konsekwencje biznesowe, nawet jeśli każda wiadomość zostanie przekazana SPF, DKIM I DMARC. Uwierzytelnianie dotyczy aspektów tożsamości domeny wysyłającej; nie stwierdza, czy wiadomość była autoryzowana, dokładna lub odpowiednia. Zarządzaj akcją wysyłania jako osobną możliwością ze zdefiniowanym celem i zakresem odbiorców.
Zdefiniuj, co agent może komunikować
Określ zatwierdzone przypadki użycia, konto wysyłające, źródła odbiorców, limity woluminów, reguły załączników i wymagania dotyczące przeglądu. Rutynowe podsumowania statusu wewnętrznego i zobowiązania umowne nie powinny mieć tej samej autonomicznej ścieżki zatwierdzania. Ogranicz odbiorców zewnętrznych i treści wrażliwe zgodnie z polityką organizacji i ustal, kto może zmienić tę politykę.
Uzyskaj tożsamość odbiorcy na podstawie zaufanego katalogu lub wyraźnie zatwierdzonego adresu, a nie na podstawie instrukcji zawartej w analizowanej wiadomości e-mail. Wiadomość z informacją o wysłaniu raportu na ten nowy adres jest dowodem do oceny, a nie automatyczną autoryzacją. Natychmiastowy zastrzyk OWASP wyjaśnia, dlaczego tekst zewnętrzny może manipulować zachowaniem agenta, jeśli jest traktowany jako instrukcja.
Uprawnienia do wysyłania należy oddzielić od uprawnień do czytania
Używaj tożsamości wysyłającej tylko z niezbędnymi uprawnieniami do skrzynki pocztowej i interfejsu API. Integracja polegająca na czytaniu raportów nie powinna po cichu zyskiwać uprawnień do wysyłania w imieniu lub wysyłania w imieniu. Zachowaj generowanie wersji roboczej, zatwierdzanie i przesyłanie jako osobne rejestrowane zdarzenia. Przed przesłaniem ponownie sprawdź odbiorców, temat, treść i załączniki pod kątem zatwierdzonej wersji.
OWASP Nadmierna swoboda zaleca ograniczenie odsłoniętych funkcji i uprawnień oraz egzekwowanie autoryzacji na dalszym etapie. Zastosuj te kontrolki na bramce wysyłającej, aby model nie mógł ich ominąć za pomocą ogólnego narzędzia HTTP lub alternatywnego interfejsu API poczty. Limity szybkości i wyłącznik awaryjny zmniejszają wpływ, ale nie zastępują autoryzacji odbiorcy i treści.
Przetestuj ograniczony przepływ pracy wysyłania
W przypadku planu pisemnego SEND-01 załóż skrzynkę pocztową najemcy A/usługi, od status@example.invalid , odbiorca ops@example.invalid , temat Status rutynowy, treść Recenzja zakończona; brak propozycji zmian, brak załączników, cel, status wewnętrzny. Wszystkie dane mają charakter poglądowy i nie są dostarczane żadne dane uwierzytelniające ani rzeczywiste zatwierdzenia.
Zgodnie z proponowaną regułą dotyczącą bramy do przesłania może kwalifikować się dokładny obiekt z ważnym chronionym zatwierdzeniem i niewykorzystanym identyfikatorem operacji. Nowy odbiorca zewnętrzny, zajęcie, cel umowny, zmiana podmiotu, zmiana nadawcy, inne konto lub ponownie użyty identyfikator operacji muszą to zatrzymać. Ogólna trasa HTTP nie może omijać tej samej granicy autoryzacji. Są to oczekiwane decyzje, a nie wykonane testy.
W środowisku produkcyjnym rozróżnij żądanie zaakceptowane przez dostawcę od dostarczenia odbiorcy. Jeśli odpowiedź na wiadomość zostanie utracona, przed ponowną próbą sprawdź dostępne identyfikatory wiadomości lub operacji, aby uniknąć duplikacji poczty. Obsługa idempotencji dostawcy jest różna; Sam lokalny strażnik powtórek nie jest w stanie udowodnić dostarczenia dokładnie raz przez awarię sieci.
Zachowaj możliwy do sprawdzenia łańcuch działań
Proponowana sekwencja obejmuje pobieranie zatwierdzonego raportu, tworzenie wersji roboczej, autoryzowaną decyzję człowieka, walidację bramki wykonawczej, przesłanie dostawcy i oddzielną obserwację dostawy. Zapisz, który komponent jest właścicielem każdego kroku. Identyfikator żądania dostawcy, potwierdzenie zatwierdzenia, sygnatura czasowa przesłania i wynik dostarczenia są niedostępne w tym przykładzie. Nie przeprowadzono testu adaptera dostawcy, lokalnego strażnika ani testu powtórki i nie wysłano żadnej wiadomości.
Uwierzytelnij i sprawdź rzeczywistą ścieżkę poczty
Skonfiguruj udokumentowane uwierzytelnianie usługi wysyłającej dla wybranej domeny Od i zweryfikuj autoryzowane wiadomości testowe u odbiorców. RFC 9989 wyjaśnia wyrównanie, chwila DKIM oddziela odpowiedzialność podpisującego od rzekomego autora. Żaden z protokołów nie potwierdza prawdziwości oświadczenia wygenerowanego przez sztuczną inteligencję.
Zachowaj autoryzację użytkownika lub usługi, zatwierdzoną wersję treści, decyzję odbiorcy, wynik przesłania i dowody późniejszej dostawy pod odpowiednimi środkami kontroli przechowywania. Zapewnij możliwość natychmiastowego zawieszenia wysyłania bez wyłączania diagnostyki tylko do odczytu. Jeśli zostanie wysłana nieautoryzowana wiadomość, potraktuj ją jako zdarzenie komunikacyjne; naprawienie DNS nie spowoduje wycofania jego zawartości.