Vai al contenuto principale
I segreti finiscono dove non dovrebbero. Uno sviluppatore incolla un file .env in un prompt per “aiuto con il debug”. Un documento recuperato porta con sé una chiave API incorporata. Un modello, a cui viene chiesto di “mostrare la config”, riecheggia una chiave di accesso AWS direttamente al client. Un agent costruisce una chiamata a tool con un token live incorporato negli argomenti. Ognuno di questi è un percorso per cui una credenziale può sfuggire — nei log di un provider upstream, in un transcript del client o in un tool di terze parti. Questa pagina copre come i Guardrails e l’Agent Firewall di OrcaRouter ti permettono di difenderti dalla fuga di segreti verso l’LLM — senza modificare il codice della tua applicazione.
La detection avviene al gateway, davanti a ogni chiave collegata — così una singola policy copre ogni provider, ogni modello e ogni agent senza una modifica all’SDK.

​
1. Dove trapelano i segreti

Una credenziale può sfuggire in tre punti distinti di una richiesta:
La credenziale è nella richiesta prima che il modello giri — una chiave incollata, uno snippet .env, un token dentro un chunk RAG recuperato. Se non controllata raggiunge il provider upstream e può finire nei loro log. Fermala con il guardrail di input Secrets Blocker (§2).
Il modello emette un segreto di ritorno al tuo client — rigurgita una chiave dal suo contesto, o allucina una stringa a forma di credenziale. Intercettala con una regola secrets di output (§3).
Il tuo agent costruisce una chiamata a tool con un token negli argomenti. Il verdetto sanitize del Firewall redige le sottostringhe corrispondenti dagli argomenti prima che la chiamata venga dispatchata (§4).
I primi due sono controlli di contenuto (Guardrails); il terzo è un controllo di azione (Firewall). Stratificali tutti e tre per una difesa in profondità.

​
2. Secrets Blocker — ferma le credenziali nel prompt

Il Secrets Blocker è un preset di guardrail sotto la categoria secrets che gira allo stage input. Scansiona la richiesta alla ricerca di forme di credenziale — chiavi di accesso AWS, chiavi in stile OpenAI e token GitHub — e blocca la chiamata prima che lasci il gateway. La credenziale non raggiunge mai un modello. Scrivilo una volta nella console, collega una chiave, e ogni richiesta attraverso quella chiave viene filtrata:
1

Crea il guardrail

Nella console, apri /console/guardrails, clicca New guardrail e applica il preset Secrets & API-Key Blocker dalla categoria secrets. Genera un guardrail con regole di block in fase di input per le forme di credenziale comuni — modificalo liberamente da lì.
2

Collega una chiave

Apri /console/token, modifica una chiave API e scegli il guardrail dal menu a tendina Guardrail — oppure impostalo come default del workspace così ogni chiave non collegata lo eredita.
3

Invia una richiesta

Chiama il gateway esattamente come prima con quella chiave sk-orca-...:
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": "why is AKIAIOSFODNN7EXAMPLE rejected"}
    ]
  }'
La forma della chiave AWS fa scattare il guardrail e la richiesta viene rifiutata con HTTP 400 guardrail_blocked. La chiave non raggiunge mai il modello.
Una richiesta bloccata non costa quota — un block in fase di input scatta prima della contabilizzazione — ed è marcata skip-retry, così rieseguire lo stesso prompt si limita a bloccarlo di nuovo invece di bruciare un canale di fallback.
Ti serve una copertura più ampia? La categoria secrets include anche un preset Private Keys & Cloud Tokens che blocca chiavi private PEM, token Slack e Stripe, chiavi API Google e JWT. Applicali entrambi — un guardrail può contenere un numero qualsiasi di regole. Per intercettare JWT e forme di credenziale come entità tipizzate (con tag [JWT] / [AWS_ACCESS_KEY]), una regola pii che copre jwt, aws_access_key e api_key_openai è l’alternativa basata sulle entità; vedi il riferimento Guardrails.
Il livello di autonomia tight del Firewall attiva il guardrail Secrets Blocker come parte della sua postura, accanto a PII Shield e ai deny della shell distruttiva. Se vuoi un solo interruttore invece di scrivere regole a mano, è il percorso rapido. Il controllo della credenziale in sé è sempre il guardrail — non lo scanner degli argomenti del firewall.

​
3. Blocca i segreti nell’output del modello

