Polityki kontekstu: jak ograniczać okno kontekstowe, by agent nie „przeciekał” danych między sprawami

1. Wprowadzenie: czym są polityki kontekstu i dlaczego są krytyczne w aplikacjach agentowych

Aplikacje agentowe różnią się od prostych chatbotów tym, że realizują zadania wieloetapowo, często wchodzą w interakcje z narzędziami (np. wyszukiwaniem, bazami danych, systemami ticketowymi) i operują na zmiennym kontekście: historii rozmowy, danych ze sprawy, wynikach narzędzi oraz „pamięci” o użytkowniku. To sprawia, że kontekst staje się jednocześnie źródłem skuteczności i głównym wektorem ryzyka.

Polityki kontekstu to zestaw reguł i mechanizmów, które określają:

• co może trafić do kontekstu modelu (jakie dane i z jakich źródeł),
• kiedy i w jakiej formie jest dołączane (np. pełne treści vs skrót),
• jak długo informacje pozostają dostępne,
• dla kogo są widoczne (granice między użytkownikami, sprawami, rolami),
• jak zapobiega się niepożądanemu mieszaniu wątków i przenoszeniu informacji.

W praktyce polityki kontekstu są odpowiednikiem „zasad higieny danych” dla systemów opartych o modele językowe. Bez nich agent może działać poprawnie w prostych scenariuszach, ale w środowisku produkcyjnym zaczyna zachowywać się jak proces, który przypadkowo dziedziczy fragmenty danych z poprzednich interakcji, narzędzi lub dokumentów.

Dlaczego to krytyczne? Ponieważ okno kontekstowe modelu to obszar, w którym informacje są traktowane jako bezpośrednie wskazówki do działania. Jeśli znajdzie się tam treść niepowiązana ze sprawą, zbyt szeroka, zbyt wrażliwa lub pochodząca z niepewnego źródła, agent może:

• ujawnić dane nie temu odbiorcy,
• podjąć błędne decyzje na podstawie „obcego” kontekstu,
• zafałszować odpowiedź przez zderzenie sprzecznych instrukcji,
• utrwalić niepożądane informacje w swojej pamięci operacyjnej, wpływając na kolejne kroki.

Polityki kontekstu są więc kluczowe z trzech perspektyw:

• Bezpieczeństwo — ograniczają ryzyko ujawnienia danych i nieautoryzowanego przenoszenia informacji między sprawami.
• Jakość — poprawiają trafność odpowiedzi, bo model dostaje tylko to, co rzeczywiście wspiera bieżące zadanie.
• Kontrola kosztów i wydajności — dyscyplinują rozmiar kontekstu, co zmniejsza zużycie tokenów i stabilizuje czas odpowiedzi.

Warto podkreślić, że „kontekst” to nie tylko historia czatu. To także wyniki wyszukiwań, fragmenty dokumentów, metadane sprawy, notatki robocze agenta, a czasem również treści pochodzące od użytkownika, które mogą zawierać instrukcje próbujące zmienić sposób działania systemu. Dlatego polityki kontekstu powinny być projektowane jako warstwa sterowania przepływem informacji: świadomie definiują granice, priorytety i zasady doboru danych, zanim model je zobaczy.

2. Modele zagrożeń: wycieki między sprawami/sesjami, prompt injection i mieszanie kontekstów

W aplikacjach agentowych ryzyko rzadko wynika z pojedynczego „błędu modelu”. Częściej jest skutkiem tego, jak kontekst jest budowany, przechowywany i ponownie używany między kolejnymi interakcjami. Model zagrożeń powinien więc opisywać, kto może dostarczyć treść do kontekstu, co może znaleźć się w pamięci agenta, oraz jak te informacje mogą zostać nieintencjonalnie ujawnione lub użyte w niewłaściwej sprawie. Ten wpis powstał w odpowiedzi na zagadnienia, które regularnie pojawiają się na szkoleniach prowadzonych przez Cognity.

Trzy klasy zagrożeń pojawiają się szczególnie często: wycieki między sprawami/sesjami, prompt injection oraz mieszanie kontekstów. Choć brzmią podobnie, różnią się mechanizmem i punktami kontrolnymi, które warto projektować już na etapie architektury.

Wycieki między sprawami/sesjami

To sytuacje, w których agent ujawnia lub wykorzystuje informacje pochodzące z innej rozmowy, sprawy, użytkownika albo tenant’a. W praktyce oznacza to złamanie oczekiwanej izolacji: użytkownik A otrzymuje odpowiedź, która zawiera dane użytkownika B lub wynikające z jego historii.

Typowe wektory obejmują:

• Współdzieloną pamięć lub cache używany między sesjami bez twardego rozdzielenia zakresów (np. „globalne” notatki agenta).
• Błędne mapowanie identyfikatorów (np. przypisanie wiadomości do niewłaściwej sprawy) lub race conditions w systemach równoległych.
• Nieintencjonalne utrwalenie danych w logach, telemetrii, transkrypcjach, a następnie ich ponowne wciągnięcie do kontekstu podczas obsługi innego zadania.
• Reużycie artefaktów takich jak streszczenia, „profil użytkownika” lub wynik wcześniejszego narzędzia, które nie powinny przechodzić między granicami spraw.

Kluczową cechą tych wycieków jest to, że nie muszą wymagać aktywnego ataku. Często wynikają z domyślnej „wygody” implementacyjnej: pamięć agenta jest traktowana jako wspólna, a nie jako zasób ściśle powiązany z kontekstem uprawnień.

Prompt injection

Prompt injection polega na podstawieniu instrukcji, które mają skłonić model do zachowania sprzecznego z intencją twórców systemu – np. do ujawnienia informacji, pominięcia zasad, wywołania narzędzi w niepożądany sposób lub do „przestawienia” priorytetów instrukcji.

Istotne rozróżnienia w modelu zagrożeń:

• Źródło treści: instrukcja może przyjść nie tylko od użytkownika, ale też z dokumentu, strony WWW, e-maila, pliku PDF czy wyniku wyszukiwania – czyli z danych, które agent ma „przeczytać”.
• Cel ataku: nie chodzi wyłącznie o odpowiedź tekstową. Atak może dążyć do manipulacji decyzją agenta (np. jakie dane pobrać, jakie kroki wykonać, co uznać za prawdę).
• Warstwa skutku: skutkiem może być ujawnienie danych, ale też wykonanie akcji w narzędziach, nieautoryzowane zapytania lub wprowadzenie trwałego „zatrucia” pamięci agenta.

W odróżnieniu od wycieków między sesjami, prompt injection jest zazwyczaj aktywną próbą wpływu na system poprzez treść wciąganą do kontekstu i potraktowaną przez model jako instrukcyjna, a nie informacyjna.

Mieszanie kontekstów

Mieszanie kontekstów to klasa błędów, w której w jednym przebiegu rozumowania agenta łączą się niekompatybilne fragmenty informacji: z różnych spraw, etapów procesu, źródeł o różnych poziomach zaufania lub z różnych ról (np. użytkownik vs. system). Efektem może być odpowiedź, która wygląda wiarygodnie, ale opiera się na „sklejeniu” danych, które nie powinny być zestawione razem.

Do mieszania kontekstów prowadzi najczęściej:

• Zbyt szerokie dobieranie kontekstu: agent dołącza „na wszelki wypadek” wiele treści, zwiększając ryzyko, że coś nieadekwatnego wpłynie na wynik.
• Brak rozróżnienia poziomu zaufania: dokument z Internetu i wewnętrzna notatka trafiają obok siebie bez oznaczenia, co jest źródłem autorytatywnym.
• Przenoszenie stanu zadania: instrukcje lub decyzje z poprzedniego kroku zostają zastosowane do nowego wątku, choć powinny wygasnąć.
• Łączenie kontekstu narzędzi: wyniki różnych narzędzi (np. wyszukiwanie, CRM, baza wiedzy) zostają zestawione bez kontroli spójności i uprawnień.

Ta kategoria jest szczególnie podstępna, bo nie musi skutkować „twardym” ujawnieniem sekretu. Może natomiast powodować nieuprawnione wnioskowanie (np. ujawnienie wrażliwego faktu poprzez połączenie kilku pozornie nieszkodliwych informacji) albo błędne decyzje operacyjne.

Jak te zagrożenia się łączą

W praktyce zagrożenia przenikają się: prompt injection może posłużyć do wymuszenia mieszania kontekstów (np. „dołącz wszystkie wcześniejsze notatki”), a mieszanie kontekstów zwiększa szansę wycieku między sprawami (bo w kontekście pojawiają się dane spoza granicy sesji). Dlatego model zagrożeń powinien jasno definiować granice: granice sesji/sprawy, granice zaufania źródeł oraz granice uprawnień narzędzi – i traktować naruszenie każdej z nich jako osobny scenariusz do zabezpieczenia.

3. Ograniczanie okna kontekstowego: budżet tokenów, selekcja treści, streszczanie i RAG

Ograniczanie okna kontekstowego to zestaw praktyk, które decydują co i w jakiej postaci trafia do promptu. W aplikacjach agentowych ma to dwa cele: (1) utrzymać stabilną jakość odpowiedzi przy skończonym limicie tokenów oraz (2) zmniejszyć ryzyko „przeciekania” informacji przez przypadkowe dołączanie niepowiązanych fragmentów historii, notatek czy wyników narzędzi.

Budżet tokenów jako mechanizm kontroli

Budżet tokenów to jawny podział limitu kontekstu na kategorie treści, np. instrukcje systemowe, bieżące pytanie, wybrane elementy historii, wyniki narzędzi, materiały referencyjne. Zamiast „doklejać wszystko”, agent działa według reguły: jeśli coś nie mieści się w budżecie lub nie przechodzi kryteriów doboru, nie trafia do promptu.

• Stałe rezerwy: utrzymuj minimalną przestrzeń na odpowiedź modelu oraz na krytyczne instrukcje.
• Limity per źródło: osobne limity dla historii rozmowy, dokumentów, logów narzędzi.
• Priorytety: instrukcje i dane do bieżącego zadania wyżej niż tło i „miłe do posiadania” konteksty.

Selekcja treści: co wchodzi do promptu, a co zostaje poza nim

Selekcja treści to polityka wyboru fragmentów kontekstu w oparciu o przydatność i ryzyko. W praktyce oznacza to, że agent nie traktuje historii i pamięci jako jednego worka, tylko wybiera minimalny zestaw informacji potrzebnych do wykonania kroku.

• Relewancja zadaniowa: preferuj fragmenty bezpośrednio odpowiadające na pytanie lub wymagane do następnego działania.
• Świeżość: nowsze informacje zwykle są ważniejsze, ale nie powinny wypierać krytycznych ustaleń.
• Spójność: odrzucaj elementy sprzeczne z aktualnym stanem sprawy, jeśli nie mają potwierdzenia.
• Higiena źródeł: pomijaj nieustrukturyzowane „zrzuty” (np. długie logi), jeśli można je zastąpić krótkim wyciągiem.

Kluczowe jest utrzymanie zasady: brak domyślnego dołączania. Każdy typ kontekstu musi mieć powód, by wejść do promptu.

Streszczanie: kompresja bez utraty tego, co krytyczne

Streszczanie pozwala zmniejszyć objętość kontekstu, ale wprowadza ryzyko: streszczenie może utrwalić błąd lub pominąć szczegół, który później okaże się ważny. Dlatego streszczanie traktuje się jako kompresję z kontraktem: streszczenie ma określony format i zakres.

• Streszczenie rozmowy: zamiana długiej historii na listę ustaleń, otwartych pytań i decyzji.
• Streszczenie artefaktów: skrót dokumentu z punktami „fakty / wymagania / ograniczenia”.
• Streszczenie narzędzi: wyciąg z wyników (np. „3 rekordy znalezione, kluczowe pola…”) zamiast pełnego outputu.

