Guardrails para agentes de IA: como adicionar aprovações e orçamentos

Guardrails para agentes de IA são controles de backend que restringem o que um agente pode acessar, executar e gastar, mesmo quando o modelo gera instruções inseguras. Para um app construído no Lovable, comece com permissões restritas de ferramentas, aprovações específicas para cada ação, logs de auditoria e limites rígidos de gastos. Este guia transforma esses controles em uma arquitetura concreta de agente de suporte, com um prompt pronto para copiar e colar e testes de lançamento.

O que os guardrails de agentes de IA devem controlar

O modelo propõe uma ação. Sua aplicação decide se essa ação é permitida. Mantenha essa fronteira intacta.

Pensando em um aplicativo lançado em outubro de 2026, a pergunta útil não é se o modelo suporta chamadas de função (tool calling). A questão real é se uma chamada inadequada pode invadir os dados de outro cliente, movimentar dinheiro ou estourar a fatura.

Imagine um agente de suporte que lê chamados, redige respostas e propõe reembolsos. Ler um chamado autorizado traz baixo risco. Enviar uma resposta gera consequências externas. Emitir um reembolso envolve dinheiro. Essas ações não devem compartilhar a mesma política de permissão.

| Ação | Política padrão | Aplicação no backend | | --- | --- | --- | | Ler um chamado | Permitir dentro do escopo do tenant | Verificar autenticação do membro e titularidade do chamado | | Redigir uma resposta | Permitir sem enviar | Salvar rascunho, sem expor credenciais de e-mail | | Enviar uma resposta | Exigir aprovação inicialmente | Aprovar destinatário exato, corpo e anexos | | Emitir um reembolso | Exigir aprovação autorizada | Validar pagamento original, valor, moeda e saldo reembolsável restante | | Excluir registros | Negar na primeira versão | Não expor nenhuma ferramenta de exclusão |

Essas regras são políticas de produto, não limites universais. Um fluxo de trabalho na área médica exige diretrizes bem diferentes de um sumarizador de reuniões internas.

Trabalhe com cinco controles distintos:

1. Identidade: Qual usuário e tenant iniciaram esta execução?
2. Escopo: Quais registros e ferramentas o agente consegue alcançar?
3. Autoridade: Quais ações exigem o aval de outra pessoa?
4. Orçamento: Quantas chamadas e quantos dólares ele pode consumir?
5. Evidência: O que aconteceu, e você consegue reconstruir o histórico?

Validadores de saída e detectores de injeção de prompt ajudam. Eles não substituem esses controles. Um pedido de reembolso perfeitamente formatado ainda pode atingir o pagamento de outra pessoa.

Se você ainda estiver escolhendo um fluxo de trabalho, explore nossos guias de agentes de IA. Comece com uma ferramenta que gere valor real, em vez de criar um agente genérico com acesso irrestrito a requisições HTTP.

Construa um fluxo de aprovação no Lovable

Utilize o Lovable para a interface de operação e a estrutura visual da aplicação. Deixe a autorização, a validação de aprovações e a execução das ferramentas em funções server-side ou em um worker. Uma implementação baseada em Supabase é uma ótima opção; a mesma arquitetura funciona com outros bancos de dados transacionais.

Reserve cerca de 6 a 12 horas de engenharia para um protótipo enxuto com uma ferramenta de leitura e uma de escrita protegida por aprovação. Essa estimativa serve para planejamento, não é garantia de que código gerado esteja pronto para produção. Integrações de pagamento e revisões de segurança exigem tempo dedicado.

1. Crie o modelo mínimo de dados

Crie estas tabelas:

• `agent_runs`: tenant, usuário que iniciou, status, versão da política, limites e contadores de custo.
• `agent_actions`: execução, nome tipado da ferramenta, argumentos canônicos, hash dos argumentos, expiração e estado de execução.
• `agent_approvals`: ação, aprovador, hash dos argumentos aprovados, decisão e expiração.
• `agent_events`: execução, ação, timestamp, tipo de evento, autor e metadados tratados.
• `agent_usage`: reserva, identificador da requisição no provedor, custo estimado, custo real e status de conciliação.

