# As ações de custos da nuvem para agentes de IA precisam de um limite rígido

Um agente de IA pode ler uma fatura da nuvem, agrupar recursos ociosos e estimar uma oportunidade de economia com pouco perigo. A situação muda quando ele redimensiona um banco de dados, compra uma reserva, transfere uma relação de cobrança ou fecha uma conta. Essas chamadas alteram dinheiro, capacidade de serviço, compromissos contratuais ou opções de recuperação. Elas precisam de um limite que um relatório útil não precisa.

As equipes cometem esse erro porque as APIs de nuvem colocam relatórios e alterações atrás da mesma identidade. Um agente recebe um token amplo para inspecionar custos, e alguém então pede que ele «aplique a economia óbvia». O modelo de permissões resultante pede que o agente decida onde termina a análise e começa a autoridade. Não delegue essa distinção a um modelo.

## Relatórios não devem carregar permissão para gastar

Os relatórios de custos respondem ao que aconteceu ou ao que pode acontecer. Uma operação que altera gastos cria um novo fato na conta do provedor. Coloque essas duas tarefas atrás de credenciais separadas, ferramentas separadas ou ambas.

Um agente pode produzir com segurança uma lista de candidatos quando lê exportações de cobrança, métricas de uso, inventário e dados de preços. A saída deve identificar suas evidências e lacunas. O agente não deve transformar silenciosamente um candidato em uma solicitação de API porque uma economia projetada ultrapassou algum limite.

A distinção fica confusa por causa de comandos com nomes inofensivos. Um endpoint de «recomendação» pode criar uma exportação. Um endpoint de «compromisso» pode cotar, comprar, alterar ou cancelar, dependendo de um campo. Uma solicitação de capacidade pode ser uma estimativa em um provedor e uma alteração vinculante em outro. Leia a referência exata da API do provedor, não o rótulo que o console coloca acima de um botão.

A orientação Cloud FinOps da FinOps Foundation separa as atividades de informar, otimizar e operar. Esse é um modelo de negócio útil, mas não cria um modelo de autorização. Uma pessoa ou um agente pode informar sem ter permissão para operar. Trate essa diferença como uma decisão de projeto, não como burocracia.

Dê ao lado de relatórios um contrato restrito. Ele pode solicitar um período limitado, contas nomeadas, regiões nomeadas e um tipo de relatório. Deve retornar valores com suas unidades e sua origem. Uma ferramenta deve rejeitar uma consulta sem limites, como «mostre todos os registros de cobrança», quando a tarefa envolve uma única conta de produção.

Um relatório também precisa trazer contexto suficiente para evitar confiança excessiva. No mínimo, mantenha:

- o escopo da conta de cobrança ou do projeto
- o período e a atualização dos dados
- a moeda, a base de preços e a indicação de impostos ou créditos
- os identificadores dos recursos por trás de cada recomendação
- as premissas usadas na previsão

Isso não é burocracia. Um custo mensal amortizado e uma cobrança diária em dinheiro podem estar corretos e ainda assim apoiar conclusões opostas sobre um compromisso proposto.

## Classifique a ação pela consequência, não pelo verbo da API

Um verbo como `update` quase não informa o risco. Classifique uma ação de custos da nuvem pelo que ela altera, pelo alcance do efeito e pela dificuldade de desfazê-la.

Eu uso quatro grupos. O primeiro contém observações: listar recursos, obter faturas, ler utilização e gerar uma previsão. O segundo contém alterações locais reversíveis: ajustar o limite mínimo de escalonamento automático ou mudar o tamanho de um worker não crítico quando a equipe tem uma reversão testada. O terceiro contém compromissos controlados: comprar uma reserva, alterar um plano de economia, mover um recurso para outro acordo de preços ou mudar um alerta de orçamento. O quarto contém ações destrutivas ou de governança: excluir exportações de cobrança, remover controles de pagamento, transferir propriedade, excluir recursos compartilhados e fechar uma conta.

