Como o OrcaRouter inspeciona cada requisição

O gateway fica entre o seu agente e cada modelo que ele chama. Isso o torna o único ponto que vê cada chamada independentemente do provedor — cada prompt, cada resposta, cada chamada de ferramenta e cada requisição outbound que seu agente rota por ele — independentemente de qual SDK emitiu a chamada. Esse ponto de estrangulamento é onde a inspeção e o enforcement pertencem. (O que ele não pode ver — uma ferramenta que roda inteiramente dentro do seu processo e nunca cruza o gateway — é coberto em §4.) Esta página explica exatamente o que o gateway pode e não pode ver, como a detecção funciona e como fechar as lacunas.

​

1. Por que o gateway é o ponto de inspeção correto

A maioria dos controles de segurança vive na aplicação: wrappers de biblioteca, hooks de framework de agente, SDKs por provedor. Esses controles têm uma falha estrutural fatal — eles quebram assim que você adiciona um segundo provedor, troca de framework ou deixa um agente auto-instalar uma nova skill. O gateway não tem nenhuma dessas juntas. Cada chamada que seu agente emite, independentemente do modelo, provedor ou como a capacidade da ferramenta chegou, transita por um único ponto antes que qualquer coisa alcance o upstream. Essa é a única camada onde você pode fazer uma garantia: se aconteceu, o gateway viu. O OrcaRouter usa essa posição para dois passes distintos de enforcement:

• Os Guardrails inspecionam texto — o prompt que seu agente envia e a resposta que o modelo retorna. Um bloqueio de guardrail retorna HTTP 400 guardrail_blocked e não custa cota.
• O Firewall julga ações — as ferramentas que um agente chama, os servidores MCP que ele alcança e os destinos de rede que ele reporta. Um deny do firewall retorna HTTP 400 firewall_blocked na superfície inbound, ou um erro de ferramenta na superfície MCP, para que o modelo veja a rejeição e possa raciocinar sobre ela.

Ambas as camadas são configuradas uma vez no seu workspace e se conectam a uma chave de API. Sem redeploy. Sem mudança de SDK. Seu agente continua chamando https://api.orcarouter.ai/v1 exatamente como antes.

​

2. As quatro superfícies de enforcement

O Firewall avalia cada chamada de ferramenta contra exatamente uma superfície — o ponto no ciclo de vida da chamada onde o gateway a vê. Os guardrails adicionam dois estágios de texto que se sobrepõem às superfícies acima: input (o prompt e as mensagens da requisição) e output (o texto da resposta do modelo). Uma única requisição pode passar por todos eles.

​

3. Detecção no primeiro uso

Isso significa que uma ferramenta nova aparece na visão de Ferramentas Descobertas no momento em que aparece em uma requisição, mesmo que nenhuma regra a nomeie. Ative o observe mode para registrar cada chamada de ferramenta que não tem regra correspondente como um gap de cobertura — essa visão orienta a criação de políticas a partir do tráfego real.

​

4. O que o gateway não pode ver

A garantia de inspeção cobre chamadas que cruzam o gateway. Ela não se estende a uma ferramenta que seu agente roda inteiramente dentro de seu próprio processo — uma que lê um arquivo local, chama uma função de biblioteca ou executa um subprocesso sem nunca enviar uma mensagem ao gateway. Esse é um limite honesto, não uma falha de design. O objetivo de design é tornar o gateway o caminho auditado para as chamadas que importam — as que têm consequências no mundo real: Se você tem ferramentas que rodam em processo hoje e têm consequências no mundo real, o caminho para cobertura é registrá-las como servidores MCP atrás do gateway MCP do Firewall ou chamar o hook de avaliação do seu loop de agente antes de despachar.

​

5. Controle de acesso por papel nos dados de inspeção

O acesso às superfícies de inspeção tem escopo por papel dentro do seu workspace:

​

6. Para onde ir a seguir

O gateway é o único ponto de inspeção para cada chamada que o cruza — configure suas políticas uma vez e cada provedor, cada agente e cada chamada de ferramenta está coberta.