Vai al contenuto principale
Il giorno in cui metti un agent davanti agli utenti è il peggior giorno per scoprire che un jailbreak passa dritto attraverso la tua content policy, o che un tool che hai dimenticato di governare scatta alla prima esecuzione. Un red team pre-lancio trasforma quelle sorprese in un numero che puoi leggere prima di spedire — e OrcaRouter ti dà tre modi per produrlo, tutti senza toccare il codice del tuo agent o inviare una singola richiesta live che non intendevi. Questa ricetta è la passata di dry-run: misura una policy contro attacchi noti, shadow contro il tuo stesso traffico, e simula una postura più stretta prima di impegnartici.
Tutto qui è in sola lettura o in sandbox — nessun block visibile all’utente, nessun traffico di produzione interessato. (Le regole keyword, regex e PII girano interamente in locale; una regola llm_judge chiama comunque il suo modello configurato, quindi un eval su una policy con judge fa quella chiamata.) Il punto è rompere le cose prima del lancio, alle tue condizioni.

​
1. Come fare red team di un agent AI prima del lancio

Un red team pre-lancio risponde a tre domande, e OrcaRouter ha uno strumento per ciascuna:

Il mio guardrail coglie gli attacchi?

Esegui l’Eval harness del guardrail contro corpora adversarial integrati e leggi precision / recall / F1.

Cosa romperebbe il mio firewall?

Attiva la shadow mode e osserva quali chiamate a tool reali verrebbero negate — senza negarne ancora alcuna.

Una postura più stretta è sicura?

Simula un livello di autonomia per fare un’anteprima esatta di cosa cambierebbe contro il tuo traffico prima di applicarlo.
Il primo testa i tuoi Guardrails (il piano del testo); il secondo e il terzo testano il tuo Firewall (il piano delle azioni). Una vera checklist di lancio esegue tutti e tre.

​
2. Assegna un punteggio al tuo guardrail contro corpora adversarial

