Przejdź do głównej treści
Sprawdzenia bezpieczeństwa mają znaczenie tylko wtedy, gdy faktycznie się uruchamiają — ale nie powinieneś rezygnować z przepustowości dla bezpieczeństwa. Ta strona odpowiada na pytanie, które zadają deweloperzy najczęściej: czy egzekwowanie spowolni mojego agenta i o ile? Krótka odpowiedź: wbudowane reguły nie kosztują nic mierzalnego. Zaawansowane reguły kosztują co najwyżej jedno ograniczone, współbieżne, fail-open wywołanie modelu. Oto dlaczego i jak to kontrolować.

​
1. Dwie klasy sprawdzeń

Każda reguła guardrail i każda ewaluacja firewalla należy do jednej z dwóch klas.

​
Wbudowane / deterministyczne sprawdzenia

Reguły guardrail — lista zakazanych słów kluczowych (keyword), wyrażenie regularne (regex), wykrywanie PII (pii) i maksymalna długość (max_chars) — to czyste lokalne operacje na łańcuchach i regex — bez wywołania modelu, bez skoku sieciowego, nic co może przekroczyć timeout. Ewaluacja reguł firewalla (dopasowanie glob nazwy narzędzia, predykaty argumentów, zakres egress) jest taka sama: deterministyczna i lokalna. Dla praktycznych celów te sprawdzenia dodają pomijalnie małe opóźnienie do twojego żądania. Są bezpieczne do uruchamiania na gorącej ścieżce i z nich zbudowane są wbudowane szablony guardrail.

​
Zaawansowane / semantyczne sprawdzenia

Reguły llm_judge, grounding i external dostawcy delegują sprawdzenie do modelu lub dostawcy. Kosztują one podróż w obie strony. Trzy właściwości ograniczają ten koszt:
  1. Współbieżna dyspozycja. Jeśli twoja polityka ma wiele zaawansowanych reguł, są one dyspozytowane równolegle — jedno wolne sprawdzenie nigdy nie serializuje się za innym.
  2. Timeout per reguła. Każda zaawansowana reguła ma timeout (judge_timeout_ms / grounding_timeout_ms / timeout_ms). Sprawdzenie grounding domyślnie wynosi ~3 000 ms; sędzia używa konfigurowalnej wartości (0 → domyślne silnika). Reguła jest ograniczona — nie może wisieć w nieskończoność.
  3. Fail-open domyślnie. Gdy reguła przekroczy timeout lub jej dostawca zwróci błąd, zdarzenie jest rejestrowane, ale żądanie kontynuuje. Ustaw judge_fail_open: false (sędzia) lub fail_open: false (external), aby przełączyć na fail-closed zamiast.
Więc najgorszy przypadek dla dowolnej liczby zaawansowanych reguł to najdłuższy pojedynczy timeout, nie suma wszystkich timeoutów.

​
2. Na pierwszy rzut oka

Typ sprawdzeniaDodaje opóźnienie?Jak jest ograniczony
Lista zakazanych słów kluczowych keywordPomijalne — lokalne skanowanie łańcuchaBez sieci; brak potrzeby timeoutu
regexPomijalne — lokalne dopasowanie RE2Bez sieci; brak potrzeby timeoutu
Wykrywanie PII piiPomijalne — lokalne skanowanie regex/encjiBez sieci; brak potrzeby timeoutu
max_charsPomijalne — liczenie znakówBez sieci; brak potrzeby timeoutu
Ewaluacja reguły firewallaPomijalne — dopasowanie glob + predykatBez sieci; brak potrzeby timeoutu
llm_judgeJedno ograniczone wywołanie modelujudge_timeout_ms; fail-open domyślnie
groundingJedno ograniczone wywołanie modelugrounding_timeout_ms (domyślnie ~3 000 ms); fail-open domyślnie
external dostawcaJedno ograniczone wywołanie dostawcytimeout_ms; fail_open domyślnie
Wiele zaawansowanych regułJedna ograniczona podróż w obie strony (współbieżna dyspozycja)Najgorszy przypadek = max pojedynczy timeout, nie suma

​
3. Gdzie w cyklu życia żądania biegną sprawdzenia

Egzekwowanie nie odbywa się w tym samym punkcie. Sprawdzanie wejścia i wyjścia dodaje czas w różnych miejscach: 
Klient
  │
  ▼
[Sprawdzanie guardrail wejściowego]     ← dodaje czas TUTAJ, przed nadrzędnym
  │
  ▼
Wywołanie modelu nadrzędnego
  │
  ▼
[Sprawdzanie guardrail wyjściowego]    ← dodaje czas TUTAJ, po odpowiedzi modelu
  │
  ▼
