O Bank of America enviou um e-mail pedindo que clientes não compartilhem usuário e senha com ferramentas ou agentes de IA que se oferecem para agir em nome deles, lembrando que quem compartilha o login responde pelo que for feito com ele. Veja por que o caminho certo para agentes é acesso com escopo, por API, token e permissão específica, e como aplicar isso na sua empresa.
Com agentes de IA se oferecendo para pagar contas, conferir extratos e preencher sistemas, cresce a tentação de fazer o caminho mais curto: entregar ao agente o usuário e a senha e deixar que ele entre como se fosse a pessoa. Um e-mail de um grande banco americano, relatado pelo TechCrunch nesta terça, 27 de outubro, mostra por que esse atalho é um problema.
O que o Bank of America pediu aos clientes?
Segundo o TechCrunch, o Bank of America enviou aos clientes um e-mail com o título "Protecting your finances in the AI World" (protegendo suas finanças no mundo da IA). Nele, o banco pede que o cliente nunca compartilhe usuário e senha com outra pessoa ou serviço externo, incluindo uma ferramenta ou agente com IA que se ofereça para agir em seu nome. Um porta-voz do banco confirmou ao TechCrunch que o e-mail é autêntico.
O banco lista os riscos de entregar o login a um agente:
- O agente pode fazer movimentações sem que o cliente saiba.
- O banco pode bloquear a conta ao perceber um acesso fora do padrão.
- Uma falha de segurança no agente ou no serviço pode expor as credenciais.
E deixa claro de quem é a responsabilidade. Na frase do e-mail citada pelo TechCrunch:
"If you do share your credentials, keep in mind that you're responsible for activity resulting from that access." (Se você compartilhar suas credenciais, lembre-se de que você é responsável pela atividade resultante desse acesso.)
Segundo o TechCrunch, os contratos de conta costumam prever exatamente isso: o cliente responde pelo uso das credenciais que compartilhou. E bancos, empresas de pagamento e processadoras ainda estão definindo como os pagamentos feitos por agentes vão funcionar.
Por que a senha de uma pessoa é o acesso errado para um agente?
O recado do banco vale para muito além da conta bancária. Quando um agente entra com o login de uma pessoa, acontecem três coisas ao mesmo tempo:
- Ele herda tudo o que a pessoa pode fazer, e não só o que a tarefa pede. Quem só precisava consultar um saldo passa a poder transferir dinheiro.
- O sistema do outro lado não consegue distinguir o agente da pessoa. No registro, a ação aparece como se o dono do login tivesse feito.
- A senha passa a existir em mais um lugar, fora do controle de quem a criou, e cancelar o acesso do agente significa trocar a senha da pessoa.
O resultado é um acesso amplo, difícil de rastrear e difícil de revogar, com a responsabilidade caindo sobre quem emprestou o login.
Qual é o jeito certo de dar acesso a um agente?
Na FlowNexus, quando um agente precisa mexer em banco, ERP, CRM ou e-mail, o acesso é desenhado para o agente, e não emprestado de uma pessoa:
- Acesso por API ou integração oficial sempre que o sistema oferece, em vez de o agente digitar usuário e senha numa tela.
- Credencial própria do agente, como token ou chave, separada das credenciais das pessoas e com nome que identifica o agente.
- Escopo mínimo. Se a tarefa é ler extratos, a permissão é só de leitura. Pagar, transferir ou alterar cadastro exige outra permissão, dada só quando necessário.
- Validade curta e revogação simples. O token expira e pode ser cancelado a qualquer momento sem mexer na senha de ninguém.
- Cofre de credenciais. O agente usa a credencial para fazer a chamada, mas ela fica guardada num cofre, fora do prompt e dos registros.
- Aprovação humana nas ações de risco. Pagamento, transferência e mudança de dado sensível passam por uma pessoa antes de acontecer.
- Registro de cada ação, com o agente identificado, para saber o que foi feito, quando e a pedido de quem.
Quando o sistema não oferece API nem acesso limitado, a resposta não é emprestar a senha. É manter aquela etapa com uma pessoa, ou usar o agente só para preparar o trabalho, como montar a lista de pagamentos, deixando a execução para quem tem o acesso.
Já falamos de como o agente pode fazer login sem ver a senha em 1Password para agentes, e de permissão mínima e aprovação em Agente de IA como funcionário com crachá.
Um agente de IA deve ter o próprio crachá, com acesso só ao que a tarefa pede. Nunca a senha de uma pessoa.
Leia também
- 1Password para agentes: o agente faz o login, mas nunca vê a senha
- Agente de IA como funcionário com crachá: permissão mínima, aprovação humana e registro de tudo
- Um modelo de IA tentou falar com um servidor externo durante um teste: como colocar agentes em produção com segurança
Fontes
Transforme essa leitura em um sistema.
Diagnóstico da operação, projeto e construção por etapas. O próximo passo depende do seu caso, não de um pacote pronto.
