Zum Hauptinhalt springen
Ein Agent muss keine Daten leaken, um Ihnen zu schaden. Er kann einfach ausgeben — eine Retry-Schleife, die auf ein teures Modell einhämmert, eine prompt-injizierte Anweisung, die tausend Tool-Calls auffächert, oder ein geleakter API-Key, der Inferenz anhäuft, bis die Rechnung kommt. Das ist Denial of Wallet: Der Angriff sind die Kosten selbst. Anders als ein klassischer Denial-of-Service bleibt das Gateway oben und jeder Request sieht einzeln legitim aus — der Schaden sind die aggregierten Ausgaben. OrcaRouter gibt Ihnen drei unabhängige Obergrenzen, die alle vor dem Upstream-Modell sitzen, sodass kein einzelner außer Kontrolle geratener Pfad Ihre Rechnung unbegrenzt treiben kann.

​
1. Die Denial-of-Wallet-KI-Bedrohung

Ein Denial-of-Wallet-Vorfall lässt sich meist auf eine von drei Formen zurückführen:
Ein Agent wiederholt dasselbe fehlschlagende Tool oder plant in einer engen Schleife neu und zahlt bei jedem Durchgang erneut für Tokens. Keine Bösartigkeit nötig — eine schlechte Abbruchbedingung reicht.
Eine Prompt-Injection steuert den Agenten dazu, ein Tool zu spammen oder übergroße Requests auszugeben, was die Ausgaben pro Zug vervielfacht.
Ein Key landet, wo er nicht sollte — eine committete .env, ein geteiltes Notebook — und ein Angreifer läuft Inferenz auf Ihrem Konto, bis die Ausgaben bemerkt werden.
Die Verteidigung ist in allen drei Fällen dieselbe: eine harte Obergrenze, um die sich der Angreifer nicht herumreden kann, durchgesetzt am Gateway, nicht in Ihrem Agenten-Code.

​
2. Pro-Lauf-Kosten-Obergrenze mit cap_cost

