Przejdź do głównej treści
Agent nie musi wyciekać danych, by ci zaszkodzić. Może po prostu wydawać — pętla ponawiania waląca w drogi model, wstrzyknięta promptem instrukcja, która rozkłada tysiąc wywołań narzędzi, lub wyciekły klucz API nabijający inferencję, aż przyjdzie rachunek. To jest denial of wallet: atakiem jest sam koszt. W przeciwieństwie do klasycznego denial-of-service brama pozostaje na nogach, a każde żądanie wygląda pojedynczo legalnie — szkodą są zagregowane wydatki. OrcaRouter daje ci trzy niezależne sufity, które wszystkie siedzą przed modelem nadrzędnym, więc żadna pojedyncza rozbiegana ścieżka nie może puścić twojego rachunku w nieograniczoność.

​
1. Zagrożenie denial of wallet AI

Incydent denial-of-wallet zwykle prowadzi do jednego z trzech kształtów:
Agent ponawia to samo zawodzące narzędzie lub przeplanowuje w ciasnej pętli, ponownie płacąc za tokeny przy każdym przejściu. Nie wymaga złośliwości — zły warunek stopu wystarczy.
Prompt injection steruje agentem ku spamowaniu narzędzia lub wystawianiu przerośniętych żądań, mnożąc wydatki per tura.
Klucz ląduje gdzieś, gdzie nie powinien — zacommitowany .env, współdzielony notatnik — a atakujący uruchamia inferencję na twoim koncie, aż wydatki zostaną zauważone.
Obrona jest taka sama we wszystkich trzech przypadkach: twardy sufit, którego atakujący nie wygada, egzekwowany w bramie, nie w kodzie twojego agenta.

​
2. Sufit kosztu per uruchomienie z cap_cost

