Lakera Guard, ochrona LLM przed prompt injection

Lakera Guard, ochrona LLM przed prompt injection

Lakera Guard to zewnętrzne API, przez które przepuszczasz tekst przed wysłaniem go do modelu językowego i po otrzymaniu odpowiedzi. Zwraca informację, czy treść wygląda na próbę wstrzyknięcia instrukcji, ucieczki z ograniczeń, wyciek danych osobowych albo materiał naruszający zasady.

Problem, który rozwiązuje, jest wpisany w konstrukcję modeli językowych: instrukcja od Ciebie i tekst od użytkownika trafiają do tego samego kanału. Model nie ma sposobu, żeby je rozróżnić na poziomie architektury, więc odpowiednio sformułowane zdanie w danych wejściowych potrafi nadpisać Twój prompt systemowy.

Zmiana nazwy i właściciela

Zanim zaczniesz szukać dokumentacji, przyjmij do wiadomości, że nazwy się rozjechały i to jest źródło sporego zamieszania.

Lakera została przejęta przez Check Point. Umowa została ogłoszona we wrześniu 2025 i zamknięta w październiku tego samego roku, przy kwocie podawanej publicznie w okolicach trzystu milionów dolarów.

Produkt nazywa się dziś Check Point AI Guardrails. Dokumentacja stoi nadal pod domeną Lakery, punkt końcowy API również pozostał bez zmian, więc kod napisany wcześniej działa dalej. Zmieniło się natomiast to, co widzisz w materiałach handlowych i w panelu, a przede wszystkim sposób sprzedaży: produkt wchodzi w tryb zakupu korporacyjnego, z rozmową handlową zamiast samodzielnego wykupienia planu.

Dla małego zespołu ma to praktyczne znaczenie. Narzędzie, które kiedyś dawało się wpiąć w popołudnie, dziś przy większym ruchu wymaga przejścia przez proces zakupowy dostawcy z segmentu korporacyjnego. Do prób i do prototypu nadal wystarczy klucz z darmowego progu.

Jak to działa w praktyce

Model działania jest celowo prosty i to jego największa zaleta.

Guard stoi obok Twojej aplikacji, nie w jej środku. Wysyłasz zapytanie z treścią, dostajesz odpowiedź z oceną, decydujesz co dalej. Nie zmienia to Twojego modelu, dostawcy ani struktury promptu, więc wpięcie i wypięcie tego elementu jest kwestią jednego warunku w kodzie.

Ma to konsekwencję, którą trzeba zaakceptować: każdy sprawdzany fragment to dodatkowe wywołanie sieciowe. Dostawca podaje opóźnienie poniżej pięćdziesięciu milisekund, przy czym jest to liczba deklarowana i mierzona po stronie usługi, więc do własnych obliczeń doliczaj jeszcze przelot z Twojego regionu.

Sam adres kieruje domyślnie do regionu najbliższego nadawcy, a przy wymogach dotyczących miejsca przetwarzania możesz wskazać konkretny poddomeną: Irlandia, Singapur albo jeden z regionów w Stanach. Miejsce przechowywania logów i lista regionów dopuszczonych do przetwarzania konfigurują się osobno, więc jedno nie wymusza drugiego.

Przy sprawdzaniu wejścia i wyjścia osobno masz dwa wywołania na jedną interakcję użytkownika. Przy strumieniowaniu odpowiedzi robi się trudniej, bo albo czekasz z pokazaniem czegokolwiek do końca generowania, albo sprawdzasz fragmentami i ryzykujesz, że wycofasz tekst już pokazany na ekranie.

Pierwsze wywołanie

export LAKERA_GUARD_API_KEY=...

import os
import requests

sesja = requests.Session()

def sprawdz(tresc: str) -> bool:
    odpowiedz = sesja.post(
        "https://api.lakera.ai/v2/guard",
        json={
            "messages": [{"content": tresc, "role": "user"}],
            "project_id": "project-XXXXXXXXXXX",
        },
        headers={"Authorization": f"Bearer {os.environ['LAKERA_GUARD_API_KEY']}"},
        timeout=3,
    )
    odpowiedz.raise_for_status()
    return odpowiedz.json()["flagged"]

if sprawdz(prompt_uzytkownika):
    raise ValueError("Zapytanie odrzucone przez filtr")

Pole flagged to jedna wartość logiczna i na start wystarczy. Odpowiedź zawiera też rozbicie na poszczególne wykrycia, i do tego warto sięgnąć od razu, bo pozwala rozróżnić sytuacje, które wymagają zupełnie innej reakcji: próba wstrzyknięcia to co innego niż numer karty przypadkiem wklejony przez użytkownika.

