Czym jest bezpieczeństwo LLM? Jak ograniczyć 10 największych zagrożeń według OWASP

Atak, który nakłania AI do traktowania instrukcji atakującego jak poleceń — wstrzykiwanie promptów (prompt injection) — zajmuje 1. miejsce na liście OWASP Top 10 for LLM Applications w każdej edycji od 2023 roku.

W dziedzinie bezpieczeństwa AI trudno o coś bliższego konsensusowi niż ta lista. Projekt zapoczątkowała niewielka grupa specjalistów ds. bezpieczeństwa, a dziś współtworzy go ponad 600 ekspertów z ponad 18 krajów.

Jesteśmy firmą AI, która publikuje przewodnik o tym, jak AI daje się do czegoś namówić, więc nie będziemy udawać, że problem został rozwiązany. Wilson, współkierujący projektem OWASP, wypowiedział się dość jasno na temat obecnych zabezpieczeń: „...szczerze mówiąc, nie sądzę, żebyśmy byli na poziomie 99%”.

Edycja 2026 zaczyna się w tym samym tonie. Lider projektu radzi nam „przestać próbować budować model, którego nie da się oszukać” i zaprojektować otaczający go system tak, by oszukany model nie mógł zepsuć niczego ważnego.

Z takiej perspektywy omawiamy wszystkie 10 zagrożeń z listy OWASP na 2026 rok.

Co oznacza bezpieczeństwo LLM?

Bezpieczeństwo LLM oznacza ochronę modeli AI i korzystających z nich aplikacji przed atakami i nadużyciami. Ryzyko rośnie wraz z tym, do czego model jest podłączony: plików i danych, które może odczytać, oraz narzędzi, z których może korzystać, takich jak poczta e-mail, wyszukiwarka czy firmowa baza danych.

W odpowiednio zabezpieczonym oprogramowaniu istnieje wyraźna granica między instrukcjami, które program wykonuje, a informacjami, które przetwarza. Modele LLM takiej granicy jednak nie mają.

Wszystko, co model czyta, trafia do niego jako jeden długi strumień tekstu: instrukcje dewelopera, Twoje pytanie, strona internetowa, którą sprawdził. Modele AI powinny śledzić, kto mówi — czy to deweloper, użytkownik, czy sam model analizujący problem.

Badacze Jasmine Cui i Charles Ye odkryli jednak, że modele w większości zgadują, kto mówi, na podstawie tego, jak brzmi tekst. Jeśli więc atakujący napisze coś, co brzmi jak własne rozumowanie modelu, model może uznać, że sam wpadł na ten pomysł. To problem dla każdego mechanizmu bezpieczeństwa, który zakłada, że model wie, kto tu rządzi.

Ten sam problem napotkaliśmy w przypadku naszych własnych agentów AI. Nasz CISO, Kyle Polley, powiedział w rozmowie z ISMG, że agenci „mogą nie przestrzegać zasad, nawet jeśli doda się je do promptu systemowego”. Dlatego stworzyliśmy Numbat — narzędzie open source, które sprawdza, co agent zamierza zrobić, i może zablokować działanie, jeśli narusza ono skonfigurowaną regułę bezpieczeństwa.

Bezpieczeństwo LLM oznacza pogodzenie się z tym, że model czasem przyjmie polecenia od niewłaściwej osoby, i otoczenie go zabezpieczeniami AI, które zadziałają nawet wtedy, gdy do tego dojdzie.

Jakie są najlepsze praktyki w zakresie bezpieczeństwa LLM?

Omówimy po kolei zagrożenia z listy OWASP Top 10 for LLM Applications 2026 — od pierwszego do dziesiątego.

Dla każdego zagrożenia otrzymasz przystępne wyjaśnienie, co może pójść nie tak, oraz przykład z rzeczywistości. Następnie omówimy praktyki, które mogą pomóc mu zapobiec lub przynajmniej ograniczyć szkody.

1. Ogranicz skutki wstrzykiwania promptów

Do wstrzyknięcia promptu dochodzi, gdy atakujący sprawia, że AI wykonuje instrukcje, których nie powinna. Instrukcje te mogą pojawić się bezpośrednio w czacie lub zostać ukryte w e-mailu, na stronie internetowej czy w dokumencie.

