Ataki CSS w webmailu ujawniają lukę w obronie AI poczty e-mail

Google News zwróciło uwagę na atak CSS w webmailu, zaobserwowany od kwietnia 2026 roku w ponad milionie wiadomości phishingowych. Kampania ujawnia podstawowy konflikt w bezpieczeństwie poczty e-mail opartym na AI. Ludzie i maszyny mogą otrzymywać tę samą wiadomość, lecz odczytywać radykalnie różne treści.

Opisana technika, nazywana text salting, wykorzystuje Cascading Style Sheets do ukrywania tekstu wypełniającego w wiadomości HTML. Ten ukryty materiał zmienia sposób interpretowania wiadomości przez zautomatyzowane systemy, nie zmieniając tego, co widzi odbiorca.

Badacze Barracuda znaleźli tę technikę w kampaniach phishingowych o tematyce handlowej, obiecujących nagrody, karty podarunkowe, punkty lojalnościowe lub pilną realizację świadczeń. Atakujący wykorzystywali ukryty tekst, aby rozmyć podejrzany język i sprawić, by złośliwe wiadomości wyglądały bezpieczniej dla zautomatyzowanych filtrów.

Nie jest to po prostu kolejna sztuczka pozwalająca ominąć filtr spamu. Ta sama luka w widoczności może działać w przeciwnym kierunku. Ukryte instrukcje mogą celować w asystenta AI, który podsumowuje e-maile, przygotowuje odpowiedzi, przeszukuje skrzynkę lub uruchamia połączone narzędzia.

To tworzy kluczowy kompromis bezpieczeństwa. Narzędzia AI do obsługi e-maili stają się użyteczniejsze, gdy odczytują więcej kontekstu i otrzymują szerszy dostęp. Te same możliwości zwiększają konsekwencje sytuacji, w której niezaufana treść wiadomości wpływa na model.

Tradycyjne zabezpieczenia zakładają, że wiadomość wyświetlana człowiekowi jest zasadniczo równoważna wiadomości analizowanej przez oprogramowanie. CSS łamie to założenie, tworząc w jednym e-mailu oddzielne wersje: widoczną dla człowieka i odczytywalną przez maszynę.

Bezpośrednia presja spada na Google, Microsoft, dostawców zabezpieczeń poczty e-mail oraz deweloperów budujących asystentów pracujących na danych ze skrzynek. Muszą oni pogodzić analizę surowej wiadomości z treścią po renderowaniu, zachowując jednocześnie dostępność i prawidłowe formatowanie.

Co raport Google News ujawnia o text salting

Istotna zmiana nie polega na tym, że atakujący odkryli ukryty tekst. Chodzi o to, że stare metody omijania zabezpieczeń działają teraz przeciwko ocenie opartej na AI.

Text salting dodaje do złośliwej wiadomości nieszkodliwe lub niepowiązane kontekstowo słowa. Oprogramowanie zabezpieczające analizuje te słowa, lecz CSS uniemożliwia odbiorcy ich zobaczenie.

Barracuda poinformowała o wykryciu miliona ataków wykorzystujących te techniki od kwietnia 2026 roku. Wiadomości należały do kampanii o tematyce handlowej, zbudowanej wokół nagród i ofert realizacji świadczeń.

Atakujący użyli kilku zwykłych właściwości CSS. clip-path: inset(100%) zmniejszał widoczny obszar bloku tekstu do zera. Reguły zerowej wysokości i zerowej wysokości wiersza usuwały podejrzane puste miejsce.

Inne reguły przesuwały tekst poza granicę ekranu. Duża ujemna wartość text-indent przesuwała go o tysiące pikseli w lewo, a overflow: hidden ukrywało zdradzający obecność tekstu pasek przewijania.

Atakujący zmniejszali też rozmiar czcionek do zera. Żadna z tych właściwości sama w sobie nie jest złośliwa. Ta niejednoznaczność sprawia, że prosta lista blokad jest zawodna, ponieważ legalne szablony e-maili mogą stosować pokrewne techniki stylizacji.

Kampania miała podobno opierać się na przejętych witrynach lub domenach podszywających się pod inne podmioty. Niektóre domeny obsługiwały standardowe uwierzytelnianie poczty, w tym DomainKeys Identified Mail, czyli DKIM, który weryfikuje, że wiadomość została podpisana przez uprawnioną domenę.

