Vai al contenuto principale
La maggior parte dei team ricorre alla sicurezza degli agent troppo tardi e un piano alla volta — una regex sui prompt qui, una deny-list di tool là. Il risultato è una postura con buchi: filtraggio del testo che non vede mai un shell.exec, o un firewall dei tool che non nota mai un numero di carta di credito che esce in un prompt. Il modo più rapido per una baseline di sicurezza degli agent completa è impostare entrambi i piani in una volta. Il controllo di autonomia di OrcaRouter — la baseline Secure Agents — fa esattamente questo: un singolo interruttore a livello di workspace che scrive una policy del firewall e un guardrail insieme, in una transazione, con undo a un clic. Non scrivi una regola per essere protetto; scegli un livello e metti a punto dopo.
I due piani sono complementari, non ridondanti. I Guardrails filtrano il testo di prompt/risposta (PII, segreti, intento di jailbreak e injection); il firewall governa le azioni che un agent compie (quali tool, chiamate MCP e host). Ciascuno da solo lascia un gap che l’altro chiude — vedi Guardrails vs. Firewall.

​
1. Perché una baseline batte due mezze misure

Un’esecuzione reale di un agent attraversa entrambi i piani in una singola richiesta. Il modello legge un prompt (testo), decide di chiamare db.query (azione), e il risultato del tool rientra nel turno successivo (testo di nuovo). Proteggere un solo piano lascia l’altro non sorvegliato:

Solo firewall

Neghi la shell distruttiva, ma un prompt porta comunque l’SSN di un cliente direttamente al modello — e un argomento di un tool fa comunque trapelare una chiave API.

Solo guardrails

Mascheri le PII nei prompt, ma l’agent chiama comunque rm -rf, raggiunge un endpoint cloud-metadata, o entra in loop su un tool incontrollato.
Il controllo di autonomia rimuove la scelta. Un livello imposta una postura coerente su entrambi i piani, così non c’è una finestra in cui uno è configurato e l’altro no.

​
2. La baseline di sicurezza degli agent: tre livelli

Ogni livello copre gli stessi due piani. Scegline uno; è il tuo pavimento, e aggiungi precisione con le regole più avanti.
LivelloFirewallGuardrailsObserve mode
tightDefault-deny; shell distruttiva + tool a forma di fetch negatiPII Shield + Secrets Blocker applicatiDisattivato
balancedDefault-audit; shell distruttiva negataPII Shield solo in audit (segnala le PII)Disattivato
permissiveNessuna policy applicativaNessunoAttivo — logga ogni chiamata come un gap
Qualche specificità da fissare, dato che plasma ciò che ogni livello cattura effettivamente:
tight marca il verdetto di default della policy del firewall a deny, poi stratifica regole di deny per i nomi di tool shell/exec che portano comandi distruttivi — shell.*, bash, cmd, powershell, exec — e per i nomi di tool a forma di fetch che portano SSRF — http_fetch, web_search, fetch_url, request (e le loro varianti MCP con namespace <server>.*). Nega questi nomi di tool; non include una regola di egress CIDR o cloud-metadata. Se vuoi negare 169.254.169.254 o i range RFC-1918 per destinazione, scrivi la tua regola di egress — vedi Controllo dell’egress.
Sia il guardrail PII Shield sia Secrets Blocker sono attivi e applicativi. PII Shield maschera le PII sulla richiesta prima che raggiunga il modello; Secrets Blocker cattura le credenziali nella richiesta. I segreti negli argomenti dei tool sono catturati da questo guardrail sulla richiesta — il firewall non li rimuove per default.
balanced audita tutto (verdetto di default audit) così vedi il comportamento reale del tuo agent, pur negando comunque l’unica classe più distruttiva — la shell distruttiva. PII Shield gira in modalità solo-audit (segnala le PII, non blocca). Ottieni una traccia completa con quasi nessun rischio di un block inatteso, poi irrigidisci dalla visibilità anziché tirando a indovinare.
permissive non applica nulla — esiste per osservare un agent nuovo di zecca con rischio zero di block accidentali. L’observe mode resta attivo, così ogni chiamata a tool è comunque loggata come un gap di copertura (visibile in Discovered Tools). Usalo per imparare la forma di un agent, poi passa a balanced o tight.

​
3. Un esempio concreto: applica balanced, osserva entrambi i feed

