Vai al contenuto principale
Un agent autonomo a lunga esecuzione è la cosa più difficile da proteggere. Gira in loop per ore, sceglie i propri tool, recupera i propri URL e spende i tuoi soldi tutto il tempo. Le modalità di fallimento non sono un singolo prompt sbagliato — sono un loop di retry che brucia 400$ durante la notte, una chiamata a tool che non hai mai esaminato, una chiave coniata per un esperimento di una settimana che funziona ancora sei mesi dopo. Questa ricetta collega quattro controlli attorno esattamente a quella forma di agent. Li configuri tutti nella console (o nella REST API) — l’agent continua a chiamare https://api.orcarouter.ai/v1/... esattamente come prima.
Nuovo qui? Applica prima la baseline balanced e osserva cosa fa il tuo agent per un giorno. Questa pagina è il passo successivo: trasformare l’osservazione in applicazione per un agent che non puoi fare da babysitter.

​
1. La ricetta per un agent autonomo sicuro

Un agent autonomo sicuro ha bisogno di quattro cose che un chatbot non ha:

Un tetto di costo rigido

Una regola cap_cost nega l’esecuzione una volta che la sua spesa accumulata supera il tuo cap — l’interruttore di sicurezza per un loop che non si ferma.

Rilevamento dei picchi

Il rilevamento delle anomalie apprende la forma ora-della-settimana normale dell’agent e segnala picchi di rate e costo che sfuggono alle regole statiche.

Approvazione sulle chiamate pericolose

Un verdetto pending_approval mette in attesa per un umano le chiamate a tool distruttive o irreversibili, anziché fidarsi che l’agent sia prudente.

Una chiave che scade

Dai scope alla chiave dell’agent con una scadenza e un tetto di credito così un esperimento dimenticato non può girare — o spendere — per sempre.
Ciascuno mappa su un campo di una policy Firewall o di una chiave. Nessuno tocca il codice del tuo agent.

​
2. Limita il costo di ogni esecuzione

La prima cosa che un loop fuori controllo fa saltare è il tuo budget. Una regola cap_cost è un tetto di costo a pre-controllo stretto: quando corrisponde, il gateway stima il costo della richiesta e nega prima del dispatch una volta che la spesa accumulata dell’esecuzione supererebbe il cap — così una chiamata fuori budget non raggiunge mai il provider. Il cap è con scope sull’esecuzione. Il gateway somma la spesa precedente su tutta l’esecuzione dell’agent, così un’esecuzione lunga che ha già bruciato la maggior parte del suo budget viene negata anche quando la prossima chiamata individuale è economica. È ciò che lo rende un interruttore di sicurezza piuttosto che un limite per-richiesta. Aggiungi una regola wildcard alla tua policy del firewall: 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
Questo limita l’esecuzione a $10 (cap_cost_cents è in centesimi USD). Il verdetto si risolve in allow mentre è sotto budget e deny una volta che la stima lo supererebbe. La maggior parte dei template integrati del firewall (Coding, Support, RAG, Data, DevOps, Browser) fornisce un cap di costo per esecuzione esattamente come questo — applicane uno e modifica il cap.
L’accumulo con scope sull’esecuzione richiede la cattura dei request-log abilitata per il workspace. Con essa disattivata, il rollup della spesa precedente legge zero e il cap degrada a solo per-richiesta — ancora sicuro, ma non coglierà uno stillicidio lento di 500 chiamate. Vedi denial-of-wallet.

​
3. Rileva i picchi rispetto a una baseline appresa

Un cap ferma la catastrofe; il rilevamento delle anomalie coglie lo strano prima che lo diventi. Il Firewall apprende la forma normale d’uso dei tool di ciascun workspace — una media mobile a 14 giorni raggruppata per ora-della-settimana, così il traffico del martedì-14:00 viene confrontato con la storia del martedì-14:00, non con una media giornaliera piatta — e fa emergere le deviazioni su un feed leggibile dal viewer:
Il volume di chiamate per tool valutato rispetto alla baseline appresa. “143 chiamate db.query in un’ora contro una baseline di 8” emerge anche quando ogni chiamata individuale è consentita.
La stessa baseline, applicata alla spesa anziché al conteggio — un’esecuzione che improvvisamente brucia molto più di quanto faccia di solito quest’ora.
La firma di un agent autonomo bloccato a ritentare la stessa chiamata rotta. Vedi agenzia eccessiva.
Un salto da tool a tool che questo workspace non ha mai fatto — la forma di un agent che va da qualche parte di nuovo.
Il feed riporta nomi di tool, id di token redatti e conteggi — mai argomenti grezzi. Leggerlo è aperto a qualsiasi Member; un Developer+ può mettere in snooze il feed per un massimo di 7 giorni mentre indaga. Abbina il feed a una regola cap_cost così un picco che è anche fuori budget viene fermato, non solo notato.