W kontekście ograniczania „przeciekania” ważne jest, by streszczenie usuwało detale nieistotne dla zadania (np. przypadkowe identyfikatory, fragmenty cudzej korespondencji), a zachowywało to, co steruje decyzjami (np. wymagania, definicje, kryteria).

RAG: dostarczaj tylko te źródła, których potrzebujesz

Retrieval-Augmented Generation (RAG) zmienia sposób „karmienia” modelu: zamiast przechowywać duże porcje danych w historii rozmowy, agent pobiera na żądanie małe fragmenty wiedzy z indeksu (np. bazy dokumentów). W efekcie kontekst jest krótszy i bardziej celowany.

• Wąskie konteksty: do promptu trafiają tylko najlepiej dopasowane fragmenty, a nie całe dokumenty.
• Kontrolowane cytowanie: łatwiej narzucić zasadę „odpowiadaj na podstawie dostarczonych źródeł”.
• Aktualność: wiedza może być odświeżana w indeksie bez przepisywania promptów.

RAG bywa łączony ze streszczaniem: pobrane fragmenty mogą być dodatkowo skompresowane do „pakietu dowodów” o stałym rozmiarze tokenów.

Porównanie podejść (kiedy które stosować)

Minimalny przykład: twardy budżet + selekcja

// Pseudokod: składanie promptu z budżetami
budzet = {
  system: 800,
  instrukcje: 400,
  historia: 600,
  narzedzia: 500,
  zrodla: 900,
  rezerwa_na_odpowiedz: 700
}

prompt = []
prompt += take(system_messages, budzet.system)
prompt += take(task_instructions, budzet.instrukcje)

hist = rank_by_relevance(conversation_history, query)
prompt += take(hist, budzet.historia)

tools = summarize_if_needed(tool_outputs)
prompt += take(tools, budzet.narzedzia)

chunks = rag_retrieve(query, k=6)
chunks = rank_by_relevance(chunks, query)
prompt += take(chunks, budzet.zrodla)

assert(tokens(prompt) <= context_limit - budzet.rezerwa_na_odpowiedz)

Taki szkielet wymusza dyscyplinę: każdy element kontekstu konkuruje o miejsce, a do promptu trafia tylko to, co przejdzie selekcję i mieści się w przydzielonym limicie.

4. Izolacja danych: tenanci, separacja wątków/spraw, identyfikatory sesji i kontrola dostępu

W aplikacjach agentowych izolacja danych to zestaw reguł i mechanizmów, które mają zapewnić, że agent operuje wyłącznie na informacjach należących do właściwego użytkownika, organizacji i konkretnej sprawy. W praktyce oznacza to twarde granice między tenantami (organizacjami), sesjami oraz „sprawami” (wątkami zadaniowymi), a także konsekwentne egzekwowanie uprawnień na każdym etapie: od pobierania kontekstu, przez użycie narzędzi, po zapis wyników.

Tenanci (multi-tenant): granica organizacyjna

Tenant to najwyższy poziom separacji — typowo odpowiada organizacji/klientowi. W modelu multi-tenant ryzyko „przecieku” jest najwyższe, bo błędna filtracja może odsłonić dane innego podmiotu. Dlatego tenant powinien być pierwszorzędnym atrybutem w całym systemie: w bazach, indeksach wyszukiwania, pamięci agenta i logach.

• Co izolować: dokumenty, wyniki wyszukiwania, pamięć długotrwałą, historię interakcji, zasoby narzędzi (np. pliki, bilety, rekordy CRM).
• Jak myśleć o granicy: tenant to „osobny świat” — jakakolwiek funkcja pobierająca dane musi umieć odpowiedzieć na pytanie: „z jakiego tenanta wolno mi czytać?”

Separacja wątków/spraw: granica zadaniowa

Nawet w obrębie jednego użytkownika i jednego tenanta agent może prowadzić równolegle wiele tematów. Sprawa (case/thread/matter) to logiczny kontener dla kontekstu i artefaktów dotyczących jednego zadania. Separacja spraw ogranicza mieszanie informacji między tematami oraz przypadkowe „ciągnięcie” kontekstu z poprzedniej rozmowy do nowej. Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności — zwykle dlatego, że granice biznesowe (sprawy) i techniczne (sesje) nie są od początku jasno rozdzielone w projekcie.

• Zastosowanie: obsługa zgłoszeń, analizy dokumentów, przygotowanie oferty, wnioski, audyty — każdy proces jako oddzielna sprawa.
• Minimalna zasada: kontekst i zasoby przypisuj do konkretnego identyfikatora sprawy, a nie tylko do użytkownika.

Identyfikatory sesji: granica „tu i teraz”

Sesja to zazwyczaj krótkotrwały kontekst interakcji (np. pojedyncze okno czatu lub okres aktywności). Identyfikator sesji pozwala odseparować współbieżne rozmowy tego samego użytkownika i zapobiegać sytuacjom, w których wiadomości lub narzędzia „przeskakują” między równoległymi konwersacjami.

• Sesja ≠ sprawa: sesja jest techniczna i krótsza, sprawa jest biznesowa i może trwać dni/tygodnie.
• Wymóg praktyczny: każda operacja odczytu/zapisu kontekstu powinna nieść session_id (i zwykle także case_id), aby uniknąć kolizji.

Kontrola dostępu: egzekwowanie uprawnień na każdym kroku

Izolacja nie zadziała, jeśli opiera się tylko na „umowie” w kodzie aplikacji. Potrzebujesz egzekwowalnej kontroli dostępu, która działa niezależnie od treści promptu i zachowania modelu. Kluczowe jest, aby uprawnienia były sprawdzane przed pobraniem danych i przed wykonaniem akcji w narzędziu.