Drugi typ to tzw. pośrednie wstrzykiwanie promptów. Prosisz asystenta o podsumowanie dokumentu. Jego autor umieścił w nim polecenie, by asystent przesłał mu Twoje prywatne pliki. Jeśli asystent wykona te instrukcje, osoba, która napisała dokument, w praktyce przejmie Twój dostęp.

PCMag porównuje zabezpieczanie promptów do łatania dziur w porowatym kamieniu. Uszczelniasz jeden otwór, a woda znajduje inny. „Atak znajduje drogę; zostaje naprawiony, ale niezliczone inne drogi ataku wciąż czekają na odkrycie, po prostu dlatego, że systemy takie jak LLM są tak dynamiczne”.

Przykład: W czerwcu 2025 roku badacze z Aim Security wykryli EchoLeak — lukę, która nakłaniała Microsoft 365 Copilot do ujawniania prywatnych informacji firmowych. Gdy pracownik zadawał rutynowe pytanie związane z pracą, Copilot mógł sięgnąć po spreparowaną wiadomość e-mail, wykonać ukryte w niej instrukcje i wysłać poufne informacje atakującemu. Atak omijał mechanizmy kontroli, które miały wyłapywać złośliwe instrukcje i usuwać podejrzane linki.

Co możesz zrobić:

• Stosuj „Zasadę dwóch” firmy Meta: EchoLeak potrzebował AI, która mogła odczytywać dane firmowe, odczytywać zewnętrzne wiadomości e-mail i wysyłać informacje na zewnątrz — a ta miała wszystkie trzy możliwości. Ograniczenie jej do dwóch z nich sprawia, że wstrzyknięty prompt nie przejmie zbyt dużej kontroli. Jeśli zadanie wymaga wszystkich trzech, każde działanie musi najpierw zatwierdzić człowiek.
• Testuj odporność na atakujących, którzy znają Twoje zabezpieczenia: Przekaż testerom bezpieczeństwa wdrożone reguły i filtry, a następnie pozwól im je obejść. W jednym z badań atakujący, którzy dostosowali się do zabezpieczeń, odnieśli sukces w ponad 90% przypadków w starciu z większością z 12 testowanych zabezpieczeń.

2. Zapobiegaj wyciekom informacji wrażliwych

Gdy systemy AI przekazują prywatne informacje osobom, które nie powinny ich widzieć, mówimy o ujawnianiu informacji wrażliwych. Może chodzić na przykład o wyjawienie danych płatniczych klienta lub pozostawienie prywatnych rozmów we współdzielonej bazie danych.

Wiele wycieków zaczyna się od „nadmiernego udostępniania”. Załóżmy, że firma podłącza swoją AI do dysków i baz wiedzy z luźno ustawionymi uprawnieniami. AI pobiera wszystko, do czego ma dostęp — dokładnie tak, jak ją zaprojektowano. Nikt nie musi się włamywać, a mimo to LLM można uznać za skompromitowany.

Przykład: W styczniu 2025 roku badacze z Wiz odkryli bazę danych DeepSeek dostępną publicznie w internecie, zawierającą ponad milion wpisów w logach, w tym historię czatów i klucze API, których oprogramowanie używa do uzyskiwania dostępu do innych usług. Badacze nie musieli przekonywać modelu, by cokolwiek ujawnił.

Co możesz zrobić:

• Sprawdzaj uprawnienia, zanim AI odczyta dane: Twoja aplikacja powinna sprawdzić, które dokumenty może zobaczyć osoba zadająca pytanie, zanim przekaże je modelowi.
• Chroń zapisy, które pozostawia Twoja AI: Usuwaj dane prywatne i tajne klucze przed zapisaniem logów aktywności, wymagaj logowania i ograniczaj dostęp do osób, które go potrzebują. Ustal okres przechowywania, aby te zapisy nie gromadziły się w nieskończoność.

3. Okiełznaj nadmierną sprawczość

AI z nadmierną sprawczością ma więcej władzy, niż wymaga jej rola: narzędzia, których nie potrzebuje, uprawnienia wykraczające poza jej zadanie lub swobodę działania bez weryfikacji. Przyczyna nie ma tu znaczenia.