DKIM nie określa, czy treść jest uczciwa. Weryfikuje obsługę i integralność wiadomości na poziomie domeny. Złośliwy operator kontrolujący uwierzytelnioną domenę nadal może rozpowszechniać phishing.

To rozróżnienie ma znaczenie, ponieważ systemy AI często łączą wiele sygnałów. Uwierzytelnianie, język naturalny, reputacja nadawcy, widoczne linki i struktura wiadomości mogą wpływać na klasyfikację.

Text salting manipuluje sygnałem językowym. Dostarcza klasyfikatorowi większą porcję tekstu wyglądającego na nieszkodliwy, pozostawiając jednocześnie przynętę phishingową wyraźną dla odbiorcy.

Filtr analizujący surowy HTML może napotkać akapity o niepowiązanej działalności biznesowej, obsłudze klienta lub zwykłych transakcjach handlowych. Odbiorca może zobaczyć wyłącznie pilne powiadomienie o nagrodzie i przycisk.

Tworzy to semantyczną wersję danych wejściowych o charakterze adwersarialnym. Atakujący nie musi koniecznie wykorzystywać luki w pamięci oprogramowania. Kształtuje dowody wykorzystywane przez statystyczny system decyzyjny.

Generatywna AI obniża również koszt tworzenia zróżnicowanego tekstu wypełniającego. Atakujący mogą tworzyć inne nieszkodliwe fragmenty dla każdej wiadomości, zmniejszając wartość dokładnego dopasowywania tekstu.

Nagłówek Google News wskazuje zatem na szerszą zmianę. Treść e-maili można obecnie projektować dla dwóch odbiorców: z jedną historią dla użytkownika, a drugą dla maszyny.

Dlaczego filtry e-mailowe AI mają problem z renderowaniem

Model AI nie może wiarygodnie ocenić e-maila, gdy jego dane wejściowe nie odpowiadają wiadomości wyświetlanej odbiorcy.

Wiele systemów bezpieczeństwa poczty e-mail analizuje surową treść wiadomości, ponieważ zawiera ona cenne dowody. Ujawnia adresy URL, atrybuty HTML, metadane, zakodowane sekcje i tekst, który renderowanie może ukryć.

Takie podejście miało sens, gdy ukryty tekst służył głównie do atakowania filtrów spamu opartych na słowach kluczowych. Obrońcy mogli wyszukiwać podejrzane formatowanie i porównywać widoczne słowa z bazowym źródłem.

Duże modele językowe komplikują ten proces. Potrafią wyciągać znaczenie z długich fragmentów, lecz ta zdolność daje także ukrytemu tekstowi większy wpływ na klasyfikację.

Model może widzieć wiadomość zdominowaną przez zwyczajny język handlowy. Widoczne żądanie phishingowe może zajmować jedynie niewielką część całego wejścia odczytywalnego dla maszyny.

Atak nie wymaga, by model wykonał bezpośrednie polecenie. Może odnieść sukces, zmieniając pozorny temat, ton lub intencję na tyle, by uzyskać łagodną klasyfikację.

Analiza po renderowaniu również stwarza problemy. Klienci pocztowi różnią się obsługą HTML i CSS. Wiadomość może wyświetlać się inaczej w Gmail, Outlook, aplikacjach mobilnych i wyspecjalizowanym oprogramowaniu webmail.

Funkcje dostępności mogą także ujawniać tekst ukryty przez domyślne renderowanie wizualne. Czytniki ekranu, tryby wysokiego kontrastu i uproszczone widoki komplikują twierdzenie, że istnieje jedna definitywna prezentacja.

Narzędzia bezpieczeństwa potrzebują więc czegoś więcej niż zrzutu ekranu. Potrzebują ustrukturyzowanego porównania surowej treści, obliczonego układu, danych wyjściowych dla dostępności oraz elementów, które może dostrzec typowy użytkownik.

Najbardziej użyteczne pytanie nie brzmi, czy dana właściwość wygląda podejrzanie w izolacji. Chodzi o to, czy stylizacja tworzy istotną różnicę między interpretacją maszyny a percepcją człowieka.

Akapit o zerowym rozmiarze, zawierający setki niepowiązanych słów, jest silniejszym sygnałem niż pojedyncza ukryta etykieta formatowania. Duże bloki przesunięte poza ekran zasługują na podobną kontrolę.

Obrońcy mogą też porównywać językowe znaczenie widocznych i ukrytych regionów. Wiadomość o nagrodach lojalnościowych nie powinna zawierać ukrytych akapitów o niepowiązanych fakturach, podróżach czy obsłudze klienta.

Atakujący mogą jednak się dostosować. Mogą generować tekst wypełniający, który pozostaje bliski widocznemu tematowi, zmniejszając różnicę semantyczną, a jednocześnie rozcieńczając złośliwe frazy.

Tworzy to wyścig zbrojeń między generowaniem treści a wykrywaniem uwzględniającym widoczność. Filtr musi rozumieć nie tylko to, co mówi wiadomość, lecz także które jej części mają znaczenie dla osoby ją otrzymującej.

Uczenie maszynowe nie jest tu bezużyteczne. Nadal pozostaje wartościowe w wykrywaniu anomalii strukturalnych, wzorców nadawców, infrastruktury kampanii i nietypowych kombinacji reguł stylizacji.

Problemem jest architektoniczna nadmierna pewność siebie. Model językowy nie może zrekompensować potoku wejściowego, który bez wyraźnych granic łączy zaufane instrukcje, niezaufaną treść i niewidoczny materiał.

Google opisało wielowarstwową obronę przed pośrednim prompt injection. Podejście obejmuje klasyfikatory treści, trening adwersarialny, red teaming oraz potwierdzenie przed wykonaniem wrażliwych działań.

Te mechanizmy pokazują kierunek, w którym muszą podążać zabezpieczenia e-maili. Żaden pojedynczy werdykt modelu nie powinien decydować o tym, czy wiadomość jest bezpieczna, zwłaszcza gdy CSS zmienia to, co otrzymują różni obserwatorzy.

Ukryta treść może celować w filtr lub asystenta

Ta sama luka w widoczności CSS umożliwia dwa przeciwstawne ataki: ukrywanie nieszkodliwego tekstu przed ludźmi oraz ukrywanie przed nimi złośliwych instrukcji.

Text salting próbuje sprawić, aby złośliwy e-mail wyglądał nieszkodliwie dla systemu bezpieczeństwa. Pośredni prompt injection próbuje skłonić asystenta AI do wykonania instrukcji, których użytkownik nigdy świadomie nie przekazał.

OWASP definiuje pośredni prompt injection jako złośliwe instrukcje osadzone w zewnętrznej treści, którą system AI przetwarza później. E-mail jest naturalnym kanałem dostarczania, ponieważ każdy może wysłać dane wejściowe do wielu skrzynek.

Atakujący mogą ukrywać instrukcje za pomocą białego tekstu, czcionek o zerowym rozmiarze, pozycjonowania poza ekranem, zakodowanych znaków lub struktur HTML pomijanych przez renderer wizualny.

Ofiara może poprosić asystenta o podsumowanie nieprzeczytanych wiadomości. Autonomiczny przepływ pracy może przetwarzać skrzynkę odbiorczą bez bezpośredniego żądania. W obu przypadkach model może napotkać instrukcje napisane przez atakującego.

Prosty atak może manipulować podsumowaniem. AI może wymyślić ostrzeżenie bezpieczeństwa, ukryć wskaźnik phishingu lub opisać złośliwą wiadomość jako zatwierdzoną.

Poważniejszy atak staje się możliwy, gdy asystent może przeszukiwać inne wiadomości, odczytywać połączone dokumenty, przygotowywać wychodzące e-maile lub wywoływać zewnętrzne narzędzia.

Złośliwy e-mail działa wtedy jako wejście sterujące. Może próbować przekierować asystenta z zadania użytkownika w kierunku pobrania danych, ujawnienia informacji lub nieautoryzowanego działania.

Microsoft ogłosił ochronę przed inbox injection w Defender for Office 365 w lipcu 2026 roku. Funkcja została udostępniona w publicznej wersji zapoznawczej dla kwalifikujących się klientów.