• Weryfikacja podmiotu: kto żąda (użytkownik/rola/serwis) i w jakim kontekście (tenant/case/session).
• Weryfikacja zasobu: czy dany dokument/rekord/plik należy do tego samego tenanta i jest przypisany do dozwolonej sprawy.
• Zasada najmniejszych uprawnień: agent dostaje tylko te uprawnienia, które są niezbędne do wykonania bieżącego zadania.

Porównanie: tenant vs sprawa vs sesja

Minimalny wzorzec implementacyjny (kontrakt kontekstu)

Dobrym nawykiem jest traktowanie tenant_id, user_id, case_id i session_id jako stałych atrybutów kontekstu wywołania, które przechodzą przez wszystkie warstwy: UI → API → retrieval → narzędzia → pamięć. Poniżej przykład prostego „kontraktu”, który wymusza jawność granic (to tylko szkic, bez detali o pamięci i budżecie kontekstu):

{
  "tenant_id": "...",
  "user_id": "...",
  "case_id": "...",
  "session_id": "...",
  "scopes": ["read:case", "write:case"],
  "request_id": "..."
}

Najważniejsze: żaden komponent nie powinien wykonywać zapytań ani akcji „bez kontekstu” — brak któregoś identyfikatora to sygnał, że operacja jest potencjalnie niebezpieczna i wymaga odrzucenia lub jawnej decyzji.

5. Memory scopes i zarządzanie pamięcią agenta: krótkotrwała vs długotrwała, TTL, pinning i polityki retencji

„Pamięć” agenta to nie tylko to, co mieści się w oknie kontekstowym, ale cały zestaw mechanizmów przechowywania i ponownego przywoływania informacji: od historii bieżącej rozmowy, przez notatki robocze, po trwałe zapisy preferencji użytkownika. Kluczowe jest wprowadzenie memory scopes, czyli zakresów pamięci o jasno zdefiniowanych granicach: co może być zapamiętane, na jak długo, dla kogo i w jakim celu. Dobrze zaprojektowane scope’y minimalizują ryzyko „przeciekania” danych między sprawami, bo ograniczają zarówno zapis, jak i odczyt informacji poza właściwym kontekstem.

5.1. Zakresy pamięci (memory scopes): po co i jak je rozumieć

Memory scope to praktyczna umowa: dane zapisane w danym zakresie mogą być użyte tylko w określonych sytuacjach. Najczęściej spotyka się scope’y odpowiadające poziomom pracy agenta:

• Turn / krok – dane tylko na czas pojedynczej odpowiedzi (np. wyniki pośrednie obliczeń).
• Sesja – dane ważne w ramach jednej rozmowy (np. ustalenia dotyczące bieżącej sprawy).
• Sprawa / wątek – dane wspólne dla kilku sesji, ale tylko dla jednej sprawy (np. numer zgłoszenia, stan realizacji).
• Użytkownik – preferencje i stałe ustawienia, które mogą przetrwać wiele spraw (np. język odpowiedzi).
• Organizacja / tenant – wiedza współdzielona w ramach jednego środowiska (np. wewnętrzne definicje pojęć), bez przenikania na inne środowiska.

W praktyce scope’y powinny być odzwierciedlone w systemie przechowywania (np. osobne kolekcje/namespace’y, osobne klucze) oraz w logice agenta (reguły, kiedy wolno pobierać i łączyć pamięć).

5.2. Pamięć krótkotrwała vs długotrwała: różnice i zastosowania

Podstawowy podział to pamięć krótkotrwała (operacyjna) i długotrwała (persistowana). Ich dobór powinien wynikać z celu biznesowego i ryzyka nadużyć.

W aplikacjach agentowych bezpieczniej jest traktować długotrwałą pamięć jako wyjątek, a nie domyślność. Jeśli system nie ma jasnej potrzeby utrwalania danych, lepszą polityką jest pozostanie przy pamięci krótkotrwałej.

5.3. TTL (time-to-live): automatyczne wygaszanie pamięci

TTL to mechanizm, który nadaje zapisanej informacji datę ważności. Po jej upływie wpis powinien zostać usunięty lub stać się niedostępny dla agenta. TTL jest kluczowy, bo „pamięć bez końca” niemal zawsze prowadzi do nadmiernego gromadzenia danych oraz zwiększa prawdopodobieństwo przypadkowego użycia informacji nieadekwatnej do nowej sprawy.

• TTL per scope – inne czasy dla sesji, sprawy i profilu użytkownika.
• TTL per typ danych – np. krótszy dla danych operacyjnych, dłuższy dla preferencji.
• Odświeżanie TTL – tylko dla danych, które realnie są nadal potrzebne (nie automatycznie dla wszystkiego).

Dobrym standardem jest zasada: jeśli nie potrafisz uzasadnić TTL, nie zapisuj. TTL powinien być elementem definicji memory scope, a nie ustawieniem „na końcu projektu”.

5.4. Pinning: co można „przypiąć” i kiedy

Pinning oznacza oznaczenie wybranych informacji jako szczególnie istotnych, aby nie zostały przypadkowo nadpisane, wyparte przez nowszy kontekst lub usunięte zbyt agresywną polityką czyszczenia. Mechanizm ten bywa potrzebny, ale jest też ryzykowny: „przypięte” dane z definicji częściej wracają do kontekstu, więc mogą zwiększać szanse na niepożądane przeniesienie ustaleń do innej sprawy.

• Pinning preferencji (np. forma odpowiedzi) zwykle jest bezpieczniejszy niż pinning treści sprawy.
• Pinning faktów operacyjnych ma sens tylko, jeśli jest jednoznacznie związany ze scope’em (np. konkretną sprawą) i nie „wędruje” między wątkami.
• Pinning warunkowy – przypięcie obowiązuje tylko w określonym trybie (np. tylko w danej sprawie), a nie globalnie.

Praktyczna zasada: przypinaj jak najmniej i zawsze wraz z metadanymi: zakres, cel, czas obowiązywania oraz źródło.

5.5. Polityki retencji: minimalizm, rozliczalność i kontrola

