Vai al contenuto principale
Hai scritto un guardrail e una policy del firewall per il tuo workspace. Ora vuoi che questa singola chiave — quella usata dal tuo agent finanziario — applichi una policy sui contenuti più rigida e un’allow-list di tool più stretta del resto del workspace. È ciò che fanno i due campi di collegamento su una chiave: collegano un guardrail e una policy del firewall a una singola chiave, e ogni richiesta che quella chiave fa viene filtrata e applicata esattamente da quelle policy — senza modifiche al codice dell’agent, senza redeploy. Questa pagina copre i due campi, come si risolvono al momento della richiesta, e l’unica regola di risoluzione che frega le persone: un collegamento al firewall disabilitato si comporta diversamente da un collegamento al guardrail disabilitato.

​
1. La policy di sicurezza per singola chiave: due campi su una chiave

Un guardrail filtra il testo che scorre attraverso un modello (PII, segreti, jailbreak). Una policy del firewall governa le chiamate a tool che un agent emette (quali tool, quali MCP server, quali host). Entrambe sono policy nominate, con scope a livello di workspace — scritte una volta, condivise in tutto il workspace — e una chiave opta per una specifica tramite due campi:
CampoCollegaSi imposta in console
guardrail_idIl guardrail che filtra i prompt e le risposte di questa chiave.Developer+
firewall_policy_idLa policy del firewall che valuta le chiamate a tool di questa chiave.Developer+
Entrambi si impostano nell’editor delle chiavi su /console/token. Impostarne uno qualsiasi è un’azione Developer+ — le policy stesse sono anch’esse scritte da Developer+ (vedi Scope e chiavi).
Questi due campi sono indipendenti. Una chiave può collegare un guardrail e non una policy del firewall, il contrario, entrambi, o nessuno — ogni piano si risolve per conto suo. Lasciare un campo non impostato (0) non equivale a disattivare l’applicazione; vedi §3.

​
2. Un esempio concreto

Supponi che il guardrail di default del tuo workspace segnali le PII ma le lasci passare, e che la policy del firewall di default faccia audit di ogni chiamata a tool. Va bene per la maggior parte degli agent — ma il tuo agent finanziario gestisce SSN di clienti e non dovrebbe mai chiamare un tool di shell. Scrivi un finance-guardrail più rigido (blocca le PII del tutto) e un finance-firewall (mette in allow-list solo i tre tool che gli servono), poi collega entrambi alla chiave di quell’agent: 
# Configura tramite la CONSOLE (UserAuth — la tua sessione), non una chiave di relay.
# Questa è la chiamata di aggiornamento chiave che l'editor su /console/token effettua.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (allow-list di 3 tool)
}
Dalla richiesta successiva in poi, il traffico di quella chiave è filtrato dal guardrail 12 e le sue chiamate a tool sono valutate dalla policy 8 — mentre ogni altra chiave nel workspace continua a girare con i default del workspace. Il codice stesso dell’agent non cambia mai; continua a chiamare https://api.orcarouter.ai/v1/... con la sua chiave sk-orca-… esattamente come prima.
Questo è il pattern di minima agenzia: una chiave con scope ristretto per ogni agent, ciascuna collegata alle policy di cui il suo lavoro ha effettivamente bisogno. Quando quell’agent viene compromesso, il raggio d’esplosione è quanto la sua chiave era autorizzata a fare — niente di più. Vedi la checklist di minima agenzia.

​
3. Risoluzione: la regola che frega le persone

Per ogni richiesta, il gateway risolve il guardrail attivo e la policy del firewall attiva in modo indipendente. L’ordine sembra lo stesso per entrambi — prima il collegamento, poi il default del workspace — ma divergono su un caso.

​
Risoluzione del guardrail

Il guardrail_id della chiave punta a un guardrail che esiste ed è abilitato. Quel guardrail filtra la richiesta.
Disabilitare il guardrail collegato è un interruttore di spegnimento. La chiave non ottiene alcun filtro dei contenuti — non fa fallback al default del workspace. È deliberato: collegare un guardrail e disabilitarlo è il modo per disattivare il filtro per quella chiave.
Nessun guardrail_id sulla chiave. Si applica il guardrail di default abilitato del workspace, se ne è impostato uno.
Nessun collegamento e nessun default del workspace → la richiesta passa senza filtro dei contenuti.

​
Risoluzione del firewall

Il firewall_policy_id della chiave punta a una policy che esiste ed è abilitata. Quella policy valuta le chiamate a tool della chiave.
Qui sta la differenza. Un collegamento al firewall disabilitato fa fallback alla policy del firewall di default del workspace — non disattiva l’applicazione. Disabilitare un collegamento al firewall riporta la chiave al default del workspace; non lascia la chiave senza protezione.
Nessun firewall_policy_id sulla chiave → si applica la policy del firewall di default abilitata del workspace.
Disabilitare una policy collegata non è simmetrico. Un collegamento al guardrail disabilitato significa nessun guardrail per quella chiave. Un collegamento al firewall disabilitato significa fallback al default del workspace. Se vuoi che una chiave giri davvero senza alcuna applicazione del firewall, non puoi arrivarci disabilitando il suo collegamento — assicurati che non sia impostata alcuna policy del firewall di default per il workspace (oppure dai alla chiave uno scope tale da non emettere chiamate a tool governate).
Al massimo un guardrail e una policy del firewall per workspace possono essere il default in un dato momento; promuovere un nuovo default declassa il vecchio nella stessa transazione, così non puoi mai averne due per sbaglio.

​
4. Com’è fatto un block

Quando una policy collegata nega una richiesta, il chiamante vede un errore strutturato — l’agent può reagire invece di andare in crash:
PianoCodice di erroreHTTPCosto
Guardrailguardrail_blocked400Nessuno — un block in input scatta prima del metering; un block in output rimborsa. Marcato skip-retry.
Firewall (inbound)firewall_blocked400Un block inbound scatta prima della chiamata al modello, quindi nessun token del modello. Skip-retry.
Firewall (held)firewall_approval_pending400In attesa di approvazione umana; l’agent fa polling e ri-invia una volta approvata.
Entrambi i corpi di errore sono in forma OpenAI e nominano la policy e la motivazione, così il tuo agent può ramificare sul codice. Vedi i riferimenti approfonditi per il record completo dell’evento e per come i match vengono loggati.

​
5. Dove andare dopo

Scope e chiavi

Il modello completo a tre livelli — workspace, policy, chiave — e ogni campo che una chiave porta.

Il token object

Ogni campo su una chiave: model_limits, allow_ips, credit_limit_usd, expired_time, e i due collegamenti a policy.

Guardrails

Scrivi la policy sui contenuti che colleghi tramite guardrail_id — regole, entità PII, azioni e preset.

Firewall

Scrivi la policy sulle chiamate a tool che colleghi tramite firewall_policy_id — verdetti, superfici e livelli di autonomia.
Vuoi impostare l’intera postura del tuo workspace in un’unica mossa invece di collegare le chiavi una alla volta? Un livello di autonomia scrive entrambi i piani — guardrails e firewall — in una volta. Poi collega policy più rigide sulle poche chiavi che devono spingersi oltre il default del workspace. Vedi Guardrails vs Firewall.