Agente CFO vazou banco no Slack: erro de canal

Um extrato pessoal no canal errado

Agente de IA pessoal com acesso à conta bancária parece uma ideia inofensiva até o dia em que ele publica o seu extrato no lugar errado. Foi exatamente o que aconteceu com Shane Mac, CEO da XMTP Labs, no dia 1 de outubro. O relatório mensal do seu agente chamado de CFO, criado dentro do Grok Bot, com saldos de conta corrente e poupança, maiores gastos do mês e o estouro da meta por causa da construção de um celeiro na propriedade dele, foi parar direto no Slack da empresa. O head de produto leu as primeiras linhas achando que se tratava do caixa da startup, até perceber pelo detalhe do celeiro que aquilo era a vida financeira pessoal do chefe exposta para o time executivo.

Se você constrói com agentes hoje, esse caso dói porque é reconhecível. Todo mundo já conectou Gmail pessoal e do trabalho no mesmo harness, já deu acesso ao calendário, ao Drive, ao Stripe, só para economizar vinte minutos por dia. Mac fez o mesmo em escala maior. Desde dezembro ele vinha testando OpenClaw, Hermes e outros harnesses para resolver burocracia como DMV, orçamentos domésticos e agendamentos. No final de agosto ele formalizou a ideia do time executivo pessoal no Grok Bot, com um agente financeiro que deveria responder todo mês perguntas simples: quanto tenho, quanto gastei, o que é recorrente, tem algo suspeito, onde dá para cortar custo. A promessa era ótima e funcionou bem no modo semanal, até a primeira rodada mensal disparar para o destino errado.

O fato

O que aconteceu foi direto e sem sofisticação técnica. Mac deu ao agente acesso de leitura às contas pessoais e instruiu para enviar o relatório apenas para ele, em um grupo privado dentro do Grok Bot que ele chamou de 'My Personal Exec Team'. Na quinta feira do fechamento mensal, o agente gerou o audit corretamente, mas entregou no canal errado. Em vez do grupo pessoal, postou em um chat do Slack conectado chamado 'Exec-team', que reunia a liderança da XMTP. Nomes praticamente idênticos, contextos totalmente diferentes. O conteúdo incluía saldos, gastos e o alerta de que ele estava bem acima da meta mensal por conta da obra.

Quando confrontado com um simples 'por que você mandou isso para a empresa', o agente pediu desculpas e disse que apagaria a mensagem. Mac já tinha apagado manualmente. Na investigação posterior, a equipe do Grok concluiu que não houve alucinação no conteúdo, houve erro de roteamento. O agente fez o que foi pedido, mas escolheu o canal errado porque os nomes colidiram. Pior: por baixo do capô, todos os agentes criados por Mac compartilhavam as mesmas conexões, mesmo parecendo entidades separadas. Um agente tinha integração com o Slack da empresa, e o agente CFO acabou herdando esse caminho de entrega. Depois do susto, o Grok implementou uma trava exigindo permissão explícita do usuário antes de um agente mover informação para outro canal. Mac, por sua vez, desconectou tudo: Google, calendários, banco, Stripe.

Como funciona na visão de operador

Para quem opera agentes, o desenho provável é familiar. Você tem um orquestrador que roda tools via OAuth: leitura de extrato bancário por API ou screen scraping via provedor como Plaid, leitura de Slack via bot token com escopo de canais, e um scheduler mensal que dispara o prompt do CFO. O agente monta contexto, chama a tool de banco, resume com o modelo, depois chama a tool de envio com um parâmetro tipo channel_id ou conversation_id. O problema clássico está aí: resolução de destino por nome em linguagem natural em vez de identificador imutável. Se o LLM recebe uma lista com 'My Personal Exec Team' e 'Exec-team' e precisa escolher, a similaridade semântica vira roleta. Sem um binding forte entre agente, credencial e canal permitido, qualquer ambiguidade vira vazamento.

Em termos de custo e latência, esse tipo de fluxo é barato para rodar e caro quando falha. Uma auditoria mensal consome poucas chamadas, talvez alguns milhares de tokens para resumir transações mais o custo da API bancária, nada relevante perto de um vazamento de dados sensíveis. A latência também não era o gargalo, o relatório semanal funcionava bem. O gargalo real era permissão. O modelo mental de 'cada agente é isolado' era falso. Na prática era um único runtime com várias personas compartilhando tokens. Isso é comum em produtos early stage para simplificar UX, mas quebra o princípio básico de least privilege. O correto seria escopos separados por agente, com allowlist explícita de destinos e confirmação humana para qualquer ação cross-context, principalmente quando o payload contém PII financeira.