Zwróć uwagę na limit czasu w wywołaniu. Bez niego awaria usługi zewnętrznej zamienia się w zawieszoną aplikację, a przy filtrze bezpieczeństwa to najgorszy możliwy scenariusz, bo blokuje ruch, którego wcale nie trzeba było blokować.

Pięć rodzin zabezpieczeń

Usługa dzieli zagrożenia na pięć rodzin i różnice między nimi mają znaczenie, bo do każdej pasuje inna reakcja.

Ataki na prompt to wstrzyknięcia instrukcji, próby ucieczki z ograniczeń i manipulacja treścią systemową. To jest podstawowe zastosowanie i najczęstszy powód sięgania po to narzędzie.

Wyciek danych obejmuje dane osobowe i inne informacje wrażliwe. Ta kategoria działa w obie strony: chroni przed wysłaniem czegoś do modelu i przed pokazaniem czegoś użytkownikowi.

Naruszenie zasad treści to materiał obraźliwy, nienawistny, seksualny albo przemocowy. Bliżej temu do klasycznej moderacji niż do bezpieczeństwa.

Nieznane odnośniki to wykrywanie adresów spoza listy dozwolonych domen. Kategoria najmniej oczywista, a przy agentach potrafiąca uratować sytuację, bo wyprowadzenie danych przez odnośnik w odpowiedzi to realny sposób ataku.

Piąta rodzina, dołożona najpóźniej, dotyczy zachowania agenta. Składa się z wykrywania działań poza zadaniem, czyli wywołań narzędzia niepasujących do tego, o co prosił użytkownik, oraz z listy narzędzi dozwolonych i zablokowanych, egzekwowanej w chwili wywołania. Ta warstwa patrzy nie na treść, tylko na to, co agent faktycznie robi, więc łapie skutki wstrzyknięcia, które przeszło przez wcześniejsze filtry. Sam punkt końcowy sprawdza przy tym również opisy narzędzi i odpowiedzi z narzędzi, bo obie te drogi wprowadzają obcy tekst do kontekstu modelu.

Polityki, projekty i strojenie

Konfiguracja opiera się na dwóch pojęciach, które trzeba zrozumieć przed uruchomieniem czegokolwiek na produkcji.

Projekt to Twoja aplikacja albo jej fragment. Identyfikator projektu podajesz w każdym wywołaniu, a on decyduje, która polityka zostanie zastosowana.

Polityka określa, które mechanizmy są włączone i jak czułe. Dostawca daje gotowy zestaw dla aplikacji dostępnych publicznie i to jest rozsądny punkt wyjścia, natomiast rzadko jest punktem docelowym.

Powód jest zawsze ten sam: czułość to kompromis, a właściwe ustawienie zależy od tego, co Twoi użytkownicy faktycznie piszą. Aplikacja dla programistów dostaje w promptach fragmenty kodu, opisy podatności i treści, które przy wysokiej czułości wyglądają jak atak. Aplikacja dla klientów banku prawie nigdy takich treści nie dostaje, więc może pozwolić sobie na ostrzejsze ustawienia.

Praktyczna droga wygląda tak. Uruchom filtr w trybie obserwacji, gdzie zapisujesz wyniki, ale niczego nie blokujesz. Zbierz kilka tysięcy realnych zapytań. Przejrzyj wykrycia i policz, ile z nich to fałszywe alarmy. Dopiero potem włącz blokowanie, i to najpierw dla kategorii o najniższym poziomie błędu.

Osobne projekty dla środowiska testowego i produkcyjnego oszczędzają sporo kłopotów, bo pozwalają zmieniać czułość bez ryzyka, że zmiana wejdzie od razu użytkownikom.

Gdzie to wpiąć w aplikacji

Miejsce wpięcia decyduje o skuteczności bardziej niż same ustawienia.

Wejście od użytkownika to oczywiste miejsce i zwykle pierwsze. Sprawdzasz tekst, zanim trafi do promptu.

Wyjście z modelu jest równie ważne, a bywa pomijane. Model, który przyjął wstrzykniętą instrukcję, ujawni to właśnie w odpowiedzi, i tam jeszcze da się to zatrzymać.

Trzecie miejsce jest najczęściej zapominane, a przy agentach najgroźniejsze: treść pobrana z zewnątrz. Strona internetowa, dokument, wynik wyszukiwania albo odpowiedź z narzędzia trafiają do kontekstu modelu tak samo jak tekst od użytkownika. Instrukcja ukryta w treści pobranej strony działa dokładnie tak samo jak wpisana w okno czatu, a nikt jej nie wpisywał świadomie.