Un segreto può anche uscire nella risposta — il modello riecheggia una chiave dal suo contesto o emette una stringa a forma di credenziale. Aggiungi una regola sullo stage output per filtrare la risposta del modello prima che torni al client. La categoria secrets include un preset Code Secret in Output proprio per questo: regole di block in fase di output per chiavi private PEM, chiavi di accesso AWS e token segreti in stile OpenAI. 
{
  "type": "regex",
  "stage": "output",
  "action": "block",
  "pattern": "AKIA[0-9A-Z]{16}"
}
Il block di output viene applicato sia sulle risposte non-streaming sia su quelle in streaming — su uno stream, uno scanner interrompe la risposta a metà prima che qualsiasi contenuto bloccato raggiunga il client. Un block di output rimborsa la quota pre-consumata.
Il masking di output (sostituire un match con un tag tipizzato anziché rifiutare l’intera risposta) si applica attualmente solo alle risposte non-streaming. Per le credenziali nell’output, l’azione block è la scelta affidabile sul traffico in streaming. Verifica la tua combinazione stage/stream nel tab Test del guardrail prima di farci affidamento.

​
4. Sanitizza i segreti dagli argomenti delle chiamate a tool

Quando il tuo agent costruisce una chiamata a tool, una credenziale può viaggiare con essa negli argomenti. Il verdetto sanitize del Firewall redige le sottostringhe corrispondenti dagli argomenti della chiamata a tool e inoltra la chiamata ripulita — sulle superfici response e mcp, dove ci sono argomenti live al momento della chiamata da riscrivere. Una regola sanitize nomina quali rilevatori redigere nella sua config sanitize_json — un set di preset integrati più regex custom opzionali. Il materiale corrispondente viene sostituito con [redacted:<preset>] (i match custom con [redacted:custom]): 
{
  "priority": 10,
  "label": "Redact AWS keys from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize_json": {
    "presets": ["aws_access_key", "aws_secret_key", "openai_key", "anthropic_key", "bearer_token"],
    "custom": []
  }
}
I preset a forma di segreto disponibili per un sanitizer sono aws_access_key, aws_secret_key, openai_key, anthropic_key e bearer_token (più email, ssn_us e credit_card per le PII). Una regola sanitize deve nominare almeno un preset o un pattern custom — un sanitizer vuoto viene rifiutato al salvataggio.
Sanitize redige gli argomenti, non i risultati. Ripulisce gli argomenti di una chiamata a tool che il tuo agent ha scritto; non ripulisce il contenuto che un tool restituisce. E sulla superficie inbound — dove non ci sono ancora argomenti al momento della chiamata — sanitize escala a un deny. Vedi il riferimento delle regole del firewall per il linguaggio di matching.
Il guardrail Secrets Blocker (§2) resta la tua difesa primaria per le credenziali nel corpo della richiesta — il sanitizer del firewall è il complemento a livello di azione per i segreti che compaiono specificamente dentro gli argomenti delle chiamate a tool.

​
5. Stratificare le tre difese

Dov’è il segretoLayer che lo fermaAzione
Nel promptSecrets Blocker (guardrail di input)block
Nella risposta del modelloRegola secrets di output (guardrail di output)block
In un argomento di chiamata a toolSanitizer del firewallsanitize
Fai il rollout di ogni nuova regola in shadow mode (firewall) o con l’azione flag (guardrail) prima. Osserva il feed events / Matches per confermare che scatta su credenziali reali e non su sosia benigni, poi passa all’azione applicativa.

​
6. Osserva cosa è scattato

Ogni regola di guardrail che scatta registra un match — tipo di regola, azione, stage e una stringa di dettaglio — sul feed Matches del workspace (GET /api/guardrail/match, Member). La sottostringa corrispondente viene registrata solo quando “Log raw content” è attivo, ed è disattivato di default — la postura conservativa per la privacy, così il feed Matches non diventa esso stesso un posto in cui i segreti si accumulano. Lascialo disattivato per le regole sulle credenziali a meno che non ti serva specificamente la sottostringa per il triage. Le decisioni di sanitize del firewall finiscono nel feed Events del Firewall (GET /api/workspace/firewall/events, Developer+), con segreti e blob delle regole mai loggati.

​
7. Dove andare dopo

Riferimento Guardrails

Tipi di regola, entità PII, preset, la sandbox di test e l’eval harness per intero.

Riferimento regole del Firewall

Il linguaggio di matching — glob di tool, clausole sugli argomenti e sanitizer.

Esposizione di PII

La minaccia di contenuto sorella: dati personali in prompt e risposte.

Esfiltrazione di dati

Quando una credenziale trapelata diventa il payload di una chiamata di esfiltrazione in uscita.

Guardrails vs Firewall

Quale piano ferma quale classe di fuga, e come si compongono.

Baseline secure-agents

La postura di partenza che attiva queste difese insieme.