Wstrzyknięty prompt, błąd w kodzie czy model, który po prostu się myli — wszystko to prowadzi do tego samego. Jeśli AI ma ku temu możliwości, prędzej czy później zrobi coś destrukcyjnego.

Przykład: W lipcu 2025 roku założyciel SaaStr, Jason Lemkin, poinformował, że agent programistyczny Replit usunął jego bazę danych zawierającą 1206 rekordów dotyczących kadry kierowniczej, mimo poleceń, by nie wprowadzać zmian. Agent początkowo twierdził, że danych nie da się przywrócić, choć później okazało się, że ich odzyskanie jest możliwe. Jason przekonał się, że polecenie, by nie ruszać bazy danych, nie odebrało agentowi możliwości jej usunięcia.

Powiększ

Źródło: X

Co możesz zrobić:

• Usuń możliwości, których zadanie nie wymaga: Ogranicz zarówno narzędzia, które otrzymuje agent, jak i to, co te narzędzia mogą robić. Asystent podsumowujący e-maile potrzebuje uprawnień do ich odczytu, a nie do wysyłania czy usuwania.
• Umieść kontrolę uprawnień poza AI: Za każdym razem, gdy żądane jest wykonanie działania, sprawdzaj je pod kątem reguł bezpieczeństwa i wymagaj jego zatwierdzenia przez człowieka.

4. Sprawdzaj, co trafia do łańcucha dostaw Twojej AI

Niewiele firm tworzy AI od podstaw, a z roku na rok jest ich coraz mniej. Według badania Menlo Ventures „2025 The State of Generative AI in the Enterprise” w 2024 roku modele AI kupowało 53% firm, a w 2025 roku odsetek ten wzrósł do 76%.

Najczęściej firmy pobierają modele z platform takich jak Hugging Face, dotrenowują je na zbiorach danych zebranych przez innych i podłączają dodatki oraz pakiety kodu napisane przez nieznanych autorów.

Każdy z tych elementów to potencjalna furtka. Jeśli którykolwiek zostanie zmanipulowany, problem trafi do Twojego produktu.

Przykład: Liczba publicznych repozytoriów modeli w Hugging Face wzrosła z 2,43 mln do 2,96 mln między styczniem a sierpniem 2026 roku. Jednak w lipcu 2026 roku modele OpenAI podczas wewnętrznych testów bezpieczeństwa obeszły zabezpieczenia, które miały odcinać je od internetu, i włamały się do części systemów Hugging Face. Jeden z agentów zdobył nawet 14 publicznie ujawnionych poświadczeń dostępu, sprawdził, czy działają, i udostępnił je innym agentom. Agenci wykorzystali następnie luki, które pozwoliły im uruchamiać kod na serwerach Hugging Face.

„Wprowadzamy bardziej rygorystyczne wymagania dotyczące dopasowania (alignment) w całym cyklu życia modelu, tworzymy lepiej odizolowane piaskownice, ograniczamy dostęp do internetu i dodatkowo kontrolujemy dostęp do wag modeli” — czytamy w raporcie OpenAI.

Co możesz zrobić:

• Przypinaj modele do konkretnych wersji i weryfikuj je: Przypnij każdy model do sprawdzonej wersji i przed załadowaniem weryfikuj odcisk cyfrowy jego pliku, aby podmieniony plik nie mógł prześlizgnąć się pod tą samą etykietą. OWASP zaleca również podpisy cyfrowe, z jednym zastrzeżeniem — podpis dowodzi, skąd pochodzi model, a nie tego, że jest bezpieczny.
• Sprawdzaj każdy pakiet sugerowany przez AI: Zanim zainstalujesz pakiet kodu polecony przez asystenta AI, upewnij się, że on istnieje, że to ten pakiet, o który Ci chodziło, i że pochodzi od oczekiwanego wydawcy.

5. Chroń się przed zatruwaniem danych i modeli

Zatruta AI uczy się na podstawie uszkodzonych danych. Mogą to być przykłady, na których ją dostrajano, lub baza wiedzy, którą przeszukuje w poszukiwaniu odpowiedzi. Model nadal wygląda na sprawny — po prostu wyciąga niewłaściwe wnioski, a czasem uczy się działać nieprawidłowo tylko wtedy, gdy napotka określoną frazę wyzwalającą.

