Passer au contenu principal
Un agent n’a pas besoin de laisser fuir des données pour vous nuire. Il peut simplement dépenser — une boucle de réessai martelant un modèle coûteux, une instruction injectée par prompt qui fait éclater un millier d’appels d’outils, ou une clé API fuitée accumulant de l’inférence jusqu’à l’arrivée de la facture. C’est le denial of wallet : l’attaque est le coût lui-même. Contrairement à un déni de service classique, la passerelle reste debout et chaque requête semble individuellement légitime — le dommage est la dépense agrégée. OrcaRouter vous donne trois plafonds indépendants qui se trouvent tous devant le modèle amont, de sorte qu’aucun chemin emballé unique ne peut faire courir votre facture sans limite.

​
1. La menace denial of wallet ia

Un incident de denial-of-wallet se ramène généralement à l’une de trois formes :
Un agent réessaie le même outil défaillant ou re-planifie dans une boucle serrée, repayant des tokens à chaque passe. Aucune malveillance requise — une mauvaise condition d’arrêt suffit.
Une injection de prompt oriente l’agent vers le spam d’un outil ou l’émission de requêtes surdimensionnées, multipliant la dépense par tour.
Une clé finit là où elle ne devrait pas — un .env commité, un notebook partagé — et un attaquant exécute de l’inférence sur votre compte jusqu’à ce que la dépense soit remarquée.
La défense est la même dans les trois cas : un plafond dur que l’attaquant ne peut pas contourner par la parole, appliqué à la passerelle, pas dans le code de votre agent.

​
2. Plafond de coût par exécution avec cap_cost