Adicione `tenant_id` em cada registro relevante. Ative o Row-Level Security para tabelas acessíveis pelo navegador. O backend ainda precisa verificar o tenant ao usar credenciais privilegiadas, já que essas credenciais ignoram as políticas de RLS.

O navegador pode solicitar uma execução ou enviar a decisão de uma aprovação. Ele nunca deve editar diretamente o estado da execução, orçamentos ou registros de auditoria.

2. Exponha ferramentas de escopo reduzido

Prefira `get_ticket(ticket_id)` e `propose_refund(payment_id, amount_minor, currency, reason)` em vez de `fetch_url(url)` ou `execute_sql(query)`.

Valide os argumentos contra um schema estrito, rejeite campos desconhecidos e carregue o recurso desejado sempre dentro do tenant autenticado. Obtenha a identidade do tenant a partir da requisição autenticada, nunca a partir de argumentos gerados pelo modelo.

No protótipo, limite os reembolsos propostos a 5.000 unidades menores para USD, ou seja, $50. Lembre-se de que nem toda moeda trabalha com duas casas decimais. Qualquer proposta acima do teto configurado deve ser rejeitada ou enviada para um fluxo manual à parte.

O agente jamais deve ter acesso aos segredos do provedor de pagamento. Ele também não deve inventar um novo destinatário para a devolução; o serviço de pagamento é quem determina para onde o reembolso vai.

3. Aprove a ação exata, não a conversa inteira

Uma aprovação genérica do tipo 'Permitir que o agente continue' abre brechas perigosas.

Mostre ao operador o cliente, pagamento original, valor, moeda, justificativa e o chamado correspondente. Salve a aprovação vinculada ao hash da carga útil canônica da ação, incluindo o nome da ferramenta, tenant, identificadores dos recursos e argumentos.

Na primeira versão, torne as propostas imutáveis. Alterar um valor exige criar uma nova proposta e passar por uma nova aprovação. Defina um prazo de expiração de 15 minutos para as aprovações como configuração inicial, ajustando conforme a dinâmica da equipe.

No momento da execução, verifique:

• O aprovador possui o cargo necessário dentro deste tenant.
• A aprovação continua dentro do prazo e bate com o hash da ação armazenada.
• A ação segue pendente e ainda não foi processada.
• O pagamento atual continua elegível para o reembolso proposto.
• A execução não foi cancelada e dispõe de orçamento suficiente.

Cheque a autorização novamente na hora de executar. Um colaborador pode perder o acesso financeiro logo após ter aprovado uma solicitação.

4. Reivindique a execução uma única vez

Utilize uma transição atômica no banco de dados para assumir o processamento da ação aprovada. Dois workers não podem mudar o status de `approved` para `executing` ao mesmo tempo.

Em seguida, chame a API externa enviando uma chave de idempotência estável derivada do ID da ação, caso o provedor suporte o recurso. Tentativas adicionais devem reutilizar essa mesma chave.

O banco de dados e uma API externa não compartilham a mesma transação. Se uma requisição de pagamento sofrer timeout, o resultado é desconhecido, não necessariamente uma falha. Consulte o provedor ou faça uma conciliação pelas regras de idempotência documentadas antes de reenviar. Nunca gere uma nova cobrança apenas porque a primeira resposta se perdeu no caminho.

A interface de aprovação precisa refletir essa incerteza. A mensagem 'Verificando status no provedor' é muito mais transparente do que um selo verde prematuro ou um falso aviso de erro.

Adicione orçamentos e logs de auditoria

Controles de orçamento precisam interromper a próxima chamada, não apenas relatar os gastos de ontem.

Para o protótipo do agente de suporte, adote estas configurações iniciais:

