Vai al contenuto principale
Un agent che può raggiungere la rete può essere trasformato in un tubo di dati. Istruzioni iniettate gli dicono di raccogliere segreti, righe o PII con i tool che già possiede e di farne POST verso un host dell’attaccante — o di sondare servizi interni (SSRF). L’agent non “decide” mai di esfiltrare; esegue ciò che, per lui, sembra un’istruzione legittima. Questa ricetta collega tre controlli che chiudono il loop end-to-end — una allow-list di egress che blinda dove le chiamate in uscita possono andare, il guardrail Secrets Blocker che ferma le credenziali prima che raggiungano un modello, e un sanitizer degli argomenti che rimuove i segreti dalle chiamate a tool che un modello emette. Tutto vive nel gateway, quindi lo configuri una volta nella console con zero modifiche al codice del tuo agent. Per l’anatomia completa dell’attacco, leggi Esfiltrazione di dati sulla rete; questa pagina è i passi di build.
Tutto qui si collega al tuo workspace ed è configurato dalla console. Il tuo agent continua a chiamare https://api.orcarouter.ai/v1/... con la stessa chiave sk-orca-... — cambia solo la policy nel gateway. Le azioni di configurazione richiedono i ruoli indicati per ciascun passaggio; le chiamate di relay usano la chiave con scope. Il firewall vede l’egress solo per destinazioni instradate attraverso il gateway (il percorso di dispatch MCP o l’hook di evaluate) — instrada le tue chiamate a tool rivolte alla rete attraverso di esso e sono governate.

​
1. I tre layer che prevengono l’esfiltrazione di dati AI

Ogni layer coglie l’attacco in un punto diverso del ciclo di vita della richiesta. Impila tutti e tre — sono indipendenti e complementari.

Credenziali nel prompt

Un segreto incollato (o tirato) nella richiesta viene colto allo stage di input dal guardrail Secrets Blocker — prima che qualsiasi modello lo veda.

Segreti negli args dei tool

Un modello che emette una chiamata a tool che porta una credenziale viene ripulito da una regola sanitize del firewall, che redige l’argomento corrispondente.

Destinazione in uscita

Il passo di rete effettivo è limitato da una allow-list di egress — solo gli host enumerati passano; tutto il resto è negato.
Questa ricetta usa entrambi i piani: Guardrails per il testo nella richiesta, il Firewall per le azioni e la rete. Vedi guardrails vs firewall per dove si trova la linea.

​
2. Ferma le credenziali al prompt — il guardrail Secrets Blocker

La prima cosa da blindare è la credenziale stessa. Il guardrail Secrets & API-Key Blocker gira allo stage di input e scansiona la richiesta in cerca di pattern di credenziali — chiavi di accesso in stile AWS, chiavi OpenAI, JWT e token simili — prima che la richiesta lasci il gateway. Su un match la richiesta viene bloccata: la credenziale non raggiunge mai un modello e non finisce mai in una chiamata a tool. Nella console, apri Guardrails → New guardrail (il ruolo Developer; le letture e la sandbox di Test sono aperte a qualsiasi membro), chiamalo exfil-shield e applica il preset Secrets & API-Key Blocker dalla libreria dei template (categoria secrets). Il preset semina tre regole di block regex allo stage input, una per forma di credenziale — chiavi di accesso AWS, chiavi in stile OpenAI e token GitHub: 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
Per estendere la copertura, aggiungi una regola pii sulle entità integrate — l’insieme di detector copre email, phone, credit_card, ssn, ip, iban, mac_address, api_key_openai, aws_access_key, jwt e bitcoin_address. Scegli mask (redigi in un tag tipizzato come [EMAIL]) o block per entità tramite entity_actions. Il masking allo stage di input è attivo; riscrive la richiesta prima che il modello la veda.
Una richiesta bloccata restituisce HTTP 400 guardrail_blocked, non costa alcuna quota (un block allo stage di input scatta prima del metering) ed è marcata skip-retry. Dimostralo nel tab Test — incolla una chiave AWS di esempio, scegli lo stage input e conferma il verdetto — prima di collegare una chiave.

​
3. Sanitizza i segreti fuori dagli argomenti delle chiamate a tool

Un guardrail filtra il prompt; non vede le chiamate a tool che un modello emette. Quando il modello produce un tool_call i cui argomenti portano una credenziale, una regola sanitize del firewall la coglie. Sanitize redige le sottostringhe corrispondenti dagli argomenti della chiamata a tool e inoltra la chiamata ripulita — il tool gira, ma con il segreto rimosso. In Firewall → Policies → New policy (ruolo Developer), chiamala exfil-firewall e aggiungi una regola sanitize sulla superficie response — i tool_calls che il modello emette nella sua risposta: 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
Sanitize redige solo gli argomenti della chiamata a tool — mai il contenuto che un tool restituisce. È una difesa sulla forma della chiamata in uscita, non sui risultati di tool in entrata. Sulla superficie inbound (dove non ci sono ancora argomenti al momento della chiamata) un verdetto sanitize escala a un deny. Vedi il linguaggio di matching completo in Regole del firewall.