Das cap_cost-Verdikt der Firewall ist ein Schutzschalter für außer Kontrolle geratene Schleifen. Sie verfassen es als Regel mit einer Pro-Lauf-Cent-Obergrenze; die Engine summiert die akkumulierten Ausgaben des Agentenlaufs, und sobald der Lauf die Obergrenze überschreitet, löst es das Verdikt zu deny auf — jeder spätere Tool-Call in diesem Lauf wird blockiert. cap_cost ist eine Pre-Dispatch-Obergrenze: Sie wertet aus, bevor der Aufruf das Tool erreicht, sodass sie den nächsten teuren Aufruf stoppt, statt einen bereits getätigten zu erstatten. Eine typische Catch-all-Obergrenze auf jedem Tool: 
{
  "priority": 50,
  "label": "cap runaway spend at $5 per run",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Unter der Obergrenze wird der Aufruf erlaubt; darüber wird der Lauf mit einem HTTP 400 firewall_blocked abgelehnt — als skip-retry markiert, sodass die Schleife nicht um die Ablehnung herumhämmern kann. Die Obergrenze ist pro Agentenlauf und über Ihre gesamte Workspace-Policy summiert, sodass eine außer Kontrolle geratene Konversation nicht in das Budget einer anderen bluten kann.
cap_cost liest die laufenden Ausgaben aus Ihren Request-Logs. Halten Sie die Request-Log-Erfassung für den Workspace an, damit der Laufende-Ausgaben-Rollup Zeilen zum Summieren hat — andernfalls ist die Vorab-Ausgaben-Schätzung konservativ 0 und die Obergrenze kann nicht sehen, was ein Lauf bereits gekostet hat.
Siehe die Firewall-Regeln-Referenz für die vollständige Matching-Sprache und wo cap_cost unter den anderen Verdikten sitzt.

​
3. Hartes Budget pro Key mit credit_limit_usd

cap_cost begrenzt einen einzelnen Lauf. Um einen Key zu begrenzen — jeden Lauf, den er je ausgibt — setzen Sie credit_limit_usd auf dem API-Key. Es ist eine harte USD-Obergrenze für die Lebenszeit-Ausgaben dieses Keys: Das Gateway wandelt sie in das verbleibende Kontingent des Keys um, und sobald der Key seine Zuteilung verausgabt hat, werden weitere Relay-Aufrufe wegen unzureichenden Guthabens abgelehnt. 0 bedeutet unbegrenzt. Paaren Sie es mit den anderen Scopes des Keys, sodass ein geleakter Key auf jeder Achse zugleich begrenzt ist:

credit_limit_usd

Harte USD-Ausgaben-Obergrenze für den Key (0 = unbegrenzt).

expired_time

Auto-Ablauf-Zeitstempel (-1 = nie). Ein kurzlebiger Key begrenzt das Wirkungsradius-Fenster.

allow_ips

Den Key an bekannte Quell-IPs pinnen — ein geleakter Key ist außerhalb des Netzwerks nutzlos.

model_limits

Den Key auf bestimmte Modelle beschränken, sodass er die teuersten überhaupt nicht erreichen kann.
Geben Sie jedem Agenten seinen eigenen eng gescopeten Key mit einem credit_limit_usd, das er legitim nie überschreiten sollte. Das Limit ist das Budget, keine Vermutung über das Verhalten des Angreifers — selbst ein vollständig kompromittierter Key stoppt an der Obergrenze.
Konfigurieren Sie all das aus dem Konsolen-Key-Editor (oder der Token-API) unter Ihrer Session — das sind Key-Einstellungen, keine Relay-Aufrufe. Nur die /v1/*-Inferenz-Requests verwenden den sk-orca-...-Key selbst. Das Bearbeiten des Limits tritt beim nächsten Request des Keys in Kraft; kein Redeploy.

​
4. Den Spike abfangen, den Sie nicht vorhergesagt haben: Kosten-Anomalien

Eine statische Obergrenze stoppt Ausgaben, die Sie erwartet haben. Die Anomalieerkennung der Firewall fängt die Ausgaben, die Sie nicht erwartet haben. Sie lernt die normale Tool-Nutzungsform jedes Workspaces gegen eine Hour-of-week-Baseline (ein gleitender 14-Tage-Durchschnitt) und macht Abweichungen auf einem Member-lesbaren Feed sichtbar:
AnomalieWas sie flaggt
burn_spikeKosten für ein Tool weit über seinen gelernten Baseline-Kosten — das Denial-of-Wallet-Signal.
rate_spikeAufrufvolumen weit über der Baseline — Fan-out und Fluten.
retry_loopDasselbe Tool mit denselben Argumenten, das in einem engen Fenster wiederholt — die klassische außer Kontrolle geratene Schleife.
So sticht „dieses Tool hat diese Stunde das 40-Fache seiner üblichen Kosten verbrannt” heraus, selbst wenn jeder einzelne Aufruf von der Policy erlaubt war. Sie können eine Anomalie für bis zu 7 Tage snoozen, während Sie ermitteln.
Anomalieerkennung ist Ihre Frühwarnung; cap_cost und credit_limit_usd sind die harten Stopps. Beobachten Sie den Feed, um zu entdecken, wo Ihre echten Ausgaben leben, und schreiben Sie dann eine Obergrenze darum.

​
5. Alles zusammensetzen

Schichten Sie die drei, sodass ein Ausreißer nie die Rechnung erreicht:
KontrolleScopeWann sie feuert
cap_cost-RegelEin AgentenlaufDie akkumulierten Ausgaben des Laufs überschreiten die Cent-Obergrenze
credit_limit_usdEin Key, lebenslangDie Gesamtausgaben des Keys erreichen seine USD-Obergrenze
burn_spike / retry_loopWorkspace, gelerntAusgaben oder Wiederhol-Pattern weichen von der Baseline ab
Eine praktische Baseline: ein Pro-Lauf-cap_cost auf *, ein credit_limit_usd auf jedem Agenten-Key und die Gewohnheit, den Anomalie-Feed zu prüfen. Rollen Sie eine neue cap_cost-Policy zuerst im Shadow-Mode aus — er loggt [shadow] would deny, ohne zu blockieren — sodass Sie die Obergrenze gegen echten Traffic dimensionieren können, bevor sie zubeißt.
cap_cost und der Anomalie-Feed begrenzen Tool-Calls und Läufe, die das Gateway überqueren. Ein Tool, das ein Agent vollständig innerhalb seines eigenen Prozesses ausführt, erreicht die Engine nie. Routen Sie modellvermittelte und MCP-Tool-Calls durch das Gateway — und geben Sie jedem Key ein credit_limit_usd — sodass die Obergrenze hält, ganz gleich, wie der Agent schleift.

​
6. Verwandte Bedrohungen

Denial of Wallet kommt selten allein an — die Schleife, die Ihr Budget verbrennt, wird oft von etwas Upstream angetrieben:

Firewall-Überblick

Verdikte, Anomalieerkennung, Autonomie-Stufen und Observability.

Scoped Keys & Policies

Wie Key-Limits, Guardrails und Firewall-Policies pro Key komponieren.