| Limite | Valor inicial | Finalidade | | --- | --- | --- | | Chamadas ao modelo por execução | 8 | Evitar loops repetitivos de raciocínio | | Chamadas de ferramentas por execução | 12 | Limitar interações externas | | Tempo de execução ativa | 120 segundos | Parar novos agendamentos após o prazo | | Orçamento do modelo e ferramentas | $0.25 por execução | Delimitar o custo operacional estimado | | Orçamento diário do tenant | $10 | Conter gastos com execuções repetidas | | Limite de retentativas | 2 tentativas por operação | Impedir loops de recuperação sem fim |

O tempo de espera pela aprovação humana não deve prender um worker ativo. Salve a proposta, suspenda a execução e retome o fluxo em um novo job assim que a aprovação chegar. Estabeleça regras claras sobre quanto tempo uma execução suspensa pode aguardar antes de expirar.

Um timeout também não reverte uma chamada externa já disparada. Cancele tarefas futuras e faça a conciliação das requisições pendentes.

Reserve o valor antes do envio

Imagine que uma chamada possa custar no máximo $0.04 dentro dos limites configurados de entrada e saída. Reserve essa quantia antes de fazer o envio. Concluída a operação, debite o valor real e libere a sobra da reserva.

A regra de admissão funciona assim:

```text settled_cost + active_reservations + next_reservation <= budget ```

Consulte e reserve o saldo de maneira atômica tanto para a execução quanto para o limite diário do tenant. Uma abordagem que lê e depois grava abre espaço para estouros quando workers simultâneos enxergam o mesmo saldo disponível.

Use inteiros em microdólares ou tipos numéricos de precisão fixa no banco de dados para evitar erros de arredondamento. Contabilize tentativas de repetição e inclua ferramentas com cobrança avulsa. Não libere uma reserva apenas porque a requisição deu timeout; primeiro confirme se o provedor processou a chamada.

Estimativas de reserva só garantem um teto confiável se você conseguir limitar cada tarifa. Se uma ferramenta tiver cobranças variáveis imprevisíveis, limite o uso, aumente a margem da reserva ou retire a ferramenta do fluxo automático. Travas de gastos no painel do próprio provedor servem como excelente camada extra de proteção.

Veja um cálculo ilustrativo, sem considerar tabelas de preços atuais. Assumindo taxas de $1 por milhão de tokens de entrada e $5 por milhão de tokens de saída, uma chamada com 6.000 tokens de entrada e 1.000 de saída custa $0.011. Oito chamadas idênticas somam $0.088 antes de somar ferramentas e infraestrutura. Requisições mais avançadas costumam carregar mais contexto, então calcule as reservas com base em cada chamada real em vez de apenas multiplicar o valor da primeira.

Os créditos de desenvolvimento do Lovable não cobrem o consumo de IA em produção da sua aplicação. Consulte nosso guia de preços do Lovable para planejar a assinatura da plataforma e calcule os serviços de runtime de forma independente.

Registre decisões sem vazar dados do cliente

Grave IDs de execução e ação, nome da ferramenta, versão da política, decisão de autorização, referência da aprovação, latência, contagem de repetições, custo e ID da requisição no provedor.

Evite despejar tokens de acesso, dados completos de cartão ou o conteúdo integral de chamados privados em um fluxo genérico de eventos. Armazene resumos com dados sensíveis mascarados e referências aos registros originais. Se precisar reter payloads confidenciais, aplique controles de acesso separados e uma política de exclusão programada.

Configure os eventos como append-only para as credenciais da aplicação. Essa prática melhora a rastreabilidade, embora não impeça alterações por parte de administradores do banco de dados. Exigências mais severas de compliance podem demandar um armazenamento imutável externo.

Registre recusas e eventos de conciliação com o mesmo cuidado dedicado aos sucessos. Do contrário, o painel vai mascarar justamente os incidentes que você precisa investigar.

Prompt para copiar e checklist de lançamento

Cole o texto abaixo no Lovable após conectar seu backend. Peça para a plataforma explicar a migration e a arquitetura de autorização server-side antes de aplicar o código. Nossa biblioteca de prompts traz mais modelos para manter alterações geradas sob controle.

