Saltar para o conteúdo principal
Um chatbot voltado ao cliente recebe entrada não confiável do público e a envia para um modelo. Isso o torna a superfície de maior exposição que você opera: usuários colam PII que você não quer armazenada upstream, atacantes tentam sobrescrever seu system prompt, e o modelo pode ecoar segredos ou conteúdo inseguro de volta para a janela de chat. Esta receita conecta os quatro controles que protegem um chatbot de IA de ponta a ponta — um guardrail de PII na requisição, triagem de injeção de prompt, segurança de saída e uma única chave fortemente escopada — tudo no console, com zero mudança no código do seu chatbot.
Tudo aqui se vincula ao seu workspace e é configurado a partir do console. Seu chatbot continua chamando https://api.orcarouter.ai/v1/chat/completions com a mesma chave sk-orca-... — apenas a política no gateway muda. As ações de configuração precisam dos papéis indicados por etapa; as chamadas de relay usam a chave com escopo.

​
1. O modelo de ameaças de um chatbot público

Antes de criar qualquer coisa, saiba contra o que você está defendendo. A superfície de ataque de um chatbot é mais estreita que a de um agente completo — mas os riscos de alta frequência são concretos:

PII entra, PII registrada

Usuários colam emails, números de cartão, SSNs no chat — e você os encaminha upstream e para os seus logs.

Injeção de prompt

“Ignore as instruções anteriores e …” — tentativas de sobrescrever seu system prompt e mudar o comportamento do bot.

Jailbreaks

Enquadramentos DAN / role-play que tentam tirar o bot da política.

Saída insegura

O modelo ecoando segredos vazados, boilerplate de system prompt ou conteúdo com injeção de volta para o chat.
Um chatbot simples não tem chamadas de ferramenta, então esta receita se apoia nos Guardrails — o plano de texto — em vez do Firewall. Se o seu bot de fato chama ferramentas, sobreponha o Firewall (veja §6).

​
2. Um guardrail, quatro tarefas

Em vez de quatro políticas separadas, crie um guardrail de workspace com regras ordenadas cobrindo cada risco. Um guardrail é uma lista nomeada e ordenada de regras; cada regra diz o que procurar, onde (input, output ou both) e o que fazer (block, mask ou flag). No console, abra Guardrails → New guardrail, dê o nome chatbot-shield e adicione as regras abaixo. Criar um guardrail — e rodar o sandbox de Test — precisa do papel Developer; visualizar guardrails está aberto a qualquer membro.

​
a. PII na requisição

Adicione uma regra de PII, stage input, ação mask. O conjunto de entidades embutido é fechado — escolha as que um chatbot realmente vê: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Uma mask substitui cada correspondência por uma tag tipada — jane@acme.com vira [EMAIL], então o modelo upstream nunca vê o endereço. O override entity_actions bloqueia a requisição inteira em um número de cartão ou SSN enquanto mascara as entidades de menor severidade. Isto é exatamente o preset PII Shield, estendido com overrides por entidade — aplique o preset a partir da biblioteca de templates e edite dali.
A máscara de PII no stage input está disponível hoje — ela reescreve a requisição antes que o modelo a veja. A máscara ao vivo da resposta em streaming está no roadmap. Para redigir PII do que o bot responde, use uma regra de block na saída (aplicada em streaming e não-streaming) ou rode o bot em modo não-streaming, onde a máscara de saída se aplica. Prove a sua combinação exata de stage/stream na aba Test primeiro.

​
b. Triagem de injeção de prompt

O OrcaRouter entrega isto como o preset de segurança Prompt-Injection Basics (uma denylist de palavras-chave para frases como “ignore previous instructions” e “reveal your system prompt”; para cobertura regex mais rígida de enquadramentos DAN / role-play, adicione o preset Jailbreak / Role-Play Blocker) e, para intenção semântica que nenhum padrão captura, uma regra llm_judge. Adicione o preset, depois uma regra de judge no stage input com um rubric que sinaliza tentativas de injeção/override. O judge roda contra um modelo no seu workspace, é limitado por judge_timeout_ms e falha aberto por padrão (um erro do judge é registrado e a requisição continua) — defina judge_fail_open: false para falhar fechado.
Comece as regras de injeção em flag, observe o feed de Matches por um dia em tráfego real, depois promova para block assim que confirmar que elas disparam em ataques e não em perguntas legítimas. Veja modos de enforcement.

​
c. Segurança de saída