Microsoft twierdzi, że system wykrywa złośliwe instrukcje AI podczas inspekcji przepływu poczty. Wykryte wiadomości otrzymują werdykt phishingu o wysokiej pewności i mogą zostać odizolowane, zanim dotrą do użytkowników lub połączonych asystentów.

To umiejscowienie jest istotne. Zablokowanie ataku przed dostarczeniem uniemożliwia mu trafienie do indeksów wyszukiwania skrzynek, systemów retrieval, podsumowań i kontekstu dalszych agentów.

Wykrywanie na bramie nie rozwiąże jednak każdego przypadku. Atakujący może umieścić złośliwe instrukcje na przejętym koncie wewnętrznym, dozwolonej liście mailingowej, w przekazanym wątku lub załączniku.

Rozróżnienie między instrukcjami a danymi pozostaje również trudne dla modeli językowych. Oba docierają w języku naturalnym i oba mogą zawierać prośby, cytowane polecenia lub tekst proceduralny.

E-mail od menedżera może zgodnie z prawem brzmieć: „Przejrzyj załączony plik i wyślij odpowiedź”. Złośliwe wstrzyknięcie może używać niemal identycznego języka, zwracając się jednak do AI, a nie do pracownika.

Asystent musi wnioskować o autorytecie, pochodzeniu i intencji. Sama płynność języka naturalnego nie zapewnia tych właściwości bezpieczeństwa.

Dlatego atak na filtr i atak na asystenta należą do tej samej dyskusji. Oba wykorzystują niejednoznaczność między treścią wyświetlaną, przetwarzaną i autoryzowaną.

Google News nagłośniło historię o zabezpieczeniach e-maili opartych na AI, lecz konsekwencje wykraczają poza klasyfikację spamu. Każdy agent połączony ze skrzynką odziedzicza ten nierozwiązany problem granic danych wejściowych.

EchoLeak pokazał, co dzieje się, gdy e-mail dociera do narzędzi

Ukryty e-mail staje się znacznie groźniejszy, gdy asystent AI może pobierać prywatny kontekst i komunikować się poza skrzynką pocztową.

Ujawnienie EchoLeak w 2025 roku stanowiło konkretne ostrzeżenie. Badacze opisali wieloetapowy atak obejmujący Microsoft 365 Copilot i starannie przygotowaną wiadomość e-mail.

Microsoft identyfikuje EchoLeak jako CVE-2025-32711 i twierdzi, że problem został naprawiony. Firma opisuje go jako technikę wstrzykiwania między promptami, która mogła ujawnić ograniczone dane już dostępne dla ofiary.

Zgodnie ze wskazówkami Microsoft dotyczącymi bezpieczeństwa AI, niewinnie wyglądająca wiadomość mogła zatruć kontekst przetwarzany przez Copilot. Technika ta mogła następnie prowadzić do niezamierzonego ujawnienia danych w określonych warunkach.

Incydent był istotny, ponieważ nie wymagał wcześniejszego wykradzenia hasła użytkownika. Atakował asystenta za pośrednictwem danych, które asystent miał odczytać.

EchoLeak był bardziej złożony niż kampania text saltingu nagłośniona przez Google News. Obejmował wiele etapów i warunków, podczas gdy text salting miał przede wszystkim na celu obejście klasyfikacji.

Oba przypadki podważają jednak to samo założenie. E-mail jest traktowany jako treść, chociaż jego fragmenty mogą działać jak wrogie instrukcje dla systemów AI.

Ryzyko rośnie wraz z generowaniem wspomaganym wyszukiwaniem, czyli RAG. Ten projekt wyszukuje istotne prywatne informacje i dodaje je do kontekstu modelu przed wygenerowaniem odpowiedzi.

RAG pomaga asystentowi e-mailowemu odpowiadać na pytania dotyczące projektów, harmonogramów, klientów i wcześniejszych dyskusji. Umieszcza jednak również cenne informacje blisko treści wiadomości kontrolowanych przez atakującego.

Dostęp do narzędzi dodaje kolejną warstwę. Asystent ograniczony do podsumowań może wprowadzić użytkownika w błąd, ale agent dysponujący narzędziami do obsługi wiadomości lub plików może wywołać bezpośrednie konsekwencje operacyjne.