```text Build a guarded support-agent prototype with a Supabase backend.

Scope:

• Read tenant-authorized tickets.
• Draft replies without sending.
• Propose USD refunds up to 5000 cents.
• Use a mock payment adapter first. No live refunds.

Create agent_runs, agent_actions, agent_approvals, agent_events, and agent_usage tables with tenant isolation. Use integer microdollars for cost accounting.

Security:

• Derive user and tenant authorization server-side.
• Never expose provider or service-role secrets in browser code.
• Reject unknown tool names and invalid argument fields.
• Browser clients cannot modify execution state or cost counters.
• Elevated backend credentials require explicit tenant checks.

Approvals:

• Show the exact payment, amount, currency, and reason.
• Store immutable proposals and hash canonical action payloads.
• Require a finance-role approval with a 15-minute expiry.
• Recheck role, hash, expiry, payment eligibility, and run state.
• Atomically claim actions before execution.
• Reuse one provider idempotency key per action.
• Reconcile unknown provider outcomes before retrying.

Budgets:

• Maximum 8 model calls and 12 tool calls per run.
• $0.25 run budget and $10 tenant daily budget.
• Atomically reserve bounded costs before dispatch.
• Settle actual usage and retain unresolved reservations.
• Suspend workers while awaiting approval.

UI:

• Run list, approval inbox, action details, redacted event timeline.
• Cancel control that blocks future dispatches.
• Clearly label mock actions and unknown provider outcomes.

Add automated tests for cross-tenant access, expired approvals, changed payloads, concurrent execution, budget races, and timeouts. Explain deployment requirements and any unimplemented controls. ```

Antes de habilitar qualquer ferramenta de escrita real, valide os pontos:

• [ ] Usuários do tenant A não conseguem ler nem aprovar ações do tenant B.
• [ ] Um chamado malicioso não consegue acionar ferramentas fora da lista permitida.
• [ ] Argumentos alterados invalidam a aprovação correspondente.
• [ ] Aprovadores com sessão expirada ou acesso revogado não conseguem autorizar execuções.
• [ ] Múltiplos workers em paralelo geram uma única operação externa.
• [ ] Reservas concorrentes não ultrapassam o teto orçamentário configurado.
• [ ] Um timeout entra em fluxo de conciliação em vez de disparar uma nova tentativa cega.
• [ ] O cancelamento de uma execução bloqueia novos disparos com sucesso.
• [ ] Os logs não guardam credenciais nem dados sensíveis desnecessários.

Coloque o sistema no ar em três etapas: comece com ações simuladas (mocked), passe para leituras reais com propostas de escrita e só então libere uma ferramenta de escrita real para operadores internos. Amplie o escopo apenas depois de analisar recusas reais, custos e casos com status incerto.

Um system prompt consegue impedir injeção de prompt?

Não. O system prompt orienta o comportamento do modelo, mas chamados, documentos e páginas web de terceiros continuam capazes de manipular as respostas. Encare qualquer chamada de ferramenta gerada pelo modelo como uma requisição não confiável. Permissões no backend, schemas rígidos, escopo restrito e etapas de aprovação contêm o estrago quando as instruções falharem.

Toda ação do agente precisa de aprovação humana?

Não. Leituras autorizadas e rascunhos reversíveis costumam rodar de forma automática sem problemas. Exija aprovação principalmente para transações financeiras, disparos de mensagens externas, exclusões e mudanças de privilégios. Qualquer exceção automatizada deve ser bem delimitada, monitorável e controlada fora do modelo.

Quanto custa manter guardrails para agentes de IA?

Em termos de planejamento, reserve de 6 a 12 horas de engenharia para o protótipo simulado apresentado aqui, separando horas extras para integrações reais e revisões de segurança. Um ambiente pequeno de desenvolvimento consome cerca de $25 a $75 mensais em serviços de backend e workers, fora os custos do Lovable, consumo dos modelos e ferramentas pagas. Acompanhe a tabela dos provedores escolhidos; o maior investimento inicial costuma ser implementação e testes, não a tela de aprovação.