Saltar para o conteúdo principal
Um agente autônomo de longa duração é a coisa mais difícil de proteger. Ele roda em loop por conta própria por horas, escolhe suas próprias ferramentas, busca suas próprias URLs e gasta o seu dinheiro o tempo todo. Os modos de falha não são um único prompt ruim — são um loop de retry que queima $400 durante a noite, uma chamada de ferramenta que você nunca revisou, uma chave que você cunhou para um experimento de uma semana e que ainda funciona seis meses depois. Esta receita conecta quatro controles em torno exatamente desse formato de agente. Você configura todos eles no console (ou na API REST) — o agente continua chamando https://api.orcarouter.ai/v1/... exatamente como antes.
Novo aqui? Aplique a linha de base balanced primeiro e observe o que seu agente faz por um dia. Esta página é o próximo passo: transformar observação em enforcement para um agente que você não pode babar.

​
1. A receita do agente autônomo seguro

Um agente autônomo seguro precisa de quatro coisas que um chatbot não precisa:

Um teto de custo rígido

Uma regra cap_cost nega a run assim que o seu gasto acumulado cruza o seu limite — o disjuntor para um loop que não para.

Detecção de picos

A detecção de anomalias aprende o formato normal de hora-da-semana do agente e sinaliza picos de taxa e custo que escapam de regras estáticas.

Aprovação nas chamadas perigosas

Um veredito pending_approval retém chamadas de ferramenta destrutivas ou irreversíveis para um humano, em vez de confiar que o agente terá cuidado.

Uma chave que expira

Escope a chave do agente para uma expiração e um teto de crédito, de modo que um experimento esquecido não possa rodar — ou gastar — para sempre.
Cada uma mapeia para um campo de política de Firewall ou de chave. Nenhuma toca no código do seu agente.

​
2. Limite o custo de cada run

A primeira coisa que um loop descontrolado estoura é o seu orçamento. Uma regra cap_cost é um teto de custo estrito de pré-verificação: quando ela corresponde, o gateway estima o custo da requisição e nega antes do dispatch assim que o gasto acumulado da run excederia o limite — então uma chamada acima do orçamento nunca chega ao provedor. O limite é com escopo de run. O gateway soma o gasto anterior em toda a run do agente, então uma run longa que já queimou a maior parte do seu orçamento é negada mesmo quando a próxima chamada individual é barata. É isso que o torna um disjuntor em vez de um limite por requisição. Adicione uma regra wildcard à sua política de firewall: 
{
  "priority": 50,
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 1000
}
Isso limita a run em $10 (cap_cost_cents está em centavos de USD). O veredito resolve para allow enquanto está abaixo do orçamento e deny assim que a estimativa o cruzaria. A maioria dos templates de firewall embutidos (Coding, Support, RAG, Data, DevOps, Browser) entrega um limite de custo por run exatamente assim — aplique um e edite o limite.
A acumulação com escopo de run precisa da captura de request-log habilitada para o workspace. Com ela desligada, o rollup de gasto anterior lê zero e o limite degrada para somente por requisição — ainda seguro, mas não vai capturar um gotejamento lento de 500 chamadas. Veja denial-of-wallet.

​
3. Detecte picos contra uma baseline aprendida

Um limite para a catástrofe; a detecção de anomalias captura o estranho antes que se torne uma. O Firewall aprende o formato normal de uso de ferramentas de cada workspace — uma média móvel de 14 dias agrupada por hora-da-semana, de modo que o tráfego de terça-14:00 é comparado com o histórico de terça-14:00, não com uma média diária plana — e exibe desvios em um feed legível pelo viewer:
Volume de chamadas por ferramenta pontuado contra a baseline aprendida. “143 chamadas db.query em uma hora contra uma baseline de 8” se destaca mesmo quando cada chamada individual é permitida.
A mesma baseline, aplicada ao gasto em vez de contagem — uma run que de repente queima muito mais do que esta hora normalmente queima.
A assinatura de um agente autônomo preso reexecutando a mesma chamada quebrada. Veja agência excessiva.
Um salto de ferramenta-para-ferramenta que este workspace nunca fez — o formato de um agente indo para algum lugar novo.
O feed reporta nomes de ferramenta, ids de token redigidos e contagens — nunca argumentos brutos. Lê-lo está aberto a qualquer Member; um Developer+ pode dar snooze no feed por até 7 dias enquanto investiga. Emparelhe o feed com uma regra cap_cost para que um pico que também está acima do orçamento seja parado, não apenas notado.