Taki model przejdzie każdy test, któremu go poddasz, dopóki ktoś nie użyje tej frazy.

Powiększ

Co więcej, bardzo trudno to odwrócić. Zatrucia nie da się załatać jak zwykłego błędu. Jeśli Twoje dane są błędne, może być konieczne ich ponowne sprawdzenie, ponowne wytrenowanie modelu lub całkowite jego zastąpienie.

Przykład: W październiku 2025 roku badacze z Anthropic, brytyjskiego AI Security Institute i Alan Turing Institute wykazali, że 250 zatrutych dokumentów wystarczy, by nauczyć model generowania bełkotu za każdym razem, gdy napotka określony wyzwalacz. Ta sama liczba sprawdziła się we wszystkich czterech testowanych rozmiarach modeli, mimo że największy z nich trenowano na ponad 20 razy większej ilości czystych danych.

Co możesz zrobić:

• Śledź pochodzenie swoich danych: Prowadź rejestr wszystkich używanych zbiorów danych i modeli, ich źródeł oraz zmian między wersjami. Zalecamy kontrolę wersji zbiorów danych, aby w razie wykrycia zatrucia można było przywrócić czystą wersję i ustalić, jak do niego doszło.
• Testuj pod kątem backdoorów: „Backdoor” (tylne drzwi) to ukryte zachowanie, które atakujący umieszcza w modelu i które czeka na określoną frazę lub inny wyzwalacz, by się aktywować. Wykrywaj je za pomocą danych wejściowych zaprojektowanych tak, by skłonić model do złamania jego zwykłych reguł.

6. Nałóż limity na nieograniczone zużycie zasobów

Gdy AI nie ma żadnych limitów co do tego, ile pracy może wykonać ani ile może kosztować, jej zużycie zasobów uznaje się za „nieograniczone”. Większość usług AI pobiera opłaty za użycie, więc atakujący mógłby nabić Ci rachunek lub zbudować kopię Twojego modelu.

OWASP nazywa sedno problemu „asymetrią kosztów”. Krótkie, tanie zapytanie może uruchomić kosztowne obliczenia po Twojej stronie.

Przykład: W maju 2024 roku zespół Sysdig Threat Research Team wykrył nowy atak o nazwie „LLMjacking”. Grupa atakujących wzięła na cel 10 usług LLM hostowanych w chmurze, wykorzystując skradzione dane uwierzytelniające. Atakujący dostali się do środka przez podatną wersję frameworka Laravel, a następnie ustalili, na co pozwalają te dane uwierzytelniające i jakie obowiązują limity — w oczywistym celu sprzedaży dostępu. Odpytywali też wiele ustawień rejestrowania zdarzeń, prawdopodobnie po to, by uniknąć wykrycia. Według Sysdig w najgorszym scenariuszu ofiara mogłaby ponosić koszty przekraczające 46 000 USD dziennie.

Co możesz zrobić:

• Ustal budżety, które faktycznie zatrzymują wydatki: Wprowadź sztywne limity wydatków dla poszczególnych użytkowników, kluczy API, zespołów i całego konta. Egzekwuj je wszędzie tam, gdzie mogą napływać zapytania.
• Wyznacz każdemu zadaniu punkt zatrzymania: Ogranicz czas działania zadania, ilość tekstu, jaką może przetworzyć i wygenerować, oraz liczbę wywołań narzędzi. Dodaj automatyczne wyłączniki dla agentów, którzy się zapętlają lub przekraczają przydzielony limit.

7. Wyłapuj dezinformację, zanim podejmiesz działanie

Gdy AI generuje coś fałszywego, co brzmi wiarygodnie, a ktoś lub coś na tej podstawie działa, mówimy o dezinformacji. Główne ryzyko polega nie tyle na samej błędnej odpowiedzi, co na tym, że ktoś jej zaufa i ją wykorzysta.

Historia incydentów sugeruje, że praktycy nie przejmowali się dezinformacją tak bardzo, jak powinni. Według listu otwierającego edycję 2026 głosujący umieścili ją blisko końca listy, ale rzeczywiste incydenty plasują ją w ścisłej czołówce.