Os dois grupos intermediários causam a maioria das decisões ruins. As equipes chamam um redimensionamento de reversível porque podem enviar outra solicitação de redimensionamento. Isso ignora o tempo de reinicialização, os limites de capacidade, a disponibilidade da família de instâncias, os discos locais e as aplicações que dependem do formato antigo. As equipes chamam uma reserva de compra porque o console diz «comprar». Ela também é uma previsão sobre o uso elegível futuro, com prazo e obrigação de pagamento.

Use um registro de consequências antes que o agente possa chamar qualquer alteração. O registro deve indicar o alvo, o efeito esperado sobre os custos, o efeito no serviço, o método de recuperação e a aprovação humana necessária. Pode ser um JSON simples:

```json
{
  "action": "resize_compute_group",
  "scope": {
    "billing_account": "finance-prod",
    "region": "eu-west-1",
    "resource_group": "batch-workers"
  },
  "before": {"instance_type": "c6i.2xlarge", "minimum": 6},
  "after": {"instance_type": "c6i.xlarge", "minimum": 6},
  "expected_monthly_delta": {"currency": "USD", "amount": -412},
  "service_effect": "rolling replacement of batch workers",
  "rollback": "restore c6i.2xlarge and wait for replacements",
  "approval": "per_call"
}
```

Esse artefato evita uma falha recorrente: o agente envia uma solicitação válida para um alvo que o revisor nunca viu. O provedor valida apenas se a carga pode ser executada. Ele não valida se o solicitante quis dizer `finance-prod`, se a previsão usa o preço correto ou se o grupo de workers tem capacidade disponível suficiente.

Não deduza o risco apenas pelo valor esperado em dinheiro. Um pequeno redimensionamento pode interromper um serviço que gera receita. Uma compra grande, mas limitada, pode ser aceitável se o departamento financeiro já a tiver previsto. Escopo, reversibilidade e dependência operacional devem aparecer ao lado da economia projetada.

## Uma recomendação é evidência, não instrução

Um agente deve fazer recomendações de custos em um formato que um revisor possa contestar. Se não consegue explicar por que um recurso parece desperdiçado, quais medições usou e o que tornaria a recomendação errada, ele escreveu um palpite cercado por uma tabela.

Para um redimensionamento de computação, exija utilização ao longo de um ciclo operacional relevante, não uma amostra conveniente de uma tarde tranquila. Inclua CPU, memória quando disponível, profundidade da fila, latência, taxa de erros e picos programados. A CPU sozinha costuma enganar. Muitos serviços esperam por memória, armazenamento, rede, um pool de conexões ou um limite de licenciamento.

Para uma alteração de armazenamento, diferencie o tamanho alocado dos bytes consumidos, o desempenho provisionado dos IOPS observados e a retenção de snapshots do custo atual do volume. Uma proposta para reduzir um volume pode não fazer sentido quando o provedor não permite reduzi-lo no local. Uma proposta para excluir snapshots antigos pode destruir a única cópia recuperável de um banco de dados cujo processo de restauração deixou de ser testado há anos.

A mesma disciplina vale para recomendações de compromissos. O agente precisa do uso elegível, não do gasto total. Um compromisso que se aplica apenas a uma família, região, sistema operacional, modelo de locação ou opção de compra específica não cobre tudo em uma categoria ampla de serviço. O desconto aparente importa menos que a quantidade de uso estável que realmente se qualifica.

Peça ao agente que retorne uma abstenção explícita quando as evidências forem insuficientes. Boas abstenções soam assim:

> Encontrei baixo uso de CPU nestes workers, mas não há métricas de memória nem registro do pico programado. Posso preparar uma solicitação de redimensionamento depois que o responsável confirmar a carga máxima e a janela de reversão.

Essa resposta é mais útil que uma recomendação confiante que obriga um operador a reconstruir as premissas ausentes. Modelos tendem a completar padrões. Sua interface de ações deve oferecer uma forma autorizada de parar.

## Compromissos merecem uma revisão de compra separada

Reservas, compromissos de economia, blocos de capacidade e descontos semelhantes exigem uma revisão de compra mesmo quando a aritmética do agente está correta. Eles transformam uma previsão de uso em uma obrigação.

