TL;DR: Bezpieczeństwo AI w organizacji obejmuje zarówno ochronę aplikacji udostępnianych użytkownikom zewnętrznym, jak i kontrolę korzystania z narzędzi AI przez pracowników. Wraz z rosnącym wykorzystaniem sztucznej inteligencji pojawiają się nowe zagrożenia, takie jak prompt injection, Shadow AI, wycieki danych czy niekontrolowane integracje z firmowymi systemami. Rozwiązania takie jak AI Gateway i DLP pomagają monitorować komunikację z modelami oraz chronić poufne informacje. Podstawą skutecznej strategii bezpieczeństwa AI są widoczność, ochrona aplikacji, ochrona danych i governance, które pozwalają organizacji korzystać z AI w sposób bezpieczny i kontrolowany.
Sztuczna inteligencja bardzo szybko stała się częścią codziennego funkcjonowania organizacji, znajdując zastosowanie zarówno w wewnętrznych procesach, jak i w rozwiązaniach udostępnianych klientom. Pracownicy wykorzystują modele AI do analizy informacji, pracy z kodem czy automatyzacji powtarzalnych zadań, podczas gdy firmy coraz częściej wdrażają własne chatboty, asystentów oraz mechanizmy wspierające użytkowników w wyszukiwaniu informacji i produktów.
Wraz z rosnącą skalą wykorzystania AI zmienia się również powierzchnia, którą należy uwzględnić w strategii cyberbezpieczeństwa. Organizacja powinna mieć wiedzę nie tylko o tym, gdzie wykorzystuje modele językowe, lecz także kto ma do nich dostęp, jakie informacje są do nich przesyłane, z jakimi systemami mogą się komunikować oraz w jaki sposób chronione są aplikacje AI udostępniane użytkownikom zewnętrznym.
Dwa kierunki bezpieczeństwa AI: inbound i outbound
Bezpieczeństwo AI można podzielić na dwa kierunki. Pierwszy obszar, określany jako inbound, dotyczy aplikacji wykorzystujących AI, które organizacja sama udostępnia użytkownikom zewnętrznym. Może to być chatbot odpowiedzialny za obsługę klienta, asystent dostępny na stronie internetowej czy mechanizm, w którym użytkownik opisuje swoje potrzeby, a model na tej podstawie wyszukuje i prezentuje odpowiednie produkty. Za dostępnym dla użytkownika interfejsem działa wówczas model, który przetwarza przesyłane do niego zapytania, dlatego publiczne udostępnienie takiej aplikacji oznacza konieczność uwzględnienia scenariuszy, w których ktoś będzie próbował manipulować jej zachowaniem, uzyskać informacje, których system nie powinien ujawniać, masowo generować zapytania lub wykorzystać dostęp do modelu w sposób niezgodny z przeznaczeniem.
Drugi obszar, czyli outbound, odwraca tę perspektywę. To pracownicy organizacji korzystają z zewnętrznych modeli i aplikacji AI, przesyłając do nich prompty, dokumenty, kod lub inne informacje wykorzystywane w codziennej pracy. W tym przypadku kluczowe staje się uzyskanie wiedzy o tym, z jakich narzędzi korzystają użytkownicy, jakie dane do nich przekazują oraz czy możliwe jest wykrycie i zatrzymanie informacji, które zgodnie z polityką organizacji nie powinny opuszczać jej środowiska.
Rozdzielenie tych dwóch kierunków pozwala uporządkować bezpieczeństwo AI i dobrać mechanizmy odpowiadające rzeczywistemu charakterowi ryzyka – inne są po stronie aplikacji wystawianych do internetu, a inne po stronie użytkowników korzystających z zewnętrznych usług.
Z jakimi zagrożeniami wiąże się wykorzystanie AI?
Ryzyka związane z wykorzystaniem sztucznej inteligencji można podzielić w zależności od kierunku komunikacji. Z jednej strony organizacja musi chronić własne aplikacje AI udostępniane użytkownikom zewnętrznym, z drugiej – kontrolować sposób, w jaki pracownicy korzystają z publicznych modeli, jakie informacje do nich przesyłają oraz z jakimi systemami mogą je integrować.
Inbound – zagrożenia dla aplikacji AI
- Prompt injection – polega na próbie wpłynięcia na zachowanie modelu za pomocą odpowiednio skonstruowanego polecenia, np. nakłonienia go do zignorowania wcześniejszych instrukcji czy ujawnienia systemu promptu. W przeciwieństwie do wielu klasycznych ataków zagrożenie może wynikać przede wszystkim z treści i znaczenia zapytania, dlatego jego wykrycie wymaga uwzględnienia kontekstu promptu.
- Ujawnienie wrażliwych informacji – użytkownik może próbować skłonić model do zwrócenia danych, instrukcji lub innych informacji, do których nie powinien mieć dostępu. Ryzyko dotyczy zarówno danych przetwarzanych przez aplikację, jak i informacji związanych z jej konfiguracją czy sposobem działania.
- Denial of Wallet – w aplikacjach korzystających z płatnych modeli dużym problemem może być celowe generowanie dużej liczby zapytań lub szczególnie rozbudowanych promptów. Jeżeli korzystanie z modelu rozliczane jest na podstawie liczby tokenów, taki ruch może prowadzić do zwiększonego wykorzystania zasobów, a w konsekwencji do wzrostu kosztów ponoszonych przez organizację.
- Wykorzystanie aplikacji jako proxy do LLM – publicznie dostępny chatbot może zostać wykorzystany do wykonywania zapytań, które nie mają nic wspólnego z jego właściwym przeznaczeniem. Użytkownik korzysta wówczas z modelu i zasobów opłacanych przez organizację do realizowania własnych zadań, dlatego istotne staje się kontrolowanie nie tylko liczby, ale również tematyki kierowanych do niego zapytań.
- Boty, scraping i DDoS – wykorzystanie modelu językowego nie eliminuje klasycznych zagrożeń charakterystycznych dla aplikacji webowych. Automatyczny ruch może służyć m.in. do scrapingu lub masowego generowania zapytań, natomiast ataki DDoS mogą być ukierunkowane na ograniczenie dostępności usługi, dlatego zabezpieczenia warstwy AI powinny uzupełniać standardowe mechanizmy ochrony aplikacji.
Outbound – ryzyka związane z wykorzystaniem AI przez pracowników
- Shadow AI – pracownicy mogą korzystać z różnych narzędzi AI bez pełnej wiedzy organizacji, przez co zespół bezpieczeństwa nie ma wystarczającej kontroli nad tym, jakie modele są wykorzystywane i w jaki sposób. Bez takiej wiedzy trudno ocenić ryzyko poszczególnych usług oraz zdecydować, które z nich powinny być dozwolone, monitorowane lub blokowane.
- Wyciek danych do zewnętrznych modeli – informacje mogą opuszczać środowisko organizacji poprzez zwykłe kopiowanie treści do promptu, przesyłanie dokumentów czy fragmentów kodu.
- Niekontrolowane integracje – przepływ danych do zewnętrznych usług nie musi odbywać się wyłącznie poprzez prompty i przesyłane pliki. Kolejnym kanałem są integracje i wtyczki, które mogą rozszerzać dostęp narzędzi AI do informacji znajdujących się w innych systemach, dlatego organizacja powinna uwzględniać również ten sposób komunikacji.
Agenci AI i MCP
Osobnym obszarem ryzyka są systemy, w których sztuczna inteligencja może również korzystać z narzędzi, pobierać informacje z innych aplikacji i wykonywać określone operacje.
Takie możliwości oferują m.in. agenci AI, którzy na podstawie otrzymanego zadania mogą realizować kolejne działania z wykorzystaniem udostępnionych im zasobów. Istotną rolę w budowaniu tego rodzaju integracji odgrywa Model Context Protocol (MCP), umożliwiający komunikację aplikacji AI z zewnętrznymi narzędziami i źródłami danych.
Wyobraźmy sobie agenta AI zintegrowanego z firmowym CRM-em, którego zadaniem jest wyszukiwanie informacji o klientach i przygotowywanie podsumowań dla zespołu sprzedaży. Jeżeli agent dysponuje zbyt szerokimi uprawnieniami, może uzyskać dostęp również do danych, które nie są potrzebne do realizacji konkretnego zadania. Dodatkowe zagrożenie pojawia się wtedy, gdy przetwarza treści pochodzące z niezaufanych źródeł, np. notatki zapisane w CRM-ie, zawierające złośliwe instrukcje mające wpłynąć na jego zachowanie.
W takim scenariuszu atakujący może próbować nakłonić agenta do pobrania dodatkowych informacji, przekazania ich do innego narzędzia lub wykonania operacji, której użytkownik nie zlecił. Skuteczność takiego ataku zależy m.in. od dostępnych uprawnień, konfiguracji integracji oraz mechanizmów kontrolujących działania agenta.
Jak zabezpieczyć komunikację aplikacji z modelami AI?
Ochrona aplikacji AI nie kończy się na wykrywaniu prób manipulowania modelem. Równie istotne jest kontrolowanie sposobu, w jaki aplikacje komunikują się z wykorzystywanymi usługami, jakie zapytania do nich trafiają oraz w jaki sposób zarządzane są związane z tym zasoby.
W organizacjach korzystających z wielu modeli językowych komunikacja może odbywać się pomiędzy różnymi aplikacjami i dostawcami usług AI. Utrudnia to uzyskanie pełnej widoczności nad ruchem, monitorowanie wykorzystania poszczególnych modeli oraz egzekwowanie spójnych zasad ich używania.
Jednym ze sposobów uporządkowania takiej komunikacji jest zastosowanie warstwy pośredniczącej pomiędzy aplikacjami a modelami AI. Pozwala ona centralizować obsługę zapytań, monitorować wykorzystanie usług oraz zarządzać sposobem kierowania ruchu do poszczególnych modeli. Przykładem takiego rozwiązania jest Cloudflare AI Gateway, który umożliwia m.in. monitorowanie zapytań, zarządzanie ruchem kierowanym do modeli, stosowanie mechanizmów fallbacku oraz cache’owanie odpowiedzi w celu ograniczenia opóźnień i kosztów.
Organizacja może dzięki temu lepiej kontrolować wykorzystanie zasobów i ograniczać zależność od pojedynczego dostawcy. Przykładowo, jeżeli jeden z modeli przestanie odpowiadać, odpowiednio skonfigurowany mechanizm może skierować zapytanie do alternatywnej usługi.
Warto jednak pamiętać, że sama kontrola komunikacji nie rozwiązuje wszystkich problemów bezpieczeństwa AI.
DLP – kontrola danych przesyłanych do narzędzi AI
Sama wiedza o tym, z jakich aplikacji korzystają pracownicy, nie wystarcza, ponieważ kolejnym etapem jest ustalenie, jakie informacje są do nich przekazywane. Mechanizmy DLP pozwalają analizować ruch użytkowników i reagować w sytuacji, gdy do zewnętrznego narzędzia próbuje trafić określony rodzaj danych.
Dobrym przykładem jest deweloper, który podczas pracy nad aplikacją napotyka problem w kodzie, dlatego kopiuje jego fragment do narzędzia AI i prosi model o znalezienie oraz poprawienie błędu. Z punktu widzenia użytkownika jest to zwykłe wykorzystanie AI do przyspieszenia pracy, jednak w przesyłanym fragmencie może znajdować się produkcyjny klucz API lub inne dane uwierzytelniające, które nie powinny zostać przekazane do zewnętrznej usługi.
Jeżeli ruch użytkownika przechodzi przez kontrolowane środowisko, mechanizmy DLP mogą wykryć obecność takich informacji i zastosować odpowiednią politykę – na przykład zablokować transmisję oraz poinformować użytkownika, jaki element spowodował zatrzymanie żądania. Istotne jest przy tym również logowanie zdarzenia, ponieważ sama blokada chroni przed konkretną próbą przesłania danych, natomiast zapis informacji o zdarzeniu umożliwia późniejszą analizę oraz przekazanie danych do zewnętrznych narzędzi, np. systemów wykorzystywanego przez zespół SOC.
Od widoczności do governance – cztery elementy bezpieczeństwa AI
Podejście do bezpieczeństwa AI można uporządkować wokół czterech wzajemnie powiązanych obszarów: widoczności, ochrony aplikacji, ochrony danych oraz governance. Ich kolejność nie jest przypadkowa, ponieważ trudno skutecznie zabezpieczyć środowisko, jeżeli organizacja nie posiada wiedzy o tym, gdzie i w jaki sposób sztuczna inteligencja jest już wykorzystywana.
Pierwszym krokiem jest więc uzyskanie widoczności zarówno nad aplikacjami AI udostępnianymi przez organizację, jak i nad narzędziami wykorzystywanymi przez pracowników. Obejmuje to identyfikację endpointów, modeli, użytkowników oraz sposobów komunikacji z zewnętrznymi usługami.
Drugim elementem jest ochrona aplikacji, która powinna uwzględniać zarówno zagrożenia charakterystyczne dla modeli językowych, takie jak prompt injection czy Denial of Wallet, jak i klasyczne ryzyka dotyczące aplikacji webowych – boty, DDoS czy nadużycia ruchu.
Trzecim obszarem jest ochrona danych, czyli kontrolowanie informacji przesyłanych przez użytkowników do zewnętrznych modeli za pomocą mechanizmów takich jak DLP i polityki Secure Web Gateway. Ostatnim etapem jest governance, a więc bieżące zarządzanie zasadami wykorzystania AI oraz ich dostosowywanie do zmian zachodzących w środowisku.
Wspólnym mianownikiem pozostaje widoczność. Bez wiedzy o tym, gdzie działa AI, kto z niego korzysta, jakie dane do niego trafiają oraz z jakimi systemami może się komunikować, organizacja nie ma wystarczających podstaw do podejmowania świadomych decyzji dotyczących bezpieczeństwa.
Celem nie musi być przy tym całkowite blokowanie sztucznej inteligencji. Znacznie ważniejsze jest stworzenie modelu, w którym organizacja może zdecydować, jakie rozwiązania dopuszcza, które działania monitoruje, jakie dane podlegają dodatkowej kontroli oraz w jakich sytuacjach ruch powinien zostać zatrzymany.
Autorzy tekstu:
