Bezpieczny development w erze AI, czyli stare grzechy, nowy front i regulacje

Każdy chce dziś dokleić do produktu "warstwę AI" - chatbota, agenta, wtyczkę, integrację przez API modelu. Tempo jest oszałamiające, a wraz z nim narasta cichy dług bezpieczeństwa, bo wiele zespołów wdraża agentów w przekonaniu, że stare zasady AppSec wystarczą. Nie wystarczą - bo AI kasuje fundamentalne założenie, na którym stało całe bezpieczeństwo aplikacji: granicę między "danymi" a "instrukcją".

W Visera, budując narzędzia Red Team dla Obsigen AI, oglądamy ten dług z obu stron - i jako obrońcy, i jako ci, którzy jako red team łamią cudze wdrożenia AI na zlecenie. Ten tekst to praktyczny przewodnik dla deweloperów i architektów: trzy warstwy, o których trzeba myśleć równocześnie - klasyka, która nie zniknęła; nowy front podatności AI; oraz regulacje, które od 2026 przestają być teorią.

Część I: Stare grzechy, które nie zniknęły

Zanim AI - najpierw higiena, bo nowa warstwa nie zwalnia z podstaw, a wręcz je zaostrza.

Sól w hashach to przeżytek; parametryzacja nie obejmuje identyfikatorów dynamicznych; ORM nie zwalnia z myślenia; NoSQL injection istnieje; waliduj i autoryzuj na serwerze; żadnych sekretów we froncie ani w repo (używaj menedżera sekretów, skanuj repo, rotuj klucze); nie pisz własnej kryptografii; uważaj na JWT w localStorage (XSS go wykradnie). I łańcuch dostaw: przypinaj wersje, generuj SBOM, skanuj zależności (SCA) - o tym więcej w części o AI, bo tam supply chain dostał nowy, paskudny wariant.

Część II: Nowy front - dziury w AI

Tu zaczyna się to, co większość zespołów ignoruje. Punkt wyjścia, z którego wynika niemal wszystko inne: model językowy przetwarza instrukcje i dane w tym samym kanale i nie potrafi ich od siebie odróżnić. Jeśli w treści, którą model czyta, znajdzie się coś, co wygląda jak polecenie - może je wykonać. To nie bug konkretnej implementacji; to natura technologii. Dlatego OWASP wydał osobny ranking - OWASP Top 10 for LLM Applications (2025) - i warto go znać na pamięć.

Prompt injection (LLM01) - wektor numer jeden, drugą edycję z rzędu. Dwie odmiany. Bezpośrednia - użytkownik wpisuje "zignoruj instrukcje i zrób X". Pośrednia (groźniejsza) - złośliwe instrukcje są ukryte w treści, którą model pobiera sam: na stronie WWW, w mailu, w dokumencie, w opisie zgłoszenia, w wyniku narzędzia. Model czyta tę treść jako dane, ale traktuje ją jak polecenie. Nie ma na to niezawodnej obrony - możesz tylko ograniczać skutki.

Excessive agency (LLM06) - i tu jest sedno problemu z wtyczkami AI. Przeszliśmy od pasywnych chatbotów do agentów, które wysyłają maile, odpytują bazy, wołają API i podejmują decyzje. Im więcej narzędzi i uprawnień dasz agentowi, tym większą tworzysz powierzchnię ataku. Klasyczny scenariusz: asystent e-mail z uprzywilejowanym kontem skanującym wszystkie skrzynki. Wystarczy jeden spreparowany mail z pośrednim prompt injection, by agent dostał polecenie wyeksfiltrowania danych wszystkich użytkowników - i je wykona, bo ma do tego uprawnienia. Marzenie o "bezszwowej automatyzacji" staje się architektem wycieku.

Dobre podsumowanie ryzyka to tzw. lethal trifecta (Simon Willison): naprawdę groźnie robi się dopiero, gdy agent ma jednocześnie (1) dostęp do prywatnych danych, (2) styczność z niezaufaną treścią i (3) możliwość komunikacji na zewnątrz. Każdy z tych elementów osobno jest do opanowania; wszystkie trzy razem to gotowa ścieżka eksfiltracji. Projektując wtyczkę, świadomie rozbijaj tę trójcę.

Improper output handling (LLM05) - traktuj wyjście modelu jak niezaufane dane. Jeśli renderujesz odpowiedź modelu bez sanityzacji, masz XSS. Jeśli wykonujesz wygenerowany kod albo polecenie powłoki - masz RCE. Jeśli wpychasz wygenerowany SQL bez parametryzacji - wracamy do części I. Wyjście LLM to taki sam nieufny input jak wszystko z internetu.