​
4. Retenha as chamadas perigosas para um humano

Você não pode revisar cada chamada que um agente autônomo faz — mas pode fazê-lo parar e perguntar antes da meia dúzia que importa. Um veredito pending_approval retém uma chamada de ferramenta fora de banda:
  1. O agente emite, digamos, uma chamada payments.transfer. A regra corresponde e o motor retorna HTTP 400 firewall_approval_pending com um id de aprovação — a chamada nunca chega à ferramenta.
  2. Um revisor a resolve a partir do console (Developer+), ou o seu próprio sistema a resolve via um callback de webhook assinado por HMAC para POST /api/v1/firewall/approvals/:id/callback.
  3. O agente consulta GET /api/v1/firewall/approvals/:id; uma vez aprovado ele reenvia a chamada original com um header X-OrcaRouter-Firewall-Approval de uso único, e o gateway a deixa passar aquela única vez.
Uma regra que retém escritas em uma superfície destrutiva: 
{
  "priority": 20,
  "tool_name_glob": "payments.*",
  "verdict": "pending_approval"
}
Faça o rollout disto em shadow mode primeiro — pending_approval rebaixa para audit, então você vê quais chamadas seriam retidas sem de fato bloquear seu agente. Vire o shadow off quando o feed parecer certo.

​
5. Dê ao agente uma chave que expira

O controle que sobrevive a toda política é a própria chave. Um agente autônomo deveria receber uma chave com escopo, não a sua padrão. Defina estes campos quando você a cunhar (console → keys, ou a API de token):
CampoDefina paraPor quê
expired_timeum timestamp UnixO experimento acaba; a chave morre com ele. -1 significa nunca — não use isso aqui.
credit_limit_usdum teto em dólaresUm limite de gasto na chave independente do limite da run. 0 significa ilimitado.
firewall_policy_idsua política acimaVincula as regras cap_cost + aprovação a esta chave.
allow_ipsos IPs de egress do agenteUma chave vazada é inútil de qualquer outro lugar.
Defina também uma tag environment, para que a chave — e tudo o que ela faz em Events e Matches — seja atribuível a este agente. Uma chave que expira, com limite de crédito e fixada por IP é a última linha: mesmo que toda política fosse de alguma forma contornada, o raio de explosão é limitado por tempo e dólares.
A configuração de chave é uma ação de console / API de token e é controlada por papel. Ler o texto plano de uma chave de firewall-gateway exige Admin+.

​
6. Juntando tudo

Um agente autônomo endurecido acaba com uma política de firewall e uma chave com escopo:
CamadaControleCaptura
OrçamentoRegra cap_cost, com escopo de runLoops descontrolados, denial-of-wallet
ComportamentoFeed de anomalias (rate / burn / retry / novel)O estranho-mas-permitido
Confiançapending_approval em ferramentas destrutivasAções irreversíveis
EscopoChave que expira, com limite de crédito e fixada por IPChaves esquecidas ou vazadas
Crie as regras de orçamento e aprovação juntas, defina um limite por run com regras de firewall e leia o resto da referência de Firewall para superfícies, vereditos e observabilidade. Para as ameaças relacionadas contra as quais esta receita defende, veja agência excessiva, chamadas de ferramenta perigosas e denial-of-wallet.

​
7. Próximos passos

Endureça um agente MCP

Governe um agente que alcança ferramentas através de servidores MCP.

Pare a exfiltração

Regras de egress para um agente que busca suas próprias URLs.

Modos de enforcement

Observe → shadow → enforce, o rollout seguro.

Regras de firewall

A linguagem de correspondência por trás de cada regra acima.