Saltar para o conteúdo principal
Segredos acabam onde não deveriam. Um desenvolvedor cola um arquivo .env em um prompt pedindo “ajuda para depurar”. Um documento recuperado carrega uma chave de API embutida. Um modelo, ao ser solicitado a “mostrar a config”, ecoa uma chave de acesso AWS direto de volta ao cliente. Um agente constrói uma chamada de ferramenta com um token ativo embutido nos argumentos. Cada um desses é um caminho para uma credencial escapar — para os logs de um provedor upstream, para o transcript de um cliente ou para uma ferramenta de terceiros. Esta página cobre como os Guardrails e o Agent Firewall do OrcaRouter permitem que você se defenda contra vazamento de segredos de llm — sem alterar o código da sua aplicação.
A detecção acontece no gateway, na frente de cada chave vinculada — então uma única política cobre cada provedor, cada modelo e cada agente sem uma mudança de SDK.

​
1. Onde os segredos vazam

Uma credencial pode escapar em três pontos distintos de uma requisição:
A credencial está na requisição antes de o modelo sequer rodar — uma chave colada, um trecho de .env, um token dentro de um chunk RAG recuperado. Sem verificação, ela chega ao provedor upstream e pode acabar nos logs dele. Detenha-a com o guardrail de input Secrets Blocker (§2).
O modelo emite um segredo de volta ao seu cliente — ele regurgita uma chave do seu contexto, ou alucina uma string em formato de credencial. Capture-a com uma regra de segredos de output (§3).
Seu agente constrói uma chamada de ferramenta com um token nos argumentos. O veredito sanitize do Firewall redige os substrings correspondentes dos argumentos antes que a chamada seja despachada (§4).
Os dois primeiros são verificações de conteúdo (Guardrails); o terceiro é uma verificação de ação (Firewall). Empilhe os três para defesa em profundidade.

​
2. Secrets Blocker — detenha credenciais no prompt

O Secrets Blocker é um preset de guardrail sob a categoria secrets que roda no stage input. Ele escaneia a requisição em busca de formatos de credencial — chaves de acesso AWS, chaves estilo OpenAI e tokens GitHub — e bloqueia a chamada antes que ela saia do gateway. A credencial nunca chega a um modelo. Escreva-o uma vez no console, anexe uma chave, e cada requisição através dessa chave é filtrada:
1

Crie o guardrail

No console, abra /console/guardrails, clique em New guardrail e aplique o preset Secrets & API-Key Blocker da categoria secrets. Ele inicializa um guardrail com regras de block no stage de input para os formatos de credencial comuns — edite livremente a partir daí.
2

Anexe uma chave

Abra /console/token, edite uma chave de API e escolha o guardrail no dropdown Guardrail — ou defina-o como padrão do workspace para que cada chave não anexada o herde.
3

Envie uma requisição

Chame o gateway exatamente como antes com essa chave 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"}
    ]
  }'
O formato de chave AWS dispara o guardrail e a requisição é rejeitada com HTTP 400 guardrail_blocked. A chave nunca chega ao modelo.
Uma requisição bloqueada não custa quota — um block de stage de input dispara antes da medição — e é marcada como skip-retry, então re-executar o mesmo prompt apenas bloqueia novamente em vez de queimar um canal de fallback.
Precisa de cobertura mais ampla? A categoria secrets também traz um preset Private Keys & Cloud Tokens que bloqueia chaves privadas PEM, tokens Slack e Stripe, chaves de API Google e JWTs. Aplique ambos — um guardrail pode conter qualquer número de regras. Para capturar JWTs e formatos de credencial como entidades tipadas (com tags [JWT] / [AWS_ACCESS_KEY]), uma regra pii cobrindo jwt, aws_access_key e api_key_openai é a alternativa orientada a entidades; veja a referência de Guardrails.
O nível de autonomia tight do Firewall liga o guardrail Secrets Blocker como parte da sua postura, ao lado do PII Shield e das negações de shell destrutivo. Se você quer um único interruptor em vez de escrever regras à mão, esse é o caminho rápido. A verificação de credencial em si é sempre o guardrail — não o scanner de argumentos do firewall.

​
3. Bloqueie segredos na saída do modelo

