Porque é que os agentes aumentam a superfície de ataque
Um chatbot clássico recebe uma mensagem e gera uma resposta. Um agente de IA pode também chamar API, ler ficheiros, consultar bases de dados, enviar e-mails ou desencadear ações.
Isto transforma um erro de prompt num risco operacional real. O problema deixa de ser apenas uma resposta errada e passa a ser um acesso ou uma transmissão de dados não autorizados.
A segurança deve, por isso, ser concebida ao nível das ferramentas, das permissões e dos dados, e não apenas no prompt de sistema.
A injeção de prompts pode provocar fugas de dados
Um conteúdo externo pode conter instruções destinadas a manipular o agente: um documento, um e-mail, uma página web, um pedido de suporte ou um resultado de RAG.
Se o agente tratar essas instruções como fiáveis, pode revelar informação, usar uma ferramenta não prevista ou desviar-se da tarefa pedida.
Todo o conteúdo recuperado deve ser considerado não fiável, as instruções de sistema devem manter-se separadas dos dados e as ferramentas disponíveis devem ser estritamente limitadas.
Aplicar o menor privilégio às ferramentas do agente
Um agente que só precisa de consultar o estado de uma encomenda não precisa de acesso genérico de escrita a toda a base de dados.
Cada ferramenta deve expor uma única operação de negócio precisa, com parâmetros limitados, verificações de autorização no servidor e validação.
As credenciais usadas pelo agente devem ter menos privilégios do que um administrador humano, nunca mais.
Evitar fugas entre tenants no RAG
Num SaaS multi-tenant, a filtragem por organização deve ser aplicada antes da pesquisa vetorial, e não depois de os documentos já terem sido recuperados.
A semelhança semântica nunca deve bastar para tornar um documento acessível. A autorização de negócio prevalece sempre sobre a semelhança.
Os testes devem incluir cenários de fuga entre tenants, porque um erro de filtragem pode expor dados sem produzir qualquer exceção técnica.
Não enviar segredos ao modelo
Tokens OAuth, chaves de API, palavras-passe, cadeias de ligação e segredos técnicos nunca devem ser colocados no contexto do modelo.
As ferramentas devem usar as suas próprias credenciais no servidor e devolver apenas o resultado de negócio necessário.
Quando um agente age em nome de um utilizador, uma autorização delegada e limitada no tempo é preferível à exposição direta de um segredo.
Registar sem recriar a fuga nos registos
Os registos são essenciais para compreender o comportamento de um agente, mas podem tornar-se uma fonte de fuga se cada prompt e cada resposta forem guardados em texto simples.
É preferível registar identificadores de correlação, metadados, decisões, nomes de ferramentas e estados, mascarando a informação pessoal ou sensível.
Os registos que precisam realmente do conteúdo devem ter períodos de conservação curtos e controlos de acesso mais rigorosos.
Envolver uma pessoa nas ações sensíveis
A eliminação de dados, uma transferência financeira, uma alteração de permissões, um envio em massa ou a divulgação de documentos sensíveis não devem ser executados automaticamente apenas com base na saída de um modelo.
O agente pode preparar a ação, explicar o que vai fazer e pedir uma confirmação explícita antes da execução.
Esta validação reduz consideravelmente o impacto de alucinações, injeção de prompts ou contexto errado.