Le verdict cap_cost du Firewall est un disjoncteur pour les boucles emballées. Vous le rédigez comme une règle avec un plafond en centimes par exécution ; le moteur additionne la dépense accumulée de l’exécution de l’agent et, une fois que l’exécution franchit le plafond, résout le verdict en deny — chaque appel d’outil ultérieur dans cette exécution est bloqué. cap_cost est un plafond pré-dispatch : il évalue avant que l’appel n’atteigne l’outil, donc il stoppe le prochain appel coûteux plutôt que d’en rembourser un déjà effectué. Un plafond fourre-tout typique sur chaque outil : 
{
  "priority": 50,
  "label": "cap runaway spend at $5 per run",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Sous le plafond, l’appel est autorisé ; au-dessus, l’exécution est refusée avec une HTTP 400 firewall_blocked — marquée skip-retry, de sorte que la boucle ne puisse pas marteler autour du refus. Le plafond est par exécution d’agent et additionné à travers toute votre politique d’espace de travail, de sorte qu’une conversation emballée ne puisse pas déborder sur le budget d’une autre.
cap_cost lit la dépense courante depuis vos journaux de requêtes. Gardez la capture des journaux de requêtes activée pour l’espace de travail afin que le rollup de dépense courante ait des lignes à additionner — sinon l’estimation de dépense antérieure est prudemment 0 et le plafond ne peut pas voir ce qu’une exécution a déjà coûté.
Voir la référence des règles de firewall pour le langage de correspondance complet et où cap_cost se situe parmi les autres verdicts.

​
3. Budget dur par clé avec credit_limit_usd

cap_cost borne une seule exécution. Pour borner une clé — chaque exécution qu’elle émet jamais — réglez credit_limit_usd sur la clé API. C’est un plafond USD dur sur la dépense à vie de cette clé : la passerelle le convertit en quota restant de la clé, et une fois que la clé a dépensé son allocation, les appels de relais ultérieurs sont rejetés pour crédit insuffisant. 0 signifie illimité. Associez-le aux autres scopes de la clé de sorte qu’une clé fuitée soit bornée sur chaque axe à la fois :

credit_limit_usd

Plafond de dépense USD dur pour la clé (0 = illimité).

expired_time

Timestamp d’expiration automatique (-1 = jamais). Une clé à courte durée de vie borne la fenêtre du rayon de souffle.

allow_ips

Épinglez la clé à des IP sources connues — une clé fuitée est inutile hors-réseau.

model_limits

Restreignez la clé à des modèles spécifiques, de sorte qu’elle ne puisse pas atteindre les plus chers du tout.
Donnez à chaque agent sa propre clé étroitement scopée avec un credit_limit_usd qu’il ne devrait jamais légitimement dépasser. La limite est le budget, pas une supposition sur le comportement de l’attaquant — même une clé entièrement compromise s’arrête au plafond.
Configurez tout ceci depuis l’éditeur de clé de la console (ou l’API token) sous votre session — ce sont des réglages de clé, pas des appels de relais. Seules les requêtes d’inférence /v1/* utilisent la clé sk-orca-... elle-même. Éditer la limite prend effet à la prochaine requête de la clé ; aucun redéploiement.

​
4. Attrapez le pic que vous n’aviez pas prévu : anomalies de coût

Un plafond statique stoppe la dépense que vous anticipiez. La détection d’anomalies du Firewall attrape la dépense que vous n’aviez pas anticipée. Elle apprend la forme normale d’utilisation des outils de chaque espace de travail contre une baseline heure-de-la-semaine (une moyenne glissante sur 14 jours) et fait surface les écarts sur un flux lisible par un Member :
AnomalieCe qu’elle signale
burn_spikeCoût pour un outil bien au-dessus de son coût de baseline appris — le signal de denial-of-wallet.
rate_spikeVolume d’appels bien au-dessus de la baseline — éclatements et inondations.
retry_loopLe même outil avec les mêmes arguments répété dans une fenêtre serrée — la boucle emballée classique.
Ainsi « cet outil a brûlé 40× son coût habituel cette heure-ci » ressort même quand chaque appel individuel a été autorisé par la politique. Vous pouvez mettre en sourdine une anomalie jusqu’à 7 jours pendant que vous enquêtez.
La détection d’anomalies est votre alerte précoce ; cap_cost et credit_limit_usd sont les arrêts durs. Surveillez le flux pour découvrir où vit votre dépense réelle, puis écrivez un plafond autour.

​
5. Mettre le tout ensemble

Superposez les trois de sorte qu’un emballement n’atteigne jamais la facture :
ContrôlePortéeQuand il se déclenche
Règle cap_costUne exécution d’agentLa dépense accumulée de l’exécution franchit le plafond en centimes
credit_limit_usdUne clé, à vieLa dépense totale de la clé atteint son plafond USD
burn_spike / retry_loopEspace de travail, apprisLa dépense ou le motif de répétition dévie de la baseline
Une baseline pratique : un cap_cost par exécution sur *, un credit_limit_usd sur chaque clé d’agent, et l’habitude de vérifier le flux d’anomalies. Déployez une nouvelle politique cap_cost en mode shadow d’abord — elle journalise [shadow] would deny sans bloquer — de sorte que vous puissiez dimensionner le plafond contre du trafic réel avant qu’il ne morde.
cap_cost et le flux d’anomalies bornent les appels d’outils et les exécutions qui franchissent la passerelle. Un outil qu’un agent exécute entièrement à l’intérieur de son propre processus n’atteint jamais le moteur. Routez les appels d’outils médiés par le modèle et MCP à travers la passerelle — et donnez à chaque clé un credit_limit_usd — de sorte que le plafond tienne peu importe comment l’agent boucle.

​
6. Menaces liées

Le denial of wallet arrive rarement seul — la boucle qui brûle votre budget est souvent pilotée par quelque chose en amont :
  • Injection de prompt — les instructions injectées sont un déclencheur courant d’éclatement et de spam d’outils.
  • Agence excessive — un agent avec trop de latitude a plus de façons de dépenser.
  • Appels d’outils dangereux — le même plan de règles de firewall borne ce qu’un outil peut faire, pas seulement combien il coûte.
  • Le modèle de menace — où le coût emballé s’inscrit dans la surface d’attaque agentique complète.

Vue d'ensemble du Firewall

Verdicts, détection d’anomalies, niveaux d’autonomie, et observabilité.

Clés et politiques scopées

Comment les limites de clé, les guardrails, et les politiques firewall se composent par clé.