Supply chain (LLM03) + slopsquatting. Modele halucynują nazwy pakietów, których nie ma w npm/PyPI - powtarzalnie. W badaniu USENIX Security '25 odsetek zmyślonych pakietów sięgał od ~5% (modele komercyjne) do ~22% (open-source), a atakujący rejestrują te halucynowane nazwy z malware'em i czekają, aż AI podsunie je kolejnemu deweloperowi. Modele z 2026 zbiły wskaźnik do ~5–6%, ale go nie usunęły - istnieje zestaw nazw, które wszystkie modele zmyślają identycznie. Zweryfikuj każdą zależność, zanim ją zainstalujesz.

Pozostałe pozycje rankingu, których nie wolno pomijać: Sensitive Information Disclosure (LLM02) i System Prompt Leakage (LLM07) - nie wkładaj sekretów ani kluczy do promptu systemowego i zakładaj, że prompt wycieknie; Data and Model Poisoning (LLM04) - zatruwanie danych treningowych/fine-tuningu; Vector and Embedding Weaknesses (LLM08) - RAG to nowa powierzchnia ataku, nie tarcza; zatrute dokumenty w bazie wektorowej to po prostu kolejny kanał pośredniego injection; Misinformation (LLM09) - halucynacje podawane wiarygodnie; Unbounded Consumption (LLM10) - niekontrolowane zapytania = DoS i rachunek za tokeny.

Wtyczki, agenci i MCP - konkretnie, bo to o to pytasz. To nie są scenariusze teoretyczne. Widzieliśmy już w realu: błędy bezpieczeństwa w serwerach MCP, zatruwanie "skills" agentów na publicznych marketplace'ach, a w jednym z udokumentowanych łańcuchów spreparowany tytuł zgłoszenia na GitHubie uruchomił bota triażującego opartego na AI, ten wyeksfiltrował GITHUB_TOKEN, którym opublikowano zatrutą zależność npm - instalującą drugiego agenta na ~4000 maszyn deweloperów. Jeden tytuł issue. Żaden człowiek niczego nie zatwierdzał.

Co z tym robić - zasady projektowania agentów i wtyczek:

• Całą treść z zewnątrz (narzędzia, RAG, web, maile) traktuj jako niezaufane dane, nigdy jako instrukcje. Wyraźnie oddzielaj treść niezaufaną od poleceń. To dokładnie ta sama dyscyplina, którą wymuszają bezpieczne wdrożenia: instrukcje pochodzą wyłącznie od użytkownika, nie z tego, co model przeczytał.
• Human-in-the-loop dla akcji wysokiego ryzyka. Przelew, zmiana uprawnień, wysłanie maila, publikacja, usunięcie - wymaga zatwierdzenia przez człowieka, niezależnie od tego, jak "pewny" jest agent.
• Least privilege na poziomie narzędzi. Token agenta powinien mieć minimalny, wąski zakres (just-in-time), nie uprzywilejowane konto "na wszelki wypadek".
• Waliduj wyjście, zanim trafi do innego systemu; nigdy nie wykonuj kodu/SQL/poleceń wprost z modelu.
• Rozbij lethal trifecta - odetnij agentowi jedną z trzech nóg (np. brak kanału wyjściowego tam, gdzie ma dostęp do danych).
• Limity zużycia i kosztów, guardraile, oraz adwersarialne testowanie wdrożenia - bo prompt injection wykryjesz tylko, atakując własnego agenta.

Część III: Regulacje, które od sierpnia 2026 będą mieć zęby

Bezpieczeństwo AI to dziś również zgodność - i to z realnymi karami.

EU AI Act - kalendarz, który deweloper musi znać. Rozporządzenie weszło w życie 1 sierpnia 2024 i działa etapami: od 2 lutego 2025 obowiązują zakazane praktyki i wymóg "AI literacy"; od 2 sierpnia 2025 - obowiązki dla modeli ogólnego przeznaczenia (GPAI); 2 sierpnia 2026 wchodzi większość pozostałych reguł, w tym obowiązki dla systemów wysokiego ryzyka i obowiązki transparentności; systemy AI wbudowane w produkty regulowane mają czas do 2027. Kary sięgają 35 mln euro lub 7% globalnego obrotu - wyżej niż w RODO. (Część terminów wysokiego ryzyka może się jeszcze przesunąć w ramach negocjowanego "Digital Omnibus", więc warto śledzić.)

