Saltar para o conteúdo principal
A maioria das equipes recorre à segurança de agentes tarde demais e um plano de cada vez — um regex em prompts aqui, uma deny-list de ferramenta ali. O resultado é uma postura com buracos: filtragem de texto que nunca vê um shell.exec, ou um firewall de ferramenta que nunca nota um número de cartão de crédito saindo num prompt. A maneira mais rápida de uma linha de base de segurança de agentes completa é definir ambos os planos de uma vez. O controle de autonomia do OrcaRouter — a linha de base Secure Agents — faz exatamente isso: um único interruptor em nível de workspace que escreve uma política de firewall e um guardrail juntos, em uma transação, com desfazer em um clique. Você não cria uma regra para ficar protegido; você escolhe um nível e ajusta depois.
Os dois planos são complementares, não redundantes. Os Guardrails filtram o texto de prompt/response (PII, segredos, intenção de jailbreak e injeção); o firewall governa as ações que um agente toma (quais ferramentas, chamadas MCP e hosts). Qualquer um sozinho deixa um gap que o outro fecha — veja Guardrails vs. Firewall.

​
1. Por que uma linha de base supera duas meias-medidas

Uma run de agente real cruza ambos os planos em uma única requisição. O modelo lê um prompt (texto), decide chamar db.query (ação), e o resultado da ferramenta alimenta de volta no próximo turno (texto de novo). Proteger apenas um plano deixa o outro desprotegido:

Apenas firewall

Você nega shell destrutivo, mas um prompt ainda carrega o SSN de um cliente direto ao modelo — e um argumento de ferramenta ainda vaza uma chave de API.

Apenas guardrails

Você mascara PII em prompts, mas o agente ainda chama rm -rf, alcança um endpoint de cloud-metadata, ou faz loop numa ferramenta descontrolada.
O controle de autonomia remove a escolha. Um nível define uma postura coerente através de ambos os planos, então não há uma janela onde um está configurado e o outro não.

​
2. A linha de base de segurança de agentes: três níveis

Cada nível cobre os mesmos dois planos. Escolha um; ele é seu piso, e você adiciona precisão com regras depois.
NívelFirewallGuardrailsObserve mode
tightDefault-deny; shell destrutivo + ferramentas com formato de fetch negadasPII Shield + Secrets Blocker aplicadosOff
balancedDefault-audit; shell destrutivo negadoPII Shield em apenas-audit (sinaliza PII)Off
permissiveSem política de enforcementNenhumOn — registra cada chamada como um gap
Algumas especificidades que vale fixar, já que elas moldam o que cada nível de fato captura:
O tight carimba o veredito padrão da política de firewall para deny, depois sobrepõe regras de deny para os nomes de ferramenta shell/exec que carregam comandos destrutivos — shell.*, bash, cmd, powershell, exec — e para os nomes de ferramenta com formato de fetch que carregam SSRF — http_fetch, web_search, fetch_url, request (e suas variantes MCP com namespace <server>.*). Ele nega esses nomes de ferramenta; ele não traz uma regra de egress de CIDR ou cloud-metadata. Se você quer negar 169.254.169.254 ou faixas RFC-1918 por destino, crie sua própria regra de egress — veja Controle de egress.
Tanto o guardrail PII Shield quanto o Secrets Blocker estão ativos e aplicando. O PII Shield mascara PII na requisição antes de ela chegar ao modelo; o Secrets Blocker captura credenciais na requisição. Segredos em argumentos de ferramenta são capturados por este guardrail na requisição — o firewall não os remove por padrão.
O balanced audita tudo (veredito padrão audit) para que você veja o comportamento real do seu agente, ainda negando a única classe mais destrutiva — shell destrutivo. O PII Shield roda em modo apenas-audit (sinaliza PII, não bloqueia). Você obtém uma trilha completa com quase nenhum risco de um block inesperado, depois aperta a partir da visibilidade em vez de adivinhação.
O permissive aplica nada — ele existe para observar um agente novinho com risco zero de blocks acidentais. O observe mode permanece ligado, então cada chamada de ferramenta ainda é registrada como um gap de cobertura (visível em Discovered Tools). Use-o para aprender a forma de um agente, depois mude para balanced ou tight.

​
3. Um exemplo concreto: aplique balanced, observe ambos os feeds