def zapytaj_model(prompt: str, kontekst_z_sieci: str) -> str:
    if sprawdz(prompt) or sprawdz(kontekst_z_sieci):
        return "Nie mogę przetworzyć tego zapytania."

    odpowiedz = wywolaj_model(prompt, kontekst_z_sieci)

    if sprawdz(odpowiedz):
        return "Odpowiedź została zatrzymana przez filtr."

    return odpowiedz

Ten układ daje trzy wywołania na interakcję i to jest realny koszt, o którym trzeba pamiętać przy liczeniu budżetu i opóźnienia. Przy dużym ruchu warto sprawdzać treść pobraną raz i buforować wynik, bo ta sama strona wraca w wielu zapytaniach.

Co zrobić z wykryciem

Sam sygnał to dopiero połowa pracy. Reakcja na wykrycie jest decyzją produktową, nie techniczną, i warto ją podjąć przed wdrożeniem, a nie w trakcie awarii.

Twarde odrzucenie jest najprostsze i najczęściej stosowane. Użytkownik dostaje komunikat, zapytanie nie idzie dalej. Sprawdza się przy wyraźnych atakach, natomiast przy fałszywym alarmie wygląda jak zepsuta aplikacja i tak jest zgłaszane.

Odrzucenie miękkie polega na przepuszczeniu zapytania z ograniczeniami: bez dostępu do narzędzi, bez danych z bazy, tylko z ogólną odpowiedzią. Użytkownik dostaje coś zamiast ściany, a Ty ograniczasz szkodę. To dobre domyślne zachowanie dla kategorii o wyższym poziomie fałszywych alarmów.

Oznaczenie do przeglądu bez blokowania pasuje tam, gdzie koszt zatrzymania prawdziwego użytkownika jest wysoki, a skutek przepuszczenia ataku ograniczony. Zapisujesz zdarzenie, ktoś je przegląda później.

Osobno traktuj sytuację, w której filtr zadziałał na wyjściu z modelu. Tam wykrycie oznacza, że coś już poszło nie tak wcześniej, więc oprócz zatrzymania odpowiedzi warto zapisać cały kontekst: prompt systemowy, dane pobrane z zewnątrz i pełną odpowiedź. Bez tego nie odtworzysz przebiegu i nie zrozumiesz, którędy weszła instrukcja.

Ostatnia rzecz dotyczy komunikatów. Informowanie użytkownika, którą regułę naruszył i jak dokładnie, ułatwia obejście zabezpieczenia, bo zamienia filtr w narzędzie do eksperymentowania. Komunikat ogólny plus identyfikator zdarzenia w logu daje wsparciu wszystko, czego potrzebuje, a atakującemu nie daje nic.

Lakera Guard kontra alternatywy

Wybór między pierwszym a resztą sprowadza się do jednego pytania: czy chcesz utrzymywać własną warstwę wykrywania. Usługa zewnętrzna aktualizuje się sama i to jest jej główna wartość, bo techniki wstrzykiwania zmieniają się co kilka miesięcy i lista wzorców napisana raz starzeje się szybciej niż większość kodu.

Ceną jest zależność od dostawcy, koszt za wywołanie oraz fakt, że w wariancie chmurowym treść promptów przechodzi przez cudzy serwer. Ten ostatni punkt bywa rozstrzygający, ale da się go zdjąć bez zmiany narzędzia: ten sam produkt wdraża się jako kontener we własnej infrastrukturze. Kosztuje to licencję korporacyjną, więc przy małym budżecie zostaje rozwiązanie otwarte.

Ostatni wiersz warto rozważyć uczciwie, zanim cokolwiek dokupisz. Moderacja wbudowana w API dostawcy modelu łapie treści obraźliwe i to zwykle za darmo, natomiast wstrzyknięć nie wykrywa, bo do tego nie służy.

Cennik, limity i co z tym zrobić

Cennik nie jest publikowany, a po przejściu pod Check Point produkt sprzedaje się w trybie korporacyjnym, więc konkretna kwota pochodzi z rozmowy handlowej i zależy od wolumenu.

Do prób istnieje darmowe konto, wystarczające do sprawdzenia jakości wykrywania na własnych danych, i od tego dobrze jest zacząć niezależnie od dalszych planów. Kilkaset realnych zapytań przepuszczonych przez filtr powie Ci więcej niż jakiekolwiek zestawienie skuteczności, bo Twoje dane rzadko przypominają zbiór testowy.

Osobną pozycją jest wdrożenie u siebie. Kontener uruchamiany Dockerem albo w Kubernetesie z pakietu Helm, z wariantem całkowicie odciętym od sieci włącznie, wymaga licencji korporacyjnej i poświadczeń do rejestru obrazów, więc nie da się go włączyć samodzielnie z darmowego konta. W zamian treść nigdy nie opuszcza Twojej sieci, a punkt końcowy w tej wersji nie używa nawet autoryzacji, bo klucza API po prostu nie ma.