Kluczowe dla zespołów jest rozróżnienie ról. Jeśli budujesz aplikację, RAG czy agenta na cudzym modelu przez API - jesteś najczęściej "deployerem": Twoje główne obowiązki to transparentność, nadzór człowieka i upewnienie się, że dostawca modelu odrobił dokumentację. Jeśli istotnie modyfikujesz model (np. mocny fine-tuning), możesz zostać przekwalifikowany na "providera" z dużo cięższymi obowiązkami. Transparentność z art. 50 obowiązuje niezależnie od poziomu ryzyka: użytkownik musi wiedzieć, że rozmawia z AI, a treści generowane (w tym deepfake) muszą być oznaczane. Systemy wysokiego ryzyka to dodatkowo system zarządzania ryzykiem, ład nad danymi, logowanie, nadzór człowieka oraz odpowiednia dokładność i cyberbezpieczeństwo.

RODO i mit "zanonimizowaliśmy, więc jesteśmy poza RODO". To pułapka, bo poprzeczka anonimizacji przy AI jest bardzo wysoko. Z opinii EDPB (28/2024) wynika, że anonimowość modelu ocenia się case-by-case, a model jest anonimowy tylko wtedy, gdy jest skrajnie nieprawdopodobne (1) zidentyfikowanie osób z danych treningowych oraz (2) wydobycie ich danych z modelu zapytaniami. Dane osobowe potrafią zostać "wchłonięte" w parametry modelu i wracać w odpowiedziach (regurgitacja, ataki inwersji). Drugi częsty błąd: pseudonimizacja to nie anonimizacja - wg wytycznych EDPB (01/2025) dane spseudonimizowane wciąż są danymi osobowymi. To nie są martwe przepisy: włoski Garante nałożył na OpenAI karę 15 mln euro.

Praktyczne wnioski dla deweloperów:

• Nie wysyłaj danych osobowych do zewnętrznego API modelu bez podstawy prawnej, oceny i - często - umowy powierzenia; rozważ rezydencję danych i suwerenność (dokąd te dane realnie trafiają).
• Minimalizuj i maskuj dane przed treningiem/inferencją (deidentyfikacja, pseudonimizacja, differential privacy, k-anonimizacja).
• Pamiętaj o logach - prompty i odpowiedzi często zawierają dane osobowe, a ich logowanie to przetwarzanie.
• Zaplanuj prawa osób (dostęp, usunięcie) wobec modelu, który mógł dane zapamiętać - to trudne i lepiej przewidzieć je w architekturze niż dorabiać później.
• Rób DPIA dla wrażliwych zastosowań; AI Act i RODO obowiązują równolegle, nie zamiast siebie.

Na koniec: nie da się tego dokleić później

Wspólny mianownik wszystkich trzech warstw jest ten sam, co przy starych mitach: kiedyś uczyliśmy się rozpoznawać złą rzecz po sygnale. Przy AI sygnału nie ma - bo granica między danymi a instrukcją zniknęła, a wyjście modelu jest tak samo nieufne jak wejście. Bezpieczeństwa AI nie da się dokleić sprintem na końcu; trzeba je wprojektować: threat modeling na etapie designu, least privilege dla agentów, traktowanie każdej treści z zewnątrz jak wroga i - co najważniejsze - testowanie ciągłe, nie raz w roku.

To zresztą logika, na której zbudowaliśmy Obsigen AI: patrzeć na wdrożenie tak, jak realny przeciwnik - łączyć drobiazgi, atakować agenta jego własnym kanałem, sprawdzać, czy "bezszwowa automatyzacja" nie jest po cichu otwartymi drzwiami. Bo w 2026 pytanie nie brzmi "czy nasza integracja AI ma lukę", tylko "czy znajdziemy ją, zanim zrobi to ktoś inny".

Źródła: OWASP Top 10 for LLM Applications (2025), OWASP Password Storage Cheat Sheet, badania nad slopsquatting (USENIX Security '25 i re-ewaluacja modeli 2026), EU AI Act (Regulation 2024/1689) wraz z oficjalnym harmonogramem, EDPB Opinion 28/2024 oraz Guidelines 01/2025 on Pseudonymisation. Liczby i terminy opisano zachowawczo; część terminów AI Act może ulec zmianie w toku prac legislacyjnych.