Come OrcaRouter ispeziona ogni richiesta

Il gateway si trova tra il tuo agent e ogni modello che chiama. Questo lo rende l’unico punto che vede ogni chiamata indipendentemente dal provider — ogni prompt, ogni risposta, ogni chiamata a tool e ogni richiesta in uscita che il tuo agent instrada attraverso di esso — indipendentemente da quale SDK ha emesso la chiamata. Quel punto di strozzatura è dove appartengono ispezione e applicazione. (Ciò che non può vedere — un tool che gira interamente dentro il tuo processo e non attraversa mai il gateway — è trattato in §4.) Questa pagina spiega esattamente cosa il gateway può e non può vedere, come funziona la detection e come colmare le lacune.

​

1. Perché il gateway è il punto di ispezione corretto

La maggior parte dei controlli di sicurezza vive nell’applicazione: wrapper di libreria, hook del framework per agent, SDK per-provider. Quei controlli hanno un difetto strutturale fatale — si rompono non appena aggiungi un secondo provider, cambi framework, o lasci che un agent auto-installi una nuova skill. Il gateway non ha nessuna di quelle cuciture. Ogni chiamata che il tuo agent emette, indipendentemente dal modello, dal provider, o da come la capability del tool è arrivata, transita un singolo punto prima che qualcosa raggiunga l’upstream. Questo è l’unico layer dove puoi fare una garanzia: se è accaduto, il gateway l’ha visto. OrcaRouter usa quella posizione per due passaggi di applicazione distinti:

• I Guardrails filtrano il testo — il prompt che il tuo agent invia e la risposta che il modello restituisce. Un block del guardrail restituisce HTTP 400 guardrail_blocked e non costa quota.
• Il Firewall giudica le azioni — i tool che un agent chiama, gli MCP server che raggiunge, e le destinazioni di rete che segnala. Un deny del firewall restituisce HTTP 400 firewall_blocked sulla superficie inbound, o un errore di tool sulla superficie MCP, così il modello vede il rifiuto e può ragionare su di esso.

Entrambi i layer vengono configurati una volta nel tuo workspace e si collegano a una chiave API. Nessun redeploy. Nessuna modifica all’SDK. Il tuo agent continua a chiamare https://api.orcarouter.ai/v1 esattamente come prima.

​

2. Le quattro superfici di applicazione

Il Firewall valuta ogni chiamata a tool rispetto esattamente a una superficie — il punto nel ciclo di vita della chiamata in cui il gateway la vede. I Guardrails aggiungono altri due stage di testo che si sovrappongono alle superfici sopra: input (il prompt e i messaggi della richiesta) e output (il testo della risposta del modello). Una singola richiesta può passare attraverso tutti.

​

3. Detection al primo utilizzo

Questo significa che un tool nuovo finisce nella vista Discovered tools nel momento in cui appare su una richiesta, anche se nessuna regola lo nomina. Attiva l’observe mode per registrare ogni chiamata a tool che non ha regola corrispondente come un gap di copertura — quella vista guida la creazione delle policy dal traffico reale.

​

4. Cosa il gateway non può vedere

La garanzia di ispezione copre le chiamate che attraversano il gateway. Non si estende a un tool che il tuo agent esegue interamente dentro il proprio processo — uno che legge un file locale, chiama una funzione di libreria, o esegue un sottoprocesso senza mai inviare un messaggio al gateway. Questo è un confine onesto, non un difetto di design. L’obiettivo di design è rendere il gateway il percorso controllato per le chiamate che contano — quelle con conseguenze reali: Se hai tool che girano in-process oggi e hanno conseguenze reali, il percorso verso la copertura è registrarli come MCP server dietro il gateway MCP del Firewall o chiamare l’hook di evaluate dal tuo loop di agent prima del dispatch.

​

5. Role gating sui dati di ispezione

L’accesso alle superfici di ispezione è role-scoped dentro il tuo workspace:

​

6. Dove andare dopo

Il gateway è l’unico punto di ispezione per ogni chiamata che lo attraversa — configura le tue policy una volta e ogni provider, ogni agent e ogni chiamata a tool è coperta.