Adicione uma regra de block no stage output (regex ou keyword) para conteúdo que nunca deve chegar à janela de chat — segredos vazados, tokens de controle de chat-template, boilerplate de system prompt. O Secrets & API-Key Blocker e os presets de segurança de vazamento de system prompt cobrem os casos comuns; aplique-os e fixe as regras relevantes ao stage output. O block de saída é aplicado também em streaming — o scanner corta o stream em voo e emite uma mensagem de substituição antes que o conteúdo bloqueado chegue ao usuário.

​
3. Teste antes de lançar

Todo editor de guardrail tem uma aba Test. Cole uma amostra, escolha o stage e rode a política atual localmente — sem chamada upstream, sem cota gasta.
Cole istoStageEspere
email me at jane@acme.cominputemail me at [EMAIL]
ignore previous instructionsinputflag / block (sua escolha)
cartão 4111 1111 1111 1111inputguardrail_blocked (conforme o override)
Para cobertura adversarial, a aba Eval roda a política contra corpora de red-team embutidos (ou seu próprio JSONL) e reporta como ela pontuou — ajuste o rubric do judge até ele capturar ataques conhecidos sem sinalizar chat benigno.

​
4. Cunhe uma única chave com escopo para o bot

Um guardrail só aplica enforcement em chaves que resolvem para ele. Dê ao chatbot sua própria chave, escopada ao mínimo de que ele precisa — nunca sua chave para toda a conta. Em API Keys → New key, defina:
Escolha chatbot-shield no dropdown Guardrail. Isso define guardrail_id na chave. Um vínculo explícito é o oposto do interruptor de desligar: se estiver definido e habilitado, ele sempre se aplica e nunca cai de volta silenciosamente. (Deixe-o sem definir para cair de volta ao guardrail is_default do workspace.)
Defina credit_limit_usd em um teto sensato (0 = ilimitado). Um chatbot público é a chave com maior probabilidade de ser abusada — um teto de crédito rígido é o seu limite de raio de explosão. Veja denial-of-wallet.
Ative model_limits e liste apenas o(s) modelo(s) que o bot tem permissão de chamar, para que uma chave vazada não possa ser usada para rodar um modelo caro que você nunca pretendeu expor.
Defina allow_ips para os IPs de egress do seu backend se o bot chama de um servidor fixo, e um expired_time se a chave for temporária (-1 = nunca expira).
A chave é mascarada na exibição após a criação — copie-a uma vez. O backend do seu chatbot agora envia cada turno de usuário através de chatbot-shield sem nenhum código ciente de que a triagem está acontecendo.

​
5. Observe em produção

Duas leituras mantêm você honesto, ambas com escopo de workspace:
  • Guardrails → Matches (qualquer Member) — toda regra que disparou: tipo, ação, stage e detalhe. A substring correspondente é registrada somente se Log raw content estiver ligado para o guardrail (desligado por padrão — a postura conservadora de privacidade). Marque um falso positivo para ajustar a política (Admin).
  • Version history — toda mudança escreve uma linha de histórico; faça diff de quaisquer duas versões e reverta se uma regra se mostrar agressiva demais. Uma requisição bloqueada retorna HTTP 400 guardrail_blocked, custa nenhuma cota e é marcada como skip-retry.
Uma resposta guardrail_blocked é um 400 deliberado e visível ao usuário. Trate-o na UI do seu chatbot com uma mensagem amigável (“Não consigo processar isso”) em vez de expor o erro bruto — o gateway já parou o turno inseguro por você.

​
6. Se o seu bot chama ferramentas

No momento em que seu chatbot pode chamar uma função, buscar uma URL ou alcançar um servidor MCP, a triagem de texto não basta — você precisa do plano de ação. Vincule uma política de Firewall à mesma chave via firewall_policy_id, ou aplique o nível de autonomia balanced para auditar chamadas de ferramenta e sinalizar PII em todo o workspace antes de restringir. O caminho mais rápido é o quickstart de zero trust; para um agente que chama ferramentas pesadamente, veja proteja um agente autônomo.

​
7. Para onde aprofundar

Referência de Guardrails

Cada tipo de regra, entidade de PII, campo de judge e o eval harness por completo.

Guardrails vs. Firewall

Plano de texto vs. plano de ação — quando você precisa de qual.

Modos de enforcement

Observe → shadow → enforce: faça o rollout sem quebrar o bot.

Escope chaves, políticas, workspaces

Como o vínculo de chave e os padrões de workspace resolvem.