Retencja określa, jak długo i w jakiej formie przechowujesz pamięć agenta oraz kiedy ją usuwasz lub anonimizujesz. To warstwa ponad TTL: TTL jest technicznym mechanizmem wygaszania wpisów, a polityka retencji jest zestawem reguł organizacyjno-systemowych, które determinują, co w ogóle wolno utrwalać.

• Minimalizm – utrwalaj tylko to, co ma jasno opisany przypadek użycia i niezbędność.
• Rozdział „pamięci” od „logów” – logi służą audytowi i diagnostyce, pamięć ma wspierać działanie agenta; nie powinny się mieszać.
• Prawo do zapomnienia – możliwość usunięcia danych z pamięci (i powiązanych indeksów) na żądanie.
• Wersjonowanie i nadpisywanie – jeśli pamięć zawiera preferencje, musi istnieć sposób ich aktualizacji bez zostawiania „zalegających” sprzecznych wpisów.
• Metadane retencyjne – przy każdym zapisie: scope, właściciel, podstawa przechowywania, TTL/retencja, tag wrażliwości.

5.6. Minimalny szkic implementacyjny (przykład)

Poniższy przykład pokazuje, jak można narzucić scope, TTL i pinning w warstwie zapisu pamięci. To nie jest pełna architektura, a jedynie ilustracja, jak „polityka” może stać się częścią kontraktu danych.

// Pseudokod
function remember(entry) {
  assert(entry.scope in ["turn","session","case","user","tenant"])
  assert(entry.purpose != null)

  // Domyślne TTL per scope
  const ttlByScope = {
    turn:    "5m",
    session: "4h",
    case:    "14d",
    user:    "90d",
    tenant:  "180d"
  }

  // Pinning ograniczamy do wybranych typów
  if (entry.pinned) {
    assert(entry.scope in ["case","user"])      // np. nie pozwalaj na globalny pinning
    assert(entry.pin_expires_at != null)
  }

  entry.expires_at = entry.expires_at ?? now() + ttlByScope[entry.scope]
  entry.meta = {
    scope: entry.scope,
    owner_id: entry.owner_id,
    purpose: entry.purpose,
    sensitivity: entry.sensitivity ?? "unknown",
    pinned: !!entry.pinned
  }

  storage.write(entry)
}

Najważniejsze jest nie tyle API, co konsekwencja: bez scope, TTL i metadanych pamięć staje się „workiem”, z którego agent może zacząć wyciągać nieadekwatne informacje.

6. Redakcja i minimalizacja danych: maskowanie PII/sekretów, klasyfikacja wrażliwości i filtry wyjścia

Redakcja i minimalizacja danych to zestaw praktyk, które ograniczają ilość oraz wrażliwość informacji wpadających do kontekstu i opuszczających system. Celem nie jest „lepsza pamięć” agenta, lecz zmniejszenie ryzyka, że model zobaczy lub ujawni dane, których nie powinien — nawet jeśli pojawi się błąd logiki, nieoczekiwane skojarzenie kontekstu lub próba wymuszenia ujawnienia informacji.

Minimalizacja vs redakcja: dwie różne dźwignie

• Minimalizacja odpowiada na pytanie: czy w ogóle musimy użyć tych danych? Zasada: przekazuj do modelu tylko to, co konieczne do wykonania zadania.
• Redakcja (maskowanie) odpowiada na pytanie: jak bezpiecznie użyć danych, które są potrzebne? Zasada: jeśli dane są potrzebne w logice (np. do dopasowania, walidacji), model nie musi widzieć ich w formie jawnej.

Maskowanie PII i sekretów: co i kiedy ukrywać

PII (dane osobowe) i sekrety (np. klucze API, tokeny sesji, hasła) wymagają szczególnej ostrożności, bo ich ujawnienie ma natychmiastowe skutki: naruszenia prywatności, przejęcia kont, eskalacja uprawnień. Maskowanie polega na zastąpieniu fragmentów tekstu bezpiecznymi reprezentacjami, tak by zachować użyteczność rozmowy, a ograniczyć ryzyko.

• Maskowanie formatowe: zamiana na stałe znaczniki, np. [EMAIL], [PHONE]. Dobre, gdy model ma jedynie „wiedzieć, że coś było”, bez potrzeby odtwarzania.
• Tokenizacja/pseudonimizacja: zamiana na stabilne identyfikatory, np. CUSTOMER_42. Dobre, gdy trzeba zachować spójność w rozmowie (ta sama osoba/obiekt), ale bez ujawniania wartości.
• Skracanie (truncation): pozostawienie fragmentu, np. ostatnie 4 cyfry identyfikatora. Dobre w obsłudze klienta (rozpoznanie) przy mniejszym ryzyku.
• Hashowanie: przydatne do porównań i deduplikacji, ale zwykle ma sens tylko w kontrolowanej logice; nie powinno służyć jako „bezpieczne ujawnienie” w tekście.

W praktyce najbezpieczniej traktować redakcję jako proces dwukierunkowy: (1) przed wysłaniem do modelu oraz (2) przed pokazaniem odpowiedzi użytkownikowi i przed zapisaniem logów.

Klasyfikacja wrażliwości: reguły zamiast intuicji

Żeby minimalizacja i redakcja były konsekwentne, potrzebujesz prostego modelu klasyfikacji danych. Nie musi być rozbudowany — ważne, by był spójny i osadzony w procesach (prompting, narzędzia, logowanie, analityka).

Klasyfikacja może być realizowana regułami (np. wykrywanie wzorców), metadanymi źródła (etykiety dokumentów) lub mieszanie obu podejść. Kluczowe jest, aby decyzja „co wolno pokazać modelowi” nie była każdorazowo podejmowana ad hoc.

Filtry wyjścia: ostatnia linia obrony przed ujawnieniem

Nawet przy dobrej minimalizacji model może spróbować zrekonstruować lub przypadkowo powtórzyć dane w odpowiedzi. Filtry wyjścia to mechanizmy, które analizują wygenerowany tekst przed dostarczeniem go użytkownikowi (oraz przed logowaniem) i blokują, redagują albo wymagają dodatkowej akceptacji, jeśli wykryją niedozwoloną treść.