​
4. Metti in attesa di un umano le chiamate pericolose

Non puoi esaminare ogni chiamata che un agent autonomo fa — ma puoi farlo fermare e chiedere prima di quella manciata che conta. Un verdetto pending_approval mette in attesa una chiamata a tool fuori banda:
  1. L’agent emette, diciamo, una chiamata payments.transfer. La regola corrisponde e il motore restituisce HTTP 400 firewall_approval_pending con un id di approvazione — la chiamata non raggiunge mai il tool.
  2. Un revisore la risolve dalla console (Developer+), o il tuo sistema la risolve tramite un webhook callback firmato con HMAC verso POST /api/v1/firewall/approvals/:id/callback.
  3. L’agent fa polling su GET /api/v1/firewall/approvals/:id; una volta approvata ri-invia la chiamata originale con un header monouso X-OrcaRouter-Firewall-Approval, e il gateway la lascia passare quella sola volta.
Una regola che mette in attesa le scritture su una superficie distruttiva: 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
Fai il rollout di questo prima in shadow mode — pending_approval si declassa a audit, così vedi quali chiamate verrebbero messe in attesa senza bloccare effettivamente il tuo agent. Disattiva la shadow quando il feed sembra giusto.

​
5. Dai all’agent una chiave che scade

Il controllo che sopravvive a ogni policy è la chiave stessa. Un agent autonomo dovrebbe ricevere una chiave con scope, non la tua di default. Imposta questi campi quando la coni (console → chiavi, o la token API):
CampoImpostalo aPerché
expired_timeun timestamp UnixL’esperimento finisce; la chiave muore con esso. -1 significa mai — non usarlo qui.
credit_limit_usdun tetto in dollariUn cap di spesa sulla chiave indipendente dal cap dell’esecuzione. 0 significa illimitato.
firewall_policy_idla tua policy sopraCollega le regole cap_cost + approvazione a questa chiave.
allow_ipsgli IP di egress dell’agentUna chiave trapelata è inutile da qualsiasi altro posto.
Imposta anche un tag environment, così la chiave — e tutto ciò che fa in Events e Matches — è attribuibile a questo agent. Una chiave che scade, con cap di credito e fissata sugli IP è l’ultima linea: anche se ogni policy fosse in qualche modo bypassata, il blast radius è limitato dal tempo e dai dollari.
La configurazione della chiave è un’azione di console / token-API ed è role-gated. Leggere il plaintext di una chiave di firewall-gateway richiede Admin+.

​
6. Mettilo insieme

Un agent autonomo hardenizzato finisce con una policy del firewall e una chiave con scope:
LayerControlloCoglie
BudgetRegola cap_cost, con scope sull’esecuzioneLoop fuori controllo, denial-of-wallet
ComportamentoFeed delle anomalie (rate / burn / retry / novel)Lo strano-ma-consentito
Fiduciapending_approval sui tool distruttiviAzioni irreversibili
ScopeChiave che scade, con cap di credito, fissata sugli IPChiavi dimenticate o trapelate
Scrivi insieme le regole di budget e approvazione, imposta un cap per esecuzione con le regole del firewall, e leggi il resto del riferimento Firewall per superfici, verdetti e osservabilità. Per i threat correlati contro cui questa ricetta si difende, vedi agenzia eccessiva, chiamate a tool pericolose e denial-of-wallet.

​
7. Prossimi passi

Hardening di un agent MCP

Governa un agent che raggiunge i tool attraverso MCP server.

Fermare l'esfiltrazione

Regole di egress per un agent che recupera i propri URL.

Modalità di applicazione

Observe → shadow → enforce, il rollout sicuro.

Regole del firewall

Il linguaggio di matching dietro ogni regola qui sopra.