Przejdź do głównej treści
Długo działający agent autonomiczny to najtrudniejsza rzecz do zabezpieczenia. Zapętla się samodzielnie godzinami, sam wybiera narzędzia, sam pobiera URL-e i przez cały czas wydaje twoje pieniądze. Tryby awarii to nie pojedynczy zły prompt — to pętla ponawiania, która spala 400 $ przez noc, wywołanie narzędzia, którego nigdy nie przejrzałeś, klucz wybity na tygodniowy eksperyment, który dalej działa sześć miesięcy później. Ten przepis łączy cztery kontrole wokół dokładnie takiego kształtu agenta. Konfigurujesz je wszystkie w konsoli (lub REST API) — agent dalej woła https://api.orcarouter.ai/v1/... dokładnie jak wcześniej.
Nowy tutaj? Zastosuj najpierw bazę balanced i obserwuj, co robi twój agent przez dzień. Ta strona to następny krok: zamiana obserwacji w egzekwowanie dla agenta, którego nie możesz pilnować.

​
1. Przepis na bezpiecznego agenta autonomicznego

Bezpieczny agent autonomiczny potrzebuje czterech rzeczy, których chatbot nie potrzebuje:

Twardy pułap kosztu

Reguła cap_cost odmawia uruchomienia, gdy jego zakumulowane wydatki przekroczą twój limit — bezpiecznik dla pętli, która nie chce się zatrzymać.

Wykrywanie skoków

Wykrywanie anomalii uczy się normalnego kształtu godziny-tygodnia agenta i flaguje skoki tempa i kosztu, które wymykają się statycznym regułom.

Zatwierdzenie na niebezpiecznych wywołaniach

Werdykt pending_approval wstrzymuje destrukcyjne lub nieodwracalne wywołania narzędzi dla człowieka, zamiast ufać, że agent będzie ostrożny.

Klucz, który wygasa

Ogranicz klucz agenta wygaśnięciem i pułapem kredytu, aby zapomniany eksperyment nie mógł działać — ani wydawać — w nieskończoność.
Każde mapuje się na jedno pole polityki Firewall lub klucza. Żadne nie dotyka kodu twojego agenta.

​
2. Ogranicz koszt każdego uruchomienia

Pierwszą rzeczą, którą rozbiegana pętla wysadza, jest twój budżet. Reguła cap_cost to ścisły pułap kosztu przed-sprawdzenia: gdy pasuje, brama szacuje koszt żądania i odmawia przed dyspozycją, gdy zakumulowane wydatki uruchomienia przekroczyłyby limit — więc wywołanie ponad budżet nigdy nie dociera do dostawcy. Limit jest w zakresie uruchomienia. Brama sumuje wcześniejsze wydatki przez całe uruchomienie agenta, więc długie uruchomienie, które już spaliło większość budżetu, jest odmawiane, nawet gdy następne pojedyncze wywołanie jest tanie. To właśnie czyni go bezpiecznikiem, a nie limitem per żądanie. Dodaj jedną regułę z symbolem wieloznacznym do swojej polityki firewalla: 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
To ogranicza uruchomienie do 10 $ (cap_cost_cents jest w centach USD). Werdykt rozwiązuje się do allow, gdy poniżej budżetu, i deny, gdy oszacowanie by go przekroczyło. Większość wbudowanych szablonów firewalla (Coding, Support, RAG, Data, DevOps, Browser) dostarcza limit kosztu per uruchomienie dokładnie taki — zastosuj jeden i edytuj limit.
Akumulacja w zakresie uruchomienia wymaga włączonego przechwytywania logów żądań dla przestrzeni roboczej. Z wyłączonym zwinięcie wcześniejszych wydatków czyta zero, a limit degraduje się do per żądanie — wciąż bezpieczne, ale nie wychwyci powolnego sączenia 500 wywołań. Zobacz denial-of-wallet.

​
3. Wykrywaj skoki wobec wyuczonej bazowej linii

Limit zatrzymuje katastrofę; wykrywanie anomalii wychwytuje dziwne, zanim stanie się jedną. Firewall uczy się normalnego kształtu użycia narzędzi każdej przestrzeni roboczej — 14-dniowa średnia krocząca pogrupowana po godzinie-tygodnia, więc ruch wtorek-14:00 jest porównywany z historią wtorek-14:00, a nie z płaską dzienną średnią — i wynosi odchylenia na strumień czytelny dla obserwującego:
Wolumen wywołań per narzędzie oceniany wobec wyuczonej bazowej linii. „143 wywołania db.query w godzinę wobec bazowej linii 8” wynurza się nawet, gdy każde pojedyncze wywołanie jest dozwolone.
Ta sama bazowa linia, zastosowana do wydatków zamiast liczby — uruchomienie, które nagle spala znacznie więcej, niż ta godzina zwykle robi.
Sygnatura autonomicznego agenta utkniętego na ponawianiu tego samego zepsutego wywołania. Zobacz excessive-agency.
Przeskok narzędzie-do-narzędzia, którego ta przestrzeń robocza nigdy nie wykonała — kształt agenta idącego gdzieś nowego.
Strumień raportuje nazwy narzędzi, zredagowane id tokenów i liczniki — nigdy surowe argumenty. Odczyt jest otwarty dla każdego Membera; Developer+ może uśpić strumień na do 7 dni podczas badania. Sparuj strumień z regułą cap_cost, aby skok, który jest też ponad budżetem, był zatrzymany, a nie tylko zauważony.