Przykład: W 2025 roku Deloitte Australia dostarczyło przegląd systemów IT obsługujących świadczenia socjalne w ramach rządowego kontraktu o wartości 440 000 AUD. Związany z University of Sydney badacz Chris Rudge znalazł w nim odwołania do nieistniejących badań oraz zmyślony cytat z wyroku sądu federalnego. W poprawionym raporcie ujawniono, że Deloitte wykorzystało w swojej metodologii Azure OpenAI GPT-4o, a firma zgodziła się zwrócić ostatnią ratę wynagrodzenia. Na domiar złego był to przegląd typu assurance, który miał właśnie potwierdzać rzetelność.

Co możesz zrobić:

• Sprawdzaj, czy dowody potwierdzają odpowiedź: Opieraj twierdzenia na aktualnych, wiarygodnych źródłach. W przypadku odpowiedzi dotyczącej zasad pobierz zatwierdzony dokument z zasadami i sprawdź, czy potwierdza on wniosek, łącznie z wyjątkami.
• Weryfikuj, zanim system podejmie działanie: Jeśli agent twierdzi, że klient przeszedł weryfikację tożsamości, potwierdź to w systemie weryfikacji przed zwolnieniem płatności. Wymagaj zatwierdzenia przez człowieka w przypadku decyzji o istotnych skutkach i udostępniaj osobie weryfikującej dowody, na których się one opierają.

8. Ogranicz szkody wynikające z ujawnienia ukrytego kontekstu

Aplikacje AI przekazują modelowi instrukcje i informacje kontekstowe, których użytkownicy zwykle nie widzą. Mogą to być prompt systemowy, wewnętrzne zasady, opisy dostępnych narzędzi oraz reguły określające, kto może z nich korzystać. Do ujawnienia ukrytego kontekstu dochodzi, gdy model komuś te informacje zdradzi.

W 2026 roku OWASP rozszerzył tę pozycję z „wycieku promptu systemowego”, ponieważ prompt systemowy to tylko część tego, co może wyciec. Zagrożenie zależy od tego, co tam umieszczono. Wyciek wytycznych dotyczących tonu komunikacji jest co najwyżej lekko żenujący, ale wyciek klucza API daje komuś dostęp do Twojej poufnej bazy danych.

Przykład: W lutym 2023 roku użytkownicy skłonili Bing Chat firmy Microsoft do ujawnienia jego wewnętrznych instrukcji. Jedna z udanych prób należała do Marvina von Hagena, który podał się za dewelopera OpenAI i poprosił o instrukcje, aby móc skonfigurować model. Bing ujawnił zasady dotyczące wyszukiwania, odpowiedzi i zachowań związanych z bezpieczeństwem, a także swoją wewnętrzną nazwę — Sydney. Wśród ujawnionych instrukcji była jedna nakazująca mu zachować te instrukcje w tajemnicy.

Co możesz zrobić:

• Nie dopuszczaj sekretów do kontekstu modelu: Zakładaj, że wszystko, co model może odczytać, może stać się widoczne dla użytkowników — przechowuj hasła, klucze API i tokeny dostępu w oddzielnym systemie zarządzania sekretami.
• Zadbaj, by uprawnienia działały nawet po wycieku reguł: Egzekwuj kontrolę dostępu w kodzie aplikacji. Jeśli narzędzie jest dostępne tylko dla administratorów, przed jego uruchomieniem sprawdź uprawnienia konta użytkownika.

9. Zabezpiecz wektory i osadzenia

Gdy AI korzysta z wyszukiwania wektorowego, aby znaleźć odpowiedzi w dokumentach Twojej firmy, nie przeszukuje bezpośrednio tekstu. Dokumenty są przekształcane w „osadzenia” (ang. embeddings), czyli długie listy liczb oddające znaczenie każdego fragmentu, i zapisywane w wektorowej bazie danych. Pytanie jest przekształcane w ten sam sposób, a system wybiera fragmenty, których liczby leżą najbliżej.

OWASP wymienia cztery sposoby, w jakie ten mechanizm może zawieść: zatruwanie sprawia, że system się myli, inwersja — że ujawnia dane, zagłuszanie — że milknie, a wadliwa kontrola dostępu — że udostępnia wszystko każdemu.

