Ir para o conteúdo principal
AprenderGlossárioPolítica de gastos do agente
GLOSSÁRIO

O que é uma política de gastos do agente.

DEFINIÇÃO

Uma política de gastos de agente é o conjunto de regras anexadas a uma carteira de agente de IA que governam o que o agente está autorizado a pagar - uma alocação por período (diária, semanal ou mensal), um limite por transação e uma janela de validade de datas de início e fim. A política é definida no painel e aplicada na camada da API da carteira (fora do escopo manipulável do agente), verificada em cada pagamento antes de ser liquidado. A API a expõe como somente leitura.

POR QUE ISSO É IMPORTANTE

A única coisa que torna o pagamento autônomo seguro.

Sem uma política de gastos, dar a um agente uma carteira é dar a um LLM acesso ilimitado a um talão de cheques em dólares. Dois modos de falha são inevitáveis. O primeiro é o loop descontrolado: o planejador de um agente fica preso tentando novamente uma ferramenta paga e consome o saldo do espaço de trabalho em minutos. O segundo é a injeção de prompt: um atacante convence o agente a pagar uma carteira controlada pelo atacante sob a aparência de uma tarefa normal.

Uma política de gasto limita ambos os modos de falha por construção. O loop descontrolado esgota a concessão do período e para. O pagamento injetado excede o limite por transação (ou a concessão restante) e nunca é liquidado. O agente não precisa ser perfeitamente confiável porque a carteira se recusa a liquidar qualquer coisa fora da política. Esta é a diferença entre 'agentes que pagam' serem utilizáveis em produção e serem um experimento.

COMO FUNCIONA

Configure uma vez, avalie cada chamada.

  1. Configurar. O usuário humano define a política no painel: uma concessão por período, um limite por transação e uma janela de validade opcional (datas de início e término). A API expõe a política como somente leitura; as alterações são registradas em auditoria.
  2. Vincular à identidade. A política se anexa à identidade de pagamento do agente. Workspaces de múltiplos agentes têm uma política por agente, além de um limite de nível de workspace que limita a soma.
  3. Avalie em cada intenção. Quando o agente envia uma intenção de pagamento (geralmente impulsionada por uma resposta 402), a API da carteira executa a política: verifique o limite por transação, verifique a concessão restante do período, verifique a janela de validade.
  4. Liquidar ou rejeitar. Se todas as verificações forem bem-sucedidas, a carteira liquida o pagamento e decremente a concessão restante. Se alguma verificação falhar, a carteira rejeita o pagamento (excede um limite ou fica fora da janela) e não liquida.
  5. Auditoria. Cada intenção aceita e cada intenção rejeitada é registrada com a decisão da política anexada. O humano pode revisar o log a qualquer momento para ver o que o agente tentou e o que a política permitiu.

A política é o mesmo tipo de objeto, independentemente de quantos agentes compartilham a carteira. Políticas por agente isolam orçamentos de forma clara; uma política de espaço de trabalho no nível pai aplica um teto rigoroso em todos os agentes filhos combinados.

EXEMPLOS

Três formas de política que vemos em produção.

EXEMPLO 1

Limite diário por agente com teto de chamada única

Um agente de pesquisa tem um limite de $5/dia e um teto de $0,50/chamada. Ele pode fazer 10 chamadas de $0,50, ou 100 chamadas de $0,05, ou qualquer combinação abaixo do total diário. Uma fatura surpresa de $2,00 de uma ferramenta é rejeitada no teto da chamada antes de ser liquidada. Ambos os limites são aplicados simultaneamente; o mais restrito vence por chamada.

EXEMPLO 2

Bloqueio apenas de recebimento

Um agente que só recebe pagamentos tem sua alocação e limite por transação ambos definidos como zero. Ele pode ser pago por qualquer um a qualquer momento, mas não pode enviar USDC de forma alguma - independentemente do que seu código ou uma injeção de prompt tentem fazê-lo fazer. Definir ambos os limites como zero é a defesa mais forte contra redirecionamento de pagamento impulsionado por injeção de prompt: a carteira recusa todos os pagamentos de saída.

EXEMPLO 3

Janela de engajamento com tempo limitado

Um agente contratado recebe uma permissão de gasto que é válida apenas para a janela de 30 dias do engajamento (uma data de início e uma data de término). Dentro da janela, ele pode gastar até sua concessão semanal; após a data de término, a permissão expira e nenhum pagamento adicional é liquidado, sem que ninguém precise se lembrar de desativá-la.

FAQ

Três perguntas comuns.

Qual é a diferença entre uma política de gastos e um limite de taxa?

Um limite de taxa governa a contagem de chamadas; uma política de gastos governa o valor em dólares nas chamadas. Um agente pode ser limitado a 100 chamadas por minuto, mas ainda assim falir seu espaço de trabalho se essas chamadas custarem $1 cada e o agente as fizer por uma hora. Uma política de gastos limita a exposição em dólares independentemente da contagem de chamadas. Os dois controles se complementam - limites de taxa previnem negação de serviço na execução do agente, políticas de gastos previnem negação de fundos na carteira do agente.

Onde a política é aplicada - no código do agente ou na carteira?

Na carteira, na camada da API de pagamento. Aplicá-lo no código do agente significaria que qualquer ataque de injeção de prompt que contornasse o planejador do agente também contornaria o orçamento. Ao aplicá-lo na API da carteira, a política está fora do escopo manipulável do agente. O agente envia uma intenção de pagamento; a carteira avalia a intenção em relação à política; a carteira aceita ou rejeita. O agente não pode aumentar seus próprios limites.

O usuário pode ajustar a política em andamento se um gasto legítimo estiver sendo rejeitado?

Sim, mas apenas o usuário humano (ou outro humano autorizado) pode ajustá-lo - nunca o agente em si. O painel de administração da carteira expõe o editor de políticas; as mudanças são registradas em auditoria com quem-e-quando. Isso mantém o agente dentro dos limites por padrão, enquanto dá ao humano a autorização de que precisa quando um gasto legítimo maior surge. O agente não tem como pedir 'por favor, aumente meu limite' dentro de seu loop de planejamento, porque isso derrotaria o propósito de ter um limite.
Última revisão: 2026-05-15. Publicado sob CC BY 4.0.

Dê ao seu agente um envelope de orçamento.

Concessões por período e limites por transação, definidos no painel. Livre para começar.