Bank of America alerta sobre senhas em agentes de IA

O Bank of America delimita o que não deve ser compartilhado

A mensagem foi enviada por email com o título “Protecting your finances in the AI World”. O texto diz que o banco continua investindo em IA e recomenda atenção quando ferramentas externas ajudam a administrar finanças.

A orientação específica é não entregar nome de usuário nem senha a outra pessoa ou serviço externo, incluindo um agente de IA que se ofereça para agir em nome do cliente. O foco são credenciais completas de acesso.

O email também diz que o cliente pode ser responsável por atividades realizadas depois de compartilhar essas credenciais. Esse é o teor do aviso enviado pelo banco, não uma análise jurídica independente sobre cada contrato ou situação.

O jornalista Bryan Toporek publicou uma cópia da mensagem no Bluesky. O TechCrunch confirmou a autenticidade do email com o Bank of America, mas a reportagem não informa quantos clientes receberam o aviso.

A foto abaixo vem do acervo de imprensa do Bank of America. Ela mostra uma transação com cartão e ilustra o contexto financeiro, mas não representa um agente de IA nem uma ação automatizada.

O alerta do Bank of America não é uma proibição geral de IA

O email não anuncia que todos os assistentes de IA estão bloqueados, nem afirma que o banco proíbe o uso de IA para pesquisa, organização ou atendimento. A mensagem delimita uma prática que os clientes devem evitar.

O ponto é entregar credenciais de login a um serviço externo. O texto não detalha conectores oficiais, APIs, permissões OAuth ou outros meios de acesso consentido. Também não explica como cada produto pode se integrar à conta.

Por isso, não dá para concluir que qualquer ferramenta de IA que interaja com uma instituição financeira viola uma regra. A recomendação publicada é sobre o compartilhamento de usuário e senha, não uma descrição completa das integrações autorizadas.

A reportagem não relata uma violação, vazamento ou perda causada por um agente. Também não traz uma estatística de clientes que usam essas ferramentas. O fato novo é um lembrete de segurança, confirmado pelo banco, e não um incidente de fraude.

Essa distinção importa para quem cria produtos. Uma notícia de segurança pode ser relevante sem provar que uma tecnologia específica foi comprometida ou que todo fluxo automatizado é inseguro.

Entregar a senha bancária amplia o poder do agente

Uma senha de banco foi criada para autenticar a pessoa em uma conta, não para autorizar uma única tarefa isolada. Quando o agente recebe o login completo, pode ganhar um alcance maior do que o necessário para responder a uma pergunta ou organizar dados.

Se a credencial for colocada em uma conversa, campo de configuração ou arquivo de registro, ela também pode acabar guardada fora do sistema do banco. Esse risco depende de como cada ferramenta armazena e processa dados, algo que o email não avalia.

Agentes podem interpretar instruções de maneiras inesperadas, chamar ferramentas conectadas ou executar passos além do que a pessoa imaginava. Isso não significa que todo agente vá agir assim. Significa que as permissões precisam limitar o impacto de um erro.

O OWASP Top 10 for Agentic Applications 2026 organiza dez categorias de risco para aplicações agênticas, incluindo abuso de identidade e privilégios. A lista não descreve o Bank of America; ela ajuda equipes técnicas a pensar em controles para sistemas que usam agentes.

O artigo sobre 1Password for Agents mostra uma arquitetura em que a pessoa aprova um login específico sem revelar a senha ao agente. É um contraste útil com copiar a credencial para um prompt.

Integre agentes financeiros com permissões menores

Antes de escolher um modelo, defina quais dados e ações a tarefa realmente exige. Se o agente só precisa organizar informações, não conceda acesso a transferências, pagamentos ou alterações de cadastro.

Quando existir uma integração oficial, prefira permissões específicas a uma senha reutilizada. Escopos limitados podem separar leitura de escrita e reduzir o conjunto de ações disponíveis. A disponibilidade desses recursos depende de cada instituição.

Use acessos temporários e revogáveis quando a plataforma permitir. Um token com prazo e escopo definidos é mais fácil de encerrar do que uma senha permanente compartilhada com vários serviços.

Mantenha segredos fora do prompt, do histórico de conversa, dos registros de execução e do repositório de código. Use um cofre de credenciais, limite quem pode ler cada segredo e substitua tokens quando houver suspeita de exposição.

Para operações que alteram uma conta, peça confirmação humana em uma interface confiável. Mostre a ação, o destinatário e o valor antes da confirmação, em vez de depender apenas de uma frase gerada pelo agente.

Registre quais ferramentas foram chamadas e qual permissão permitiu cada ação. Logs ajudam a investigar problemas, mas não devem armazenar senhas ou tokens completos. Também é importante ter uma forma simples de revogar a conexão.

O guia sobre inference hooks da Anthropic explica um exemplo de controle que avalia solicitações antes de chegarem ao modelo. Já o artigo sobre NVIDIA Vera e OpenShell aborda isolamento e políticas para workloads agênticos.