Agentes de IA: como limitar ações e conter prompt injection

Um agente que lê mensagens e chama ferramentas está exposto a instruções que não vieram do seu operador. Um e-mail pode conter um pedido para encaminhar arquivos; uma página pode tentar mudar o objetivo da tarefa. O problema aparece quando esse conteúdo influencia ações para as quais nunca recebeu autoridade.

A OWASP descreve prompt injection direto e indireto, inclusive por conteúdo externo. Também documenta a autonomia excessiva: funcionalidades, permissões ou liberdade de ação além do necessário ampliam o dano possível. RAG e ajustes de prompt não eliminam essa classe de risco.

Desenhe a tarefa antes de conectar ferramentas

O exemplo hipotético deste artigo é um agente de triagem de chamados. Ele precisa ler a solicitação e sugerir uma categoria. Se recebe uma ferramenta genérica capaz de executar comandos ou consultar qualquer tabela, seu alcance fica muito maior que o trabalho atribuído.

Uma proposta mais controlável usa operações específicas, como consultar um chamado autorizado e salvar uma sugestão. O serviço verifica usuário, organização, campos permitidos e estado do registro. A decisão de acesso permanece no servidor, mesmo quando o modelo pede uma operação diferente.

Separe preparar de executar

Uma proposta de ação pode ser útil antes de haver confiança para automatizar sua execução. O agente prepara um texto; uma pessoa confere destinatário e conteúdo. O sistema deve vincular a aprovação àquela ação concreta. Se destinatário, valor ou escopo mudam, uma aprovação anterior não deve autorizar a nova versão silenciosamente.

A confirmação também precisa mostrar consequências compreensíveis. Um botão genérico de continuar ajuda pouco se a pessoa não consegue identificar quais registros serão alterados. Para ações repetíveis, use identificadores de operação e controle de duplicação no serviço responsável.

Controles para um primeiro piloto

• Exponha apenas as ferramentas necessárias para o caso de uso.
• Use credenciais de escopo reduzido, sem privilégios administrativos gerais.
• Valide argumentos, limites de volume e acesso a cada recurso.
• Defina tempo máximo, número de chamadas e condição de interrupção.
• Registre ação solicitada, decisão de autorização e resultado, sem guardar segredos.

Esse roteiro é uma proposta de engenharia para conter consequências; não representa garantia de imunidade. A aplicação deve conseguir recusar uma operação mesmo quando o texto gerado parece seguro e convincente.

Teste conteúdo hostil sem conceder acesso real

Em ambiente isolado, inclua documentos que tentam alterar destinatários, pedir dados de outro cliente ou inventar uma autorização. Use contas e registros de teste. O resultado esperado precisa ser verificável no serviço: a ação proibida foi negada e nenhum dado protegido saiu pela ferramenta.

Repita esses testes quando mudar modelo, prompt ou integração. A avaliação deve acompanhar a capacidade que o agente recebeu: quanto mais ele consegue fazer, mais importante fica demonstrar onde suas ações param.