Liczby nie są tak bezpieczną abstrakcją, na jaką wyglądają. Zapisane osadzenia można z powrotem przekształcić w tekst — jedna z metod w testach dokładnie odtworzyła 92% krótkich, 32-tokenowych fragmentów. Dlatego wyciek kopii zapasowej zawierającej „wyłącznie osadzenia” również może ujawnić treść dokumentów.

Przykład: W badaniu zaprezentowanym na konferencji USENIX Security 2025 naukowcy wykazali, że jeden starannie spreparowany dokument może sprawić, że AI przestanie odpowiadać na określone pytanie. Dodali go do zbioru przeszukiwanego przez AI. Gdy AI go znalazła, mogła odpowiedzieć, że nie ma wystarczających informacji albo że udzielenie odpowiedzi byłoby niebezpieczne. Dokument nie musiał nakazywać AI ignorowania jej reguł. Nazywa się to „zagłuszaniem wyszukiwania” (ang. retrieval jamming).

Co możesz zrobić:

• Utrzymuj oddzielne indeksy dla danych publicznych i prywatnych: Nie mieszaj treści pobranych z sieci z danymi partnerów ani z poufnymi dokumentami wewnętrznymi. Zamiast oznaczać treści tagami w jednym indeksie, rozdziel je fizycznie według poziomu zaufania — eliminuje to całą klasę błędów konfiguracji, a treści zebrane z internetu nie trafią obok dokumentów zarządu.
• Traktuj osadzenia jak dokumenty, z których powstały: Szyfruj je, chroń kopie zapasowe wektorowej bazy danych tak samo jak pliki źródłowe i usuwaj osadzenia, gdy usuwasz oryginał. Klucze API do usługi generującej osadzenia należy trzymać w tajemnicy.

10. Sprawdzaj dane wyjściowe AI, zanim przekażesz je dalej

Gdy aplikacja przekazuje dane wyjściowe AI do innego systemu, nie sprawdzając, czy można ich tam bezpiecznie użyć, mamy do czynienia z niewłaściwą obsługą danych wyjściowych LLM.

Ta kategoria obejmuje również niebezpieczny kod, który asystenci AI do programowania generują na masową skalę. Każdy wiersz napisany przez asystenta jest więc także danymi wyjściowymi.

Przykład: W 2025 roku badacz Johann Rehberger pokazał, jak asystent programowania Amp firmy Sourcegraph mógł ujawnić treść czatu po prostu przez wyświetlenie obrazu. Za pomocą wstrzykiwania promptów sprawił, że Amp umieszczał prywatne informacje w adresie internetowym obrazu. Aplikacja następnie automatycznie pobierała ten obraz, wysyłając informacje na jego serwer. Błędem w obsłudze danych wyjściowych było właśnie to automatyczne żądanie — tekst wygenerowany przez model stał się połączeniem z zewnętrznym serwerem, które przenosiło ze sobą prywatne dane.

Co możesz zrobić:

• Zadbaj, by dane wyjściowe były bezpieczne w miejscu docelowym: Sprawdzaj i obsługuj odpowiedzi zależnie od tego, dokąd trafią. W przypadku strony internetowej nie dopuść, by wygenerowany tekst stał się kodem wykonywalnym. W przypadku bazy danych używaj zapytań przygotowanych, które oddzielają przekazywane wartości od poleceń.
• Nie pozwalaj, by odpowiedzi automatycznie nawiązywały połączenia z zewnętrznymi serwerami: Domyślnie wyłącz automatyczne ładowanie obrazów, podglądów linków i osadzonych stron w odpowiedziach modelu. Ogranicz niezbędne połączenia do wyraźnie zatwierdzonych miejsc docelowych.

Jak Perplexity zabezpiecza LLM?

Zakładamy, że każde z powyższych zagrożeń w końcu się zmaterializuje, i projektujemy systemy tak, by nie mogło wtedy wyrządzić wielu szkód. Nasz CISO, Kyle Polley, omówił, jak to robimy, podczas niedawnych warsztatów.