A regra fraca mais comum diz: «aprove compromissos acima de um limite monetário». Ela é popular porque é fácil de explicar e automatizar. Falha porque um compromisso de baixo custo pode fragmentar a cobertura entre várias equipes, enquanto um compromisso maior pode corresponder a uma base documentada que o departamento financeiro já aprovou. Um limite mede o tamanho do chamado, não a qualidade da decisão.

Exija que a proposta informe claramente:

- a base de uso elegível por hora ou por dia
- o nível de cobertura que o agente propõe comprar
- prazo, opção de pagamento e escopo
- cargas que podem perder a elegibilidade depois de uma migração planejada
- a pessoa responsável pela previsão

Uma proposta sólida também separa três números que as pessoas costumam juntar: gasto sob demanda, gasto com desconto para o uso coberto e custo do compromisso não utilizado. Os dois primeiros tornam o desconto atraente. O terceiro mostra o quanto a previsão pode estar errada antes que a economia desapareça.

Suponha que um agente veja uso estável em vários grupos de computação e proponha cobertura para o total. Isso pode ser razoável ou pode ser uma armadilha. Uma equipe pode encerrar seu grupo no próximo trimestre, outra pode mudar de região e uma terceira pode usar um tipo de plataforma que não se qualifica. O agente deve informar cada componente e qualquer mudança futura que tenha encontrado. Assim, o revisor pode excluir a demanda incerta em vez de discutir com um único gráfico misturado.

A documentação do provedor geralmente descreve as regras de elegibilidade com precisão, enquanto os consoles de cobrança costumam resumi-las de forma vaga. Use a API e a documentação de cobrança como fonte de verdade quando as duas visões divergirem. A «economia estimada» de um console é um cenário, não uma revisão contratual.

Não dê a um agente geral de otimização de custos autoridade para comprar porque ele tem permissão para criar relatórios. Crie uma rota específica de compra que aceite apenas uma proposta totalmente especificada e exija um aprovador que entenda tanto o orçamento quanto o plano da carga de trabalho.

## Redimensionar a capacidade pode quebrar serviços antes de economizar dinheiro

Um redimensionamento altera um sistema em execução, mesmo quando o provedor o trata como rotina. O agente deve mostrar a consequência operacional antes que alguém aprove uma conta menor.

O padrão de falha é conhecido. O agente encontra instâncias com baixo uso médio de CPU, escolhe um formato menor e envia uma atualização gradual. As novas instâncias têm menos memória. O serviço começa a usar swap durante o pico diário de tráfego, a latência da fila aumenta, o escalonamento automático adiciona mais nós e a conta mensal sobe. Em outra versão, os nós antigos usavam armazenamento temporário local, e o processo de substituição descarta trabalho inacabado. O relatório de custos não continha nenhuma dessas informações.

Uma proposta de redimensionamento precisa de um responsável pelo serviço, uma condição de manutenção e um gatilho de reversão. «Reverter se os erros aumentarem» é vago, porque todo serviço tem alguma taxa de erros. Defina o sinal e a janela de observação. Por exemplo, o responsável pode exigir um limite para a idade da fila, um objetivo de latência ou a conclusão bem-sucedida de um ciclo de processamento antes que o agente possa informar sucesso.

A solicitação de execução deve vincular todos os seletores do alvo. Nunca permita que um comando livre como `resize all nonproduction workers` atravesse uma fronteira de autorização. Resolva primeiro a lista de alvos, apresente-a e envie identificadores, em vez de uma consulta por tags que possa encontrar novos recursos depois da aprovação.

Uma sequência de execução útil tem quatro partes:

1. O agente coleta métricas e resolve os recursos exatos.
2. Ele cria um registro da alteração com a configuração atual, a configuração proposta, a reversão e a condição de teste.
3. Uma pessoa aprova esse registro imutável para os recursos nomeados.
4. O executor envia a solicitação, registra o identificador da operação no provedor e informa apenas as verificações previstas no contrato.

A palavra «imutável» importa. Se o agente puder alterar a lista de alvos depois da aprovação, o cartão de aprovação vira encenação. Se a alteração precisar ser ampliada, crie um novo registro e solicite outra aprovação.

