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

1. Wprowadzenie: dlaczego hardening endpointów agentów jest krytyczny

Endpoint agenta (np. API czatu, webhook, punkt integracyjny w aplikacji) przestaje być „zwykłym” interfejsem do modelu językowego, gdy agent zyskuje dostęp do narzędzi, danych i możliwości wykonywania działań. Od tego momentu każde żądanie użytkownika może uruchomić łańcuch decyzji, kolejne wywołania usług oraz pobieranie lub zapisywanie informacji. To sprawia, że endpoint staje się elementem o podwyższonym ryzyku: łączy w sobie ekspozycję na internetowy ruch, nieprzewidywalność językowego wejścia oraz realne skutki po stronie systemów biznesowych.

Hardening endpointów agentów to zestaw praktyk, które ograniczają skutki nadużyć i awarii poprzez kontrolę: kto i jak często może wywoływać agenta, ile zasobów może on zużyć oraz kiedy system powinien odmówić dalszego działania lub przejść w tryb bezpieczny. To nie jest „optymalizacja wydajności” na końcu projektu, tylko warstwa bezpieczeństwa i niezawodności, która w agentach jest równie ważna jak uwierzytelnianie czy kontrola dostępu.

W przeciwieństwie do klasycznych endpointów backendowych, gdzie koszt pojedynczego requestu bywa względnie przewidywalny, koszt żądania do agenta potrafi rosnąć nieliniowo. Jedno zapytanie może wygenerować długą odpowiedź, wielokrotne odwołania do narzędzi, iteracyjne „myślenie” albo nieoczekiwaną eskalację do bardziej kosztownego trybu pracy. Dodatkowo użytkownik może celowo lub przypadkowo podać dane, które wywołają niepożądane zachowanie: od generowania ogromnych kontekstów po podejmowanie działań w systemach zewnętrznych.

Dlatego w kontekście agentów trzeba traktować endpoint jak granicę ochronną, która pilnuje trzech kluczowych obszarów:

• Dostęp i uczciwe współdzielenie zasobów – aby pojedynczy użytkownik, tenant lub zautomatyzowany klient nie zdominował przepustowości i kosztów całej usługi.
• Kontrola kosztu i czasu pracy – aby odpowiedzi nie przeradzały się w „runaway” procesy, a budżet tokenów i wywołań narzędzi pozostawał przewidywalny.
• Ograniczanie skutków zachowań nietypowych – aby system potrafił wykryć anomalie i bezpiecznie zareagować, zanim dojdzie do degradacji jakości, przestojów lub incydentu bezpieczeństwa.

Hardening endpointów agentów jest krytyczny, bo łączy w jednym miejscu kilka rodzajów ryzyka: ryzyko finansowe (koszty tokenów i integracji), ryzyko operacyjne (przeciążenia i kolejki), ryzyko bezpieczeństwa informacji (wrażliwe dane w kontekście), a także ryzyko funkcjonalne (agent podejmujący niepożądane działania). Dobrze zaprojektowane ograniczenia nie mają „blokować użytkowników”, lecz zapewniać przewidywalność: stabilny czas odpowiedzi, kontrolowany koszt, oraz zachowanie spójnego poziomu jakości nawet przy skokach ruchu lub nietypowych sesjach.

W praktyce hardening opiera się na kilku uzupełniających się mechanizmach: ograniczaniu częstotliwości i przepustowości wywołań, budżetach zużycia (np. tokenowych), limitach działań agenta w narzędziach oraz automatycznym odcinaniu podejrzanych lub niebezpiecznie „rozpędzonych” sesji. Ich wspólnym celem jest zbudowanie bezpiecznej, odpornej granicy między nieprzewidywalnym wejściem językowym a kosztownymi lub wrażliwymi zasobami po stronie systemu.

2. Model zagrożeń i typowe scenariusze ataków/awarii

Endpoint agenta to nie tylko „API do generowania tekstu”, ale w praktyce brama do zasobów: modeli, narzędzi (np. wyszukiwanie, bazy danych, integracje), pamięci konwersacji oraz budżetu kosztowego i czasowego. Model zagrożeń dla takich endpointów musi więc uwzględniać zarówno klasyczne ryzyka API, jak i specyficzne dla agentów zjawiska: sterowanie zachowaniem przez treść, łańcuchy wywołań narzędzi oraz nieprzewidywalne ścieżki wykonania. Z doświadczenia szkoleniowego Cognity wiemy, że ten temat budzi duże zainteresowanie – również wśród osób zaawansowanych. Poniżej zarys kluczowych kategorii zagrożeń i najbardziej typowych scenariuszy.

Powierzchnia ataku: co realnie może zostać wykorzystane

• Wejścia użytkownika i kontekst sesji: prompt, załączniki, metadane, historia rozmowy, parametry sterujące.
• Warstwa orkiestracji agenta: planowanie kroków, wybór narzędzi, pamięć, stan workflow.
• Narzędzia i integracje: wywołania zewnętrznych API, dostęp do danych, operacje o skutkach ubocznych (zapisy, wysyłki, akcje administracyjne).
• Zasoby współdzielone: limity konta/tenantów, kolejki, współdzielone cache, klucze API, pule połączeń.
• Koszty i wydajność: tokeny, czas inferencji, liczba wywołań narzędzi, retry, równoległość.

W agentach szczególnie ważne jest rozdzielenie dwóch pojęć: złośliwy użytkownik (intencjonalny atak) oraz „złośliwe wejście” (treść, która przypadkiem lub przez skażenie danych powoduje szkodliwe zachowanie). Obie sytuacje mogą prowadzić do podobnych skutków.

Abuse: nadużycia funkcji i kosztów

Abuse to szeroka kategoria obejmująca wykorzystanie endpointu do celów niezgodnych z założeniami, często bez łamania „technicznych” zabezpieczeń. W agentach przybiera typowo formę kosztowego lub operacyjnego drenowania zasobów.

• Eksploatacja do masowej produkcji treści: automatyzacja generowania, scraping odpowiedzi, farmienie outputu pod kolejne procesy.
• Obchodzenie ograniczeń produktowych: tworzenie wielu kont, rotacja kluczy, manipulacja parametrami sesji, „rozdrabnianie” zadań na wiele żądań.
• Wymuszanie drogich ścieżek: prośby o bardzo długie odpowiedzi, wielokrotne doprecyzowania, eskalowanie do bardziej kosztownych narzędzi.
• Wykorzystanie integracji jako proxy: zlecanie agentowi akcji, które przenoszą koszty lub ryzyko na operatora (np. intensywne zapytania do zewnętrznych usług).

Skutkiem jest zwykle niekontrolowany wzrost kosztów, spadek jakości usług dla innych oraz przeciążenie elementów infrastruktury, które same w sobie nie były projektowane pod taki profil obciążenia.

Prompt injection: sterowanie agentem przez treść

Prompt injection dotyczy sytuacji, w której treść wejściowa (od użytkownika lub z danych zewnętrznych) wpływa na zachowanie agenta w sposób sprzeczny z intencją systemu. W agentach jest to szczególnie niebezpieczne, bo agent często podejmuje decyzje i wykonuje działania, a nie tylko generuje tekst.

• Bezpośrednia injekcja: użytkownik próbuje nadpisać zasady („zignoruj instrukcje”, „ujawnij sekrety”, „wykonaj to narzędzie”).
• Pośrednia injekcja: agent pobiera treści z zewnętrznych źródeł (strony, dokumenty, e-maile) zawierające ukryte instrukcje, które stają się częścią kontekstu decyzyjnego.
• Wymuszenie nadużyć narzędzi: prowokowanie agenta do wywołań o skutkach ubocznych, nieadekwatnych do prośby użytkownika.
• Wycieki danych: skłonienie agenta do ujawnienia fragmentów kontekstu, pamięci sesji, danych z narzędzi lub informacji specyficznych dla innego użytkownika/tenant.

Kluczowa różnica względem klasycznych podatności webowych jest taka, że „payload” nie musi łamać parsera ani wykonywać kodu w systemie — wystarczy, że zmieni priorytety i decyzje agenta albo sprawi, że agent potraktuje nieufną treść jako polecenie.

DoS i degradacja usług: od przeciążenia po kaskady awarii

DoS w kontekście endpointów agentów to nie tylko zalew requestów. Często równie groźne są scenariusze, w których pojedyncze żądania są „ciężkie” albo uruchamiają łańcuchy działań.

• Wysokie RPS: wiele żądań na sekundę z botów, skryptów lub błędnie skonfigurowanych klientów.
• Wysoki koszt pojedynczego żądania: długie konteksty, złożone zadania, wielokrotne narzędzia, długie czasy odpowiedzi.
• Retry storm: agresywne ponawianie po błędach lub timeoutach, potęgujące przeciążenie.
• Kolejki i blokady zasobów: zapychanie workerów, wyczerpanie puli połączeń, saturacja zależności (np. bazy, wektorowego wyszukiwania, zewnętrznych API).
• Efekt domina: spowolnienie jednego komponentu zwiększa czasy odpowiedzi, co zwiększa liczbę timeoutów i retry, co dalej zwiększa obciążenie.

Typowy skutek to degradacja SLO (latencja, błędy), utrata przewidywalności kosztów oraz sytuacje, w których „zdrowe” żądania przestają być obsługiwane przez brak izolacji zasobów.

Runaway agents: pętle, eskalacje i niekontrolowane workflow

Runaway agent to awaria, w której agent wpada w pętlę lub nadmiernie rozbudowuje plan działania. Może to być wywołane złośliwym promptem, niejednoznaczną instrukcją, błędem w orkiestracji, a także nietypową odpowiedzią narzędzia.

• Pętle narzędzi: agent powtarza te same zapytania (np. „spróbuj ponownie”) bez kryterium stopu.
• Rozrost planu: agent dodaje kolejne kroki „dla pewności”, eskalując koszt bez proporcjonalnego wzrostu wartości.
• Nadmierna równoległość: uruchamianie wielu podzadań jednocześnie, co prowadzi do skokowego zużycia limitów i zasobów.
• „Zatrucie” pamięci: błędne wnioski trafiają do pamięci/stanów i utrwalają niewłaściwe zachowanie w kolejnych turach.

To ryzyko jest specyficzne dla agentów, bo system sam inicjuje kolejne działania. W efekcie nawet pojedyncza sesja może stać się źródłem dużego obciążenia i kosztów, a także generować trudne do przewidzenia skutki uboczne.

Awaria bez ataku: błędy integracji i nieprzewidywalne dane

W praktyce wiele incydentów nie wynika z intencji atakującego, lecz z „normalnych” problemów produkcyjnych, które w agentach mają większy promień rażenia.

• Niekompatybilne odpowiedzi narzędzi: zmiana formatu, brak pól, nietypowe kody błędów, długie payloady.
• Skoki latencji zależności: spowolnienie zewnętrznego API powoduje zawieszanie workflow i narastanie kolejek.
• Błędne uprawnienia: źle przypisane zakresy dostępu, mieszanie kontekstów użytkowników, pomyłki w identyfikacji tenantów.
• Dane „toksyczne”: treści, które wyzwalają niepożądane reakcje (np. instrukcje w dokumentach), mimo że pochodzą z legalnych źródeł.

Wniosek z modelu zagrożeń jest prosty: endpoint agenta trzeba traktować jak system wykonujący procesy na bazie treści i zależności, a nie jak statelessowy endpoint. To przesuwa akcent z samej walidacji wejścia na kontrolę kosztu, tempa, uprawnień oraz zachowania w nietypowych sesjach.

3. Projektowanie limitów per user/tenant: metryki, priorytety, fair-use i izolacja zasobów

Limity per user/tenant to warstwa kontroli, która odpowiada na pytanie: ile zasobów może zużyć dany użytkownik lub organizacja, niezależnie od tego, jak wygląda chwilowy ruch. Dobrze zaprojektowane limity ograniczają „hałaśliwych sąsiadów”, stabilizują koszty i pomagają utrzymać przewidywalną jakość usług dla całej platformy. W odróżnieniu od limitów stricte „na sekundę/minutę”, limity per user/tenant skupiają się na sprawiedliwym podziale i izolacji zasobów między podmiotami.

3.1. Co właściwie limitujemy? Podstawowe metryki

W systemach agentowych pojedyncze żądanie może uruchamiać narzędzia, pobierać kontekst, iterować i generować długie odpowiedzi. Dlatego limity warto oprzeć o metryki bliższe rzeczywistemu zużyciu:

• Tokeny (wejściowe i wyjściowe): najbardziej bezpośredni proxy kosztu i obciążenia modeli.
• Czas obliczeń / latency budget: np. maksymalny łączny czas pracy agenta dla sesji lub użytkownika.
• Równoległość: liczba jednoczesnych sesji/uruchomień agenta dla user/tenant.
• Wywołania narzędzi: ile razy agent może sięgnąć po zewnętrzne API, bazę, wyszukiwarkę itp.
• Przepustowość danych: np. limit rozmiaru pobieranych dokumentów lub liczby załączników.
• Budżet kosztowy: przeliczenie zasobów na walutę rozliczeniową (kredyty, punkty, PLN/USD) na poziomie tenant.

Dobór metryk powinien odzwierciedlać to, co w Twoim systemie jest „wąskim gardłem”: GPU/CPU, koszty LLM, limity zewnętrznych dostawców, czy ryzyko przeciążenia narzędzi.

3.2. Granularność: user, tenant, workspace, aplikacja

Projektując limity, wybierz poziomy, na których chcesz egzekwować kontrolę:

• Per user – chroni przed nadużyciami pojedynczych kont i stabilizuje UX.
• Per tenant – zapewnia przewidywalność kosztów oraz izoluje organizacje między sobą.
• Per workspace/projekt – pozwala rozdzielać budżety między zespoły.
• Per aplikacja/klient (np. klucz API) – odcina ryzyko integracji generującej nadmiar ruchu.

Praktycznie często stosuje się limity zagnieżdżone: żądanie musi przejść zarówno kontrolę per user, jak i per tenant. Dzięki temu pojedynczy użytkownik nie „zjada” budżetu całej organizacji, a jednocześnie tenant nie przekracza globalnych założeń kosztowych.

3.3. Priorytety i klasy usług (QoS)

Nie wszystkie obciążenia są równie ważne. Warto zdefiniować klasy usług, które determinują priorytet w dostępie do zasobów:

• Interaktywne (chat, asystent w UI): niski czas odpowiedzi, twardsze limity na latencję, ograniczona równoległość.
• Wsadowe (batch, raporty, indeksowanie): większa tolerancja na opóźnienia, można kolejkować i ograniczać priorytet.
• Krytyczne (operacje administracyjne, bezpieczeństwo): najwyższy priorytet i osobne rezerwy.

Priorytety powinny działać zarówno w ramach tenant (np. interaktywne wygrywa z batch), jak i między tenantami (np. plan enterprise vs free). Kluczowe jest jednak utrzymanie minimalnej jakości dla wszystkich: priorytety nie mogą oznaczać „zagłodzenia” niższych klas.

3.4. Fair-use: zasady, które są zrozumiałe i egzekwowalne

Fair-use ma dwa cele: (1) zapewnić uczciwy podział zasobów, (2) dać użytkownikom przewidywalność. Dobre zasady fair-use są proste, mierzalne i powiązane z komunikatami w produkcie:

• Jasne limity okresowe: dzienne/tygodniowe/miesięczne budżety dla user/tenant.
• Miękkie progi: ostrzeżenia i degradacja zamiast natychmiastowej blokady (tam, gdzie to bezpieczne).
• Uzasadnione wyjątki: proces podniesienia limitu, osobne pule dla zaufanych integracji.
• Transparentność: możliwość podglądu wykorzystania (np. „zużyto 70% budżetu tokenów w tym miesiącu”).

Ważne: fair-use powinno być spójne z modelem billingowym. Jeśli rozliczasz tokeny, limituj tokeny; jeśli rozliczasz „zadania”, limituj zadania, ale nadal monitoruj tokeny jako metrykę techniczną.

3.5. Izolacja zasobów: ochrona przed „noisy neighbor”

Izolacja oznacza, że intensywne użycie przez jednego tenanta nie degraduje systemu dla innych. Najczęściej realizuje się to przez:

• Oddzielne pule (quotas) dla tenantów lub planów (np. rezerwacja minimalnej przepustowości).
• Limity równoległości per tenant, aby nie „zalać” wspólnych workerów.
• Wydzielenie kolejek dla klas ruchu (interaktywne vs batch) i/lub tenantów o wysokim SLA.
• Ograniczenia na zasoby współdzielone: cache, wektorowe wyszukiwanie, narzędzia zewnętrzne.

Izolacja to nie tylko stabilność, ale też bezpieczeństwo kosztowe: pozwala utrzymać górne granice wydatków nawet przy nagłym skoku użycia w jednym segmencie.

3.6. Matryca limitów: przykładowe kategorie i zastosowania

3.7. Krótki szkic implementacyjny (bez wchodzenia w mechanikę egzekwowania)

Na poziomie projektu warto rozdzielić trzy elementy: identyfikację podmiotu (user/tenant), politykę limitów (konfiguracja), oraz księgowanie zużycia (metryki). Poniższy pseudokod pokazuje ideę oceny żądania względem wielu limitów:

// Pseudokod: decyzja o dopuszczeniu żądania
ctx = { tenantId, userId, workloadClass }
policy = loadPolicy(ctx)
usage  = loadUsage(ctx)

checks = [
  { key: "tenant.tokens.month",   need: estTokens(req),  have: policy.tenantTokenBudget - usage.tenantTokensMonth },
  { key: "user.concurrent",       need: 1,              have: policy.userConcurrentLimit - usage.userConcurrentNow },
  { key: "tenant.toolCalls.hour", need: estToolCalls(req), have: policy.tenantToolCallsHour - usage.tenantToolCallsHour }
]

if any(check.have < check.need):
  denyOrDegrade(req, reason=firstFailKey(checks))
else:
  accept(req)

Kluczowe jest, by polityki były konfigurowalne (np. per plan, per tenant) oraz by estymacje (np. tokenów) były wystarczająco konserwatywne, aby nie dopuszczać zadań, których system nie będzie w stanie „dowieźć” w ramach budżetu.

4. Rate limiting i kontrola przepustowości: limity żądań, okna czasowe, bursty, kolejki i retry

Endpointy agentów (zwłaszcza te, które inicjują wykonania narzędzi, generacje LLM lub dłuższe sesje) są podatne na przeciążenia bardziej niż klasyczne API: jedno „pozornie małe” żądanie może uruchomić kosztowny łańcuch działań. Dlatego rate limiting (ograniczanie tempa) i kontrola przepustowości (zarządzanie tym, ile pracy system wykonuje w czasie) powinny być traktowane jako pierwsza linia obrony stabilności i kosztów.

Rate limiting vs. throttling vs. quota — co i po co?

W praktyce te pojęcia bywają mieszane, ale warto rozróżnić ich intencję:

W tej sekcji skupiamy się na mechanice tempa (rate) i przepustowości, a nie na pełnych budżetach kosztowych.

Limity żądań: co limitować (i na jakim kluczu)?

Najczęstszy błąd to limitowanie tylko po IP. Dla agentów sensowne jest limitowanie na kilku osiach równolegle:

• Per user (użytkownik końcowy) – chroni przed nadużyciem jednego konta.
• Per tenant / organizacja – stabilizuje współdzielone zasoby i ułatwia rozliczalność.
• Per API key / client – ogranicza ryzyko wycieku klucza i automaty.
• Per endpoint / typ operacji – inne limity dla „chat”, inne dla „run agent”, inne dla „tool call”.
• Per model / klasa kosztu – cięższe modele zwykle wymagają ostrzejszych limitów RPS/równoległości.

Praktyka: stosuje się kompozycję limitów, np. jednocześnie: per-user + per-tenant + global. Jeśli którykolwiek zostanie przekroczony, żądanie jest ograniczane.

Okna czasowe: stałe, kroczące i „token bucket”

Sposób liczenia limitu wpływa na to, czy system będzie „szarpał” ruchem i czy da się go łatwo obejść. Najczęściej spotkasz:

• Fixed window (stałe okno): np. 100 żądań na minutę liczone od pełnej minuty. Proste, ale podatne na burst na granicy okien.
• Sliding window (kroczące): limit liczony dla dowolnego okresu ostatnich X sekund. Bardziej „sprawiedliwe”, trudniejsze implementacyjnie.
• Token bucket / leaky bucket: system „nabija” tokeny w czasie, a żądania je zużywają. Dobrze kontroluje bursty i średnią.

W kontekście agentów często najlepiej sprawdza się token bucket, bo pozwala na krótkie bursty (np. kilka kliknięć użytkownika) bez rozwalania średniego tempa.

Bursty: dopuszczalne „zrywy” bez utraty kontroli

Bursty są naturalne: odświeżenie UI, równoległe wywołania w przeglądarce, ponowne wysłanie po timeout. Zamiast „twardo” odcinać wszystko, warto zaprojektować:

• Limit średni (np. 10 req/s) oraz limit burst (np. do 30 w krótkim czasie).
• Oddzielne limity dla startu pracy (np. „create run”) i dla odpytywania statusu (polling), aby polling nie zagłuszał pracy właściwej.
• Preferowanie streamingu (jeśli używasz) zamiast agresywnego pollingu — mniej żądań kontrolnych.

Dobry burst to taki, który poprawia UX, ale nie pozwala „wypompować” backendu w sekundę. W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami, bo granica między „responsywnym UI” a „DoS przez polling” bywa zaskakująco cienka.

Kolejki zamiast odmowy: kontrola przepustowości