Um segredo também pode sair na resposta — o modelo ecoa uma chave do seu contexto ou emite uma string em formato de credencial. Adicione uma regra no stage output para filtrar a resposta do modelo antes de ela retornar ao cliente. A categoria secrets traz um preset Code Secret in Output exatamente para isso: regras de block no stage de output para chaves privadas PEM, chaves de acesso AWS e tokens secretos estilo OpenAI. 
{
  "type": "regex",
  "stage": "output",
  "action": "block",
  "pattern": "AKIA[0-9A-Z]{16}"
}
O block de output é aplicado tanto em respostas não-streaming quanto streaming — em um stream, um scanner corta a resposta em pleno voo antes que qualquer conteúdo bloqueado chegue ao cliente. Um block de output reembolsa a quota pré-consumida.
O mascaramento de output (substituir uma correspondência por uma tag tipada em vez de rejeitar a resposta inteira) aplica-se atualmente apenas a respostas não-streaming. Para credenciais na saída, a ação block é a escolha confiável em tráfego streaming. Comprove sua combinação de stage/stream na aba Test do guardrail antes de depender dela.

​
4. Sanitize segredos dos argumentos de chamada de ferramenta

Quando seu agente constrói uma chamada de ferramenta, uma credencial pode ir junto nos argumentos. O veredito sanitize do Firewall redige os substrings correspondentes dos argumentos da chamada de ferramenta e encaminha a chamada limpa — nas superfícies response e mcp, onde há argumentos ao vivo no momento da chamada para reescrever. Uma regra sanitize nomeia quais detectores redigir em sua config sanitize_json — um conjunto de presets integrados mais regexes customizados opcionais. Material correspondente é substituído por [redacted:<preset>] (correspondências customizadas com [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": []
  }
}
Os presets de formato de segredo disponíveis a um sanitizer são aws_access_key, aws_secret_key, openai_key, anthropic_key e bearer_token (mais email, ssn_us e credit_card para PII). Uma regra sanitize deve nomear pelo menos um preset ou padrão customizado — um sanitizer vazio é rejeitado ao salvar.
Sanitize redige argumentos, não resultados. Ele limpa os argumentos de uma chamada de ferramenta que seu agente escreveu; ele não depura o conteúdo que uma ferramenta retorna. E na superfície inbound — onde ainda não há argumentos de momento de chamada — sanitize escala para um deny. Veja a referência de regras do firewall para a linguagem de correspondência.
O guardrail Secrets Blocker (§2) continua sendo sua defesa principal para credenciais no corpo da requisição — o sanitizer do firewall é o complemento na camada de ação para segredos que aparecem especificamente dentro de argumentos de chamada de ferramenta.

​
5. Empilhando as três defesas

Onde o segredo estáCamada que o detémAção
No promptSecrets Blocker (guardrail de input)block
Na resposta do modeloRegra de segredos de output (guardrail de output)block
Em um argumento de chamada de ferramentaSanitizer do firewallsanitize
Faça o rollout de qualquer regra nova em shadow mode (firewall) ou com a ação flag (guardrail) primeiro. Observe o feed de eventos / Matches para confirmar que ela dispara em credenciais reais e não em sósias benignos, depois mude para a ação de enforcement.

​
6. Observe o que disparou

Cada regra de guardrail que dispara registra uma correspondência — tipo de regra, ação, stage e uma string de detalhe — no feed Matches do workspace (GET /api/guardrail/match, Member). O substring correspondente é registrado apenas quando “Log raw content” está ligado, o que está desligado por padrão — a postura conservadora de privacidade, para que o feed Matches não se torne ele próprio um lugar onde segredos se acumulam. Deixe-o desligado para regras de credencial a menos que você especificamente precise do substring para triagem. Decisões de sanitize do Firewall caem no feed Events do Firewall (GET /api/workspace/firewall/events, Developer+), com segredos e blobs de regra nunca registrados.

​
7. Para onde ir a seguir

Referência de Guardrails

Tipos de regra, entidades de PII, presets, o sandbox de teste e o eval harness por completo.

Referência de regras do Firewall

A linguagem de correspondência — globs de ferramenta, cláusulas de argumento e sanitizers.

Exposição de PII

A ameaça de conteúdo irmã: dados pessoais em prompts e respostas.

Exfiltração de dados

Quando uma credencial vazada se torna o payload de uma chamada de exfil outbound.

Guardrails vs. Firewall

Qual plano detém qual classe de vazamento, e como eles compõem.

Linha de base de agentes seguros

A postura inicial que liga essas defesas em conjunto.