Liczby podawane przez dostawcę, czyli skuteczność powyżej dziewięćdziesięciu ośmiu procent, opóźnienie poniżej pięćdziesięciu milisekund i odsetek fałszywych alarmów poniżej pół procenta, traktuj jako deklarację, nie jako pomiar w Twoim środowisku. Sprawdzenie ich zajmuje popołudnie i jest jedyną wiarygodną podstawą decyzji.

Przy liczeniu kosztu pamiętaj o mnożniku. Interakcja z trzema sprawdzeniami to trzy wywołania, a nie jedno, i przy aplikacji z agentem wykonującym kilka kroków ta liczba rośnie szybciej, niż wynikałoby z liczby rozmów.

Typowe błędy

Pierwszy to sprawdzanie wyłącznie wejścia od użytkownika. Model, który przyjął instrukcję z pobranego dokumentu, ujawni to w odpowiedzi, a tej nikt nie sprawdza.

Drugi to brak limitu czasu i obsługi awarii. Usługa zewnętrzna kiedyś odpowie wolno albo wcale, a wtedy trzeba zdecydować świadomie, czy przepuszczasz ruch, czy blokujesz. Obie odpowiedzi bywają poprawne, natomiast zawieszona aplikacja nie jest żadną z nich.

Trzeci to włączenie blokowania od pierwszego dnia, bez okresu obserwacji. Fałszywe alarmy uderzają wtedy w prawdziwych użytkowników, a Ty dowiadujesz się o tym ze zgłoszeń.

Czwarty to traktowanie filtru jako jedynego zabezpieczenia. Żaden filtr nie łapie wszystkiego, więc agent mający dostęp do usuwania danych albo do wysyłki pieniędzy potrzebuje osobnych ograniczeń uprawnień, niezależnych od tego, co model dostał w prompcie.

Piąty to wysyłanie do usługi zewnętrznej treści, której nie wolno wysyłać. Filtr bezpieczeństwa, który sam wyprowadza dane poza infrastrukturę, rozwiązuje jeden problem i tworzy drugi. Przy danych objętych ograniczeniami masz dwa wyjścia w obrębie tego samego produktu: ograniczyć przetwarzanie do wybranego regionu albo postawić kontener u siebie.

Szósty to brak zapisu wykryć. Bez logów nie wiesz, czy filtr działa, ile blokuje i czy blokuje właściwe rzeczy, więc nie masz podstawy do zmiany ustawień.

FAQ

Czy Lakera Guard to nadal Lakera?

Formalnie produkt nazywa się teraz Check Point AI Guardrails, po przejęciu ogłoszonym we wrześniu 2025 i zamkniętym w październiku. Dokumentacja i punkt końcowy API pozostały pod dawną domeną, więc istniejący kod działa bez zmian.

Ile to kosztuje?

Cennik nie jest publiczny, a sprzedaż po przejęciu odbywa się w trybie korporacyjnym, więc kwotę poznasz w rozmowie handlowej. Do prób i do oceny jakości wykrywania wystarczy darmowy próg.

Czy filtr zatrzyma każde wstrzyknięcie?

Nie. To jest system statystyczny i część prób przechodzi, zwłaszcza nowych albo dostosowanych do konkretnego zabezpieczenia. Traktuj go jako jedną warstwę, a nie jako gwarancję, i ogranicz osobno uprawnienia tego, co model może wykonać.

Czy da się to uruchomić lokalnie?

Tak. Obok wersji chmurowej istnieje wdrożenie we własnej infrastrukturze: kontener pod Dockerem albo w Kubernetesie z pakietu Helm, także w wariancie odciętym od sieci. Wymaga licencji korporacyjnej, więc nie jest to droga na popołudniowy test, ale wtedy treść nie opuszcza Twojej sieci. Jeśli szukasz czegoś darmowego, sięgnij po Guardrails AI albo Presidio do samych danych osobowych.

Jak dobrać czułość, żeby nie blokować zwykłych użytkowników?

Uruchom filtr w trybie obserwacji, zbierz kilka tysięcy realnych zapytań, policz fałszywe alarmy w każdej kategorii i dopiero potem włącz blokowanie, zaczynając od kategorii o najniższym poziomie błędu. Ustawienie dobrane bez tych danych będzie albo zbyt luźne, albo uciążliwe.

Dokumentacja API stoi na stronie z opisem punktów końcowych, a informacja o przejęciu w komunikacie Check Point.