Modelowanie zagrożeń aplikacji AI generatywnej

Wprowadzenie: dlaczego to ma znaczenie

Modelowanie zagrożeń pomaga zespołom wcześnie zidentyfikować, co może pójść źle — zanim dojdzie do rzeczywistych awarii lub wrogich exploitów. Microsoft zauważa, że aplikacje AI (zwłaszcza systemy generatywne i agentowe) łamią wiele założeń tradycyjnego, deterministycznego oprogramowania, dlatego zespoły ds. bezpieczeństwa muszą dostosować podejście do modelowania zagrożeń, aby uwzględnić probabilistyczne wyniki, rozszerzone powierzchnie ataku oraz szkody skoncentrowane na człowieku.

Co nowego: jak AI zmienia krajobraz zagrożeń

Microsoft wskazuje trzy cechy, które fundamentalnie zmieniają modelowanie zagrożeń dla AI:

• Niedeterministyczność: to samo wejście może dawać różne wyjścia w kolejnych uruchomieniach, co wymaga analizy zakresów prawdopodobnych zachowań — w tym rzadkich, ale wysokiego wpływu.
• Bias na podążanie za instrukcjami: modele są optymalizowane pod bycie pomocnymi, przez co są bardziej podatne na prompt injection, wymuszanie i manipulację — szczególnie gdy dane i instrukcje współdzielą ten sam kanał wejściowy.
• Rozszerzenie systemu przez narzędzia i pamięć: systemy agentowe mogą wywoływać API, utrzymywać stan i autonomicznie uruchamiać przepływy pracy. Gdy coś pójdzie nie tak, awarie mogą szybko kaskadować między komponentami.

Te właściwości przekształcają znane ryzyka w nowe formy, w tym:

• Bezpośredni i pośredni prompt injection (w tym przez treści zewnętrzne, które model pobiera)
• Nadużycie narzędzi i eskalacja uprawnień przez chaining
• Cicha eksfiltracja danych (wyjścia lub wywołania narzędzi ujawniające informacje wrażliwe)
• Pewne siebie, błędne odpowiedzi traktowane jak fakty
• Szkody skoncentrowane na człowieku, takie jak erozja zaufania, nadmierne poleganie, utrwalanie uprzedzeń oraz perswazyjna dezinformacja

Modeluj zagrożenia od aktywów, nie od ataków

Kluczową rekomendacją jest rozpoczęcie od jednoznacznego zdefiniowania tego, co chronisz — ponieważ aktywa w AI wykraczają poza bazy danych i poświadczenia. Typowe aktywa specyficzne dla AI obejmują:

• Bezpieczeństwo użytkownika (zwłaszcza gdy wskazówki AI wpływają na działania)
• Zaufanie użytkownika do wyników i zachowania
• Prywatność/bezpieczeństwo wrażliwych danych biznesowych i użytkowników
• Integralność promptów, instrukcji i danych kontekstowych
• Integralność działań agenta i skutków downstream

Takie ujęcie „asset-first” wymusza też wczesne decyzje polityk: Jakich działań system nigdy nie powinien podejmować? Niektóre rezultaty mogą być nieakceptowalne niezależnie od korzyści.

Modeluj system, który faktycznie zbudowałeś

Microsoft podkreśla, że modelowanie zagrożeń dla AI musi odzwierciedlać realne działanie, a nie wyidealizowane diagramy. Zwróć szczególną uwagę na:

• Jak użytkownicy faktycznie wchodzą w interakcję z systemem
• Jak prompty, pamięć i kontekst są składane i przekształcane
• Jakie źródła zewnętrzne są ingestowane i jakie istnieją założenia zaufania
• Jakie narzędzia/API system może wywoływać (i z jakimi uprawnieniami)
• Czy działania są reaktywne czy autonomiczne oraz gdzie wymuszane jest zatwierdzenie przez człowieka

W systemach AI potok składania promptów staje się granicą bezpieczeństwa pierwszej klasy — to w obszarach pobierania kontekstu, transformacji, utrwalania i ponownego użycia kumulują się „ciche” założenia zaufania.

Wpływ na administratorów IT i właścicieli platform

Dla administratorów wdrażających rozwiązania AI (aplikacje niestandardowe, Copilots lub agentowe workflow) te wskazówki wzmacniają przekaz, że mechanizmy kontrolne muszą obejmować:

• Całą ścieżkę data-to-prompt-to-action (nie tylko hosting modelu)
• Uprawnienia i guardrails dla dostępu do narzędzi oraz automatyzacji downstream
• Monitorowanie operacyjne pod kątem nieoczekiwanych wyników, nietypowych wywołań narzędzi i wzorców eksfiltracji

Działania / kolejne kroki

• Zinwentaryzuj aktywa AI: uwzględnij zaufanie, bezpieczeństwo oraz integralność instrukcji/kontekstu.
• Zmapuj potok promptów end-to-end: źródła, pobieranie, transformację, pamięć i ponowne użycie.
• Ogranicz uprawnienia narzędzi i wymagaj zatwierdzenia przez człowieka dla działań o dużym wpływie.
• Testuj pod kątem injection i nadużyć: uwzględnij pośredni prompt injection przez pobierane treści.
• Zaplanuj scenariusze wypadków: ogranicz nadmierne poleganie poprzez wskazówki UX, kroki walidacji i ścieżki eskalacji.