## O fechamento de uma conta precisa de outra credencial e confirmação humana

O fechamento de uma conta pertence a uma classe própria porque afeta cobrança, identidade, acesso ao suporte, dados retidos e caminhos de recuperação ao mesmo tempo. Não o coloque atrás de um fluxo de otimização.

Um provedor pode usar uma sequência, e não uma única chamada de API. Pode exigir credenciais do proprietário, uma verificação de pagamento, um período de espera ou ações separadas para projetos e membros da organização. Seu agente nunca deve tratar uma primeira resposta bem-sucedida como prova de que o fechamento terminou ou de que os dados desapareceram. Ele deve registrar o estado informado pelo provedor e dizer ao operador o que ainda falta fazer.

Dê ao fechamento de contas uma credencial dedicada, sem tarefas comuns de leitura ou alteração. Exija uma confirmação digitada ou uma aprovação que mostre o identificador exato da conta, o nome legal ou de cobrança, se seus registros o contiverem, e uma declaração clara do efeito esperado. Uma solicitação que diga «feche a conta de teste» não basta. Os nomes são reutilizados e as tags são copiadas.

Separe o fechamento da limpeza. Um agente pode inventariar recursos ociosos e preparar um plano de exclusão. Não deve concluir que excluir esses recursos concede permissão para fechar a conta. A economia da limpeza e a decisão de governança de encerrar uma conta têm responsáveis diferentes.

O planejamento de recuperação também muda a resposta. Se uma equipe consegue exportar registros, verificar backups, transferir domínios, preservar evidências de auditoria e documentar a remoção de dependências, pode aprovar o fechamento com confiança. Se não consegue, o agente deve produzir um relatório de prontidão e parar. Um fluxo de fechamento que falha é inconveniente. Um fechamento concluído com uma dependência esquecida é muito pior.

## A aprovação deve estar vinculada à chamada exata

Uma aprovação ampla, como «permitir a otimização da nuvem nesta sessão», é adequada para coletar evidências. É uma proteção fraca para ações que alteram gastos ou destroem acesso. Um agente pode fazer dezenas de leituras razoáveis e depois emitir uma alteração inadequada, quando o operador já parou de acompanhar.

Vincule a aprovação a uma solicitação canônica. Ela inclui o tipo de ação, a conta, a região, os identificadores dos recursos, os valores desejados e qualquer prazo ou opção de pagamento da compra. Mostre o efeito esperado sobre os custos como contexto, mas não o use como identidade da solicitação. As previsões mudam; uma chamada ao provedor precisa continuar inequívoca.

A camada de autorização deve rejeitar diferenças relevantes entre a solicitação aprovada e a solicitação enviada. Isso inclui outra conta, um seletor mais amplo, uma quantidade alterada, uma região diferente ou outro prazo de compromisso. Tenha cuidado também com campos omitidos. Os provedores costumam atribuir valores padrão, e esses valores podem mudar entre versões da API ou contas.

A confirmação por chamada tem um custo: interrompe as pessoas. Use-a para o pequeno grupo de operações em que a interrupção custa menos que o arrependimento. Permita uma autorização de sessão para o processo do agente inspecionar dados dentro do escopo, mas exija uma confirmação separada para cada compra de compromisso, alteração de capacidade, ação de governança da conta ou uso de uma credencial marcada especialmente.

O Sallyport segue esse formato, com autorização de sessão para um novo processo de agente e uma aprovação opcional por chave para cada uso dessa credencial. A distinção é útil porque uma execução aprovada do agente ainda precisa de uma decisão humana antes de chamar uma credencial capaz de alterar gastos.

O texto da aprovação deve mostrar à pessoa que revisa o que o provedor receberá. Não peça que ela aprove um nome de ferramenta como `cloud.execute`. Mostre `resize_compute_group`, o grupo-alvo exato, os valores antigos e novos e a declaração de reversão. Se a interface não comportar essas informações, o contrato da ação é amplo demais.

## Mantenha um registro de auditoria que o agente não possa reescrever