​
4. Wstrzymaj niebezpieczne wywołania dla człowieka

Nie możesz przejrzeć każdego wywołania, które robi agent autonomiczny — ale możesz sprawić, by zatrzymał się i zapytał przed tą garstką, która ma znaczenie. Werdykt pending_approval wstrzymuje wywołanie narzędzia poza pasmem:
  1. Agent wystawia, powiedzmy, wywołanie payments.transfer. Reguła pasuje, a silnik zwraca HTTP 400 firewall_approval_pending z id zatwierdzenia — wywołanie nigdy nie dociera do narzędzia.
  2. Recenzent rozstrzyga je z konsoli (Developer+) lub twój własny system rozstrzyga je przez podpisany HMAC webhook callback do POST /api/v1/firewall/approvals/:id/callback.
  3. Agent odpytuje GET /api/v1/firewall/approvals/:id; po zatwierdzeniu ponownie wysyła oryginalne wywołanie z jednorazowym nagłówkiem X-OrcaRouter-Firewall-Approval, a brama przepuszcza je ten jeden raz.
Reguła, która wstrzymuje zapisy na destrukcyjną powierzchnię: 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
Wdróż to najpierw w trybie cienia — pending_approval degraduje się do audit, więc widzisz, które wywołania by się wstrzymały, faktycznie nie blokując agenta. Wyłącz cień, gdy strumień wygląda dobrze.

​
5. Daj agentowi klucz, który wygasa

Kontrola, która przeżywa każdą politykę, to sam klucz. Agent autonomiczny powinien dostać klucz o ograniczonym zakresie, nie twój domyślny. Ustaw te pola, gdy go wybijasz (konsola → klucze lub token API):
PoleUstaw naDlaczego
expired_timeznacznik czasu UnixEksperyment się kończy; klucz umiera z nim. -1 oznacza nigdy — nie używaj tego tutaj.
credit_limit_usdpułap w dolarachLimit wydatków na kluczu niezależny od limitu uruchomienia. 0 oznacza bez limitu.
firewall_policy_idtwoja polityka powyżejWiąże reguły cap_cost + zatwierdzenia z tym kluczem.
allow_ipsIP egress agentaWyciekły klucz jest bezużyteczny skądkolwiek indziej.
Ustaw też tag environment, aby klucz — i wszystko, co robi w Events i Matches — był atrybuowalny do tego agenta. Wygasający, ograniczony kredytem, przypięty do IP klucz to ostatnia linia: nawet gdyby każda polityka została jakoś obejść, promień rażenia jest ograniczony czasem i dolarami.
Konfiguracja klucza to akcja konsoli / token-API i jest bramkowana rolami. Odczyt plaintextu klucza firewall-gateway wymaga Admin+.

​
6. Złóż to razem

Utwardzony agent autonomiczny kończy z jedną polityką firewalla i jednym kluczem o ograniczonym zakresie:
WarstwaKontrolaWychwytuje
BudżetReguła cap_cost, w zakresie uruchomieniaRozbiegane pętle, denial-of-wallet
ZachowanieStrumień anomalii (rate / burn / retry / novel)Dziwne-ale-dozwolone
Zaufaniepending_approval na destrukcyjnych narzędziachNieodwracalne akcje
ZakresWygasający, ograniczony kredytem, przypięty do IP kluczZapomniane lub wyciekłe klucze
Napisz reguły budżetu i zatwierdzenia razem, ustaw limit per uruchomienie za pomocą reguł firewalla i przeczytaj resztę referencji Firewall dla powierzchni, werdyktów i obserwowalności. Dla powiązanych zagrożeń, przed którymi broni ten przepis, zobacz excessive-agency, dangerous-tool-calls oraz denial-of-wallet.

​
7. Następne kroki

Utwardź agenta MCP

Zarządzaj agentem, który sięga po narzędzia przez serwery MCP.

Zatrzymaj eksfiltrację

Reguły egress dla agenta, który sam pobiera URL-e.

Tryby egzekwowania

Obserwuj → cień → egzekwuj, bezpieczne wdrożenie.

Reguły firewalla

Język dopasowania stojący za każdą regułą powyżej.