Programiści często polegają na prompcie systemowym nakazującym modelowi ignorowanie złośliwych instrukcji. Taki środek pomaga, ale nie tworzy twardej granicy bezpieczeństwa.

Zakrojone na szeroką skalę wyzwanie badawcze o nazwie LLMail-Inject zebrało 208 095 zgłoszeń ataków od 839 uczestników. Badacze przetestowali wiele mechanizmów obronnych, modeli i konfiguracji wyszukiwania w realistycznym środowisku agentów e-mailowych.

Liczba zgłoszeń ma znaczenie, ponieważ adaptacyjni atakujący nie powtarzają jednej oczywistej frazy. Sprawdzają transformacje, sposób przedstawienia treści, kodowanie, kontekst społeczny i zachowanie charakterystyczne dla danego modelu.

Obrońcy powinni zakładać, że każdy klasyfikator lub mechanizm ochrony promptów może generować fałszywie negatywne wyniki. Wrażliwe działania wymagają niezależnych mechanizmów autoryzacji, które nie zależą od interpretacji modelu.

Podsumowujący e-maile nie powinien uzyskiwać uprawnień do wysyłania wiadomości tylko dlatego, że potrafi je czytać. Dostęp do wyszukiwania nie powinien oznaczać dostępu do każdego folderu skrzynki pocztowej ani podłączonego dokumentu.

Wywołania narzędzi powinny stosować zasadę najmniejszych uprawnień, która daje każdemu komponentowi wyłącznie uprawnienia potrzebne do bieżącego zadania. Działania o dużym wpływie powinny wymagać wyraźnego potwierdzenia użytkownika.

Zespoły bezpieczeństwa potrzebują również logów pokazujących, która wiadomość wpłynęła na wynik lub działanie. Bez informacji o pochodzeniu osoba reagująca na incydent nie może łatwo zidentyfikować zatrutego wejścia.

Użytkownicy zarządzający materiałami źródłowymi dla systemów AI stają przed pokrewnym wyzwaniem. Przejrzyste gromadzenie informacji i rozdzielanie źródeł mogą pomóc zachować kontekst, lecz uprawnienia na poziomie aplikacji pozostają niezbędne.

Wniosek płynący z EchoLeak nie jest taki, że wszyscy asystenci e-mailowi są niebezpieczni. Chodzi o to, że ich bezpieczeństwo musi odpowiadać ich uprawnieniom, a nie ich konwersacyjnemu wyglądowi.

Kompromis w obronie: widoczność kontra użyteczność

Usunięcie każdego ukrytego elementu ograniczyłoby część ataków, ale jednocześnie uszkodziłoby prawidłowe wiadomości e-mail i nie rozwiązałoby głębszych problemów z autoryzacją.

Rygorystyczny mechanizm czyszczący mógłby usunąć CSS, ukryte elementy, zdalne zasoby i złożony HTML, zanim system AI odczyta wiadomość. Znacznie zmniejszyłoby to powierzchnię ataku.

Usunęłoby jednak także strukturę, która pomaga użytkownikom i modelom zrozumieć prawidłową pocztę. Tabele, responsywne układy, cytaty, podpisy, etykiety dostępności i formatowanie wiadomości transakcyjnych mogą przekazywać użyteczne znaczenie.

Część ukrytej treści służy celom operacyjnym. Tekst preheadera może zapewnić krótki podgląd w skrzynce odbiorczej, podczas gdy responsywne projekty wyświetlają różne elementy na ekranach komputerów i urządzeń mobilnych.

Produkty bezpieczeństwa muszą odróżniać takie przypadki od dużego ukrytego bloku zaprojektowanego w celu manipulowania klasyfikacją. Decyzja nie może opierać się na jednej właściwości CSS.

Renderowanie każdej wiadomości w kontrolowanej przeglądarce może poprawić analizę widoczności. Zwiększa jednak koszty obliczeniowe i wprowadza silnik przeglądarki do potoku bezpieczeństwa.

Widok po renderowaniu nadal może nie odpowiadać każdemu klientowi pocztowemu. Szerokość ekranu mobilnego, tryb ciemny, blokowane obrazy, ustawienia językowe i preferencje dostępności mogą zmienić rezultat.