Werdykt cap_cost Firewalla to bezpiecznik dla rozbieganych pętli. Piszesz go jako regułę z limitem w centach per uruchomienie; silnik sumuje zakumulowane wydatki uruchomienia agenta i — gdy uruchomienie przekroczy limit — rozwiązuje werdykt do deny — każde późniejsze wywołanie narzędzia w tym uruchomieniu jest blokowane. cap_cost to sufit przed-dyspozycją: ewaluuje, zanim wywołanie dotrze do narzędzia, więc zatrzymuje następne drogie wywołanie zamiast zwracać już wykonane. Typowy uniwersalny limit na każde narzędzie: 
{
  "priority": 50,
  "label": "cap runaway spend at $5 per run",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Poniżej limitu wywołanie jest dozwolone; powyżej uruchomienie jest odmawiane z HTTP 400 firewall_blocked — oznaczone jako skip-retry, więc pętla nie może walić wokół odmowy. Sufit jest per uruchomienie agenta i sumowany w całej polityce twojej przestrzeni roboczej, więc jedna rozbiegana konwersacja nie może wkrwawić się w budżet innej.
cap_cost odczytuje bieżące wydatki z twoich logów żądań. Trzymaj przechwytywanie logów żądań włączone dla przestrzeni roboczej, aby zwinięcie bieżących wydatków miało wiersze do sumowania — w przeciwnym razie szacunek wcześniejszych wydatków jest konserwatywnie 0, a limit nie widzi, ile uruchomienie już kosztowało.
Zobacz Referencję reguł firewalla dla pełnego języka dopasowania i tego, gdzie cap_cost siedzi pośród innych werdyktów.

​
3. Twardy budżet per klucz z credit_limit_usd

cap_cost ogranicza pojedyncze uruchomienie. Aby ograniczyć klucz — każde uruchomienie, które kiedykolwiek wystawi — ustaw credit_limit_usd na kluczu API. To twardy sufit w USD na wydatki dożywotnie tego klucza: brama konwertuje go na pozostałą kwotę klucza, a gdy klucz wyda swój przydział, dalsze wywołania relay są odrzucane z powodu niewystarczającego kredytu. 0 oznacza nieograniczony. Sparuj go z innymi zakresami klucza, aby wyciekły klucz był ograniczony na każdej osi naraz:

credit_limit_usd

Twardy sufit wydatków w USD dla klucza (0 = nieograniczony).

expired_time

Znacznik czasu auto-wygaśnięcia (-1 = nigdy). Krótkożyciowy klucz ogranicza okno promienia rażenia.

allow_ips

Przypnij klucz do znanych źródłowych IP — wyciekły klucz jest bezużyteczny poza siecią.

model_limits

Ogranicz klucz do konkretnych modeli, aby nie mógł w ogóle sięgnąć najdroższych.
Daj każdemu agentowi własny wąsko ograniczony klucz z credit_limit_usd, którego nigdy nie powinien legalnie przekroczyć. Limit jest budżetem, nie zgadywaniem zachowania atakującego — nawet w pełni skompromitowany klucz zatrzymuje się na suficie.
Skonfiguruj to wszystko z edytora kluczy w konsoli (lub token API) pod swoją sesją — to ustawienia klucza, nie wywołania relay. Tylko żądania inferencji /v1/* używają samego klucza sk-orca-.... Edycja limitu wchodzi w życie przy następnym żądaniu klucza; bez ponownego wdrożenia.

​
4. Wychwyć skok, którego nie przewidziałeś: anomalie kosztu

Statyczny limit zatrzymuje wydatki, które przewidziałeś. Wykrywanie anomalii Firewalla wychwytuje wydatki, których nie. Uczy się normalnego kształtu użycia narzędzi każdej przestrzeni roboczej wobec bazowej linii godziny-tygodnia (14-dniowa średnia krocząca) i wypływa odchylenia na strumieniu czytelnym dla Membera:
AnomaliaCo flaguje
burn_spikeKoszt narzędzia daleko ponad jego wyuczonym kosztem bazowym — sygnał denial-of-wallet.
rate_spikeWolumen wywołań daleko ponad bazową linią — rozkłady i powodzie.
retry_loopTo samo narzędzie z tymi samymi argumentami powtarzające się w ciasnym oknie — klasyczna rozbiegana pętla.
Więc „to narzędzie spaliło 40× swój zwykły koszt w tej godzinie” wyróżnia się, nawet gdy każde indywidualne wywołanie było dozwolone przez politykę. Możesz uśpić anomalię na do 7 dni, gdy ją badasz.
Wykrywanie anomalii to twoje wczesne ostrzeżenie; cap_cost i credit_limit_usd to twarde stopy. Obserwuj strumień, aby odkryć, gdzie żyją twoje prawdziwe wydatki, a potem napisz limit wokół nich.

​
5. Składając to razem

Warstwuj te trzy, aby rozbiegana ścieżka nigdy nie dotarła do rachunku:
KontrolaZakresKiedy odpala
Reguła cap_costJedno uruchomienie agentaZakumulowane wydatki uruchomienia przekraczają limit w centach
credit_limit_usdJeden klucz, dożywotnioCałkowite wydatki klucza trafiają w jego sufit USD
burn_spike / retry_loopPrzestrzeń robocza, wyuczoneWydatki lub wzorzec powtórzeń odchyla się od bazowej linii
Praktyczna baza: cap_cost per uruchomienie na *, credit_limit_usd na każdym kluczu agenta i nawyk sprawdzania strumienia anomalii. Wdróż nową politykę cap_cost najpierw w trybie cienia — loguje [shadow] would deny bez blokowania — abyś mógł zwymiarować limit wobec prawdziwego ruchu, zanim zacznie kąsać.
cap_cost i strumień anomalii ograniczają wywołania narzędzi i uruchomienia, które przekraczają bramę. Narzędzie, które agent wykonuje całkowicie wewnątrz własnego procesu, nigdy nie dociera do silnika. Kieruj wywołania narzędzi mediowane przez model i MCP przez bramę — i daj każdemu kluczowi credit_limit_usd — aby sufit się utrzymał niezależnie od tego, jak agent się zapętla.

​
6. Pokrewne zagrożenia

Denial of wallet rzadko przybywa sam — pętla, która pali twój budżet, jest często napędzana przez coś z góry:

Przegląd Firewalla

Werdykty, wykrywanie anomalii, poziomy autonomii i obserwowalność.

Klucze i polityki o ograniczonym zakresie

Jak limity kluczy, guardrails i polityki firewalla komponują się per klucz.