Aplicar um nível é uma única ação de console (Firewall → Posture) ou uma chamada de API. A rota roda sob sua sessão e exige Developer+. 
# Configure in the console, or POST under your session token (Developer+):
POST /api/workspace/firewall/autonomy
Content-Type: application/json

{ "level": "balanced" }
A resposta carrega um audit_id — guarde-o; é o que você passa para desfazer. Uma vez aplicada, a linha de base está ao vivo na próxima chamada de ferramenta. Sem redeploy, sem mudança no código do agente. Agora você observa ambos os planos de uma vez:
  • Firewall → Events — cada veredito de chamada de ferramenta (audit, as chamadas de shell destrutivo negadas). Veja Log de events.
  • Guardrails → Matches — cada acerto de política de conteúdo (sinalizações do PII Shield).
Porque o balanced escreve uma política de firewall e um guardrail reais e editáveis (cada um nomeado para o nível), você pode abrir qualquer um depois e ajustá-lo — a linha de base é um ponto de partida, não um preset travado.
Pré-visualize antes de se comprometer. GET /api/workspace/firewall/simulate?level=tight (Member, somente-leitura) mostra exatamente o que o tight mudaria contra seu estado atual — nada é aplicado. Rode-o após um dia ou dois no balanced para confirmar que o tight não negará chamadas que são parte do seu tráfego normal.

​
4. Desfazer é uma chamada

Cada mudança de autonomia é reversível a partir de seu snapshot de auditoria, restaurando o estado anterior exato — políticas, regras, guardrails e configurações — não um reset genérico. 
# Developer+; :audit_id is the value returned when you applied the level.
POST /api/workspace/firewall/autonomy/undo/:audit_id
Para um workspace muito grande cujo snapshot excede o limite de tamanho do log de auditoria, a aplicação ainda tem sucesso mas o desfazer em um clique fica indisponível para aquela mudança — você reaplica o nível que quer em vez disso. Isso é raro, mas vale saber antes de apertar um workspace de produção movimentado.

​
5. O caminho recomendado

Comece amplo, observe, depois aperte de uma posição de visibilidade:
1

Aplique balanced

Trilha de auditoria completa; apenas shell destrutivo é negado; PII é sinalizado. Rode seus agentes normalmente por um dia ou dois.
2

Simule tight

GET /api/workspace/firewall/simulate?level=tight e compare seus denies contra o que o feed de Events de fato mostrou. Se chamadas com formato de fetch ou de shell destrutivo são parte do seu fluxo normal, conserte o agente primeiro.
3

Aplique tight

Uma vez que o simulate não traga surpresas, mude para tight. Desfazer está a uma chamada de distância se a produção quebrar.
4

Ajuste com regras

A linha de base é seu piso. Recorte exceções ou adicione controles que ela não cobre com regras de firewall e guardrails nomeados. Vincule uma política ou guardrail específico a uma chave individual para escopo mais fino.

​
6. Papéis para a linha de base combinada

O controle de autonomia abrange ambos os planos, mas cada ação é restrita por papel.
AçãoPapel mínimo
Simular um nível / ver Matches de guardrail / ver Discovered ToolsMember
Ver Events e Runs do firewallDeveloper+
Aplicar um nível de autonomiaDeveloper+
Desfazer uma mudança de autonomiaDeveloper+
Toda a configuração roda no console sob sua sessão (/api/workspace/firewall/* e /api/guardrail/*). Apenas as chamadas de relay /v1/* usam uma chave sk-orca-…; as rotas de chave de gateway são um escopo separado. Veja Escopo: chaves, políticas, workspaces.

​
7. Após a linha de base: onde ajustar cada plano

A linha de base te protege nos primeiros 30 minutos. A partir daí, cada plano tem sua própria referência para trabalho de precisão:

Visão geral do Firewall

Vereditos, superfícies, predicados de argumento, aprovações — o plano de ação.

Guardrails

Regras de keyword, regex, PII, llm_judge e grounding — o plano de conteúdo.

Shadow mode

Faça o rollout de uma política de firewall apertada em apenas-audit antes de aplicar.

Linha de base Secure Agents

A página de conceito do controle de autonomia e sua semântica de desfazer.
A linha de base é o piso que fecha ambos os planos de uma vez; as regras são como você levanta o teto. Veja Segurança de agentes de IA e a pilha de controle para como as camadas se compõem, e Agência excessiva para a ameaça que esta linha de base responde mais diretamente.