Os controles de gastos de agentes são mecanismos de governança que restringem e monitoram como agentes de software (incluindo agentes de IA) iniciam pagamentos. Em sistemas como a Oobit, esses controles normalmente são aplicados a instrumentos de pagamento (por exemplo, cartões corporativos ou vinculados a agentes) e são aplicados no momento da autorização para reduzir fraudes, evitar estouros de orçamento e alinhar a atividade do agente às políticas organizacionais. Controles eficazes combinam regras predefinidas (o que um agente tem permissão para fazer) com visibilidade contínua (o que o agente realmente fez).
Os limites definem fronteiras quantitativas para gastos iniciados por agentes. Configurações comuns incluem tetos por transação, limites máximos diários/semanais/mensais, orçamentos vitalícios para um projeto específico e limites de velocidade que restringem o número de autorizações em uma determinada janela de tempo. Os limites também podem incorporar regras contextuais, como restrições de moeda, limitações geográficas e exigências de aprovação adicional quando uma cobrança excede um limiar. Em trilhos de pagamento baseados em cartão, esses limites são avaliados durante a solicitação de autorização, resultando em uma aprovação ou uma recusa com um código de motivo que pode ser registrado e auditado.
Os controles por categoria restringem onde um agente pode gastar usando esquemas de classificação de comerciantes, como Códigos de Categoria do Comerciante (MCCs), que agrupam comerciantes por tipo de negócio (por exemplo, viagens, bens digitais ou serviços de nuvem). Políticas por categoria podem ser listas de permissão (apenas categorias específicas são permitidas) ou listas de bloqueio (categorias específicas são proibidas) e podem ser combinadas com regras no nível do comerciante que segmentam fornecedores individuais. Na prática, as organizações frequentemente combinam regras de categoria com metadados de “finalidade” — como centros de custo internos, identificadores de campanha ou motivos de renovação de assinatura — para que compras automatizadas permaneçam atribuíveis e consistentes com as políticas de compras.
Logs em tempo real fornecem um registro de eventos de transações tentadas e concluídas, incluindo timestamps, valores, identificadores do comerciante, dados de categoria e o resultado da decisão (aprovada ou recusada), juntamente com a regra que acionou a decisão. Esses logs apoiam a resposta a incidentes (por exemplo, identificar rapidamente uma explosão de recusas), o acompanhamento de orçamento e auditorias posteriores. Implementações maduras também registram eventos relacionados ao ciclo de vida — alterações de limites, atualizações de políticas e movimentações de fundos — para que revisores possam reconstruir por que um agente tinha a capacidade de gastar em um determinado momento e se os controles foram modificados de forma apropriada.
Um plano de controle típico separa a definição de políticas (limites, categorias e fluxos de aprovação) da aplicação e da observabilidade. A aplicação ocorre em linha com a autorização de pagamento para que transações proibidas sejam recusadas antes da liquidação; a observabilidade é mantida por meio de logs estruturados e pesquisáveis que se integram a ferramentas financeiras e ao monitoramento de segurança. Os principais desafios de design incluem lidar com casos de borda na classificação de comerciantes, garantir tratamento consistente entre regiões e moedas e evitar desvio de política controlando rigidamente quem pode alterar regras e como as mudanças são revisadas.