Il modo più rapido per sapere se una content policy sopravvive al contatto con un attaccante è lanciarle contro un corpus di attacchi noti e leggere il punteggio. Il tab Eval dell’editor del guardrail fa esattamente questo: riproduce ogni campione di un corpus attraverso la tua policy corrente e confronta il verdetto con l’esito atteso di ciascun campione — riproducendo il corpus localmente contro le tue regole, mai contro il traffico live. OrcaRouter fornisce corpora red-team integrati così non devi procurarti i tuoi. Tra questi:
CorpusCos’è
advbench_harmful_behaviorsIl target set canonico di suffissi adversarial — ogni riga è una richiesta non sicura che un guardrail dovrebbe bloccare.
anthropic_hh_redteamTrascrizioni reali di red-team umano multi-turn contro un assistant.
deepset_prompt_injectionsRichieste etichettate prompt-injection vs benigne — una baseline di precision/recall per un block allo stage di input.
databricks_dolly_benignUna baseline puramente benigna: una policy troppo stretta non dovrebbe bloccarne nessuna.
Abbina sempre un corpus di attacchi a uno benigno. Una policy che blocca il 100% degli attacchi ma blocca anche databricks_dolly_benign non è sicura — è inusabile. L’esecuzione benigna è il tuo budget di falsi positivi.
Esegui un eval contro il corpus integrato deepset_prompt_injections: 
curl https://api.orcarouter.ai/api/guardrail/123/eval \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{ "corpus_name": "deepset_prompt_injections" }'
Le rotte /api/guardrail/* usano la tua sessione di console / access token, non una chiave di relay sk-orca-... — e hanno scope a livello di workspace tramite X-Workspace-Id. In pratica eseguirai questo dal tab Eval nella console; il curl è qui per mostrare la forma. Eseguire un eval è aperto a qualsiasi Member.
L’esecuzione riporta le metriche di rilevamento calcolate contro le azioni attese:
  • TP / FP / FN / TN — veri/falsi positivi e negativi, dove un “falso positivo” include cogliere un attacco con la classe di azione sbagliata (es. mascherare quando ti aspettavi un block).
  • Precision / Recall / F1 — i numeri di testa. Bassa recall significa che gli attacchi sfuggono; bassa precision significa che stai bloccando traffico benigno.
Apri l’esecuzione per ispezionare i fallimenti campione per campione, metti a punto la regola o la rubrica del judge, e ri-esegui finché il punteggio tiene. I corpora custom funzionano allo stesso modo — carica i tuoi JSONL (Developer+) per testare contro le esatte forme di attacco che il tuo prodotto affronta.
Dove vive la difesa dalla prompt-injection. Il preset integrato Prompt-Injection Basics è una regola per keyword sull’azione flag — fa emergere le frasi di jailbreak comuni per revisione senza bloccare l’utente. Per l’intento di injection semantico che nessuna lista di keyword cattura, aggiungi una regola llm_judge e fanne red-team allo stesso modo: fai eval contro deepset_prompt_injections e anthropic_hh_redteam e leggi l’F1. Vedi il riferimento guardrail.

​
3. Shadow-mode del firewall contro il traffico reale

Un eval di guardrail testa il testo contro un corpus fisso. Il tuo firewall, al contrario, deve essere testato contro la realtà disordinata di ciò che il tuo agent fa effettivamente — e il modo più sicuro per farlo prima del lancio è la shadow mode. La shadow mode è un flag per-policy che fa valutare e loggare al firewall ogni chiamata a tool esattamente come farebbe in produzione, ma declassa ogni verdetto applicativo a audit. Un deny diventa una riga di audit la cui motivazione è prefissata [shadow] would …. Nulla è bloccato. Nulla si rompe. Ma il feed Events ora ti mostra l’elenco preciso delle chiamate che la tua policy avrebbe rifiutato. Questo è il red team del firewall: scrivi la tua policy più stretta intesa, attiva la shadow mode, esegui il tuo agent attraverso una prova di lancio realistica, poi leggi gli event [shadow] would ….
Costruisci la tua policy applicativa nella console (Developer+) — per un dry-run di lancio, imposta default_verdict ad audit e aggiungi le regole di deny che intendi spedire. Attiva la shadow mode. L’intera policy ora logga senza applicare.
Esegui i tuoi flussi di agent reali contro il gateway con una chiave collegata alla policy in shadow. Ogni chiamata a tool — inbound, response, dispatch MCP, egress — è valutata e loggata.
Apri Firewall → Events (Developer+) e filtra per le motivazioni [shadow] would …. Ognuna è una chiamata che la tua policy avrebbe negato in produzione. Conferma che ogni voce sia una chiamata che vuoi negata — e che nulla di legittimo sia nella lista.
Una volta che la lista degli avrebbe-bloccato è pulita, disattiva la shadow mode. La chiamata corrispondente successiva è applicata per davvero — nessun altro cambiamento.
Abbina la shadow mode all’observe mode (un’impostazione di workspace) per la copertura, non solo la correttezza. L’observe mode logga ogni chiamata a tool che si risolve in nessuna policy come un gap, popolando la vista Discovered tools — così cogli il tool che hai dimenticato di scrivere una regola per, non solo le regole che hai sbagliato. Vedi modalità di applicazione.

​
4. Simula una postura più stretta prima di impegnarti

La terza mossa di red-team è la più economica: prima di applicare un livello di autonomia più stretto, simulalo. Il simulatore fa un’anteprima di cosa applicare tight (o qualsiasi livello) cambierebbe contro il traffico recente del tuo workspace — quante chiamate passerebbero a deny — senza scrivere una singola riga di policy. 
curl "https://api.orcarouter.ai/api/workspace/firewall/simulate?level=tight" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>"
Leggere il simulatore è aperto a qualsiasi Member. Usalo per rispondere “il mio agent è pronto per tight?” prima del lancio: se l’anteprima mostra un muro di diniegi su chiamate da cui il tuo agent dipende, hai regole da ammorbidire prima del go-live, non un incidente dopo.
Simulate è solo anteprima — non muta mai le tue policy. Applicare un livello di autonomia è un’azione separata, Developer+, ed è una transazione con undo a un clic se il risultato live ti sorprende comunque.

​
5. La checklist di red-team pre-lancio

Metti insieme le tre passate e hai un gate di lancio:
PassataStrumentoVerde quando
Content policyGuardrail Eval vs corpora di attacco + benigniAlta recall sugli attacchi, nessun block sui benigni
Action policyShadow mode del firewall vs traffico di provaOgni [shadow] would … è intenzionale
CoperturaObserve mode + Discovered toolsNessun tool a sorpresa siede in un gap di copertura
PosturaSimulate il livello di autonomia targetL’anteprima combacia con ciò che ti aspetti
Esegui tutti e quattro in verde, poi applica: disattiva la shadow mode e applica il tuo livello di autonomia. Poiché ogni binding vive sulla chiave nel gateway, il passaggio da dry-run a live è una modifica di config, non un deploy — il tuo agent continua a chiamare https://api.orcarouter.ai/v1/... esattamente come prima.
Il masking allo stage di output e lo scanning live della risposta stanno ancora maturando — un’esecuzione di eval dimostra la logica di una regola nella sandbox, ma conferma la tua specifica combinazione di stage e streaming contro le note sui guardrail prima di farci affidamento in produzione.

​
6. Prossimi passi

Modalità di applicazione

Observe → shadow → enforce, il rollout sicuro che questa ricetta prova.

La baseline Secure Agents

Cosa imposta ogni livello di autonomia — e come simulate lo fa in anteprima.

Prompt injection

Il threat contro cui il tuo eval di guardrail assegna il punteggio.

Go live

Il cutover di produzione dopo che il red team passa.
Per i motori completi dietro ogni passata, vedi i riferimenti Guardrails e Firewall, e i threat correlati: jailbreak e chiamate a tool pericolose.