​
4. Blinda le destinazioni in uscita — la allow-list di egress

La difesa più durevole è il confine di rete stesso: 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 imposta la polarità — allow lascia passare le destinazioni elencate e un catch-all deny a priorità più bassa blocca il resto. Aggiungi queste regole alla stessa policy exfil-firewall: 
[
  {
    "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 un CIDR, un IP literal o un hostname case-insensitive. Per fermare l’SSRF verso servizi interni senza una allow-list esplicita, scrivi la tua regola egress di deny che elenca l’endpoint di cloud metadata (169.254.169.254) e i range privati RFC-1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Una chiamata negata restituisce HTTP 400 firewall_blocked.
Nessun preset fornisce regole egress CIDR — scrivi tu stesso le voci di allow e deny host/CIDR. Il livello di autonomia tight è il percorso rapido adiacente: nega del tutto i nomi di tool a forma di fetch (http_fetch, web_search, fetch_url, request), rimuovendo la capability di rete prima che una destinazione sia mai valutata. Usalo quando il tuo agent non ha affatto bisogno di quei tool.

​
5. Collega un’unica chiave con scope

Una policy applica solo sulle chiavi che si risolvono su di essa. Dai all’agent la sua chiave, con scope al minimo necessario — mai la tua chiave a livello di account. In API Keys → New key (ruolo Developer):
Scegli exfil-shield dal dropdown Guardrail (imposta guardrail_id) e exfil-firewall dal dropdown Firewall policy (imposta firewall_policy_id). Entrambi i binding vivono sulla chiave nel gateway. Un collegamento esplicito di guardrail non ricade mai silenziosamente — disabilitarlo è l’interruttore di disattivazione. Una policy firewall disabilitata, al contrario, ricade sulla policy di default del workspace.
Imposta credit_limit_usd a un tetto sensato (0 = illimitato) così una chiave compromessa non può drenare quota, e allow_ips sugli IP di egress del tuo backend se l’agent chiama da un server fisso. Imposta un expired_time per le chiavi temporanee (-1 = non scade mai).
La chiave è mascherata in visualizzazione dopo la creazione — copiala una sola volta. Il tuo agent ora esegue ogni richiesta attraverso exfil-shield e ogni chiamata a tool attraverso exfil-firewall senza che alcun codice sappia che l’applicazione sta avvenendo.

​
6. Fai il rollout con shadow mode, poi osserva

Se non conosci ancora ogni host che il tuo agent raggiunge legittimamente, non applicare alla cieca — osserva prima. Vedi modalità di applicazione per il percorso completo observe → shadow → enforce.
1

Shadow delle regole egress

Imposta shadow_mode: true su exfil-firewall. Ogni verdetto applicativo viene declassato a audit e loggato come [shadow] would deny con la destinazione. Nessun traffico viene bloccato mentre la shadow mode è attiva.
2

Osserva i feed

Firewall → Events / Runs (Developer+) mostra ogni chiamata a tool e destinazione di egress che il tuo agent ha colpito e cosa verrebbe negato. Guardrails → Matches (qualsiasi Member) mostra ogni segreto che il guardrail di input ha colto. Metti a punto la lista allow di egress finché solo gli host raggiungibili dall’attaccante verrebbero negati.
3

Applica

Disattiva shadow_mode. La richiesta successiva è governata — credenziali bloccate al prompt, segreti rimossi dagli args dei tool, chiamate in uscita confinate alla tua allow-list. Nessuna modifica all’applicazione.
Il feed Matches registra la sottostringa corrispondente solo quando Log raw content è attivo per il guardrail (disattivato per default — la postura conservativa sulla privacy). Marca un falso positivo (Admin) per mettere a punto la policy. Ogni modifica al guardrail scrive una riga di version-history che puoi fare diff e revert; le modifiche alla policy del firewall sono registrate nella traccia di audit.

​
7. Copertura a colpo d’occhio

Passo di esfiltrazioneLayer che lo ferma
La credenziale entra nella richiestaGuardrail Secrets Blocker (input)
Il modello emette una chiamata a tool che porta un segretoRegola sanitize del firewall (superficie response)
Il tool compone un host dell’attaccanteRegola egress allow / deny
L’agent raggiunge cloud metadata o RFC-1918Regola egress di deny che elenca quei CIDR
Tool a forma di fetch offerto al modelloLivello di autonomia tight (deny sul nome del tool)

​
8. Dove andare dopo

Riferimento regole del firewall

Il linguaggio di matching completo — liste egress, CIDR, sanitizer e tutti i verdetti.

Threat di esfiltrazione di dati

L’anatomia dell’attacco contro cui questa ricetta si difende, end to end.

Hardening di un agent MCP

Governa ogni tools/call che un agent dispatcha attraverso un MCP server.

Logging PII-safe

Tieni i dati sensibili fuori dai tuoi request-log e dal feed Matches.