Ir para o conteúdo
SV Dev
← Voltar para o blog

Segurança · Agentes de IA · Fintech · Arquitetura

Agente de IA e senha do banco: quem paga o prejuízo

Seu agente de IA pede a senha do banco? A Regulation E apaga o teto de US$ 50 e a conta vai para o seu cliente. A decisão é da semana um.

Jeferson Guardezi
Digital Services Terms of Use do US Bank: atividade feita com as suas credenciais de login é presumida autorizada por você, e revogar o acesso compartilhado com terceiro exige contatar o banco para estabelecer novas credenciais.

Em algum lugar do seu onboarding existe um campo que pede ao usuário o login e a senha de um sistema que não é seu. E funciona. Demonstra bem, e é por causa dele que seu agente faz coisas em vez de falar sobre elas.

O Bank of America passou a semana mandando e-mail para os clientes pedindo que não preencham esse campo. O aviso tem o título "Protecting your finances in the AI World", e a frase que importa não é a advertência, é a seguinte: "If you do share your credentials, keep in mind that you're responsible for activity resulting from that access" — você é responsável pela atividade resultante desse acesso.

Isso não é banco sendo chato. É um banco descrevendo uma exclusão de definição na lei federal americana. Na Regulation E, senha é "meio de acesso", e transferência iniciada por quem recebeu esse meio de acesso das mãos do cliente não é "transferência eletrônica não autorizada". O teto de US$ 50 não fica mais fraco: a categoria em que ele vive deixa de existir.

O e-mail do Bank of America, "Protecting your finances in the AI World": nunca forneça seu usuário e senha a uma ferramenta ou agente de IA, e você é responsável pela atividade resultante desse acesso.

O e-mail foi publicado em 27 de outubro e um porta-voz do banco confirmou a autenticidade ao TechCrunch. Então aquele campo no seu cadastro não é uma integração. É uma transferência de responsabilidade, e ela transfere para o seu próprio cliente.

O que isso custa, em quatro lugares

Quem absorve o prejuízo. Com token delegado, uma transferência contestada continua sendo uma contestação — processo do banco, regras de reembolso do banco. Com senha entregue, a norma manda a conta para quem digitou, e sua fila de suporte herda a conversa. Explicar sua arquitetura não ganha essa conversa.

Se o seu acesso sobrevive ao trimestre. O Online Banking Service Agreement do Bank of America já proíbe compartilhar credenciais com terceiros, abrindo exceção apenas para curatela legal e procuração, e reserva ao banco suspender ou encerrar "in our sole discretion". Uma integração por credencial é quebra de contrato no dia um, não depois do incidente. Jamie Dimon disse a analistas na teleconferência de resultados do JPMorgan, em 13 de outubro, que o banco não vai deixar agentes de fora entrarem; um porta-voz do Chase disse à CBS News que clientes não devem dar usuário e senha a ninguém.

O Online Banking Service Agreement do Bank of America: compartilhar credenciais com terceiros é proibido, exceto em curatela ou procuração, e o banco pode suspender ou encerrar o serviço a seu exclusivo critério.

Se o offboarding é um botão ou um telefonema. Revogar um token é um clique. Revogar uma senha significa o seu usuário ligar para o banco, esperar e trocar uma credencial que quebra todas as outras integrações que ele tem. Esse é o seu fluxo de churn, e você não controla nada dele.

Se você consegue vender para comprador regulado. Toda avaliação de fornecedor que se respeite pergunta como você se autentica em sistemas de terceiros. "Guardamos a senha do banco do cliente" encerra a avaliação — já vimos essa resposta matar negócio em estágio final.

E tem o ponto que pega mais forte aqui: se você atende cliente nos Estados Unidos, é a regra americana que decide quem paga, mesmo com o time em São Paulo. Enquanto isso, o Open Finance brasileiro, regulado pelo Banco Central, já entrega o caminho delegado — consentimento com escopo, prazo e revogação dentro do app do banco. Quem constrói agente financeiro no Brasil tem menos desculpa do que quem constrói nos EUA, não mais.

Refazer autenticação depois do lançamento não é refatoração. É reonboarding de toda a sua base.

O que está documentado e o que não está

Dois tipos de afirmação circulam nesta semana, e merecem pesos diferentes.

Documentado, em fonte primária: o e-mail do Bank of America, as definições da Regulation E e os termos de uso citados aqui. São textos com URL, e você mesmo pode conferir.

Autorrelatado, e bem mais fino: a alegação de que grandes bancos americanos estão hoje detectando atividade não autorizada de agentes de IA dentro de contas de clientes vem de uma apuração do Axios baseada em grande parte em fontes bancárias não identificadas. Nenhum banco publicou dado, não existe contagem de incidentes e nenhuma perda foi atribuída a isso; a CBS News repassou o achado em entrevista com a repórter do Axios, sem confirmação independente. As informações de que o Bank of America restringiu agentes a somente leitura e de que o Morgan Stanley os bloqueou têm a mesma origem, e a afirmação do Morgan Stanley de não ter observado atividade não autorizada de agentes é a própria empresa falando de si. A posição de David Sacks, czar de IA da Casa Branca, de que a maior parte desse tráfego é autorizada pelo usuário e não um ataque, é uma alegação pública dele, contrariada pela leitura que os bancos fazem dos próprios contratos.

O argumento de arquitetura não depende da apuração. Ele se sustenta na norma e nos contratos, e esses não se movem.

A cláusula que apaga o teto

