Saltar para o conteúdo principal
Um agente não precisa vazar dados para te prejudicar. Ele pode simplesmente gastar — um retry loop martelando um modelo caro, uma instrução injetada por prompt que dispersa mil chamadas de ferramenta, ou uma chave de API vazada acumulando inferência até a fatura chegar. Isto é denial of wallet: o ataque é o próprio custo. Diferente de um denial-of-service clássico, o gateway permanece de pé e cada requisição parece individualmente legítima — o dano é o gasto agregado. O OrcaRouter te dá três tetos independentes que ficam todos na frente do modelo upstream, de modo que nenhum caminho descontrolado isolado pode rodar sua fatura sem limite.

​
1. A ameaça de denial of wallet de ia

Um incidente de denial-of-wallet geralmente remonta a uma de três formas:
Um agente tenta repetidamente a mesma ferramenta falha ou re-planeja em um loop apertado, re-pagando por tokens a cada passada. Nenhuma malícia necessária — uma condição de parada ruim é suficiente.
Uma injeção de prompt direciona o agente a fazer spam de uma ferramenta ou emitir requisições gigantes, multiplicando o gasto por turno.
Uma chave acaba em algum lugar que não deveria — um .env commitado, um notebook compartilhado — e um atacante roda inferência na sua conta até o gasto ser notado.
A defesa é a mesma nos três casos: um teto rígido que o atacante não consegue contornar com conversa, aplicado no gateway, não no código do seu agente.

​
2. Teto de custo por-run com cap_cost

O veredito cap_cost do Firewall é um disjuntor para loops descontrolados. Você o escreve como uma regra com um cap em centavos por-run; o motor soma o gasto acumulado da run do agente e, assim que a run cruza o cap, resolve o veredito para deny — cada chamada de ferramenta posterior naquela run é bloqueada. cap_cost é um teto pré-dispatch: ele avalia antes de a chamada chegar à ferramenta, então ele detém a próxima chamada cara em vez de reembolsar uma já feita. Um cap catch-all típico em cada ferramenta: 
{
  "priority": 50,
  "label": "cap runaway spend at $5 per run",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Abaixo do cap a chamada é permitida; acima dele, a run é negada com um HTTP 400 firewall_blocked — marcada como skip-retry, de modo que o loop não pode martelar em torno da negação. O teto é por run de agente e somado através de toda a política do seu workspace, de modo que uma conversa descontrolada não pode sangrar para o orçamento de outra.
cap_cost lê o gasto corrente dos seus request logs. Mantenha a captura de request-log ligada para o workspace para que o rollup de gasto corrente tenha linhas para somar — caso contrário a estimativa de gasto anterior é conservadoramente 0 e o cap não consegue ver o que uma run já custou.
Veja a referência de regras do Firewall para a linguagem de correspondência completa e onde cap_cost se encaixa entre os outros vereditos.

​
3. Orçamento rígido por chave com credit_limit_usd

cap_cost limita uma única run. Para limitar uma chave — cada run que ela emitir — defina credit_limit_usd na chave de API. É um teto rígido em USD no gasto vitalício daquela chave: o gateway o converte na quota restante da chave, e assim que a chave gastou sua cota, chamadas de relay posteriores são rejeitadas por crédito insuficiente. 0 significa ilimitado. Combine-o com os outros escopos da chave para que uma chave vazada seja limitada em cada eixo de uma vez:

credit_limit_usd

Teto rígido de gasto em USD para a chave (0 = ilimitado).

expired_time

Timestamp de auto-expiração (-1 = nunca). Uma chave de vida curta limita a janela de raio de explosão.

allow_ips

Fixe a chave a IPs de origem conhecidos — uma chave vazada é inútil fora da rede.

model_limits

Restrinja a chave a modelos específicos, para que ela não possa alcançar os mais caros de jeito nenhum.
Dê a cada agente sua própria chave de escopo restrito com um credit_limit_usd que ele nunca deveria exceder legitimamente. O limite é o orçamento, não um palpite sobre o comportamento do atacante — mesmo uma chave totalmente comprometida para no teto.
Configure tudo isso a partir do editor de chave do console (ou da API de token) sob sua sessão — estas são configurações de chave, não chamadas de relay. Apenas as requisições de inferência /v1/* usam a própria chave sk-orca-.... Editar o limite entra em vigor na próxima requisição da chave; sem redeploy.

​
4. Capture o pico que você não previu: anomalias de custo

Um cap estático detém o gasto que você antecipou. A detecção de anomalias do Firewall captura o gasto que você não previu. Ela aprende a forma normal de uso de ferramenta de cada workspace contra uma baseline por hora-da-semana (uma média móvel de 14 dias) e expõe desvios em um feed legível por Member:
AnomaliaO que ela sinaliza
burn_spikeCusto de uma ferramenta muito acima de seu custo de baseline aprendido — o sinal de denial-of-wallet.
rate_spikeVolume de chamadas muito acima da baseline — fan-out e inundações.
retry_loopA mesma ferramenta com os mesmos argumentos repetindo em uma janela apertada — o loop descontrolado clássico.
Então “esta ferramenta queimou 40× seu custo usual nesta hora” se destaca mesmo quando cada chamada individual foi permitida pela política. Você pode dar snooze em uma anomalia por até 7 dias enquanto investiga.
A detecção de anomalias é seu alerta precoce; cap_cost e credit_limit_usd são as paradas rígidas. Observe o feed para descobrir onde seu gasto real vive, depois escreva um cap em torno dele.

​
5. Juntando tudo

Empilhe os três para que um descontrole nunca chegue à fatura:
ControleEscopoQuando dispara
Regra cap_costUma run de agenteO gasto acumulado da run cruza o cap em centavos
credit_limit_usdUma chave, vitalícioO gasto total da chave atinge seu teto em USD
burn_spike / retry_loopWorkspace, aprendidoGasto ou padrão de repetição desvia da baseline
Uma baseline prática: um cap_cost por-run em *, um credit_limit_usd em cada chave de agente e o hábito de checar o feed de anomalias. Faça o rollout de uma nova política cap_cost em shadow mode primeiro — ela registra [shadow] would deny sem bloquear — de modo que você possa dimensionar o cap contra tráfego real antes de ele morder.
cap_cost e o feed de anomalias limitam chamadas de ferramenta e runs que cruzam o gateway. Uma ferramenta que um agente executa inteiramente dentro de seu próprio processo nunca chega ao motor. Roteie chamadas de ferramenta mediadas por modelo e MCP através do gateway — e dê a cada chave um credit_limit_usd — para que o teto se mantenha independentemente de como o agente faz loop.

​
6. Ameaças relacionadas

Denial of wallet raramente chega sozinho — o loop que queima seu orçamento é frequentemente conduzido por algo upstream:

Visão geral do Firewall

Vereditos, detecção de anomalias, níveis de autonomia e observabilidade.

Chaves e políticas com escopo

Como limites de chave, guardrails e políticas de firewall compõem por chave.