Uma resposta bem-sucedida da nuvem não é uma trilha de auditoria. Ela informa que o provedor aceitou uma solicitação, mas pode não preservar a intenção, a autorização, os alvos resolvidos ou as evidências que levaram à chamada.

Armazene um registro somente de acréscimo antes que a solicitação saia do ponto de controle. Registre a proposta, as referências das evidências, a solicitação canônica, a decisão de autorização, a identidade do solicitante, o horário, a resposta do provedor e o identificador da operação. Armazene também as respostas de erro. Uma solicitação rejeitada muitas vezes explica uma solução posterior ou mostra que um agente tentou obter uma permissão mais ampla.

O encadeamento de hashes oferece uma verificação prática de integridade. Cada entrada inclui um resumo da entrada anterior e do próprio conteúdo. Se alguém alterar, remover ou reordenar uma entrada histórica, a verificação falhará no ponto da ruptura. Isso não prova que a solicitação original foi sensata. Prova que a sequência registrada não mudou sem ser detectada.

A NIST SP 800-92, Guide to Computer Security Log Management, recomenda proteger a integridade dos registros e mantê-los disponíveis para revisão. O conselho é antigo porque a falha também é antiga: as equipes coletam registros em locais onde o mesmo processo comprometido pode editá-los. Para ações de agentes, mantenha o gravador de auditoria fora do acesso direto do agente ao sistema de arquivos e às credenciais.

O Sallyport projeta seus diários Sessions e Activity a partir de um registro de auditoria criptografado, encadeado por hash e sem permissão de escrita, e `sp audit verify` pode verificar a cadeia offline sem uma chave do cofre. Essa é a propriedade que você deve exigir de qualquer gateway de ações: o agente pode receber resultados, mas não pode alterar o registro do que pediu para fazer.

Revise o registro depois de uma alteração, não apenas durante um incidente. Uma amostra semanal de propostas e ações concluídas pelos agentes revela escopos inadequados, declarações de reversão fracas e aprovações que as pessoas clicam sem ler. Você encontrará vazamentos de limites mais rapidamente no trabalho rotineiro do que em uma análise posterior ao incidente.

## Crie rotas estreitas de ações em vez de um superusuário da nuvem

Uma credencial de superusuário da nuvem atrás de uma interface de chat amigável continua sendo uma credencial de superusuário. O raciocínio do agente pode melhorar, mas a autoridade não fica mais segura.

Crie rotas de ações que correspondam a decisões reais. Uma rota pode recuperar registros de custos e uso para um escopo nomeado. Outra pode preparar uma solicitação de redimensionamento, mas não executá-la. Uma rota de compra pode enviar apenas uma proposta de compromisso depois de uma aprovação dedicada. Uma rota de fechamento só deve existir se sua organização realmente precisar preparar automaticamente esse processo, e deve terminar na confirmação humana.

Mantenha a injeção de credenciais dentro do executor de ações. O agente deve receber resultados estruturados, não tokens bearer, chaves privadas SSH, saídas temporárias de comandos que exponham segredos ou marcadores que ele possa repetir acidentalmente em uma transcrição. Isso protege a credencial e reduz a chance de o agente levar autoridade para ferramentas não relacionadas.

Teste as rotas com casos de falha antes de confiar no caminho normal. Tente substituir a região depois da aprovação. Tente um seletor que se expanda para um recurso recém-criado. Tente uma solicitação de compromisso sem prazo. Tente uma solicitação de fechamento que informe um alias em vez de um identificador de conta. A rota deve rejeitar cada uma com uma explicação que aponte o campo ausente ou incompatível.

O primeiro controle que vale a pena criar geralmente não é um redimensionamento autônomo. Crie uma rota de relatórios que produza um pacote de evidências e depois uma rota de propostas que não possa chamar o provedor. Quando os revisores conseguirem aceitar, rejeitar e alterar essas propostas de forma confiável, adicione uma alteração estreita, com aprovação vinculada e reversão testada. Uma economia na nuvem que exige explicar uma interrupção ou uma compra indesejada nunca foi economia.