Onde a arquitetura quebrou

O ponto de ruptura foi a fronteira entre pessoal e corporativo. Mac usava Google pessoal e do trabalho, Slack da empresa conectado ao mesmo harness que cuidava da vida doméstica, e prompts genéricos como 'me avise todo mês'. Quando você mistura identidades no mesmo grafo de tools, o agente não tem como inferir intenção de isolamento só pelo texto. Ele precisa de guardrails estruturais: conexões com rótulos de ambiente, como pessoal versus trabalho, IDs de canal fixados na configuração e não resolvidos por busca fuzzy, além de política de egress que bloqueie envio de dados classificados como bancários para domínios corporativos sem aprovação. A correção aplicada pelo Grok, exigir grant explícito antes de mover informação entre canais, vai na direção certa, mas ainda é reativa. O ideal seria default deny para qualquer dado sensível.

O que isso muda na prática

Quem ganha com esse susto é quem vende controle: vaults de credenciais por agente, gateways de tools com políticas, audit log de cada chamada. Quem perde é o discurso do assistente universal que faz tudo com um clique. Na prática, se você dá a um agente acesso a banco, e-mail e Slack ao mesmo tempo, você criou um insider com superpoderes e sem noção de vergonha. Ele não hesita, não confirma, ele executa. Para times que estão colocando agentes em produção agora, a lição é separar superfícies. Um agente que lê dinheiro não deveria poder escrever no Slack da empresa. Ponto. Se precisar dessa ponte, ela tem que passar por aprovação humana, com preview do conteúdo e destino travado.

• Separe runtimes e tokens: um workspace pessoal e outro corporativo, sem compartilhar OAuth. Se o produto não permite isso, crie contas distintas ou não conecte os dois lados.
• Trave destino por ID, nunca por nome: fixe o channel_id permitido na configuração do agente e bloqueie resolução dinâmica. Nomes parecidos como 'Exec-team' não podem decidir para onde vai extrato.
• Classifique e exija confirmação para PII: qualquer payload com saldo, transação ou documento deve gerar um pedido de aprovação mostrando exatamente o texto e o canal antes do envio.

Outra ação prática imediata é revisar logs de entrega dos seus agentes agendados. Procure por chamadas cross-channel nas últimas semanas, principalmente relatórios automáticos semanais ou mensais. Se o seu harness não mostra qual token foi usado, qual canal foi resolvido e qual prompt gerou a ação, você está operando no escuro. E vale o básico que Mac fez depois do incidente: revogar conexões sensíveis até ter allowlist, expiração curta de token e alerta para qualquer envio fora do escopo. Conveniência sem observabilidade vira incidente de privacidade com data marcada.

A tensão que ninguém quer encarar

A dúvida real aqui não é se agentes pessoais são úteis. Eles são, e muito. A questão é se o modelo atual de permissão escala para gente normal. Hoje o setup exige que o usuário entenda OAuth, escopo, canal, scheduler e herança de conexões, coisas que nem desenvolvedor revisa direito na pressa. Mac é CEO técnico de empresa de software, testou vários harnesses, e mesmo assim caiu em uma colisão de nomes boba. O que acontece quando esse mesmo produto chega para alguém que só quer economizar tempo com contas e escola dos filhos. O custo de um erro não é só retrabalho, é exposição de saldo, de endereço, de rotina. Resolve automatizar o financeiro ou só move o gargalo da planilha para a gestão de permissões.

E tem um segundo incômodo: a correção de pedir permissão explícita antes de trocar de canal ajuda, mas cria fadiga de aprovação. Se a cada relatório você precisa clicar em permitir, em pouco tempo você passa a aprovar no automático, e voltamos ao mesmo risco. Ou o sistema é seguro por padrão, com isolamento real entre personas e conexões, ou vamos normalizar microvazamentos como custo da produtividade. Minha leitura de operador é que estamos na fase em que o poder do agente já é real, mas o controle ainda é maquiagem. Funciona na demo, funciona no uso semanal simples, quebra no primeiro job mensal com dados sensíveis e múltiplos destinos parecidos.

Conclusão

No fim, um agente obediente fez exatamente o que foi mandado, só que no lugar errado, e isso foi suficiente para expor a vida financeira do CEO para o time. Até quando vamos tratar permissão de agente como detalhe de UX em vez de requisito crítico de segurança.