CADERNO / ENGENHARIA · Engenharia de agentes
Agentes de IA precisam de limites além das instruções do prompt
Um prompt define intenção; autorização e validação definem o que um agente realmente pode executar.
Um agente de IA pode pesquisar informações, consultar sistemas e sugerir ações. Quando recebe acesso a ferramentas, passa a existir uma diferença importante entre responder a uma pergunta e executar uma operação com efeitos reais.
A intenção descrita no prompt não é uma política de segurança. Um modelo pode interpretar mal uma instrução, receber dados maliciosos em uma resposta externa ou chamar uma ferramenta em um contexto inesperado.
Dado externo não pode virar autorização
Páginas web, PDFs, mensagens e resultados de ferramentas podem conter instruções que tentam alterar o comportamento do agente. Esse material faz parte dos dados que precisam ser interpretados; não deve ganhar o mesmo nível de autoridade das regras de operação.
Por exemplo, um agente que resume documentos pode encontrar uma frase solicitando o envio de arquivos privados para um endereço desconhecido. O documento não deve conseguir ampliar as permissões do agente só porque o texto parece uma instrução.
O princípio útil é separar quatro camadas:
- Solicitação autorizada: o objetivo legítimo definido pela pessoa usuária.
- Política de acesso: quais recursos, organizações e operações podem ser utilizados.
- Dados recuperados: conteúdo externo que pode estar incorreto ou ser hostil.
- Ação efetiva: operação validada pelo servidor antes de alterar qualquer estado.
Uma ferramenta deve ter escopo menor que o agente
Um agente capaz de ler um catálogo não precisa, por padrão, da ferramenta que exclui registros desse catálogo.
O desenho pode ser expresso como capacidades específicas:
| Capacidade | Exemplo de permissão | Tratamento recomendado |
|---|---|---|
| Consultar | Buscar dados de uma entidade autorizada | Escopo validado no servidor |
| Redigir | Preparar mensagem ou alteração | Produzir rascunho sem executar envio |
| Alterar | Atualizar um registro permitido | Verificar regra de negócio e registrar auditoria |
| Irreversível | Excluir dados ou conceder permissões | Exigir confirmação e controles adicionais |
Essa separação reduz o impacto de erros e torna a ferramenta mais previsível.
A revisão humana deve acontecer no ponto certo
Pedir confirmação a cada consulta simples torna um agente impraticável. Nunca pedir confirmação pode permitir operações de alto impacto sem supervisão.
Uma política melhor classifica as ações por risco:
- Baixo: leitura de dados permitidos ou elaboração de rascunhos, com limites de uso.
- Médio: alterações reversíveis, com validação e histórico.
- Alto: envio externo, exclusão, movimentação de recursos ou mudanças de permissão, exigindo autorização explícita.
A classificação pode depender também do volume: uma atualização unitária e a mesma operação em milhares de registros não têm o mesmo risco.
O que registrar para investigar problemas
Trilhas de auditoria precisam responder o que foi solicitado, qual ferramenta foi utilizada, quais recursos foram afetados, qual política autorizou a chamada e qual foi o resultado. Não é necessário registrar segredos ou conteúdo pessoal sensível para obter rastreabilidade.
Uma observação importante: o log do agente não é a fonte de verdade da operação. Ele pode explicar o raciocínio relatado, mas a evidência precisa vir do serviço que recebeu a chamada e aplicou a autorização.
Checklist arquitetural antes de conectar novas ferramentas
- Cada ferramenta possui propósito e permissões explícitos?
- O servidor valida identidade, escopo e parâmetros independentemente do modelo?
- Dados externos são tratados como dados, não como comandos confiáveis?
- Operações sensíveis têm aprovação proporcional ao risco?
- Existe limite de volume, custo e frequência das chamadas?
- A equipe consegue identificar, interromper e investigar uma operação inesperada?
Se a resposta a essas perguntas não estiver clara, vale limitar a integração a leitura e rascunho até os controles existirem.