Klient
Guardrails wejściowe biegną przed wywołaniem modelu nadrzędnego. Wbudowana reguła wejściowa dodaje pomijalne narzuty na początku. Zaawansowana reguła wejściowa (np. llm_judge sprawdzający prompt injection) dodaje ograniczone wywołanie modelu przed rozpoczęciem głównego wywołania modelu. Guardrails wyjściowe biegną po odpowiedzi modelu. Wbudowana reguła wyjściowa dodaje pomijalne narzuty na końcu. Zaawansowana reguła wyjściowa (np. grounding sprawdzający wierność RAG) dodaje ograniczone wywołanie po tym, jak masz już odpowiedź modelu. Ewaluacja reguł Firewalla jest deterministyczna i odbywa się inline podczas routingu wywołań narzędzi — pomijalne, jak wspomniano powyżej.
Zablokowane żądanie nie kosztuje tokenów modelu i nie dodaje opóźnienia nadrzędnego dla bloków na etapie wejściowym. Blokada wejściowa odpala przed pomiarem i przed wywołaniem nadrzędnym, więc nie płacisz ani limitu, ani czasu podróży nadrzędnej w obie strony. Blokada na etapie wyjściowym zwraca wstępnie pobraną porcję po odrzuceniu odpowiedzi.

​
4. Jak timeouty i fail-open ograniczają najgorszy przypadek

Zaawansowane reguły mają dwa regulatory: Timeout — maksymalny czas zegarowy, jaki sprawdzenie może trwać. Żądanie czeka najwyżej tyle na tę regułę. Współbieżna dyspozycja oznacza, że to ograniczenie obowiązuje per reguła, nie per polityka. Jeśli masz trzy reguły llm_judge każda z timeoutem 2 000 ms, wszystkie trzy biegną jednocześnie i całkowite oczekiwanie wynosi ~2 000 ms, nie ~6 000 ms. Fail-open vs fail-closed — co zrobić, gdy reguła nie zakończy się na czas (lub dostawca błęduje):
UstawienieZachowanie przy timeoucie / błędzie
fail_open: true (domyślne)Zarejestruj zdarzenie; pozwól żądaniu kontynuować jak gdyby sprawdzenie przeszło
fail_open: falseTraktuj timeout / błąd jako blokadę; zwróć HTTP 400 guardrail_blocked
Fail-open zachowuje dostępność kosztem pominiętego sprawdzenia. Fail-closed zachowuje gwarancję polityki kosztem dostępności, jeśli sędzia jest wolny lub nieosiągalny. Wybierz na podstawie tego, co ma większe znaczenie dla twojego przypadku użycia.

​
5. Praktyczne wskazówki

Trzymaj reguły gorącej ścieżki wbudowane. Jeśli twoim głównym zmartwieniem jest PII, wyciek poświadczeń, długość promptu lub lista zakazanych słów kluczowych — wszystkie te reguły są wbudowane. Nie dodają żadnego mierzalnego opóźnienia i powinny być twoim domyślnym wyborem dla każdego sprawdzenia, które może obsłużyć dopasowanie tekstu. Używaj llm_judge i grounding tam, gdzie potrzebujesz semantyki. Toksyczność, nękanie, wykrywanie off-topic, intencja prompt-injection i wierność RAG są naprawdę rozmyte — żaden regex nie wychwytuje ich niezawodnie. To są właściwe przypadki dla zaawansowanej reguły. Zaakceptuj, że każda dodaje ograniczone dodatkowe wywołanie modelu. Dostrajaj timeouty do swojego budżetu opóźnień. Jeśli twój cel end-to-end wynosi 1 000 ms, ustaw judge_timeout_ms: 800 (lub mniej), aby sędzia nie mógł pochłonąć całego twojego budżetu. Domyślny timeout silnika jest bezpiecznym punktem startowym; obniż go, jeśli masz ścisłe wymagania. Dla ugruntowania wyjściowego, wywołanie modelu jest już zakończone. Sprawdzenie grounding biegnie po odpowiedzi modelu nadrzędnego — dodatkowe opóźnienie jest tylko na końcu, nie na krytycznej ścieżce dla time-to-first-token. To czyni z niego bezpieczne miejsce do dodania egzekwowania semantycznego. Wiele zaawansowanych reguł? Rozłóż pracę. Ponieważ zaawansowane reguły biegną współbieżnie, trzy reguły llm_judge kosztują mniej więcej tyle samo co jedna — najdłuższy indywidualny timeout określa czas zegarowy, nie liczba. Użyj tego do warstwowania sprawdzeń semantycznych bez addytywnego kosztu.

Tryby egzekwowania

Fail-open vs fail-closed — pełna referencja do dostrajania zachowania twojej polityki przy timeoucie i błędach.

Guardrails

Typy reguł, pola sędziego, progi ugruntowania i pełna referencja konfiguracji guardrail.
Wbudowane reguły są pomijalne na każdej ścieżce; zaawansowane reguły kosztują jedno ograniczone, współbieżne, fail-open wywołanie — dostrajaj timeout i tryb fail, a egzekwowanie nie dodaje żadnego niekontrolowanego opóźnienia do twoich agentów.