W miarę jak asystenci i „copiloty” oparte na sztucznej inteligencji trafiają do codziennej pracy, zespoły ds. bezpieczeństwa wciąż koncentrują się na ochronie samych modeli. Ostatnie incydenty pokazują jednak, że większym zagrożeniem są otaczające je przepływy pracy. Niedawno dwie wtyczki do Chrome podszywające się pod pomocników AI zostały przyłapane na wykradaniu rozmów z ChatGPT i DeepSeek od ponad 900 000 użytkowników. Równocześnie badacze zademonstrowali, że złośliwe instrukcje ukryte w repozytoriach kodu (tzw. prompt injections) potrafią nakłonić asystenta programistycznego IBM do uruchomienia złośliwego oprogramowania na maszynie dewelopera. Żaden z tych ataków nie naruszał samego algorytmu — wykorzystywały one kontekst, w którym AI działa. To właśnie ten wzorzec powinien być w centrum uwagi.
Modele AI jako silniki przepływów pracy
W praktyce AI coraz częściej łączy aplikacje i automatyzuje zadania, które wcześniej wykonywano ręcznie. Asystent piszący może pobrać poufny dokument ze SharePoint i zamienić go na streszczenie będące szkicem maila. Chatbot sprzedażowy może sięgać do wewnętrznego CRM, by odpowiedzieć klientowi. W takich scenariuszach granice między aplikacjami zacierają się, a na ich styku powstają nowe, dynamiczne ścieżki integracji.
Ryzyko wynika z tego, jak działają agenci AI: podejmują decyzje probabilistycznie, nie na podstawie sztywnych reguł. Wejście sformułowane w konkretny sposób może skłonić model do działania, którego twórcy nie przewidzieli — model nie rozumie pojęcia granic zaufania. W efekcie pole ataku obejmuje każde wejście, wyjście i punkt integracji, z którym model się styka. Dlatego nie trzeba „łamać” kodu modelu, gdy można zmanipulować kontekst widziany przez AI lub kanały komunikacji — jak pokazały przypadki z prompt injection w repozytoriach czy złośliwymi rozszerzeniami przeszyskującymi rozmowy.
Dlaczego tradycyjne zabezpieczenia są niewystarczające
Przepływy pracy oparte na AI odsłaniają słabe punkty w klasycznych mechanizmach bezpieczeństwa, które projektowano z myślą o deterministycznym oprogramowaniu, stałych rolach użytkowników i wyraźnych perymetrach. Modele i ich środowiska łamią te założenia.
- Tradycyjne aplikacje rozróżniają kod zaufany od niezaufanego wejścia. Dla modeli AI wszystko jest tekstem — złośliwa instrukcja ukryta w PDF‑ie wygląda tak samo jak legalny komunikat. Walidacja wejścia nie pomaga, bo ładunek ataku nie jest „kodem”, lecz naturalnym językiem.
- Narzędzia monitorujące wykrywają oczywiste anomalie, jak masowe pobrania czy podejrzane logowania. Jednak AI czytające tysiąc rekordów w ramach rutynowego zapytania może wyglądać jak normalny ruch serwis‑do‑serwisu. Jeśli te dane zostaną podsumowane i wysłane do atakującego, technicznie nie musi zostać złamana żadna reguła.
- Polityki bezpieczeństwa zwykle definiują, co jest dozwolone, a co zablokowane — „użytkownik X nie ma dostępu do pliku Y”, „blokuj ruch do serwera Z”. Zachowanie AI zależy od kontekstu: trudno zapisać regułę „nigdy nie ujawniaj danych klientów w wyjściu” w sposób jednoznaczny i wyegzekwowalny.
- Programy bezpieczeństwa opierają się na przeglądach okresowych i stałych konfiguracjach (audytach kwartalnych, regułach zapory). Integracje oparte na AI nie są statyczne — mogą otrzymać nowe uprawnienia po aktualizacji lub podłączyć się do nowego źródła danych. Do czasu kolejnego przeglądu token mógł już wyciec.
Zabezpieczanie przepływów pracy opartych na AI
Zamiast skupiać się wyłącznie na modelu, skuteczniejszym podejściem jest ochrona całego przepływu pracy. Pierwszym krokiem jest mapa użycia AI: gdzie narzędzia są wdrożone, z jakimi danymi się łączą i jakie działania wykonują. Obejmuje to zarówno oficjalne usługi, jak Microsoft 365 Copilot, jak i samodzielnie instalowane rozszerzenia przeglądarki — wiele organizacji z zaskoczeniem odkrywa dziesiątki tzw. shadow AI działających w ich środowisku.
Praktyczne zabezpieczenia obejmują wprowadzenie zewnętrznych guardraili, które sprawdzają działania przed ich wykonaniem. Jeśli asystent ma pełnić tylko funkcję wewnętrznego streszczania, uniemożliwiaj mu wysyłanie maili na zewnątrz; skanuj wyjścia pod kątem danych wrażliwych jeszcze przed opuszczeniem środowiska. Takie mechanizmy powinny działać poza samym modelem, w warstwie pośredniej kontrolującej akcje.
Traktuj agentów AI jak użytkownika lub serwis: stosuj zasadę najmniejszych uprawnień. Jeśli AI potrzebuje tylko odczytu z jednego systemu, nie dawaj mu dostępu do wszystkiego. Ograniczaj zakres tokenów OAuth do niezbędnych uprawnień i monitoruj anomalie, np. nagłe dostępy do danych, których wcześniej nie używał. Edukuj pracowników o ryzyku związanym z niezweryfikowanymi rozszerzeniami przeglądarki i kopiowaniem promptów z niezaufanych źródeł, a wtyczki firm trzecich traktuj jako element obwodu bezpieczeństwa.
Jak platformy takie jak Reco mogą pomóc
Ręczne zarządzanie tymi zasadami nie skaluje się łatwo, dlatego pojawia się nowa kategoria narzędzi — dynamiczne platformy bezpieczeństwa SaaS. Działają one jako warstwa strażnicza nad przepływami pracy opartymi na AI, ucząc się, jakie zachowania są normalne, i w czasie rzeczywistym sygnalizując odchylenia.
Reco jest przykładem takiego rozwiązania. Platforma daje zespołom bezpieczeństwa widoczność użycia AI w całej organizacji, wskazując, które aplikacje generatywne są wykorzystywane i jak są połączone. Na tej podstawie umożliwia wymuszanie guardraili na poziomie przepływu pracy, wykrywanie ryzykownych zachowań w czasie rzeczywistym i zachowanie kontroli bez spowalniania biznesu.
Wdrożenie takiej warstwy ochronnej pomaga skupić obronę tam, gdzie naprawdę występuje ryzyko — na integracjach, kanałach komunikacji i procesach biznesowych, a nie tylko na samym modelu.