Vai al contenuto principale
Un agent non deve far trapelare dati per danneggiarti. Può semplicemente spendere — un retry loop che martella un modello costoso, un’istruzione iniettata via prompt che dirama mille chiamate a tool, o una chiave API trapelata che accumula inferenza finché non arriva il conto. Questo è il denial of wallet: l’attacco è il costo stesso. A differenza di un classico denial-of-service, il gateway resta su e ogni richiesta sembra individualmente legittima — il danno è la spesa aggregata. OrcaRouter ti dà tre tetti indipendenti che si trovano tutti davanti al modello upstream, così nessun singolo percorso incontrollato può far correre il tuo conto senza limiti.

​
1. La minaccia denial of wallet AI

Un incidente di denial-of-wallet di solito riconduce a una di tre forme:
Un agent ritenta lo stesso tool che fallisce o ri-pianifica in un loop stretto, ripagando i token a ogni passaggio. Nessuna malizia richiesta — basta una cattiva condizione di stop.
Una prompt injection pilota l’agent nel fare spam di un tool o nell’emettere richieste sovradimensionate, moltiplicando la spesa per turno.
Una chiave finisce dove non dovrebbe — un .env committato, un notebook condiviso — e un attaccante esegue inferenza sul tuo account finché la spesa non viene notata.
La difesa è la stessa in tutti e tre i casi: un tetto netto che l’attaccante non può aggirare a parole, applicato al gateway, non nel codice del tuo agent.

​
2. Tetto di costo per run con cap_cost

Il verdetto cap_cost del Firewall è un interruttore di sicurezza per i loop incontrollati. Lo scrivi come una regola con un tetto in centesimi per run; il motore somma la spesa accumulata della run dell’agent e, una volta che la run supera il tetto, risolve il verdetto a deny — ogni chiamata a tool successiva in quella run viene bloccata. cap_cost è un tetto pre-dispatch: valuta prima che la chiamata raggiunga il tool, così ferma la prossima chiamata costosa anziché rimborsarne una già fatta. Un tipico tetto catch-all su ogni tool: 
{
  "priority": 50,
  "label": "cap runaway spend at $5 per run",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Sotto il tetto la chiamata è consentita; sopra, la run viene negata con un HTTP 400 firewall_blocked — marcato skip-retry, così il loop non può martellare attorno al deny. Il tetto è per run dell’agent e sommato sull’intera policy del tuo workspace, così una conversazione incontrollata non può sconfinare nel budget di un’altra.
cap_cost legge la spesa corrente dai tuoi log delle richieste. Tieni attiva la cattura dei log delle richieste per il workspace così il rollup della spesa corrente ha righe da sommare — altrimenti la stima della spesa pregressa è conservativamente 0 e il tetto non può vedere quanto una run è già costata.
Vedi il riferimento delle regole del Firewall per il linguaggio di matching completo e dove si colloca cap_cost tra gli altri verdetti.

​
3. Budget netto per chiave con credit_limit_usd

cap_cost limita una singola run. Per limitare una chiave — ogni run che emetterà mai — imposta credit_limit_usd sulla chiave API. È un tetto netto in USD sulla spesa a vita di quella chiave: il gateway lo converte nella quota rimanente della chiave, e una volta che la chiave ha speso la sua allowance, ulteriori chiamate di relay vengono rifiutate per credito insufficiente. 0 significa illimitato. Abbinalo agli altri scope della chiave così una chiave trapelata è limitata su ogni asse in una volta:

credit_limit_usd

Tetto netto di spesa in USD per la chiave (0 = illimitato).

expired_time

Timestamp di auto-scadenza (-1 = mai). Una chiave di breve durata limita la finestra del raggio d’azione.

allow_ips

Fissa la chiave a IP sorgente noti — una chiave trapelata è inutile fuori rete.

model_limits

Limita la chiave a modelli specifici, così non può raggiungere affatto quelli più costosi.
Dai a ogni agent la sua chiave con scope ristretto con un credit_limit_usd che non dovrebbe mai legittimamente superare. Il limite è il budget, non un’ipotesi sul comportamento dell’attaccante — anche una chiave completamente compromessa si ferma al tetto.
Configura tutto questo dall’editor di chiavi della console (o dalla token API) sotto la tua sessione — queste sono impostazioni di chiave, non chiamate di relay. Solo le richieste di inferenza /v1/* usano la chiave sk-orca-... stessa. Modificare il limite ha effetto alla richiesta successiva della chiave; nessun redeploy.

​
4. Cattura il picco che non avevi previsto: anomalie di costo

Un tetto statico ferma la spesa che anticipavi. L’anomaly detection del Firewall cattura la spesa che non anticipavi. Apprende la forma normale dell’uso dei tool di ciascun workspace rispetto a una baseline ora-della-settimana (una media mobile a 14 giorni) e fa emergere le deviazioni su un feed leggibile dai Member:
AnomaliaCosa segnala
burn_spikeCosto di un tool molto sopra il suo costo di baseline appreso — il segnale di denial-of-wallet.
rate_spikeVolume di chiamate molto sopra la baseline — fan-out e flood.
retry_loopLo stesso tool con gli stessi argomenti che si ripete in una finestra stretta — il classico loop incontrollato.
Così “questo tool ha bruciato 40× il suo costo abituale quest’ora” salta all’occhio anche quando ogni singola chiamata era consentita dalla policy. Puoi mettere in snooze un’anomalia per un massimo di 7 giorni mentre indaghi.
L’anomaly detection è il tuo preavviso; cap_cost e credit_limit_usd sono gli stop netti. Osserva il feed per scoprire dove vive la tua spesa reale, poi scrivi un tetto attorno ad essa.

​
5. Mettere tutto insieme

Stratifica i tre così un incontrollato non raggiunge mai il conto:
ControlloScopeQuando scatta
regola cap_costUna run dell’agentLa spesa accumulata della run supera il tetto in centesimi
credit_limit_usdUna chiave, a vitaLa spesa totale della chiave raggiunge il suo tetto in USD
burn_spike / retry_loopWorkspace, appresoLa spesa o il pattern di ripetizione devia dalla baseline
Una baseline pratica: un cap_cost per run su *, un credit_limit_usd su ogni chiave dell’agent e l’abitudine di controllare il feed delle anomalie. Fai il rollout di una nuova policy cap_cost in shadow mode prima — logga [shadow] would deny senza bloccare — così puoi dimensionare il tetto contro traffico reale prima che morda.
cap_cost e il feed delle anomalie limitano le chiamate a tool e le run che attraversano il gateway. Un tool che un agent esegue interamente dentro il proprio processo non raggiunge mai il motore. Instrada le chiamate a tool mediate dal modello e MCP attraverso il gateway — e dai a ogni chiave un credit_limit_usd — così il tetto regge indipendentemente da come l’agent fa loop.

​
6. Minacce correlate

Il denial of wallet arriva raramente da solo — il loop che brucia il tuo budget è spesso guidato da qualcosa a monte:
  • Prompt injection — le istruzioni iniettate sono un trigger comune per il fan-out e lo spam di tool.
  • Agenzia eccessiva — un agent con troppa latitudine ha più modi per spendere.
  • Chiamate a tool pericolose — lo stesso piano di regole del firewall limita cosa un tool può fare, non solo quanto costa.
  • Il threat model — dove il costo incontrollato si colloca nella superficie di attacco agentica completa.

Panoramica del Firewall

Verdetti, anomaly detection, livelli di autonomia e osservabilità.

Chiavi e policy con scope

Come limiti di chiave, guardrail e policy del firewall si compongono per chiave.