O Seu Agente de IA É Só Leitura, Mas o CRM Mudou na Mesma

Um engenheiro fez uma pequena experiência e publicou-a no Habr: um modelo de IA sem permissão para escrever num CRM acabou por alterar um registo do CRM na mesma. Não porque o modelo tenha ultrapassado os seus limites, mas porque o componente que estava por trás dele tinha as chaves. Se está prestes a deixar um agente de IA aproximar-se da base de dados de clientes, esta é a distinção que importa mais do que qualquer promessa de fornecedor.

O que realmente aconteceu no teste

A configuração era um fluxo de trabalho construído em n8n, com o DeepSeek como modelo e o HubSpot como CRM. O próprio modelo não tinha credenciais do HubSpot. Não podia chamar o CRM diretamente. Essa parte da restrição era real.

O passo seguinte no fluxo de trabalho, contudo, tinha credenciais de escrita. A sua função era pegar na proposta estruturada do modelo e executá-la. No cenário de controlo, o pedido em linguagem natural referia-se a um negócio de teste sintético, enquanto o alvo estruturado apontava para outro. O fluxo de trabalho avançou, emitiu a atualização, e o negócio errado foi alterado. Uma leitura posterior confirmou-o: o segundo negócio tinha sido modificado, o primeiro permaneceu intacto.

O autor acrescentou então uma coisa — uma verificação determinística independente entre a proposta do modelo e a chamada efetiva ao CRM. Essa verificação analisava uma pequena lista de parâmetros: que sistema estava a ser afetado, que ID de objeto, em que estado se esperava que o registo estivesse, e que transição era permitida. As credenciais não foram alteradas; o fluxo de trabalho continuava a poder escrever. Mas agora a escrita dependia de passar primeiro nessa verificação. O cenário normal passou e concluiu-se. O cenário incompatível foi recusado, e o registo manteve-se como estava.

A conclusão a que o autor chega é curta: o que o modelo tem permissão para fazer não é o mesmo que o sistema tem permissão para fazer. Em termos clássicos de segurança, isto aproxima-se do problema do "confused deputy" — uma ideia antiga a reaparecer num contexto novo.

Por que razão isto importa para uma pequena empresa

A frase "o agente é só de leitura" é conveniente. Acaba numa nota de arquitetura, num questionário de segurança, numa resposta a um cliente, ou numa decisão de avançar para produção. Se essa frase se baseia apenas nas credenciais que o modelo detém, descreve apenas parte da cadeia, não a totalidade dela.

Para uma empresa, o risco prático não é algo dramático. É silencioso e enfadonho: o negócio errado é atualizado, a encomenda errada é marcada como paga, o cliente errado sofre uma alteração de estado. Ninguém repara durante uma semana. Depois alguém tenta reconciliar números e não consegue explicá-los. O registo de auditoria, se existir, mostra uma chamada de API bem-sucedida — tecnicamente correta, factualmente errada.

Isto aplica-se a qualquer empresa que deixe a automação tocar em dados operacionais: um CRM, um sistema de encomendas, uma ferramenta de tickets, um inventário. Quanto mais banal parecer a automação, menos provável é que alguém esteja a verificar a fronteira onde a alteração efetiva acontece.

O que verificar antes de um agente tocar em dados de clientes

O artigo termina com seis perguntas que vale a pena colocar antes de entrar em produção ou antes de alargar as permissões de um agente. Transformadas numa lista de verificação que pode aplicar este mês:

• Descubra onde vivem fisicamente as credenciais de escrita. Não onde está o modelo, mas qual o componente que faz a chamada externa. Esse componente define a sua exposição real.
• Liste o que é verificado imediatamente antes da chamada. Sistema alvo, ID do objeto, estado atual esperado, transição permitida. Se nada for verificado nesse momento, a verificação não existe de forma útil.
• Pergunte se o alvo pode mudar entre o pedido e a escrita. O caso do laboratório foi exatamente isto: o pedido nomeava um registo, a proposta estruturada nomeava outro. Nada de malicioso, apenas uma incompatibilidade que nada apanhou.
• Coloque um controlo independente entre a proposta e a consequência. No teste, esse controlo era código determinístico, não outro modelo a decidir se o primeiro modelo tinha razão.
• Confirme o estado resultante depois da ação, não apenas que a chamada foi bem-sucedida. Uma leitura separada foi o que comprovou o resultado em ambas as direções da experiência.
• Mantenha uma cadeia reconstituível. O que foi proposto, quem podia executá-lo, o que foi verificado, o que foi efetivamente chamado, que estado resultou daí. Sem isso, tem uma afirmação sobre controlo, não uma prova dele.

Conclusão

Este foi um teste de laboratório com registos sintéticos, e o autor diz-o abertamente. Mas o princípio é transferível. Retirar credenciais ao modelo é um controlo genuíno — mas apenas limita o modelo, não o sistema à sua volta. Antes de dar luz verde a um agente, siga a permissão até ao componente que pode provocar uma alteração real, e coloque aí a sua verificação. É o único sítio onde ela faz alguma diferença.