• Detekcja PII/sekretów: wzorce (np. formaty identyfikatorów), słowniki, reguły kontekstowe.
• Polityki „nie ujawniaj”: np. blokowanie odpowiedzi zawierającej ciągi przypominające tokeny dostępu lub dane logowania.
• Tryb redakcji automatycznej: zamiast blokady, zamiana wykrytych elementów na znaczniki, jeśli to bezpieczne i nie psuje sensu odpowiedzi.
• Tryb eskalacji: wrażliwe przypadki kierowane do ręcznej weryfikacji lub do bezpieczniejszego kanału.

Filtry wyjścia są szczególnie istotne w dwóch sytuacjach: gdy agent pracuje na materiałach pochodzących od użytkowników (nieprzewidywalność danych) oraz gdy agent ma dostęp do systemów wewnętrznych, z których może „przynieść” do odpowiedzi informacje, których nie powinien ujawniać.

Krótki przykład: redakcja przed i po generacji

// Pseudokod: minimalny szkic przepływu
function handleMessage(userText) {
  const cleanedInput = redactPIIAndSecrets(userText); // wejście
  const draft = llm.generate({ prompt: cleanedInput });
  const cleanedOutput = filterAndRedactOutput(draft); // wyjście
  return cleanedOutput;
}

Najważniejsza zasada wdrożeniowa: redakcja i filtry powinny działać systemowo (na poziomie pipeline), a nie być zależne od tego, czy autor promptu „pamiętał dopisać” ograniczenie.

„Context firewall”: walidacja wejścia/wyjścia, sandboxing narzędzi, allowlisty źródeł i polityki kompozycji promptu

Context firewall to zestaw zasad i mechanizmów ochronnych umieszczonych „pomiędzy” użytkownikiem, modelem i narzędziami, których agent używa do wykonania zadania. Jego celem jest ograniczenie ryzyka, że do kontekstu trafią niepożądane treści (np. instrukcje atakującego, dane z innej sprawy, sekrety), a także że model wygeneruje odpowiedź ujawniającą informacje lub inicjującą niebezpieczne działania. W praktyce to warstwa, która nie ufa ani wejściu, ani wyjściu, ani treściom pobieranym z zewnętrznych źródeł.

W odróżnieniu od ogólnych polityk bezpieczeństwa aplikacji, context firewall jest skoncentrowany na kompozycji kontekstu i kontroli przepływu informacji w systemach agentowych: co może zostać dołączone do promptu, jakie narzędzia mogą zostać wywołane, z jakich źródeł wolno korzystać oraz jakie fragmenty odpowiedzi muszą być zablokowane lub przekształcone.

Walidacja wejścia: co wolno wnieść do kontekstu

Walidacja wejścia chroni przed sytuacją, w której użytkownik lub treść z dokumentu/strony wprowadza instrukcje mające zmienić zachowanie agenta (np. nakłaniać do ujawnienia danych albo do wykonania działań poza zakresem). Kluczowe jest rozdzielenie „treści” od „poleceń” oraz wymuszenie, by agent traktował niektóre źródła wyłącznie jako dane, a nie jako nadrzędne instrukcje.

• Normalizacja i kontrola formatu: ograniczanie nietypowych kodowań, ukrytych znaków, wstrzyknięć w metadanych oraz treści, które mogą „udawać” polecenia systemowe.
• Polityki akceptacji treści: dopuszczanie tylko takich typów danych i pól, które są potrzebne do sprawy; odrzucanie nadmiarowych załączników lub nieoczekiwanych sekcji tekstu.
• Wstępna klasyfikacja ryzyka: oznaczanie treści jako potencjalnie wrogiej (np. znalezionej w internecie) i narzucanie ostrzejszych zasad jej użycia w kontekście.

Walidacja wyjścia: co wolno opuścić system

Walidacja wyjścia to kontrola odpowiedzi modelu przed przekazaniem jej użytkownikowi lub przed wykonaniem akcji. Jej zadaniem jest wykrywanie i blokowanie wycieków danych oraz ograniczanie „samowoli” agenta w generowaniu instrukcji operacyjnych, które mogą prowadzić do błędnych lub niebezpiecznych działań.

• Kontrola ujawnień: wykrywanie prób podania sekretów, danych wrażliwych lub fragmentów spoza bieżącej sprawy.
• Egzekwowanie formatu odpowiedzi: dopuszczanie wyłącznie dozwolonych struktur (np. odpowiedź końcowa bez ukrytych poleceń), tak aby model nie mógł „przemycić” dodatkowych instrukcji.
• Polityki odmowy: gdy żądanie dotyczy informacji lub działań zabronionych, system wymusza bezpieczną, konsekwentną odmowę zamiast improwizacji.

Sandboxing narzędzi: ograniczanie skutków działań agenta

Agenci często korzystają z narzędzi: wyszukiwarek, baz danych, systemów plików, poczty, CRM, wykonywania zapytań czy automatyzacji. Sandboxing polega na takim ujęciu tych narzędzi, by nawet w razie błędnej decyzji modelu (lub skutecznego ataku na prompt) szkody były ograniczone.

• Minimalne uprawnienia: narzędzia udostępniają tylko te operacje, które są konieczne dla danej sprawy, bez „uniwersalnego dostępu”.
• Ograniczenia wykonania: limity czasu, liczby wywołań, zakresu danych, a także blokady działań nieodwracalnych lub kosztownych bez dodatkowej weryfikacji.
• Izolacja środowiska: oddzielenie kontekstu i zasobów, tak aby agent nie mógł swobodnie przeskakiwać między obszarami danych lub używać narzędzi jako kanału bocznego.

Allowlisty źródeł: skąd agent może brać informacje