Nie każde przekroczenie limitu musi kończyć się 429. Dla dłuższych operacji agentowych często lepsze jest podejście: przyjmij, ale kolejkuj (do określonej pojemności), a dopiero potem odrzucaj.

• Queue depth: maksymalna liczba zadań oczekujących (per tenant / global). Po przekroczeniu – odrzucenie lub degradacja.
• Concurrency limit: maksymalna równoległość workerów/uruchomień agenta; reszta czeka w kolejce.
• Timeout w kolejce: jeśli zadanie czeka zbyt długo, kończysz je kontrolowanie (np. „spróbuj ponownie później”).

Ważne: kolejka to też zobowiązanie. Jeśli nie masz twardych limitów pojemności i czasu oczekiwania, kolejka staje się „magazynem” problemu, a nie rozwiązaniem.

Retry: jak pozwolić na ponowienia, żeby nie pogorszyć sytuacji

Mechanizmy ponowień są potrzebne (sieć, krótkie przeciążenia), ale źle ustawione retry potrafią wzmocnić przeciążenie. Minimalny zestaw zasad:

• Retry tylko dla bezpiecznych błędów: typowo 429, wybrane 5xx, timeouts — i tylko gdy operacja jest idempotentna albo masz klucz idempotencji.
• Exponential backoff + jitter: rozprasza fale ponowień.
• Szanuj Retry-After: jeśli serwer go zwraca, klient powinien się dostosować.
• Limit prób: twardy cap, po którym klient eskaluje błąd użytkownikowi lub przechodzi w tryb „spróbuj później”.

Warto też rozważyć politykę: „jeśli dostajesz 429, to nie ponawiaj natychmiast status-checków/pollingu w tej samej częstotliwości”. To częsty generator zbędnego ruchu.

Kontrakty odpowiedzi: co zwracać, gdy limit zadziała?

Sam kod 429 to za mało, żeby klienci zachowywali się poprawnie. Przydatne elementy kontraktu:

• Retry-After (sekundy lub data) – podstawowy sygnał, kiedy ponowić.
• Nagłówki limitów (np. pozostałe żądania, reset okna) – ułatwiają adaptacyjne zachowanie klienta.
• Stały format błędu (kod, kategoria, wskazówka) – by front/backoff nie był „zgadywaniem”.

Mini-przykład: prosty rate limit z token bucket (pseudokod)

// Klucz: (tenant_id, user_id, endpoint)
// Konfiguracja: refill_rate = 5 tokenów/s, capacity = 20

function allowRequest(key, now):
  bucket = loadBucket(key)
  bucket.tokens = min(capacity, bucket.tokens + (now - bucket.last) * refill_rate)
  bucket.last = now

  if bucket.tokens < 1:
    return deny(429, retryAfterSeconds = (1 - bucket.tokens) / refill_rate)

  bucket.tokens -= 1
  saveBucket(key, bucket)
  return allow()

To tylko szkic pokazujący ideę: krótki burst do pojemności wiadra i kontrolowana średnia dzięki uzupełnianiu tokenów.

Najczęstsze pułapki wdrożeniowe

• Limitowanie tylko na brzegu (np. gateway), bez ochrony zasobów wewnątrz: równoległość workerów i tak „wybucha”.
• Jednolity limit dla wszystkich operacji: ciężkie endpointy agentowe potrzebują osobnych polityk.
• Brak idempotencji: retry powoduje duplikaty uruchomień agenta i mnoży koszty.
• Polling bez limitów: klienci potrafią generować większość ruchu „kontrolnego”, nie merytorycznego.
• Niespójne sygnały (brak Retry-After, różne formaty błędów): klienci implementują chaotyczne obejścia.

Dobrze zaprojektowane rate limiting i kontrola przepustowości nie tylko chronią przed nadużyciami, ale też stabilizują doświadczenie użytkownika: lepiej dostać przewidywalne „zwolnij/odczekaj”, niż losowe timeouty i błędy w środku sesji.

5. Budżety tokenów i koszty: limity kontekstu, limity na sesję/okres, degradacja jakości i fallbacki

W systemach agentowych koszt i ryzyko eskalują wraz z długością kontekstu, liczbą iteracji oraz „rozmachem” użycia narzędzi. Dlatego obok limitów żądań kluczowe są budżety tokenów: mierzalne, egzekwowalne limity zużycia (wejście/wyjście) przypisane do użytkownika, tenant’a, sesji lub konkretnego zadania. Ich celem jest jednocześnie kontrola kosztów i ochrona stabilności (np. przed runaway agentem generującym wielostronicowe odpowiedzi lub „mielącym” kontekst w pętli).

Tokeny jako jednostka kosztu i ryzyka

Tokeny są praktycznym „licznikiem” zasobów: obejmują zarówno tokeny wejściowe (prompt, historia, wyniki narzędzi), jak i tokeny wyjściowe (generowana odpowiedź). Budżet tokenów działa jak bezpiecznik: nawet gdy ruch jest umiarkowany (rate limit nie jest przekroczony), pojedyncza sesja może generować nadmiar kosztów przez zbyt długi kontekst lub zbyt rozbudowane odpowiedzi.

Limity kontekstu: ile pamięci rozmowy naprawdę potrzebujesz

Limit kontekstu to granica „ile można wcisnąć” do okna modelu. Hardening polega na tym, by nie traktować maksymalnego okna jako domyślnego, tylko świadomie sterować, co wchodzi do promptu:

• Limit długości historii – utrzymuj sufit na liczbę tokenów przeznaczonych na historię rozmowy (np. „ostatnie N tokenów” zamiast „cała rozmowa”).
• Limit na wstawki narzędziowe – wyniki narzędzi (np. długie dokumenty, logi) powinny mieć swoje własne limity lub streszczenia.
• Priorytetyzacja treści – instrukcje systemowe i reguły bezpieczeństwa mają pierwszeństwo; mniej istotne fragmenty historii mogą być obcinane.

To nie jest jeszcze temat doboru algorytmu skracania czy streszczania – istotne jest samo rozdzielenie: limit okna modelu vs. polityka, co do niego wkładamy.

Limity na sesję i na okres: budżety „ciągłe” i „skokowe”

Budżety tokenów mogą działać na różnych horyzontach czasu, a każdy rozwiązuje inny problem:

W praktyce łączy się kilka limitów naraz: np. umiarkowany limit na odpowiedź, większy na sesję i twardy „cap” miesięczny dla tenant’a. Dzięki temu system pozostaje przewidywalny finansowo i operacyjnie.

Polityki budżetowe: twarde odcięcie vs. kontrolowane „miękkie” limity

Egzekwowanie budżetu nie musi oznaczać natychmiastowego błędu. Warto rozróżnić:

• Twarde limity – po przekroczeniu system odmawia dalszego generowania lub skraca odpowiedź do bezpiecznego minimum. Stosowane tam, gdzie ryzyko kosztowe jest nieakceptowalne.
• Miękkie limity – po przekroczeniu progu uruchamia się polityka oszczędzania: krótsze odpowiedzi, mniej kontekstu, mniej „kroków” rozumowania na zewnątrz. Utrzymuje UX, ale redukuje koszty.

Miękkie limity są szczególnie przydatne w produktach, gdzie przerwanie w połowie zadania jest gorsze niż odpowiedź „w wersji light”.

Degradacja jakości: jak ciąć koszty bez psucia bezpieczeństwa

