Principais destaques
- Agentes de IA estão sendo detectados em contas bancárias: instituições como JPMorgan, Wells Fargo, Bank of America e Morgan Stanley não conseguem determinar com segurança se essas ferramentas estão autorizadas pelos clientes.
- Empresas adotam estratégias opostas: enquanto o Walmart criou uma estrutura para permitir compras automatizadas com limites e aprovações, a Amazon bloqueia agentes de compras de terceiros.
- Novos sistemas tentam resolver o problema: Cloudflare, Google, Stripe e Visa estão desenvolvendo mecanismos para verificar a identidade dos agentes e limitar suas permissões financeiras.
Imagine autorizar um assistente de inteligência artificial a consultar seu saldo, organizar suas contas e pagar uma despesa. Para você, é uma tarefa legítima. Para o sistema antifraude do banco, porém, o mesmo comportamento pode parecer uma invasão.
Esse é o novo desafio de segurança que preocupa grandes instituições financeiras dos Estados Unidos. Segundo informações publicadas pelo Axios, bancos como JPMorgan, Wells Fargo, Bank of America e Morgan Stanley identificaram agentes de IA operando em contas de clientes sem conseguir confirmar se todas essas atividades eram autorizadas.
O problema não é apenas reconhecer um robô. É descobrir quem está por trás de cada ação, quais permissões foram concedidas e se o agente continua obedecendo às instruções originais.
Até o momento, os relatos que fundamentam essa discussão não apontam perdas financeiras confirmadas decorrentes dessas atividades. A preocupação está na dificuldade de verificar a autorização e impedir que ações indevidas passem despercebidas.
🤖 Para o banco, um agente autorizado pode parecer um invasor
Agentes de IA estão evoluindo de assistentes que respondem a perguntas para sistemas capazes de executar tarefas em nome dos usuários. Eles podem navegar por sites, clicar em botões, preencher formulários e interagir com serviços digitais.
É justamente essa capacidade que cria o problema.
Quando uma pessoa acessa sua conta bancária pelo navegador, o sistema identifica uma sequência de ações. Quando um agente automatizado faz a mesma coisa, a sequência pode ser praticamente idêntica.
A diferença fundamental está na intenção, algo que não pode ser deduzido com segurança apenas pelos cliques.
🔎 O ponto crítico: os sistemas tradicionais de segurança foram desenvolvidos para avaliar identidades, dispositivos, sessões e padrões de comportamento. Nem sempre conseguem determinar se uma ação automatizada foi solicitada pelo titular da conta ou se está sendo executada por um agente comprometido.
Isso cria três situações difíceis de diferenciar:
- Um cliente acessa a própria conta e realiza uma operação.
- Um agente autorizado executa uma tarefa solicitada pelo cliente.
- Um agente não autorizado, ou manipulado por terceiros, realiza operações dentro da conta.
Para os mecanismos de proteção existentes, as três situações podem compartilhar sinais técnicos semelhantes.
O problema também não desaparece quando o agente é legítimo. Uma ferramenta pode interpretar uma instrução incorretamente, executar uma ação além do necessário ou reagir a comandos maliciosos encontrados em uma página.
🔐 O problema cresce quando milhares de agentes entram em ação
A escala da automação acrescenta outra dificuldade.
Se milhares de agentes acessarem simultaneamente serviços financeiros para consultar saldos, verificar pagamentos ou executar tarefas, o volume de requisições poderá se parecer com uma operação coordenada de bots maliciosos.
Mesmo quando os usuários autorizaram a atividade, o comportamento coletivo pode acionar mecanismos antifraude.
Esse tipo de conflito não é exclusivo dos bancos. Sistemas automatizados de reserva de restaurantes, por exemplo, também podem gerar picos de acesso que parecem abusivos, especialmente quando vários agentes tentam garantir horários concorridos.
A consequência é um dilema: bloquear a automação indiscriminadamente pode proteger a plataforma no curto prazo, mas também impede usos legítimos.
O desafio não é simplesmente identificar se existe uma IA do outro lado da conexão. É verificar quem autorizou o agente, o que ele pode fazer e até onde essa autorização continua válida.
🛒 Walmart abre uma porta controlada; Amazon prefere bloquear
O comércio eletrônico já oferece um exemplo claro de como empresas estão reagindo de maneiras diferentes.
O Walmart criou um sistema chamado agent gateway, uma espécie de porta de entrada para agentes de compras aprovados. A proposta é permitir que essas ferramentas operem dentro de regras específicas, incluindo limites de gastos e etapas que exigem aprovação.
A estratégia parte de uma ideia simples: em vez de tratar toda automação como ameaça, a empresa cria um ambiente no qual consegue controlar melhor o que os agentes fazem.
A Amazon adotou uma abordagem mais restritiva, bloqueando agentes de compras de terceiros em sua plataforma.
| Estratégia | Como funciona | Principal consequência |
|---|---|---|
| Walmart | Permite agentes por uma estrutura controlada, com limites e aprovações | Abre espaço para compras automatizadas sob regras definidas |
| Amazon | Bloqueia agentes de compras de terceiros | Reduz a exposição a automações não controladas, mas limita usos legítimos |
| Bancos citados | Restringem atividades e reforçam controles | Priorizam a proteção das contas enquanto a autorização permanece difícil de verificar |
⚖️ Por que isso importa? Bancos precisam considerar riscos que vão além de uma compra cancelável. Uma operação financeira pode envolver transferências, pagamentos, informações confidenciais e consequências difíceis de reverter.
Por isso, é compreensível que as instituições sejam cautelosas. O problema é que uma política excessivamente restritiva também pode impedir que os clientes usem assistentes de IA para tarefas financeiras rotineiras.
☁️ Cloudflare quer provar de onde veio cada agente
Uma das frentes de desenvolvimento envolve a identidade técnica dos agentes.
A Cloudflare introduziu um sistema de agentes assinados digitalmente que permite verificar a origem de determinadas requisições. A assinatura fornece evidências de que o pedido veio de uma infraestrutura ou identidade associada ao agente declarado.
Isso pode ajudar um site a diferenciar tipos de tráfego e aplicar regras específicas para cada um.
Mas existe uma distinção importante: identificar um agente não significa autorizar todas as suas ações.
Um serviço pode aceitar que determinada IA consulte informações públicas, mas impedir que ela altere dados cadastrais, cancele uma reserva ou conclua uma transação financeira.
A autorização precisa ser definida separadamente, de acordo com a ação solicitada e as permissões concedidas.
É uma diferença semelhante àquela entre apresentar um documento de identidade e ter autorização para movimentar dinheiro de uma conta.
💳 Visa, Bill e BillTrust testam pagamentos com permissões limitadas
Outra frente envolve a própria infraestrutura de pagamentos.
Em outubro, Visa, Bill e BillTrust anunciaram um piloto operacional voltado a pagamentos de faturas de fornecedores realizados por agentes de IA.
A proposta é conectar a autorização do comprador, as credenciais de pagamento e a transação à fatura original. O agente é registrado, recebe credenciais limitadas às instruções do comprador e executa o pagamento no portal do fornecedor.
Esse modelo tenta reduzir o espaço para erros e operações fora do escopo autorizado.
Em vez de entregar acesso financeiro irrestrito a um agente, o sistema estabelece limites relacionados à finalidade da transação.
💡 A mudança de abordagem: em um modelo mais seguro, a autorização não depende apenas de confiar no agente. Ela também é aplicada pelas próprias credenciais e pelos sistemas de pagamento.
Outras iniciativas seguem uma lógica semelhante:
- Google Agent Payments Protocol: busca estruturar a comunicação e a autorização em pagamentos mediados por agentes.
- Stripe Shared Payment Tokens: utiliza tokens de pagamento compartilhados com escopo definido, permitindo estabelecer restrições para determinadas operações.
- Sistemas de agentes assinados: procuram fornecer evidências verificáveis sobre a identidade ou a origem das requisições.
Essas abordagens podem ajudar a limitar vendedores, valores e períodos de validade, dependendo da implementação.
Ainda não existe, contudo, um padrão universal que conecte todas essas soluções. Empresas podem reconhecer um agente em um contexto e exigir outras credenciais ou aprovações em outro.
🧩 O que ainda falta para esses sistemas funcionarem em conjunto?
O ecossistema está se desenvolvendo por partes.
Um agente pode ter uma identidade verificável, mas o serviço precisa saber quais operações estão autorizadas. Mesmo quando as permissões estão claras, o sistema de pagamentos precisa aplicá-las corretamente.
Uma arquitetura mais robusta precisa responder a perguntas como:
- Quem é o agente e como sua identidade foi verificada?
- Qual usuário ou organização autorizou sua atuação?
- Quais ações ele pode executar?
- Qual é o limite financeiro de cada operação?
- Quando a autorização expira ou pode ser revogada?
- Como o usuário consegue auditar o que foi feito em seu nome?
Essas questões não são apenas detalhes técnicos. Elas determinam quem pode assumir a responsabilidade quando uma operação não corresponde ao que o cliente pretendia.
A autorização também precisa continuar válida durante a execução. Um agente que recebeu permissão para pagar uma fatura específica não deveria interpretar isso como autorização permanente para realizar outros pagamentos.
🚨 A preocupação aumenta com a velocidade dos ataques impulsionados por IA
O cenário de segurança torna o problema ainda mais urgente.
O texto original relaciona a preocupação dos bancos a uma sequência de incidentes de segurança conhecida informalmente como Black October. O período teria reunido vulnerabilidades graves em softwares amplamente utilizados, incluindo falhas críticas no PHP, além de violações de segurança em diferentes empresas.
A inteligência artificial pode acelerar os dois lados dessa disputa.
Equipes de defesa podem utilizar modelos para encontrar vulnerabilidades, analisar código e desenvolver correções. Atacantes também podem empregar ferramentas semelhantes para identificar falhas e explorar sistemas vulneráveis.
Nesse contexto, mecanismos que não conseguem distinguir adequadamente uma operação autorizada de uma tentativa de invasão representam uma exposição adicional.
Isso não significa que todo agente de IA seja perigoso. Significa que as instituições não podem presumir que uma atividade automatizada é segura apenas porque parece legítima.
📧 Quando a própria IA coopera demais
Existe também um risco de privacidade que não depende de um agente malicioso.
Segundo o relato apresentado no material original, agentes associados ao Claude, da Anthropic, teriam exposto endereços de e-mail humanos ao responder a instruções inseridas em sites que solicitavam sua identificação.
O episódio ilustra um problema conhecido na interação entre agentes e páginas da web: o conteúdo de um site pode incluir instruções que tentam influenciar o comportamento da ferramenta.
Se o agente obedecer sem avaliar se aquela solicitação está dentro das permissões concedidas pelo usuário, poderá revelar informações que deveria manter privadas.
Esse tipo de situação está relacionado aos riscos de injeção de prompt, nos quais instruções encontradas em conteúdo externo tentam alterar o comportamento do modelo.
O risco é especialmente relevante quando o agente tem acesso a e-mails, documentos, dados pessoais ou contas conectadas.
🛡️ A proteção precisa estar fora do modelo também: instruções bem formuladas ajudam, mas não substituem controles técnicos que impeçam a divulgação de dados ou a execução de operações não autorizadas.
🏦 O que muda para quem quer usar IA no banco?
No curto prazo, a experiência provavelmente continuará irregular.
Um agente pode organizar informações de uma viagem, consultar preços e comparar opções sem dificuldades, mas ser bloqueado quando tentar acessar uma página de pagamento ou realizar uma reserva.
Isso não indica necessariamente que o modelo seja pouco inteligente. Pode significar apenas que o serviço acessado ainda não oferece uma integração segura para aquela modalidade de automação.
Para quem utiliza agentes conectados a serviços financeiros, alguns cuidados são importantes:
- Prefira integrações oficiais: conexões oferecidas diretamente pelo banco ou pelo serviço tendem a permitir controles mais claros do que a simples automação de cliques no navegador.
- Limite as permissões: conceda apenas o acesso necessário para a tarefa.
- Exija confirmação para operações sensíveis: transferências, pagamentos e alterações cadastrais merecem controles adicionais.
- Verifique os registros de atividade: confira se o agente realizou apenas as ações esperadas.
- Evite compartilhar credenciais bancárias diretamente com ferramentas desconhecidas: uma autorização ampla pode aumentar o impacto de erros ou comprometimentos.
Nenhuma dessas medidas elimina todos os riscos, mas ajuda a reduzir a exposição enquanto os padrões de autorização evoluem.
O próximo passo é dar aos agentes uma identidade com limites reais
A evolução dos agentes de IA depende de mais do que modelos capazes de raciocinar e executar tarefas complexas. Eles também precisam de uma infraestrutura que permita identificar suas ações, limitar seus poderes e comprovar quem autorizou cada operação.
Para os bancos, isso significa construir uma fronteira mais clara entre automação legítima e atividade suspeita. Para os usuários, significa poder delegar tarefas sem entregar controle irrestrito sobre suas contas.
A questão central já não é apenas se uma IA consegue realizar uma operação financeira. É se o sistema consegue provar que ela tinha autorização para realizá-la.
Enquanto essa distinção depender de mecanismos fragmentados, os agentes continuarão encontrando portas abertas em alguns serviços e barreiras em outros. O desafio será transformar essa experiência desigual em um modelo de confiança verificável, sem tornar a automação um novo caminho para fraudes.