Allowlisty (listy dozwolonych źródeł) ograniczają ryzyko, że agent oprze się na treściach podstawionych, niezweryfikowanych lub zbyt szerokich. To szczególnie ważne, gdy agent pobiera dokumenty lub przeszukuje zasoby, w których mogą znajdować się instrukcje wrogie lub dane niepowiązane ze sprawą.

• Dozwolone domeny i repozytoria: agent korzysta wyłącznie z zatwierdzonych lokalizacji, a pozostałe traktuje jako niedozwolone lub wymagające ręcznej akceptacji.
• Dozwolone typy dokumentów: ograniczenie formatów oraz kanałów dostępu, aby zmniejszyć powierzchnię ataku i przypadkowe włączenie treści ubocznych.
• Reguły kontekstowe: to, co jest dozwolone, zależy od rodzaju sprawy i uprawnień; inne źródła mogą być dostępne tylko w trybie „tylko do odczytu” lub w ogóle.

Polityki kompozycji promptu: jak składać kontekst, by nie mieszać ról i danych

Polityki kompozycji promptu określają, jak układać elementy kontekstu (instrukcje systemowe, reguły, dane sprawy, wyniki narzędzi, treść użytkownika) tak, aby model nie traktował danych jak poleceń i nie nadawał zewnętrznym treściom niewłaściwego priorytetu.

• Hierarchia i separacja: stałe instrukcje bezpieczeństwa muszą mieć pierwszeństwo, a dane z dokumentów i internetu powinny być jednoznacznie oznaczone jako cytowane treści.
• Kontrakty narzędziowe: wyniki narzędzi są wprowadzane do kontekstu w formie, która minimalizuje ryzyko, że zawierają one „polecenia” dla modelu; agent ma je interpretować jako dane.
• Blokady mieszania spraw: do promptu trafiają tylko elementy powiązane z bieżącą sprawą, a każdy wtręt spoza niej jest traktowany jako błąd kompozycji i odrzucany.

Dobrze zaprojektowany context firewall działa jak praktyczna bariera: ogranicza, co może wejść do kontekstu, co może z niego wyjść oraz jakie działania mogą zostać wykonane. Dzięki temu nawet w obliczu nieprzewidywalnych zachowań modelu ryzyko „przeciekania” danych i niepożądanych akcji jest istotnie mniejsze.

8. Przykładowe polityki oraz testy bezpieczeństwa: scenariusze, testy regresji, monitoring i audyt

Polityki kontekstu są skuteczne tylko wtedy, gdy da się je jednoznacznie zdefiniować, przetestować i stale weryfikować w warunkach zbliżonych do produkcyjnych. W aplikacjach agentowych ryzyko nie wynika wyłącznie z błędnej konfiguracji, ale też z nieprzewidywalnych interakcji: użytkownik–model–narzędzia–źródła danych. Dlatego praktyka bezpieczeństwa powinna łączyć: proste, egzekwowalne reguły (polityki), zestaw scenariuszy ataków i nadużyć (testy), oraz ciągłą obserwowalność (monitoring i audyt).

Polityki opisują, co jest dozwolone w kontekście (np. jakie dane mogą być wprowadzone do promptu, z jakich źródeł wolno korzystać, jakie typy pamięci są dostępne). Testy bezpieczeństwa sprawdzają, czy agent rzeczywiście tych reguł przestrzega w sytuacjach granicznych, w tym przy celowo złośliwych wejściach. Monitoring i audyt pozwalają wychwycić odchylenia, które nie zostały przewidziane w testach, oraz dostarczyć ślad dowodowy zgodności i incydentów.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Przykładowe polityki: co warto ustandaryzować

Poniższe przykłady to typowe „klocki” polityk, które można wdrożyć niezależnie od stosu technologicznego. Ich celem jest ograniczanie ryzyka „przeciekania” informacji między sprawami oraz zmniejszenie powierzchni ataku.

• Polityka minimalnego kontekstu: do modelu trafia wyłącznie to, co jest konieczne do rozwiązania bieżącej sprawy; wszelkie dane „na wszelki wypadek” są odrzucane.
• Polityka źródeł: agent może cytować i wykorzystywać tylko treści pochodzące z określonych kategorii źródeł (np. repozytoria wewnętrzne, wybrane indeksy wyszukiwania), a inne traktuje jako niewiarygodne lub niedozwolone.
• Polityka granic sprawy: każda sprawa ma formalne granice (identyfikator, zakres, role) i agent nie może korzystać z danych poza nimi, nawet jeśli „pamięta” je z wcześniejszych interakcji.
• Polityka klasy danych: określa, które klasy informacji mogą wejść do kontekstu, które tylko do przetwarzania lokalnego, a które nigdy nie powinny zostać ujawnione w odpowiedzi.
• Polityka narzędzi: które narzędzia agent może wywoływać w danej sprawie, z jakimi parametrami i limitami (np. zakres wyszukiwania, uprawnienia, limity zapytań).
• Polityka odpowiedzi: wymusza, aby agent nie ujawniał danych wrażliwych, nie „dopowiadał” braków danymi z innych spraw oraz jasno sygnalizował ograniczenia, gdy brakuje kontekstu.

Kluczowa różnica między tymi politykami a ogólnymi „zasadami bezpieczeństwa” polega na tym, że są one operacyjne: dają się sprawdzić w testach, wymusić w runtime i udokumentować w audycie.

Scenariusze testowe: co symulować, by wykryć wycieki między sprawami

Skuteczne scenariusze testowe są krótkie, powtarzalne i celują w konkretne mechanizmy wycieku. W praktyce warto utrzymywać bibliotekę przypadków obejmującą co najmniej:

• Wycieki między sesjami: użytkownik w nowej sprawie próbuje skłonić agenta do odtworzenia informacji z poprzedniej rozmowy (np. „przypomnij, co ustaliliśmy wczoraj”). Test powinien sprawdzić, czy odpowiedź jest odmowna lub neutralna, jeśli brak uprawnień lub brak kontekstu.
• Mieszanie kontekstów przez podobieństwo: dwie sprawy mają podobne nazwy/tematy, a agent ma pokusę połączyć je w jedną narrację. Test sprawdza, czy agent rozdziela fakty per sprawa, zamiast „zszywać” wątki.
• Wstrzykiwanie instrukcji w treści źródłowe: agent pobiera dokument, który zawiera polecenia mające zmienić zachowanie (np. nakaz ujawnienia danych). Test sprawdza, czy takie instrukcje są ignorowane, a dokument traktowany wyłącznie jako dane.
• Ataki eskalacji przez narzędzia: użytkownik namawia agenta, by użył narzędzia poza zakresem sprawy lub zbyt szerokim filtrem. Test weryfikuje, czy agent nie potrafi „wyprosić” sobie dodatkowych uprawnień samą treścią promptu.
• Ujawnienie kontekstu systemowego: prośby o pokazanie promptu, polityk, identyfikatorów, list źródeł czy „co masz w pamięci”. Test sprawdza, czy agent nie zwraca treści wewnętrznych, które ułatwiają obejście zabezpieczeń.
• Granice cytowania: agent ma streszczać lub odpowiadać na pytania, ale nie wolno mu kopiować wrażliwych fragmentów. Scenariusz sprawdza, czy odpowiedź nie zawiera dosłownych wycinków niedozwolonych klas danych.

Ważne jest, aby scenariusze obejmowały zarówno zachowania „naiwne” (przypadkowe pomyłki modelu), jak i „wrogie” (celowa manipulacja). Dzięki temu testy wykrywają nie tylko błędy w politykach, ale też nieoczywiste ścieżki, w których agent sam łączy tropy.

Testy regresji: jak utrzymać bezpieczeństwo mimo zmian

W agentach ryzyko regresji jest wysokie, bo zmiany mogą pochodzić z wielu miejsc: nowe źródła, nowe narzędzia, modyfikacje promptów, aktualizacje modelu, parametryzacja pamięci. Testy regresji powinny być uruchamiane cyklicznie i po każdej istotnej zmianie, a ich wynik ma być binarny: polityki są spełnione albo nie.

• Stabilny zestaw przypadków: ten sam korpus scenariuszy musi być wykonywany wielokrotnie, aby porównywać wyniki w czasie.
• Kryteria akceptacji: dla każdego scenariusza trzeba z góry określić, co jest niedozwolone (np. pojawienie się danych z innej sprawy, zbyt długi cytat, ujawnienie identyfikatorów).
• Testy deterministyczne tam, gdzie to możliwe: weryfikacja powinna opierać się o jasne sygnały polityk (np. klasyfikacja odpowiedzi jako „zawiera/nie zawiera” wrażliwych danych), a nie o subiektywną ocenę stylu.
• Priorytetyzacja: najpierw przypadki dotyczące wycieków między sprawami i eskalacji dostępu, dopiero potem jakość merytoryczna.

Celem regresji nie jest pełne „udowodnienie” bezpieczeństwa, tylko szybkie wychwycenie, że nowa wersja systemu zaczęła zachowywać się inaczej wobec tych samych prób naruszenia.

Monitoring: sygnały ostrzegawcze w działaniu produkcyjnym

Nawet najlepsze testy nie pokryją wszystkich kombinacji wejść i źródeł. Monitoring powinien więc wykrywać wzorce wskazujące na ryzyko wycieku lub niepożądane mieszanie kontekstów.

• Alerty na anomalie kontekstowe: nagły wzrost rozmiaru kontekstu, częste dołączanie dużych fragmentów dokumentów, wzrost liczby odwołań do zewnętrznych źródeł.
• Wzorce podejrzanych intencji: prośby o ujawnienie „pamięci”, promptu systemowego, polityk, kluczy, logów, list indeksów lub parametrów narzędzi.
• Telemetryka narzędzi: nietypowe wywołania narzędzi (szerszy zakres niż zwykle, inna kategoria zasobów, nietypowa częstotliwość) mogą sygnalizować próbę eskalacji.
• Oznaczanie ryzyka odpowiedzi: flagi „możliwy wyciek”, „możliwa treść wrażliwa”, „odpowiedź spoza zakresu sprawy” jako sygnał do automatycznego zatrzymania lub ręcznej weryfikacji.

Monitoring powinien wspierać zarówno reakcję w czasie rzeczywistym (blokada, eskalacja), jak i analizę trendów, które wskazują, że polityki wymagają korekty.

Audyt: dowody, rozliczalność i ścieżka incydentu

Audyt w kontekście agentów ma dwa cele: rozliczalność (kto i dlaczego uzyskał dostęp do danych) oraz rekonstrukcję incydentu (jak doszło do wycieku). W praktyce audyt powinien obejmować ślad decyzji o dołączeniu kontekstu i użyciu narzędzi, a nie tylko finalne odpowiedzi.

• Ślad sprawy: identyfikator sprawy/sesji, czas, rola i zakres uprawnień oraz zestaw źródeł, z których agent korzystał.
• Ślad kompozycji odpowiedzi: jakie typy danych wpłynęły na odpowiedź (np. pamięć krótkotrwała, dokumenty, wyniki narzędzi), bez konieczności logowania pełnych treści wrażliwych.
• Ślad blokad i wyjątków: kiedy polityka zadziałała (np. odmowa, redakcja), oraz co ją wywołało.
• Retencja i dostęp do logów: zasady przechowywania i udostępniania audytu muszą być spójne z wymaganiami prywatności i minimalizacji danych.

Dobrze zaprojektowany audyt ogranicza „ślepe plamy” i pozwala poprawiać polityki na podstawie faktów: które scenariusze pojawiają się w realnym ruchu, gdzie agent najczęściej przekracza granice sprawy i jakie źródła generują najwięcej ryzyka.

Hardening endpointów agentów: rate limits, budżety tokenów i „circuit breaker” na dziwne sesje 29 kwietnia 2026

Agent AI do obsługi faktur: architektura „extract-validate-post” z progami pewności i ścieżką eskalacji 27 kwietnia 2026