Vai al contenuto principale
Una parte di ciò che devi catturare non è una parola letterale e non è un’entità PII tipizzata — è una forma. Un formato SKU, un layout di numero d’ordine, un pattern di URL interno, un codice coupon, un riferimento di contratto. Una regola regex ti permette di corrispondere a quella forma su ogni chiamata e poi bloccare, mascherare o segnalare, prima che il prompt raggiunga il modello e prima che la risposta raggiunga il tuo utente. Questa è una landing focalizzata sul caso d’uso dei pattern strutturati. Per il motore di guardrail completo — ogni tipo di regola, campo e rotta — vedi il riferimento Guardrails.
Ogni passaggio qui è un’azione di console sul gateway gestito (api.orcarouter.ai). Scrivi il guardrail sotto la tua sessione; solo la chiamata /v1/* finale usa una chiave di relay sk-orca-.... Creare e modificare guardrails richiede Developer+ nel workspace.

1. Quando ti serve un controllo regex guardrail llm

Una regola regex è lo strumento giusto quando la cosa che vuoi catturare ha struttura che una denylist letterale non può esprimere ma non è un’identità standard che il detector pii già copre.

Codici strutturati

SKU, codici coupon, riferimenti di contratto, ID di ticket interni — un prefisso fisso più una sequenza di cifre o alfanumerica.

Token a forma di formato

Qualsiasi cosa corrisponda per forma anziché per un elenco finito di parole — un layout di numero d’ordine, un formato di seriale, un pattern di URL interno.

Pattern di fuga nell'output

Una risposta che non dovrebbe far emergere un hostname interno, un percorso di file o un formato di record-ID — scansiona l’output del modello per la forma.

Controlli economici e deterministici

Puro matching di pattern, nessuna chiamata al modello, nessuna rete — sicuro da eseguire su ogni richiesta in entrambe le direzioni.
Scegli lo strumento più leggero che si adatta. Un elenco finito di termini letterali → denylist di keyword. Una forma di identità nominata per cui vuoi un mask tag tipizzato ([EMAIL], [SSN]) o un controllo Luhn → una entità PII / personalizzata. Un pattern strutturale senza tipizzazione per entità → una regola regex, coperta qui.

2. RE2 — tempo lineare, nessuna backreference

Il pattern di una regola regex è una regex Go RE2. RE2 è il motore che rende sicuro eseguire una regola regex su ogni richiesta:
RE2 garantisce un tempo di matching lineare nella lunghezza dell’input, a prescindere dal pattern. Un motore di backtracking può esplodere esponenzialmente su un input avversario (un “ReDoS”); RE2 non può. È per questo che il tuo pattern è sicuro da valutare sull’hot path su ogni chiamata.
RE2 non supporta backreference (\1), lookahead o lookbehind. Se stai portando un pattern PCRE che si basa su quelli, riscrivilo senza. Classi di caratteri, ancore, quantificatori, alternanza e gruppi non-capturing funzionano tutti come previsto.
Non c’è un interruttore separato “ignora maiuscole” — imposta i flag inline. Anteponi (?i) per case-insensitive, (?m) per multiline. Esempio: (?i)\bproject-orca\b.
Il rule builder compila il tuo pattern quando salvi il guardrail. Un pattern che non compila viene rifiutato con l’indice della regola nell’errore, così un detector difettoso non raggiunge mai il percorso di relay.
I pattern RE2 non sono PCRE. La sorpresa di porting più comune è una backreference o un lookahead — nessuno dei due è supportato. Scrivi il match come un pattern di classe-di-caratteri / alternanza invece e verificalo nella tab Test prima di collegare una chiave.

3. Anatomia di una regola regex

Una regola regex è la regola più piccola del motore dopo keyword: un pattern, uno stage e un’azione.
CampoCosa fa
patternUna regex Go RE2 (tempo lineare, nessuna backreference). Deve compilare.
stageinput (richiesta), output (risposta), o both.
actionblock, mask, o flag.
Su un’azione mask, ogni match viene sostituito sul posto con un singolo tag letterale [REDACTED] — una regola regex non è tipizzata, quindi non renderizza un tag per entità come [EMAIL]. Se vuoi un tag tipizzato o un token di sostituzione personalizzato, modella la forma come una entità PII personalizzata invece.

4. Un esempio concreto

Supponi che i tuoi numeri d’ordine interni appaiano come ORD- seguito da otto cifre, e che tu non voglia mai uno ripetuto nella risposta di un modello. Aggiungi una singola regola regex nello stage output:
{
  "type": "regex",
  "stage": "output",
  "action": "mask",
  "pattern": "ORD-\\d{8}"
}
Scrivila nella console:
1

Crea un guardrail

Apri Guardrails, fai clic su New guardrail e chiamalo (≤ 64 caratteri), es. order-id-filter.
2

Aggiungi una regola regex

Aggiungi una regola — Type: Regular expression, Stage: Output, Action: Mask — e incolla il pattern ORD-\d{8}. Salva.
3

Testala nella sandbox

Apri la tab Test, incolla un campione, scegli lo stage output ed esegui la policy corrente localmente — nessuna chiamata upstream, nessuna quota:
Your order ORD-48291507 has shipped.
Your order [REDACTED] has shipped.
4

Collega una chiave

Modifica una chiave API e scegli order-id-filter dal menu a tendina Guardrail (imposta guardrail_id sulla chiave), o marca il guardrail come default del workspace. Vedi Collega a una chiave e Default di account.
Poi chiama OrcaRouter esattamente come prima — nessun nuovo header, nessuna modifica all’SDK:
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "What is the status of my order?"}
    ]
  }'
Il numero d’ordine viene redatto nella risposta prima che raggiunga il tuo utente.

5. Stage e copertura streaming

L’azione che scegli interagisce con il fatto che la risposta sia in streaming:
AzioneNon streamingStreaming
block (output)ApplicatoApplicato — lo scanner interrompe lo stream
mask (output)ApplicatoApplicato — lo scanner riscrive il buffer
Le regole dello stage di input girano prima della chiamata upstream, quindi non sono interessate dallo streaming — mascherare la richiesta prima che il modello la veda mai è attivo. Mask di output e block di output sono entrambi applicati sulle risposte in streaming e non in streaming. Vedi Streaming coverage.

6. Scegli un’azione

Una regola regex sceglie un’azione per regola:
Qualsiasi match rifiuta la richiesta con HTTP 400 guardrail_blocked. Una richiesta bloccata non costa quota — un block nello stage di input scatta prima della misurazione; un block nello stage di output rimborsa la quota pre-consumata — ed è marcata skip-retry. Vedi l’ errore guardrail_blocked.
Ogni match viene sostituito sul posto con [REDACTED] e la richiesta continua con il testo sanitizzato — il modello upstream (stage di input) o il tuo utente (stage di output) non vede mai l’originale. Vedi Azioni.
Registra un match e non cambia nulla del traffico. Il punto di partenza giusto per un nuovo pattern: mettilo in produzione come flag, osserva il feed dei Matches, poi promuovilo a mask/block una volta che ti fidi.
Registra un match e allega una nota (es. un finding da far emergere nel triage) senza alterare il traffico. Vedi Azioni.
Una difesa nello stage di input: ogni match viene avvolto in delimitatori (es. ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧) che dicono al modello di trattare il testo come dati, non istruzioni — una mitigazione di prompt-injection. Vedi Azioni.

7. Vedi cosa è scattato — e metti a punto la precisione

Ogni regola che scatta registra un match — tipo di regola, azione, stage e una stringa di detail — nel feed Matches del workspace.
La sottostringa corrispondente viene registrata solo quando Log raw content è attivo, che è disattivato per default — la postura conservativa sulla privacy. Con esso disattivato vedi comunque che una regola regex è scattata e quanto spesso, solo non il testo letterale che ha catturato. Attivalo per ciascun guardrail quando ti serve la sottostringa per il triage; l’impostazione non è retroattiva. Vedi Feed dei match e Logging e privacy.
Un pattern troppo ampio è la classica trappola della regex — \d{8} corrisponde a ogni sequenza di otto cifre, non solo ai tuoi numeri d’ordine. Ancoralo (un prefisso fisso come ORD-, confini di parola \b), osserva il feed dei Matches, e segnala i falsi positivi per irrigidire man mano. Per una griglia A/B contro un corpus — dimostrando che un pattern cattura ciò che dovrebbe senza segnalare il traffico benigno — l’harness di eval vive una tab più in là. Vedi Tuning dei falsi positivi.

8. Dove andare dopo

Entità PII personalizzate

Quando la forma è un’identità per cui vuoi un mask tag tipizzato o un checksum Luhn — non un nudo [REDACTED].

Parole sensibili

Un elenco finito di termini letterali — più semplice di un pattern quando non ti serve struttura.

Azioni

Come block, mask e flag differiscono e quando usare ciascuno.

Riferimento Guardrails

Il motore completo — ogni tipo di regola, campo e rotta.
Una regola regex governa il contenuto. Per governare le chiamate a tool di un agent — negare azioni distruttive, redigere gli argomenti delle chiamate a tool, richiedere approvazione — usa il Firewall e i suoi rule matcher. Per policy sfumate che nessun pattern può esprimere (tossicità, fuori tema, intento di injection), una regola llm_judge esegue un controllo semantico contro un modello del workspace. Per vedere dove la regex si colloca nel design complessivo, leggi Guardrails vs Firewall.