Vai al contenuto principale
Un coding agent è la cosa a più alta leva nel tuo workspace e la più pericolosa. Esegue shell.exec, modifica file, recupera URL e carica skill della community — ognuna di queste può fare rm -rf di un volume, leggere un .env o esfiltrare verso un host dell’attaccante. Questa ricetta blinda quella superficie con il Firewall: nega la shell distruttiva, valida gli argomenti delle chiamate che consenti, recinta l’egress e mette in attesa di un umano le operazioni genuinamente rischiose. Niente di tutto ciò tocca il codice del tuo agent — la policy vive nel gateway ed è applicata alla chiamata successiva.
Tutto quanto segue è configurato nella console (Firewall → Posture / Policies). Quelle rotte di gestione usano la tua sessione di console, non una chiave di relay. Solo le chiamate /v1/* che il tuo agent fa portano una chiave sk-orca-…. Le modifiche alla policy richiedono il ruolo Developer.

​
1. Inizia osservando, non bloccando — baseline del coding agent sicuro

Non scrivere regole alla cieca. Dai all’agent la sua chiave sk-orca-…, poi apri Firewall → Posture e applica il livello di autonomia balanced. In una transazione questo auditerà ogni chiamata a tool, segnala le PII e nega la shell distruttiva — così l’azione peggiore è già recintata mentre apprendi il resto del comportamento dell’agent dal traffico reale. Lascialo girare, poi leggi Firewall → Discovered tools: ogni tool che il workspace ha visto, marcato covered (si applica una regola) o gap (nessuna lo fa). Quell’elenco è la bozza della tua allow-list. Quando il feed sembra giusto, passa a tight (default-deny) o scrivi la policy mirata qui sotto.
balanced è la postura di partenza consigliata; permissive non blocca nulla ma logga comunque tutto; tight è default-deny più i preset secrets e SSRF. Vedi la baseline per esattamente cosa materializza ciascuno.

​
2. Nega la shell distruttiva — il pavimento non negoziabile

La regola singola più importante per un coding agent è niente shell distruttiva. I livelli di autonomia balanced e tight la forniscono già come preset Block destructive shell, che materializza regole deny reali e modificabili che coprono sia i nomi di tool diretti del workspace (shell.*, bash, cmd.*, powershell.*, exec.*) sia le forme con namespace MCP che un server registrato espone (*.shell.*, *.cmd.*, …). Se preferisci restringerlo più di “nega tutta la shell”, scrivi una regola che nega solo i comandi distruttivi e auditerà il resto. Una regola corrisponde su un glob del nome del tool più un predicato sugli argomenti opzionale (JSONPath contro gli argomenti della chiamata):
In Firewall → Policies, aggiungi una regola sopra il tuo default:
  • Tool glob: shell.exec
  • Args match (clausola JSONPath):
{
  "clauses": [
    { "path": "$.command", "op": "regex", "value": "(?i)\\brm\\s+-[a-z]*[rf]" }
  ]
}
  • Verdetto: deny
Gli operatori sugli argomenti sono un insieme chiuso — eq, contains, regex, in, cidr_match, gt, lt. Una chiamata il cui $.command corrisponde al regex viene bloccata; tutto il resto cade nella regola successiva.
Una chiamata negata sulla superficie inbound restituisce HTTP 400 con codice di errore firewall_blocked e un messaggio che nomina il tool e la motivazione. Una chiamata dispatchata attraverso il gateway MCP torna indietro come un errore di tool (firewall deny: …) così il modello può reagire invece di andare in crash. I block inbound scattano prima della chiamata al modello a monte, quindi non costano token del modello.
Vedi Regole del firewall per il linguaggio di matching completo (glob di tool, clausole sugli argomenti, sequenze, cap di costo).

​
3. Valida gli argomenti sui tool che mantieni

Consentire un tool non è la stessa cosa che consentire ogni argomento ad esso. Lo stesso predicato JSONPath che dà scope a un deny ti permette di vincolare la forma di una chiamata consentita — così db.query non può portare un DROP, e file.write non può uscire da una directory.

Blocca un DROP SQL

Glob db.query, clausola {"path":"$.sql","op":"regex","value":"(?i)\\bdrop\\b"}, verdetto deny.

Redigi un segreto negli args

Il verdetto sanitize redige le sottostringhe corrispondenti dagli argomenti della chiamata a tool prima che la chiamata sia inoltrata. Non tocca mai ciò che un tool restituisce; sulla superficie inbound (nessun argomento al momento della chiamata) escala a un block.
Il Firewall sanitizza gli argomenti delle chiamate a tool, non i risultati dei tool. Per impedire a un segreto di entrare in una richiesta in primo luogo, collega il guardrail Secrets Blocker alla chiave — quello filtra il testo del prompt stesso prima che il modello lo veda. I due piani si compongono: i guardrail filtrano il testo, il Firewall governa l’azione.

​
4. Controlla l’egress — recinta dove l’agent può arrivare

Un coding agent che può recuperare URL può essere sterzato in un SSRF (colpendo il cloud-metadata o un host interno 10.x) o usato per esfiltrare. Il livello di autonomia tight fornisce un preset SSRF che nega i nomi di tool a forma di fetch (http_fetch, web_search, fetch_url, request, e le loro forme <server>.*) del tutto. Per il controllo a livello di destinazione, scrivi una regola egress. Le regole egress danno scope per host o CIDR con voci allow / deny, valutate sulla superficie egress: 
{ "deny": ["169.254.169.254", "10.0.0.0/8", "*.internal"] }
Questo scatta su qualsiasi destinazione in uscita riportata da un tool che cade su un range privato, l’IP di cloud-metadata o un hostname interno — lasciando passare le destinazioni pubbliche mentre recinta quelle pericolose.
Nessun preset fornisce regole egress basate su CIDR — il preset SSRF corrisponde sui nomi di tool a forma di fetch. La denylist host/CIDR sopra è una che scrivi tu stesso. Vedi Fermare l’esfiltrazione per il pattern completo.

​
5. Metti in attesa di un umano le operazioni rischiose (HITL)

Alcune operazioni non dovrebbero essere auto-consentite né auto-negate — un deploy, un git push, una migrazione distruttiva. Per quelle, usa il verdetto pending_approval. La chiamata viene messa in attesa, l’agent riceve una risposta “held” con un id di approvazione, e un revisore la risolve fuori banda:
  1. Scrivi una regola (es. glob deploy.*, verdetto pending_approval).
  2. La chiamata held restituisce HTTP 400 firewall_approval_pending con un id di approvazione.
  3. Un revisore la approva dalla console (Developer+) o tramite un webhook callback firmato con HMAC.
  4. L’agent fa polling sull’approvazione, poi ri-invia la chiamata originale con un header monouso X-OrcaRouter-Firewall-Approval — e il gateway la lascia passare quella sola volta.
Fai il rollout di ogni nuova policy prima in shadow mode. La policy valuta e logga esattamente come farebbe in produzione, ma ogni verdetto applicativo viene declassato a audit con una motivazione [shadow] would … — così puoi dimostrare che scatta su ciò che ti aspetti prima che possa rompere una build.

​
6. Governa le skill e gli MCP server che carica

I coding agent tirano dentro capability a runtime — skill della community, MCP server BYO. Il Firewall governa entrambi al gateway:
  • Le skill vengono scansionate in una fascia di rischio con una modalità di applicazione (allow / quarantine / block). Una skill auto-rilevata viene messa in quarantine — tenuta per approvazione — finché un revisore non la sdogana. Vedi Skill.
  • Gli MCP server che registri dispatchano ogni tools/call attraverso il gateway, che valuta ciascuno sulla superficie mcp prima del dispatch. Le credenziali sono memorizzate cifrate; una sonda di salute riporta ok / degraded / down. Vedi MCP server e Hardening di un agent MCP.

​
7. Verifica e osserva

Prima di fare affidamento su una policy, eseguila in dry-run. Il tab Test valuta una chiamata a tool di esempio contro la policy corrente e mostra il verdetto, la regola corrispondente e la motivazione — nulla viene dispatchato, nulla persistito. Una volta live, Firewall → Events / Runs è il record di ogni valutazione, filtrabile per verdetto, superficie, tool ed esecuzione, e il feed delle anomalie segnala picchi di rate/costo rispetto alla baseline appresa del workspace, retry_loop e percorsi di tool mai visti prima.

​
Ricapitolando

Riferimento Firewall

Il piano della policy completo — superfici, verdetti, risoluzione, autonomia.

Regole del firewall

Il linguaggio di matching: glob, clausole sugli argomenti, egress, sequenze.

Chiamate a tool pericolose

Il threat contro cui questa ricetta si difende.

Agenzia eccessiva

Perché gli agent con troppi permessi sono il rischio centrale degli agent.

Ricetta per agent autonomo

Blinda end to end un loop di agent completamente autonomo.

Fermare l'esfiltrazione

I pattern di egress e lethal-trifecta in profondità.