Bezpieczniejsza strategia wykorzystuje kilka reprezentacji. System może zachować surową treść do analizy kryminalistycznej, obliczyć znormalizowany widok i osobno identyfikować ukryte lub słabo widoczne obszary.

Klasyfikator AI powinien otrzymywać jawne etykiety dla tych obszarów. Ukryte materiały nie powinny po cichu trafiać do tego samego niezróżnicowanego strumienia tekstu co widoczna treść.

Asystent mógłby traktować ukryty tekst jako niezaufane metadane. Mógłby podsumowywać tę ukrytą treść tylko wtedy, gdy użytkownik zażąda analizy bezpieczeństwa.

Detektory wstrzykiwania promptów zapewniają kolejną warstwę. Implementacja Microsoft analizuje tematy, treść wiadomości, HTML, stylizację, przekazaną dalej treść i zakodowany materiał, zanim asystent je przetworzy.

Mimo to wykrywanie wstrzykiwania promptów ma charakter probabilistyczny. Prawidłowe e-maile mogą zawierać dyskusje o promptach, testach bezpieczeństwa, poleceniach automatyzacji lub cytowanych złośliwych wiadomościach.

Zespół badawczy może otrzymywać autentyczne próbki ataków e-mailem. Filtr bezpieczeństwa może poddać te wiadomości kwarantannie, nawet gdy odbiorca ich oczekuje.

Fałszywe alarmy wywierają presję na osłabienie egzekwowania zasad. Jeśli ważna poczta zbyt często znika, administratorzy dodają wyjątki, które atakujący mogą analizować i wykorzystywać.

Potwierdzenie przez człowieka także nie jest doskonałe. Użytkownicy rutynowo zatwierdzają żądania, gdy interfejs przedstawia je jako zwykłe kroki, szczególnie podczas powtarzalnej pracy.

Potwierdzenie musi więc wyjaśniać proponowane działanie, jego cel i dane, których dotyczy. Niejasny prompt pytający, czy „kontynuować”, zapewnia niewielką ochronę.

Najsilniejszy projekt oddziela rozumowanie modelu od egzekwowania zasad. Model może zasugerować działanie, podczas gdy deterministyczne oprogramowanie sprawdza uprawnienia, miejsca docelowe, klasyfikacje danych i wymagania dotyczące zatwierdzenia.

Takie podejście ogranicza szkody zarówno wynikające z ukrytych promptów, jak i zwykłych błędów modelu. Zmanipulowany asystent nie może przekroczyć granic egzekwowanych poza jego kontekstem językowym.

Kompromisem jest mniejsza wygoda. Użytkownicy mogą spotkać się z większą liczbą promptów, węższymi integracjami i wolniejszą automatyzacją zadań wysokiego ryzyka.

To dodatkowe utrudnienie jest uzasadnione, gdy asystent może wysyłać zewnętrzne wiadomości, pobierać poufne dokumenty, modyfikować rekordy lub inicjować procesy finansowe. Podsumowania niskiego ryzyka mogą zachować lżejsze mechanizmy kontroli.

Narzędzia AI do obsługi poczty e-mail powinny zatem stosować stopniowane uprawnienia. Odczyt wybranej wiadomości, przeszukiwanie folderu, przygotowanie odpowiedzi i wysłanie tej odpowiedzi powinny pozostawać odrębnymi poziomami uprawnień.

Na co zespoły bezpieczeństwa powinny zwracać uwagę w następnej kolejności

Kolejny etap będzie oceniany przez jakość wykrywania, projekt uprawnień i dowody rzeczywistych nadużyć, a nie przez kolejny benchmark modelu.

Pierwszym sygnałem jest szersza dostępność inspekcji e-maili uwzględniającej widoczność. Publiczna wersja zapoznawcza Microsoft pokazuje, że wstrzykiwanie promptów staje się odrębną kategorią bezpieczeństwa poczty.

Zespoły bezpieczeństwa powinny obserwować, jak dostawcy udostępniają te wykrycia. Użyteczne produkty wskażą ukryty obszar, wyjaśnią jego rolę i zachowają dowody na potrzeby dochodzenia.