Applicare un livello è una singola azione di console (Firewall → Posture) o una chiamata API. La rotta gira sotto la tua sessione e richiede Developer+. 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
La risposta porta un audit_id — tienilo; è ciò che passi per fare undo. Una volta applicata, la baseline è live sulla chiamata a tool successiva. Nessun redeploy, nessuna modifica al codice dell’agent. Ora osservi entrambi i piani in una volta:
  • Firewall → Events — ogni verdetto di chiamata a tool (audit, le chiamate di shell distruttiva negate). Vedi Log degli eventi.
  • Guardrails → Matches — ogni hit di policy dei contenuti (segnalazioni di PII Shield).
Poiché balanced scrive una policy del firewall e un guardrail reali e modificabili (ciascuno nominato per il livello), puoi aprire l’uno o l’altro in seguito e metterlo a punto — la baseline è un punto di partenza, non un preset bloccato.
Fai anteprima prima di impegnarti. GET /api/workspace/firewall/simulate?level=tight (Member, in sola lettura) mostra esattamente cosa tight cambierebbe rispetto al tuo stato corrente — nulla viene applicato. Eseguilo dopo un giorno o due su balanced per confermare che tight non negherà chiamate che fanno parte del tuo traffico normale.

​
4. L’undo è una chiamata

Ogni modifica di autonomia è reversibile dal suo snapshot di audit, ripristinando lo stato precedente esatto — policy, regole, guardrail e impostazioni — non un reset generico. 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
Per un workspace molto grande il cui snapshot supera il limite di dimensione del log di audit, l’applicazione ha comunque successo ma l’undo a un clic non è disponibile per quella modifica — riapplichi invece il livello che vuoi. È raro, ma vale la pena saperlo prima di irrigidire un workspace di produzione affollato.

​
5. Il percorso consigliato

Parti ampio, osserva, poi irrigidisci da una posizione di visibilità:
1

Applica balanced

Traccia di audit completa; viene negata solo la shell distruttiva; le PII sono segnalate. Fai girare i tuoi agent normalmente per un giorno o due.
2

Simula tight

GET /api/workspace/firewall/simulate?level=tight e confronta i suoi deny con ciò che il feed Events ha effettivamente mostrato. Se le chiamate a forma di fetch o di shell distruttiva fanno parte del tuo flusso normale, sistema prima l’agent.
3

Applica tight

Una volta che simulate non riserva sorprese, passa a tight. L’undo è a una chiamata di distanza se la produzione si rompe.
4

Metti a punto con le regole

La baseline è il tuo pavimento. Ricava eccezioni o aggiungi controlli che non copre con le regole del firewall e i guardrails nominati. Collega una policy o un guardrail specifico a una singola chiave per uno scope più fine.

​
6. Ruoli per la baseline combinata

Il controllo di autonomia copre entrambi i piani, ma ogni azione è role-gated.
AzioneRuolo minimo
Simulare un livello / vedere i Matches dei guardrail / vedere i Discovered ToolsMember
Vedere Events e Runs del firewallDeveloper+
Applicare un livello di autonomiaDeveloper+
Fare undo di una modifica di autonomiaDeveloper+
Tutta la configurazione gira nella console sotto la tua sessione (/api/workspace/firewall/* e /api/guardrail/*). Solo le chiamate di relay /v1/* usano una chiave sk-orca-…; le rotte della chiave del gateway sono uno scope separato. Vedi Scope: chiavi, policy, workspace.

​
7. Dopo la baseline: dove mettere a punto ogni piano

La baseline ti rende protetto nei primi 30 minuti. Da lì, ogni piano ha il proprio riferimento per il lavoro di precisione:

Panoramica del Firewall

Verdetti, superfici, predicati sugli argomenti, approvazioni — il piano delle azioni.

Guardrails

Regole keyword, regex, PII, llm_judge e grounding — il piano dei contenuti.

Shadow mode

Fai il rollout di una policy del firewall irrigidita in solo-audit prima di applicare.

Baseline Secure Agents

La pagina concettuale per il controllo di autonomia e la sua semantica di undo.
La baseline è il pavimento che chiude entrambi i piani in una volta; le regole sono come alzi il soffitto. Vedi Proteggere gli agent AI e il control stack per come i layer si compongono, e Agenzia eccessiva per la minaccia a cui questa baseline risponde più direttamente.