Najważniejsza zasada: degraduj jakość, nie kontrolę. Oznacza to, że przy oszczędzaniu tokenów nie wolno usuwać elementów, które utrzymują polityki bezpieczeństwa i zgodności. Typowe strategie degradacji:

• Skracanie odpowiedzi – proszenie modelu o wersję zwięzłą, punktową, z limitem długości.
• Redukcja historii – obcinanie mniej istotnych fragmentów rozmowy, zostawiając instrukcje i kluczowe ustalenia.
• Wymuszenie formatu – np. „3 kroki”, „5 punktów”, „jedno zalecenie + uzasadnienie” zamiast swobodnej narracji.
• Ograniczenie pracy na danych wejściowych – zamiast wklejania całych dokumentów: żądanie streszczenia, wycinka lub wskazania fragmentów.

Ważne: degradacja nie jest tym samym co „obniżanie jakości modelu” – to polityka sterowania zużyciem tokenów. Dobór modeli i routing to osobny temat, ale budżet tokenów powinien umieć wymusić zwięzłość niezależnie od modelu.

Fallbacki: co robić, gdy budżet się kończy

Gdy system zbliża się do limitu lub go przekracza, potrzebujesz z góry zdefiniowanych zachowań awaryjnych, które są przewidywalne i bezpieczne:

• Odpowiedź częściowa + plan dalszych kroków – zamiast ciągnąć generację, agent kończy na priorytetach i prosi o doprecyzowanie.
• Tryb „summary-only” – generowanie krótkiego podsumowania i zamknięcie sesji z komunikatem o limicie.
• Wymuszenie interakcji – agent przestaje „zgadywać” i zadaje jedno kluczowe pytanie, by nie marnować tokenów na błędny kierunek.
• Odmowa z komunikatem produktowym – jasna informacja o wyczerpaniu budżetu i wskazanie, jak go odnowić (np. kolejny okres, plan taryfowy, kontakt z administratorem).

Minimalny szkic implementacyjny (polityka budżetu w middleware)

Poniższy przykład pokazuje ideę: licznik tokenów i progi, które przełączają tryb odpowiedzi. To uzupełnienie – szczegóły pomiaru i integracji zależą od stacku.

// Pseudokod
function enforceTokenBudget(ctx) {
  const { tenantId, userId, sessionId } = ctx;

  const budget = getBudget(tenantId, userId);            // np. miesięczny + sesyjny
  const usage  = getCurrentUsage(tenantId, userId, sessionId);

  if (usage.sessionTokens >= budget.sessionHardLimit) {
    return { mode: "deny", reason: "SESSION_TOKEN_LIMIT" };
  }

  if (usage.periodTokens >= budget.periodHardLimit) {
    return { mode: "deny", reason: "PERIOD_TOKEN_LIMIT" };
  }

  if (usage.sessionTokens >= budget.sessionSoftLimit ||
      usage.periodTokens  >= budget.periodSoftLimit) {
    return { mode: "degrade", policy: "concise+trim_history" };
  }

  return { mode: "normal" };
}

Kluczowe jest, by polityka budżetu była deterministyczna (łatwa do wytłumaczenia i testowania) oraz by degradacja i fallbacki były spójne z oczekiwaniami produktu.

6. Limity narzędzi i ochrona przed pętlami agentów: limity wywołań, timeouts, sandboxing, guardrails

Endpointy agentów są szczególnie wrażliwe nie tylko na liczbę żądań, ale na niekontrolowaną aktywność narzędzi (tool calls): iteracyjne wyszukiwania, wielokrotne zapytania do baz, powtarzane działania w systemach zewnętrznych czy automatyczne „naprawianie” błędów w pętli. W praktyce to narzędzia generują największe ryzyka kosztowe i operacyjne: długie czasy odpowiedzi, lawinowy ruch do zależności, duplikację efektów ubocznych oraz trudno przewidywalne ścieżki wykonania.

Hardening w tym obszarze polega na wprowadzeniu prostych, egzekwowalnych barier: limitów wywołań, timeoutów, izolacji wykonania (sandbox) oraz guardrails kontrolujących co i kiedy agent może zrobić. Te mechanizmy różnią się od klasycznego rate limitingu: nie ograniczają wyłącznie częstotliwości żądań API, lecz zachowanie i skutki działania agenta wewnątrz pojedynczej sesji i w interakcjach z narzędziami.

Limity wywołań narzędzi (tool call caps)

Najprostsza i często najskuteczniejsza ochrona przed „runaway agentem” to limit liczby wywołań narzędzi w ramach:

• jednego kroku (np. maks. 1–3 narzędzia zanim agent zsyntetyzuje odpowiedź),
• jednej sesji (np. maks. N wywołań łącznie),
• jednego typu narzędzia (np. maks. 5 zapytań do wyszukiwarki, 2 do płatnej analityki),
• jednej czynności o skutkach ubocznych (np. maks. 1 modyfikacja zasobu bez potwierdzenia użytkownika).

Limity powinny być rozdzielone dla narzędzi read-only i narzędzi mutating (z efektami ubocznymi). Te drugie wymagają ostrzejszych zasad (m.in. potwierdzeń i idempotencji), ponieważ pętla może nie tylko generować koszty, ale realnie szkodzić danym i operacjom.

Timeouty i budżety czasu (time budgets)

Nawet przy ograniczonej liczbie wywołań pojedyncze narzędzie może „zawiesić” cały przebieg: długi SQL, wolny partner API, deadlock, retry storm. Stosuje się więc:

• timeout per call (twardy limit czasu na pojedyncze wywołanie narzędzia),
• timeout end-to-end (maksymalny czas na całą sesję/rozwiązanie zadania),
• budżet czasu per faza (np. eksploracja vs. finalizacja odpowiedzi),
• cancellation i sprzątanie zasobów (anulowanie zapytań, zamykanie uchwytów, przerwanie jobów).

Timeouty nie są tylko „kill switch”: wymuszają na agencie strategię pracy (np. ogranicz eksplorację, przejdź do odpowiedzi przy niepewności) i chronią zależności przed kumulacją długich połączeń.

Sandboxing: izolacja narzędzi i bezpieczne wykonanie

Gdy agent ma dostęp do wykonania kodu, systemu plików, przeglądarki lub środowisk uruchomieniowych, potrzebna jest izolacja. Sandboxing ogranicza wpływ błędu, prompt injection lub pętli narzędziowej na resztę systemu przez:

• ograniczenia uprawnień (least privilege; minimalne scope’y tokenów i kluczy),
• izolację sieci (egress allowlist, blokada dostępu do sieci wewnętrznej),
• izolację systemową (kontenery/VM, brak dostępu do hosta, ograniczony FS),
• limity zasobów (CPU, RAM, dysk, liczba procesów, czas życia środowiska),
• kontrolę danych (maskowanie sekretów, DLP, brak „przecieków” do logów).

Sandboxing jest szczególnie istotny dla narzędzi wykonujących kod lub automatyzujących akcje w systemach zewnętrznych. Tam nie wystarczy limit wywołań — potrzebna jest pewność, że nawet „zły” przebieg nie wyjdzie poza określone granice.

Guardrails: polityki i walidacja przed/po wywołaniu narzędzia

Guardrails to zestaw reguł, które określają co agent może zrobić oraz w jakiej formie ma to zrobić. W praktyce obejmują:

• schematy wejścia (walidacja parametrów narzędzia: typy, zakresy, rozmiary),
• polityki działań (np. zakaz destrukcyjnych operacji bez eksplicytnej zgody),
• kontrolę celu (czy wywołanie narzędzia jest spójne z zadaniem użytkownika),
• redakcję danych (blokowanie wysyłki PII/sekretów do narzędzi zewnętrznych),
• walidację odpowiedzi narzędzia (czy wynik ma oczekiwany format, rozmiar, poziom zaufania).

Guardrails działają najlepiej, gdy są egzekwowane po stronie serwera, a nie polegają wyłącznie na „instrukcjach w promptcie”. Dla narzędzi o skutkach ubocznych warto stosować zasadę: plan → walidacja → wykonanie, gdzie plan (intencja) i parametry są oceniane zanim dojdzie do akcji.

Ochrona przed pętlami: sygnały i proste heurystyki

Pętle agentów często mają wspólne cechy: powtarzalne wywołania, rosnąca liczba retry, brak postępu w stanie zadania, „kręcenie się” wokół tych samych danych. Bez wchodzenia w zaawansowaną detekcję anomalii, już podstawowe heurystyki są użyteczne:

• limit powtórzeń tego samego narzędzia z podobnymi parametrami,
• limit błędów (np. maks. K kolejnych wyjątków/timeoutów na narzędziu),
• wymóg postępu (np. agent musi zaktualizować stan zadania lub zakończyć po N krokach),
• blokada kaskadowych retry (retry tylko z kontrolą i jitterem, a nie w pętli wnioskowania).

Kluczowe jest odróżnienie: błąd narzędzia może uzasadniać pojedynczy retry, ale wielokrotne powtarzanie bez zmiany strategii powinno wymuszać stop i odpowiedź w trybie degradacji (np. „nie mogę potwierdzić danych teraz, podaję najlepszą możliwą odpowiedź”).

Porównanie mechanizmów (kiedy co stosować)

Minimalny wzorzec egzekwowania limitów (przykład)

Poniżej szkic serwerowego „wrappera” dla narzędzia, pokazujący ideę: waliduj parametry, egzekwuj budżet wywołań i timeout, a wynik sanity-checkuj zanim wróci do agenta.

// Pseudokod
function callTool(toolName, args, ctx) {
  assertAllowedTool(toolName, ctx.policy);               // guardrails
  validateArgs(toolName, args);                          // schema validation

  if (ctx.budgets.toolCallsRemaining <= 0) {
    throw new Error("Tool call budget exceeded");
  }

  ctx.budgets.toolCallsRemaining -= 1;                   // call cap

  const result = withTimeout(ctx.policy.perCallTimeoutMs, () => {
    return toolRegistry[toolName].invoke(args, ctx);     // sandboxed/isolated runtime
  });

  validateResultShape(toolName, result);                 // output guardrails
  return result;
}

Istotne jest to, że ograniczenia są liczone i egzekwowane w warstwie wykonawczej, a nie w samym modelu. Agent może „chcieć” wykonać kolejne kroki, ale endpoint powinien umieć odmówić w sposób kontrolowany.

Praktyczne zasady „bezpiecznej automatyzacji”

• Preferuj narzędzia deterministyczne i idempotentne (łatwiejsze retry i mniejsze szkody przy pętlach).
• Rozdziel narzędzia na klasy: read-only vs. mutating; wewnętrzne vs. zewnętrzne; niskiego vs. wysokiego ryzyka.
• Wymuszaj potwierdzenie przy akcjach destrukcyjnych lub kosztownych (nawet jeśli to tylko „soft confirm” w UI/API).
• Loguj metadane wywołań (kto, jakie narzędzie, czas, wynik, błąd) z redakcją danych wrażliwych — to podstawa późniejszej diagnozy.

7. Wykrywanie anomalii i circuit breaker: sygnały, progi, automatyczne blokady i bezpieczne tryby działania

Same limity nie wystarczą, gdy ruch jest „formalnie poprawny”, ale nietypowy lub szkodliwy: powolne wyczerpywanie budżetów, kaskadowe retry, ataki rozproszone, czy sesje, które zaczynają zachowywać się jak runaway. Dlatego endpointy agentów warto wzmacniać mechanizmami detekcji anomalii oraz circuit breakerem, który potrafi szybko odciąć ryzykowne ścieżki i przełączyć usługę w tryb bezpieczny.

Wykrywanie anomalii odpowiada na pytanie „czy to zachowanie odbiega od normy?”, a circuit breaker na „co robimy, gdy odbiega?”. Pierwsze to obserwacja i klasyfikacja (sygnały, korelacje, kontekst), drugie to egzekucja reakcji (blokada, degradacja, izolacja). Kluczowe jest to, że circuit breaker działa szybciej niż człowiek i bliżej źródła ryzyka (na granicy systemu, na poziomie endpointu lub sesji), minimalizując promień rażenia.

Sygnały anomalii: co warto obserwować

Skuteczna detekcja zaczyna się od sygnałów, które opisują nie tylko wolumen, ale też wzorzec użycia. W praktyce przydatne są sygnały na kilku poziomach:

• Poziom żądania: nietypowe rozmiary wejścia/wyjścia, nagłe skoki czasu odpowiedzi, nietypowe typy błędów, nadmiar prób ponowienia.
• Poziom sesji/konwersacji: zbyt szybkie tempo tur, wydłużające się konteksty, wzrost liczby narzędzi uruchamianych na turę, powtarzalność intencji lub treści sugerująca automatyzację.
• Poziom narzędzi i integracji: nietypowe sekwencje wywołań (np. wielokrotne odpytywanie tych samych zasobów), nagły wzrost odrzuceń/time-outów po stronie zależności, próby dostępu do wrażliwych operacji w nieadekwatnym kontekście.
• Poziom kosztu: odchylenia w zużyciu tokenów/limitów na sesję i użytkownika, wzrost kosztu na jednostkę wartości (np. „mało efektu, dużo zużycia”).
• Poziom bezpieczeństwa: wzorce charakterystyczne dla prompt injection (np. prośby o ujawnienie sekretów, instrukcje omijania zasad), a także nietypowe kombinacje nagłówków, parametrów i tożsamości.

Najważniejsze jest łączenie sygnałów: pojedyncza metryka bywa myląca, ale zbieg kilku odchyleń naraz to mocny wskaźnik „dziwnej sesji”.

Progi i reguły: jak nie utonąć w fałszywych alarmach

Progi powinny być dopasowane do ryzyka i stabilności ruchu. Dobrze sprawdzają się trzy podejścia, stosowane równolegle:

• Progi statyczne: twarde „bezpieczniki” na wartości skrajne (np. absolutne maksimum rozmiaru, czasu, liczby prób).
• Progi dynamiczne: oparte o bazę zachowania dla danego użytkownika/tenanta lub dla danego typu endpointu (ważne, gdy normalne zużycie bywa sezonowe albo mocno nierówne).
• Reguły kontekstowe: inne progi dla operacji o różnym ryzyku (np. działania modyfikujące dane vs. tylko odczyt), a także dla różnych poziomów zaufania tożsamości.