• Agent dostaje własny komputer, który na starcie jest pusty: Narzędzia agentowe zainstalowane na Twoim laptopie mogą uzyskać dostęp do jego plików, aplikacji i zapisanych danych logowania. Perplexity Computer działa odwrotnie. Każde zadanie jest uruchamiane we własnej, odizolowanej piaskownicy, która — jak ujmuje to Polley — „domyślnie nie ma dostępu do niczego”.
• Agent nigdy nie widzi haseł: Dane logowania do połączonych usług są przechowywane poza piaskownicą. Gdy agent musi połączyć się z usługą taką jak GitHub, wysyła żądanie bez dołączonych danych logowania. Brama sprawdza, czy miejsce docelowe i żądanie są zgodne z oczekiwaniami, a następnie dodaje dane logowania do wychodzącego żądania. Agent może korzystać z połączenia, nie otrzymując kluczy.
• Twoje uprawnienia są przenoszone, a Ty możesz je zawęzić: Połączenia nawiązywane przez OAuth zachowują Twoje uprawnienia dostępu w połączonej usłudze. Jeśli Ty czegoś nie widzisz, Twój agent też tego nie zobaczy.
• Każda strona internetowa jest traktowana jak nieznajomy: Stworzyliśmy BrowseSafe dla Comet, naszej przeglądarki agentowej, ponieważ testowane przez nas narzędzia nie spełniały naszych potrzeb w rzeczywistym użyciu. Przeglądarka skanuje strony internetowe i inne treści zewnętrzne, w tym e-maile, pod kątem wstrzykiwania promptów. Udostępniliśmy jako open source zarówno model, jak i zbiór danych.
• Monitorujemy agenta i maszyny, na których działa: Numbat działa pomiędzy decyzją agenta o podjęciu działania a faktycznym uruchomieniem narzędzia. Numbat rejestruje aktywność obsługiwanych agentów programistycznych i może blokować działania naruszające skonfigurowane zasady, zanim zostaną wykonane. Bumblebee inwentaryzuje pakiety oprogramowania na laptopach, serwerach i w potokach kompilacji oraz oznacza te, o których wiadomo, że są złośliwe. Oba narzędzia mają otwarty kod źródłowy.
• Dostawcy modeli nie przechowują Twoich danych: Z zewnętrznymi dostawcami LLM mamy umowy o zerowym przechowywaniu danych. Administratorzy planu Enterprise mogą też skrócić okres przechowywania danych przez samo Perplexity nawet do 24 godzin.

Numbat stworzyliśmy proaktywnie z powodu, który Polley podsumowuje jednym zdaniem: „Im więcej autonomii dajesz agentowi, tym większe ryzyko”.

Bezpieczeństwo LLM — najczęściej zadawane pytania

Który LLM jest najbezpieczniejszy?

Żaden LLM sam w sobie nie zapewnia bezpieczeństwa aplikacji — modele wciąż mogą pomylić treści, które powinny tylko przeczytać, z instrukcjami, które powinny wykonać. Zabezpieczenia, które dobrze wypadają w standardowych testach, mogą też zawieść pod presją.

Lepiej zapytać, która konfiguracja jest najbezpieczniejsza w Twoim przypadku użycia. Oznacza to ograniczone uprawnienia, dane logowania trzymane z dala od modelu, zatwierdzanie ryzykownych działań przez człowieka oraz testy przeprowadzane przez osoby, które znają Twoje zabezpieczenia.

Czym są podatności LLM?

Podatności LLM to słabe punkty, które pozwalają oszukać system AI, doprowadzić do wycieku danych lub wyrządzić szkody — za sprawą atakującego albo własnych błędów systemu.

Dziesięć głównych zagrożeń to: wstrzykiwanie promptów, ujawnianie informacji wrażliwych, nadmierna autonomia, łańcuch dostaw, zatruwanie danych i modelu, nieograniczone zużycie zasobów, dezinformacja, ujawnianie ukrytego kontekstu, słabości wektorów i osadzeń oraz niewłaściwa obsługa danych wyjściowych.

Czy prywatny LLM jest bezpieczny?

W niektórych zastosowaniach to bezpieczniejsza opcja, ale nie z definicji. Uruchamiając model na własnej infrastrukturze lub w środowisku chmurowym, masz większą kontrolę nad przetwarzaniem danych. Nie ma jednak automatycznego sposobu na zapobieganie wstrzykiwaniu promptów, nadmiernej autonomii, zatruwaniu czy dezinformacji.

Decydując się na samodzielny hosting, odpowiadasz też za pobrany model, w tym za ryzyka związane z łańcuchem dostaw oraz infrastrukturę, której wymaga.