Ogólny werdykt dotyczący phishingu nie wystarczy. Analitycy muszą wiedzieć, czy wiadomość zawierała wypełniacz ukryty przez CSS, zakodowaną instrukcję, podejrzane dyrektywy narzędziowe czy nietypową rozbieżność między treścią widoczną a surową.

Drugim sygnałem jest sposób, w jaki Google, Microsoft i zewnętrzni programiści ograniczają agentów połączonych ze skrzynkami pocztowymi. Ulepszenia modeli mają mniejsze znaczenie niż egzekwowalne granice wokół wyszukiwania i korzystania z narzędzi.

Nabywcy powinni pytać, czy asystenci rozróżniają zewnętrzne wiadomości od wewnętrznych instrukcji. Powinni także pytać, czy pobrana treść zachowuje tożsamość nadawcy, lokalizację i poziom zaufania.

Administratorzy potrzebują mechanizmów kontroli dla konkretnych działań. Zasada powinna zezwalać na podsumowywanie bez automatycznego zezwalania na pocztę wychodzącą, dostęp do plików, zmiany w kalendarzu czy wywołania API firm trzecich.

Trzecim sygnałem są zweryfikowane dowody wykorzystania ataków. Dane Barracuda dotyczące text saltingu pokazują wdrożenie na dużą skalę przeciwko filtrom, ale nie dowodzą, że każda wiadomość pokonała produkt oparty na LLM.

Dostawcy powinni, tam gdzie to możliwe, publikować metodologię i mianowniki. Same liczby wykryć nie ujawniają wskaźników dostarczenia, skutecznych klasyfikacji, interakcji ofiar ani dalszego kompromitowania systemów.

Ta sama ostrożność dotyczy demonstracji wstrzykiwania promptów. Atak laboratoryjny dowodzi istnienia ścieżki bezpieczeństwa, ale mechanizmy kontroli produkcyjnej mogą zmienić jego praktyczną niezawodność.

Z drugiej strony brak publicznych incydentów nie dowodzi bezpieczeństwa. Manipulacja agentami AI może przypominać zwykłą aktywność użytkownika, przez co incydenty trudno zidentyfikować bez szczegółowych logów.

Organizacje nie muszą czekać na doskonałe pomiary. Mogą zacząć od zmapowania każdego przepływu pracy, który pozwala AI przetwarzać przychodzące e-maile lub pobierać kontekst skrzynki pocztowej.

Zespoły powinny udokumentować, co każdy asystent może odczytywać, jakie narzędzia może wywoływać i które działania wymagają zatwierdzenia. Powinny także testować wiadomości zawierające ukrytą treść i treść poza ekranem.

Ćwiczenia bezpieczeństwa powinny obejmować oba kierunki ataku. Jeden test powinien ukrywać nieszkodliwy wypełniacz, aby ominąć klasyfikację. Drugi powinien ukrywać złośliwe instrukcje przeznaczone dla asystenta.

Programiści powinni oceniać, czy system wyjaśnia niepewność. Asystent, który wykrywa sprzeczne lub ukryte instrukcje, powinien się zatrzymać i wskazać podejrzane źródło.

Użytkownicy powinni zachować sceptycyzm wobec ostrzeżeń generowanych przez AI w podsumowaniach e-maili. Dopracowany alert może pochodzić z treści kontrolowanych przez atakującego, nawet jeśli interfejs należy do zaufanego dostawcy.

W przypadku przepływów pracy o charakterze informacyjnym należy zachować dostęp do oryginalnych źródeł i weryfikować istotne twierdzenia przed podjęciem działania. Podsumowania AI powinny przyspieszać analizę, a nie zastępować informacje o pochodzeniu.

Google News ponownie zwróciło uwagę na ataki CSS na pocztę internetową, lecz trwały problem jest większy niż jedna kampania. E-mail zawiera obecnie treści dla ludzi, klasyfikatorów, systemów wyszukiwania i autonomicznych narzędzi.

Te grupy odbiorców nie postrzegają tej samej wiadomości. Dopóki systemy bezpieczeństwa nie będą bezpośrednio modelować tej różnicy, atakujący będą nadal wykorzystywać lukę między tym, co widzą ludzie, a tym, co odczytują maszyny.