Żeby ograniczyć fałszywe alarmy, warto stosować histerezę (nie przełączać stanu przy każdym drobnym wahnięciu) oraz kryteria „kumulacji” (np. kilka zdarzeń w krótkim oknie zamiast pojedynczego). Progi należy też projektować tak, by w razie pomyłki skutki były odwracalne: łatwe odblokowanie, krótki TTL blokad i czytelne logi przyczyn.

Circuit breaker: reakcja na „dziwne sesje”

Circuit breaker to mechanizm, który w kontrolowany sposób przełącza ścieżkę obsługi, gdy ryzyko rośnie. W kontekście endpointów agentów powinien wspierać decyzje na kilku poziomach:

• Na żądanie: odrzucenie lub wymuszenie uproszczonej odpowiedzi, gdy dane wejściowe wyglądają podejrzanie albo koszt obsługi gwałtownie rośnie.
• Na sesję: „zamrożenie” sesji, skrócenie okna kontekstu, obniżenie limitów dla narzędzi lub przełączenie na bezpieczniejszy tryb działania.
• Na użytkownika/tenant: czasowa blokada, zwiększona weryfikacja, ograniczenie dostępu do operacji wysokiego ryzyka.
• Na zależność: odcięcie wywołań do przeciążonego narzędzia/serwisu i przejście na fallback, żeby nie napędzać kaskadowej awarii.

Ważne: circuit breaker nie jest „karą”, tylko mechanizmem stabilności i bezpieczeństwa. Jego celem jest szybkie ograniczenie szkody i kupienie czasu na analizę.

Automatyczne blokady: stopniowanie reakcji zamiast „wszystko albo nic”

Najlepsze efekty daje reakcja warstwowa, gdzie system najpierw próbuje łagodnych środków, a dopiero potem eskaluje. Przykładowe klasy reakcji:

• Soft throttling: spowolnienie obsługi, narzucenie dodatkowej kolejki, ograniczenie równoległości w ramach sesji.
• Degradacja funkcji: wyłączenie ryzykownych narzędzi, wymuszenie trybu „read-only”, ograniczenie długości odpowiedzi.
• Challenge/step-up: dodatkowa weryfikacja dla działań wysokiego ryzyka, gdy zachowanie odbiega od normy.
• Hard block: czasowa blokada sesji/użytkownika/klucza, gdy sygnały wskazują na nadużycie lub eskalację.

Stopniowanie jest istotne, bo anomalia nie zawsze oznacza atak: może wynikać z błędu klienta, integracji albo nagłego piku. Reakcje powinny minimalizować ryzyko, ale jednocześnie utrzymać możliwie dużo użyteczności.

Bezpieczne tryby działania: jak „odchudzić” agenta pod presją

Gdy system wykryje nietypową sesję lub przeciążenie, powinien mieć zdefiniowane bezpieczne tryby. To gotowe profile zachowania, które ograniczają ryzykowne wektory:

• Tryb restrykcyjny: krótszy kontekst, mniejsza kreatywność/ekspansja odpowiedzi, większy nacisk na zwięzłość i weryfikowalność.
• Tryb ograniczonych narzędzi: brak wywołań zewnętrznych albo tylko do wybranych, najbezpieczniejszych operacji.
• Tryb awaryjny: odpowiedzi informacyjne i bezpieczne komunikaty zamiast pełnej obsługi, gdy stabilność jest zagrożona.
• Tryb izolacji: odseparowanie sesji od współdzielonych zasobów, by nie wpływała na innych użytkowników.

Kluczowe jest, by użytkownik dostawał spójny sygnał (co się dzieje i dlaczego), a zespół operacyjny miał jasny ślad audytowy: jakie sygnały zadziałały, jaki próg został przekroczony i jaką akcję podjęto.

Praktyczne zasady wdrożeniowe

• Blisko wejścia: detekcję i breaker umieszczaj jak najbliżej endpointu, zanim kosztowne kroki zostaną uruchomione.
• Minimalny promień rażenia: preferuj blokady per sesja/użytkownik/tenant zamiast globalnych, chyba że system jest w stanie krytycznym.
• Odwracalność: blokady z TTL, mechanizmy odwołania i jasne powody w logach.
• Obserwowalność: metryki, zdarzenia i korelacja po identyfikatorach sesji, aby szybko odróżnić błąd od nadużycia.
• Testowanie w spokoju: progi i tryby bezpieczne powinny być przećwiczone wcześniej; w kryzysie nie ma czasu na strojenie od zera.

Wykrywanie anomalii i circuit breaker zamykają pętlę ochrony endpointów agentów: nie tylko ograniczają „ile” wolno zrobić, ale też reagują na to, jak i w jakim wzorcu to się dzieje. Dzięki temu system jest odporniejszy na nadużycia, błędy integracji i nieprzewidziane zachowania agentów, a jednocześnie potrafi utrzymać działanie w kontrolowanym, bezpiecznym zakresie.

8. Observability: logging, metryki, alerty oraz checklist wdrożeniowy

Hardening endpointów agentów nie działa „na wiarę” — potrzebuje ciągłej obserwowalności, która pozwala szybko odróżnić normalne skoki ruchu od nadużyć, błędów logiki agentów i awarii integracji. W praktyce observability jest warstwą spinającą polityki limitów, budżetów i zabezpieczeń: dostarcza dowodów, czy ograniczenia są skuteczne, oraz danych do korekty progów bez psucia doświadczenia użytkownika.

W tej sekcji skupiamy się na tym, co zbierać i jak organizować sygnały. Detale implementacyjne (algorytmy limitowania, budżety tokenów, circuit breaker) nie są tu rozwijane — ważne jest, by obserwowalność była projektowana równolegle z mechanizmami ochronnymi, a nie dopinana na końcu.

Logging: co logować, żeby móc reagować i audytować

Logi dla endpointów agentów muszą łączyć perspektywę bezpieczeństwa, kosztu i niezawodności. Najczęstszy błąd to logowanie wyłącznie błędów HTTP — to za mało, bo większość problemów agentowych objawia się degradacją jakości, pętlami narzędzi lub nieoczywistymi wzorcami sesji.

• Kontekst żądania: identyfikator żądania i sesji, tenant/user, kanał (API/UI), region, wersja klienta, typ endpointu (chat, tool, batch), źródłowy IP/ASN (z ostrożnością i zgodnością prawną).
• Decyzje polityk: czy zastosowano limit, jaką regułę dopasowano, czy uruchomiono degradację/fallback, czy przerwano sesję (i z jakiego powodu).
• Sygnały kosztowe: liczba tokenów wejścia/wyjścia, szacowany koszt, liczba wywołań narzędzi, czas działania sesji; to kluczowe do wykrywania „runaway” i nadużyć.
• Bezpieczeństwo: wyniki klasyfikacji ryzyka (np. podejrzenie prompt injection / data exfiltration / nietypowy pattern), ale bez zapisywania wrażliwych treści wprost.
• Minimalizacja danych: preferuj skróty (hash), redakcję PII/secrets, osobne ścieżki dla logów audytowych i diagnostycznych, oraz polityki retencji zależne od wrażliwości.
• Spójność: ujednolicone pola (structured logging) i identyfikatory korelacyjne, aby dało się skleić ślad: gateway → endpoint agenta → narzędzia → upstream LLM.

Kluczowe rozróżnienie: logi diagnostyczne służą do debugowania (krótsza retencja, mocna redakcja), a logi audytowe do rozliczalności (kto/co uruchomił, jaka polityka zadziałała, jaki był skutek) — zwykle bardziej restrykcyjne, ale stabilniejsze i dłużej przechowywane.