O 12 CFR 1005.6(b) limita a perda do consumidor em transferência não autorizada a US$ 50, ou US$ 500 sem aviso tempestivo — a proteção que todo mundo supõe estar simplesmente lá. Já o 1005.2(m)(1) diz que o termo "transferência eletrônica de fundos não autorizada" "não inclui transferência ... iniciada por pessoa a quem o consumidor forneceu o meio de acesso à sua conta", e o 1005.2(a)(1) define meio de acesso como "cartão, código ou outro meio de acesso".

Regulation E, 12 CFR 1005.2(m): "transferência eletrônica não autorizada" não inclui aquela iniciada por pessoa a quem o consumidor forneceu o meio de acesso.

Senha é código. É esse o argumento inteiro. Entregue a credencial e a transferência que seu agente fizer — ou que fizer quem comprometer seu agente — não é não autorizada. É autorizada, pelo cliente, através de você.

Você não consegue demitir o agente

Os Digital Services Terms of Use vigentes do US Bank são mais diretos que qualquer matéria publicada. Atividade feita com as suas Login Credentials "will be presumed to be authorized by you unless you tell us otherwise", o banco "não é responsável por gerenciar a autoridade das suas relações com terceiros", e para interromper o acesso "you must contact us to block access to Digital Services until new Login Credentials are established".

Digital Services Terms of Use do US Bank: atividade feita com as suas credenciais é presumida autorizada, e revogar acesso compartilhado exige contatar o banco para estabelecer novas credenciais.

Leia como engenheiro. Não existe endpoint de revogação porque não existe concessão a revogar: o agente não é delegado, ele é o cliente. Revogar é rotação de credencial feita por humano em ligação telefônica, e é indiscriminada — mata também o app de orçamento, o acesso do contador e a integração de todo concorrente. Um agente que você não consegue desligar é a mesma falha de plano de controle de um agente que silencia os próprios alertas: o botão de desligar está onde você não alcança.

O caminho autorizado, nas palavras do banco

O mesmo contrato nomeia a arquitetura que o banco aceita: "you login directly with us and provide sharing instructions ... You can manage your data sharing instructions, and revoke your authorization, using Digital Services". E descreve o outro caminho com a mesma clareza: fornecer credenciais autoriza o serviço a acessar a conta "podendo incluir a capacidade de iniciar transferências".

Os dois caminhos nos termos do US Bank: dar instruções de compartilhamento revogáveis no banco, ou entregar credenciais e autorizar transferências.

Delegado, com escopo, revogável pelo cliente: o formato OAuth, descrito por um banco que não vai te dar outra opção. É também o que o Open Finance padronizou no Brasil — a diferença é que aqui existe obrigação regulatória e lá não. A Part 1033 segue no CFR, mas uma consulta ao Federal Register nesta semana não achou regra de Personal Financial Data Rights reeditada. O caminho tokenizado é concessão do banco, o que faz de "ser fácil de autorizar" posição comercial, não checkbox de conformidade.

A decisão, na semana um

Se você ainda não lançou, isso sai barato. Três regras:

  1. Nunca receba credencial de terceiro no seu sistema. Nem criptografada em repouso, nem "só em memória", nem via navegador headless. A posse é o evento de responsabilidade, independente da sua higiene.
  2. Use o caminho delegado do provedor onde ele existe — OAuth, agregador autorizado pelo banco, APIs de Open Finance. Leitura com escopo onde você só lê; escrita explícita e concedida em separado onde você movimenta dinheiro.
  3. Faça da revogação um recurso seu. O usuário tem que conseguir cortar seu acesso de dentro do seu produto, e você tem que conseguir provar quando foi cortado.

Se você já lançou captura de credencial, a migração é problema de produto, não de autenticação: todo usuário atual precisa reconsentir por um fluxo que ainda não existe, enquanto o caminho antigo segue funcionando. Orce como feature, dê um dono, marque data para desligar o caminho velho. O custo cresce junto com sua curva de cadastros — a única curva que você queria que crescesse.

É essa a maior parte do trabalho para o qual nos chamam: uma decisão de autenticação tomada na semana um, aparecendo no mês nove como o travamento de um contrato enterprise.

Pontos principais

  • Senha é "meio de acesso" no 12 CFR 1005.2(a)(1), então entregá-la empurra a transferência para fora da definição de "não autorizada" do 1005.2(m)(1) e para fora dos tetos do 1005.6(b).
  • O e-mail só repete cláusula que já existia: o contrato do Bank of America já proibia compartilhar credencial fora de curatela e procuração, e reserva o encerramento ao exclusivo critério do banco.
  • A revogação não passa pelo seu produto. O US Bank exige telefonema e troca de credencial, o que quebra todas as outras integrações do usuário.
  • A alegação de que bancos estão detectando agentes clandestinos agora é de fonte única e não identificada. Os problemas de contrato e de norma dispensam apuração.
  • Captura de credencial versus autorização delegada é decisão de semana um que define quatro resultados: quem absorve perda, continuidade de acesso, custo de saída e se um comprador regulado pode dizer sim.
Trabalhamos com founders em qualquer lugar do mundo que têm um produto funcional construído com IA — e o bom senso de querer olhos sêniores nele antes dos usuários reais chegarem.

Receber análise

Pronto pra lançar com confiança?

30 minutos com um engenheiro sênior. A gente te diz exatamente o que separa o seu produto da produção.

Receba uma análise do seu produto

30 minutos, sem pitch, sem pressão. Se o seu produto já estiver pronto para lançar como está, vamos te dizer isso também.