Vai al contenuto principale
Un agent che può raggiungere la rete può essere trasformato in un canale di dati. Un attaccante pianta istruzioni in un documento che l’agent legge — una pagina web, un chunk recuperato, il risultato di un tool — e quelle istruzioni dirigono l’agent a fare POST di dati sensibili verso un host controllato dall’attaccante, o a sondare servizi interni (SSRF). L’agent non “decide” di esfiltrare; esegue ciò che, per lui, sembra un’istruzione legittima. Questa pagina spiega come l’Agent Firewall e i Guardrails in OrcaRouter ti permettono di difenderti dall’esfiltrazione di dati AI — senza modificare il codice del tuo agent.
Il firewall vede l’egress solo per le destinazioni instradate attraverso il gateway tramite il percorso di dispatch MCP o l’evaluate hook. Un tool che il tuo agent esegue interamente dentro il proprio processo è al di fuori della sua visibilità. Instrada le chiamate a tool di rete del tuo agent attraverso il gateway e vengono governate.

​
1. Come funziona l’attacco

Il percorso canonico attraverso un agent si svolge in tre passi:
  1. Injection — l’agent legge contenuto non attendibile che porta istruzioni incorporate (una pagina web, un documento recuperato, una nota CRM).
  2. Raccolta — le istruzioni iniettate dicono all’agent di raccogliere materiale sensibile — chiavi API, righe di database, PII degli utenti — usando tool che già possiede.
  3. Esfiltrazione — all’agent viene detto di inviare quel materiale tramite un tool di tipo fetch: http_fetch, web_search, fetch_url o request. La destinazione è controllata dall’attaccante.
SSRF è la stessa forma reindirizzata verso l’interno: invece di un host esterno l’agent viene diretto verso 169.254.169.254 (metadati cloud), una porta Redis interna, o un altro servizio privato. Vedi Prompt injection per il passo di injection; questa pagina si concentra sul passo di rete.

​
2. Allowlist egress — blocca le destinazioni in uscita

La difesa più duratura è una allowlist egress: enumera gli host che i tuoi agent sono legittimamente autorizzati a raggiungere e nega tutto il resto. Una regola egress usa stage: egress e il campo egress. Il verdetto controlla la polarità — allow fa passare le destinazioni elencate; un deny catch-all a priorità più bassa blocca il resto: 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": [
        "api.openai.com",
        "api.anthropic.com",
        "api.orcarouter.ai"
      ]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
Le voci corrispondono come CIDR, un letterale IP o un hostname case-insensitive. Gli hostname vengono risolti best-effort e ri-verificati rispetto alle voci IP/CIDR, così una destinazione come 169.254.169.254 restituita dal DNS è comunque catturata da una voce deny CIDR 10.0.0.0/8. Una chiamata bloccata restituisce HTTP 400 con codice di errore firewall_blocked. Per negare range noti-malvagi senza una allowlist esplicita, scrivi una regola egress deny mirata che elenca l’endpoint dei metadati cloud (169.254.169.254) e i range RFC-1918 privati (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Sovrapponi la tua allowlist sopra a un numero di priorità più basso così le regole deny vengono valutate per prime.

​
3. Blocca i tool di tipo fetch al layer del nome

Prima ancora che venga valutata una destinazione egress, puoi rimuovere completamente la capability. Il livello di autonomia tight nega http_fetch, web_search, fetch_url e request tramite glob del nome del tool come backstop contro SSRF e esfiltrazione. Se il tuo agent non ha bisogno di nessuno di quei tool, tight rimuove la superficie d’attacco in un unico passo: 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
Per negare i tool di fetch senza adottare la postura tight completa, scrivi una regola deny sulla superficie inbound. inbound blocca il tool prima che il modello possa sceglierlo — l’agent non riceve mai la capability nella sua lista di tool: 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
Ripeti per ogni nome di tool di tipo fetch che il tuo stack di agent usa.

​
4. Guardrail Secrets Blocker — ferma le credenziali al prompt

Il guardrail Secrets Blocker gira allo stage input, scansionando il prompt per chiavi di accesso stile AWS, chiavi OpenAI, chiavi Anthropic, token GitHub e pattern di credenziali simili prima che la richiesta lasci il gateway. Se viene rilevato un segreto, la richiesta viene bloccata — la credenziale non raggiunge mai un modello e non appare mai in una chiamata a tool. Abilitalo dal pannello Guardrails, o come parte del livello di autonomia tight. È indipendente dalle regole egress del firewall.
MinacciaLayer che la ferma
Il prompt porta una chiave APISecrets Blocker (guardrail in input)
L’agent chiama un tool di fetch verso un host dell’attaccanteRegola egress allow/deny
Tool di tipo fetch pubblicizzato al modelloRegola deny inbound o autonomia tight
L’agent raggiunge i metadati cloud o RFC-1918Regola egress deny che elenca quei CIDR

​
5. Rollout con la shadow mode

Se non sei sicuro di quali host il tuo agent raggiunge legittimamente oggi, parti in shadow mode prima di applicare:
  1. Crea le regole egress con la tua allowlist intesa e imposta shadow_mode: true sulla policy.
  2. Guarda il feed Events — le chiamate che verrebbero bloccate appaiono come [shadow] would deny con la destinazione.
  3. Aggiusta la lista allow finché solo le destinazioni raggiungibili dall’attaccante verrebbero negate, poi disabilita la shadow mode per iniziare ad applicare.
Nessun traffico viene bloccato mentre la shadow mode è attiva.

​
6. Dove andare dopo

Riferimento regole del firewall

Linguaggio di matching completo — elenchi egress, CIDR, clausole sugli argomenti e tutti i verdetti.

Panoramica Agent Firewall

Policy, superfici, livelli di autonomia e osservabilità.

Prompt injection

Il passo di injection che dirige gli agent verso l’esfiltrazione.

MCP tool poisoning

Tool MCP malevoli che registrano capability di tipo fetch.