Standard

Bezpieczeństwo LLM

Ten rozdział definiuje minimalny, wykonywalny standard bezpieczeństwa dla systemów, w których modele językowe wpływają na decyzje, treść albo akcje narzędziowe. Trzymamy się podejścia klasycznego: granice zaufania, najmniejsze uprawnienia, bramki kontroli i pełny audyt.

W tym standardzie
  • Model zagrożeń i granice zaufania dla LLM + RAG + narzędzia.
  • Zasady obowiązkowe (MUST) — minimalny poziom higieny.
  • Stos kontroli: bramki, walidacje, DLP, RBAC, cytowania.
  • Audyt i incydenty: co logujemy i jak odtwarzamy zdarzenia.

1. Zakres i definicje

Standard dotyczy systemów produkcyjnych, w których LLM jest elementem procesu (UI, API, automatyzacja, asystent narzędziowy, generowanie treści, wsparcie pracowników). Nie dotyczy prototypów uruchamianych lokalnie bez danych firmowych i bez integracji.

Definicja robocza: „bezpieczeństwo LLM” to zbiór kontroli, które ograniczają wpływ niezaufanego tekstu (promptu, dokumentu, wyniku narzędzia) na zachowanie systemu.

2. Granice zaufania i model zagrożeń

W klasycznych systemach granice zaufania wyznaczają: użytkownik, sieć, baza danych i usługi zewnętrzne. W systemie z LLM dochodzą co najmniej cztery źródła tekstu, które potrafią udawać instrukcje: użytkownik, dokumenty (RAG), wyniki narzędzi oraz pamięć.

Wejście Domyślny status Ryzyko
Użytkownik Niezaufane Prompt injection, eskalacja uprawnień, wymuszenie ujawnienia informacji.
Dokumenty (RAG) Niezaufane (nawet jeśli „nasze”) Indirect injection, wprowadzanie fałszywych instrukcji lub faktów.
Wyniki narzędzi Niezaufane Instrukcje podszyte pod dane; błędy wykonania; manipulacja kontekstem.
Pamięć / notatki Niezaufane i ograniczane Utrwalone reguły „na zawsze”, wycieki, błąd retencji.

Z tego wynika prosta konsekwencja: LLM nie jest „źródłem prawdy”. Jest generatorem propozycji, które muszą przejść przez kontrolę.

3. Zasady obowiązkowe (MUST)

Wymogi minimalne: jeśli którykolwiek punkt poniżej nie jest spełniony, system nie powinien być promowany do produkcji.
(M1) Precedence polityk
Instrukcje systemowe/polityki mają bezwzględny priorytet. Dane nie mogą ich zmieniać.
(M2) Tool Gateway
Wywołania narzędzi przechodzą przez allowlist, RBAC, walidację schematu, limity i audyt.
(M3) DLP i redakcja
Maskowanie PII/secrets przed zapisaniem logów, przed narzędziami i przed odpowiedzią.
(M4) Ślad audytowy
Trace ID, decyzje bramek, wersje polityk, parametry (po redakcji), wynik i błędy.
(M5) Testy regresji
Zestaw ataków i przypadków brzegowych uruchamiany przed wydaniem (CI) i cyklicznie.
(M6) Zasada najmniejszych uprawnień
Model nie posiada „admina”. Uprawnienia wynikają z użytkownika i kontekstu.

4. Stos kontroli: bramki, walidacje, audyt

Dobrą praktyką jest myślenie o zabezpieczeniach jak o „stosie”, w którym każda warstwa przykrywa słabości poprzedniej. Poniższy układ jest prosty, ale skuteczny.

Warstwa 1: Polityka i precedent MUST
Jasne reguły odmowy, priorytety, separacja instrukcji i danych.
Warstwa 2: Tool Gateway MUST
Allowlist, RBAC, walidacje schematu, idempotency, limity, approvals.
Warstwa 3: Dane i DLP MUST
Klasyfikacja danych, redakcja, retencja, „need-to-know” w kontekście.
Warstwa 4: Źródła i cytowania SHOULD
Wiązanie twierdzeń do źródeł; kontrola „braku źródła” jako ryzyka jakości.
Warstwa 5: Audyt i regresje MUST
Trace & replay, dashboardy, alerty, regularne testy i przeglądy.

Uwaga: oznaczenia MUST/SHOULD mają charakter normatywny w sensie organizacyjnym. Nie są gwarancją „braku ryzyka”, ale stanowią minimalny poziom kontroli, który pozwala zarządzać ryzykiem odpowiedzialnie.

5. Incydenty, wyjątki i odpowiedzialność

W praktyce bezpieczeństwo kończy się dopiero wtedy, gdy potrafimy odpowiedzieć na trzy pytania: co się stało, dlaczego system na to pozwolił oraz jak zapobiegniemy powtórce. Dlatego standard wymaga:

  • Rejestru wyjątków (czasowe odstępstwa od polityk, z akceptacją ryzyka).
  • Procesu zmian polityk wraz z testami regresji.
  • Trace & Replay dla incydentów: odtworzenie kontekstu, wersji polityk i bramek.

W praktyce oznacza to powiązanie z rozdziałami: Governance polityk, Zarządzanie wyjątkami oraz Monitoring driftu.

6. Checklista przed produkcją

  1. Zidentyfikowane granice zaufania: user / RAG / tools / memory.
  2. Polityka precedence + reguły odmowy są w system prompt i weryfikowalne w logach.
  3. Tool Gateway: allowlist, RBAC, walidacja schematu, limity, idempotency, audyt.
  4. DLP/PII: redakcja w wejściu, logach i wyjściu; retencja ograniczona.
  5. Zestaw testów regresji obejmuje injection i przypadki brzegowe (CI + cyklicznie).
  6. Trace ID jest propagowany end-to-end (UI/API → bramki → narzędzia → logi).
  7. Zdefiniowano procedurę incydentu i kanał eskalacji (owner + on-call).
  8. Ustalono termin kolejnego przeglądu (review) standardu i polityk.

7. Powiązane

Reguła zdrowego rozsądku

Jeśli „coś” może wpłynąć na zachowanie modelu, to w systemie produkcyjnym musi być traktowane jak wejście z internetu: walidowane, ograniczane i logowane.

Następny krok

Prompt injection to praktyczny test jakości granic zaufania.

Przejdź do Prompt Injection