Metryki: sygnały, które pokazują nadużycia i degradację

Metryki powinny mierzyć zarówno warstwę HTTP, jak i „wewnętrzną” dynamikę agentową. Dla endpointów agentów szczególnie ważne są metryki, które opisują przepływ sesji i koszt, nie tylko liczbę requestów.

• Ruch i opóźnienia: RPS, p95/p99 latencji, timeouty, odsetek błędów, retry rate, odrzucone żądania.
• Limity i polityki: licznik zadziałań rate limitów, kolejki (depth, age), odsetek degradacji jakości, licznik przerwanych sesji przez reguły bezpieczeństwa.
• Tokeny i koszty: tokeny per request/sesja/tenant, średnie i percentyle, tempo przyrostu tokenów na sesję, koszt na użytkownika i na tenant w oknach czasowych.
• Narzędzia i integracje: liczba wywołań narzędzi na sesję, błędy narzędzi, czas odpowiedzi narzędzi, odsetek „pętli” (np. wiele powtórzeń tego samego narzędzia w krótkim czasie).
• Jakość działania: odsetek przerwań z powodu budżetu, liczba odpowiedzi fallback, wskaźniki „niedokończonych” sesji (np. przerwane po wielu krokach), sygnały z oceny ryzyka (agregaty, bez treści).
• Izolacja tenantów: udział zasobów na tenant, wykrywanie „noisy neighbor” (np. jeden tenant generuje większość kosztu/obciążenia), odsetek odmów per tenant.

Dobre praktyki: metryki powinny być etykietowane tak, by dało się ciąć po tenant/user, typie endpointu i powodach decyzji polityk — ale z kontrolą kardynalności (nie etykietuj surowymi identyfikatorami żądań ani pełnymi promptami).

Alerty: kiedy budzić ludzi, a kiedy automatycznie hamować

Alerting dla agentów ma dwa cele: szybkie wykrywanie incydentów oraz wykrywanie trendów kosztowych, zanim staną się problemem. Zamiast jednego „error rate > X”, sensowne są alerty łączące sygnały: wzrost kosztu + wzrost retry + wzrost przerwanych sesji często oznacza awarię upstream lub pętlę w logice.

• Nadużycia/DoS: gwałtowny wzrost RPS na tenant/user, skok odrzuceń przez limit, nietypowy rozkład geograficzny, nadmiar równoległych sesji.
• Runaway / pętle: wzrost liczby kroków na sesję, wzrost tokenów na sesję, wzrost wywołań narzędzi, rosnący czas trwania sesji bez finalizacji.
• Awaria upstream: wzrost timeoutów, wzrost retry, spadek sukcesów wywołań narzędzi, wzrost fallbacków.
• Kontrola kosztów: dzienny/tygodniowy burn rate tokenów, nietypowe odchylenia kosztu na tenant, przekroczenia budżetów organizacyjnych.
• Bezpieczeństwo: wzrost sesji oznaczonych jako podejrzane, wzrost uruchomień „circuit breaker” i automatycznych blokad.

Alerty powinny mieć przypisane runbooki: minimalny zestaw kroków triage (czy to atak, błąd klienta, regresja, awaria integracji), oraz decyzję, kiedy przejść w tryb ochronny (np. zaostrzenie limitów, wymuszenie degradacji, czasowe wyłączenie narzędzia).

Przykładowe polityki (formaty YAML/JSON): co powinno istnieć w konfiguracji

Konfiguracje polityk warto traktować jak produkt: wersjonowane, testowane i wdrażane kontrolowanie. Niezależnie od tego, czy stosujesz YAML czy JSON, konfiguracja powinna wyrażać te same kategorie decyzji — dzięki temu łatwo audytować, dlaczego użytkownik został ograniczony i jakie były parametry.

• Zakres: polityki globalne, per endpoint, per tenant, per plan/subskrypcję; możliwość nadpisywania wyjątkami.
• Limity ruchu: limity żądań, limity równoległości, zachowanie przy burstach, priorytety (np. interaktywne vs batch).
• Budżety kosztowe: budżet tokenów per request/sesja/okres, reguły degradacji, zachowanie po przekroczeniu (soft/hard limit).
• Limity narzędzi: maks. liczba wywołań, listy dozwolonych narzędzi, timeouts, blokady na narzędzia ryzykowne w trybie ochronnym.
• Reguły anomalii: progi i okna czasowe, scoring ryzyka, warunki uruchomienia circuit breaker, czas trwania blokady, warunki odblokowania.
• Telemetria: wymagane pola logów, poziomy logowania per komponent, sampling, redakcja danych, retencja.
• Tryby działania: „normal”, „degraded”, „safe-mode” oraz mapowanie, co w danym trybie jest dozwolone (np. wyłączone narzędzia, niższe limity, wymuszone krótsze odpowiedzi).

Istotna różnica zastosowań: polityki limitów i budżetów są zwykle deterministyczne (łatwe do testowania), a polityki anomalii są częściej heurystyczne i wymagają strojenia na danych produkcyjnych. Dlatego konfiguracja powinna wspierać stopniowe wdrożenia i szybkie roll-backi.

Checklist wdrożeniowy: minimalny zestaw przed produkcją

• Identyfikacja: spójne ID żądania i sesji, możliwość korelacji z wywołaniami narzędzi i upstream.
• Strukturalne logi: ustandaryzowane pola, redakcja PII/secrets, rozdzielenie logów audytowych i diagnostycznych, zdefiniowana retencja.
• Metryki podstawowe: RPS, latencje (p95/p99), error rate, retry, odrzucenia; metryki per tenant/endpoint.
• Metryki agentowe: tokeny i koszt per sesja/tenant, liczba kroków i wywołań narzędzi, czas trwania sesji, fallback/degradacja.
• Alerty i runbooki: progi dla nadużyć, runaway, awarii integracji i burn rate; gotowe procedury reakcji.
• Dashboardy: osobne widoki dla SRE/ops (stabilność), security (nadużycia), oraz finansowe (koszt i budżety).
• Testy polityk: walidacja konfiguracji (schema), testy regresji progów, kontrolowany rollout i łatwy rollback.
• Tryb ochronny: możliwość szybkiego przełączenia w degraded/safe-mode bez wdrożenia kodu, z pełnym audytem zmian.
• Kontrola kardynalności: ograniczenie etykiet metryk, sampling logów, aby observability nie stała się źródłem kosztu i awarii.

Dobrze zaprojektowana observability nie tylko pomaga wykrywać incydenty, ale też daje podstawę do uczciwego egzekwowania polityk i przewidywalnego zarządzania kosztami. Bez niej hardening endpointów agentów pozostaje zestawem hipotez — z nią staje się mierzalnym, iteracyjnie doskonalonym systemem.

Na zakończenie – w Cognity wierzymy, że wiedza najlepiej działa wtedy, gdy jest osadzona w codziennej pracy. Dlatego szkolimy praktycznie.

Excel + Power Automate: automatyczne wersjonowanie plików i blokada nadpisywania (wzorzec zespołowy) 30 kwietnia 2026

Testy odporności agentów na dane brudne: 9 klas błędów wejścia (daty, waluty, OCR) i jak je symulować 28 kwietnia 2026