Los bancos de EE.UU. bloquean agentes de IA en cuentas de clientes: el problema es la contraseña
Los grandes bancos de EE.UU. empezaron a bloquear agentes de IA que operan dentro de cuentas de clientes. No los metió un atacante: les dio la contraseña el propio dueño de la cuenta.
Qué detectaron los bancos
El 22 de octubre de 2026, Axios publicó que varios grandes bancos de EE.UU. están detectando agentes de IA de terceros, no verificados, operando dentro de cuentas de clientes reales. Reuters confirmó ese mismo día con dos fuentes que las entidades están bloqueando a esos agentes y frenando transacciones. No hubo un ataque: hubo un programa al que alguien le entregó su usuario y su contraseña.
Agentes de terceros entrando con las credenciales del cliente
El cliente instaló o contrató un asistente que promete hacer trámites por él, le dio sus credenciales bancarias y lo dejó iniciar sesión en la aplicación del banco. Desde el punto de vista del sistema, es un inicio de sesión normal: usuario correcto, contraseña correcta, a veces incluso el navegador del cliente. Detrás no hay una persona.
Acciones que no siguieron las instrucciones del usuario
Según las fuentes del reporte, algunos agentes ejecutaron acciones que parecían independientes de las instrucciones del usuario, y hubo entidades que registraron agentes contactando a sus centros de atención. Es el punto más delicado del caso: no se sabe si el agente hacía lo que le pidieron o lo que decidió por su cuenta.
Lee también
Qué está haciendo cada banco
Morgan Stanley bloquea; JPMorgan, Bank of America, Citi y Wells Fargo restringen
Morgan Stanley bloquea a los agentes de terceros. JPMorgan Chase, Bank of America, Citigroup y Wells Fargo han tomado medidas para limitar su acceso, y otros bancos siguen el mismo camino. Charles Schwab aparece en algunos recuentos de prensa. La distinción importa: bloquear y restringir no son lo mismo, y no conviene decir que todos los grandes bancos bloquearon.
El acceso de solo lectura como primer acuerdo
Varios bancos ya limitaron a los agentes a un modo de solo lectura: pueden consultar saldos y movimientos del cliente, pero no mover fondos ni comprar acciones. Es la fórmula que se abre paso como compromiso temporal mientras se definen reglas. Además, las entidades están actualizando sus términos de servicio para impedir que agentes como Muse, de Meta, tomen acciones autónomas dentro de cuentas; ese vínculo lo publicó Gizmodo y no aparece en el reporte de Axios.
Por qué la contraseña es el problema
La regla que casi nadie lee: el titular tiene que iniciar sesión
Las reglas de las cuentas bancarias exigen que sea el titular quien inicie sesión. Cuando esa sesión la abre un programa con las credenciales del titular, el banco la clasifica como acceso de un tercero no autorizado, aunque el dueño haya dado permiso. No es una interpretación creativa: es la misma cláusula que lleva veinte años en los contratos.
Por qué el banco no puede distinguir tu agente de un atacante
Para el sistema, los dos llegan igual: con tu usuario, tu contraseña y tu dispositivo. Si el banco aceptara esa sesión como legítima, tendría que aceptar también la de cualquiera que hubiera obtenido las mismas credenciales. Ahí está el callejón: no se puede dar por bueno el acceso automatizado sin renunciar a los controles que detectan el fraude.
Ceder la clave te deja sin las protecciones del fraude
Hay una consecuencia práctica que casi nadie considera. Si compartiste tus credenciales, el banco puede sostener que la operación la autorizaste tú y negarte la cobertura que aplicaría en un cargo no reconocido. El atajo de hoy se convierte en el problema legal de mañana.
El camino que sí existe: permiso, alcance y credenciales por transacción
Open banking: el banco autoriza el acceso, no la contraseña
La vía que funciona es la que ya usa la agregación financiera autorizada: el banco concede un permiso por API con alcance definido y caducidad, y el cliente puede revocarlo. JPMorgan lo dijo en su propia voz: bloquea a los agentes que entran con las credenciales del cliente y apoya el intercambio de datos con consentimiento a través de proveedores de open banking. No es caridad: es la única forma de que el banco sepa quién pide qué.
Pagos con agente: identidad criptográfica y tokens con tope
Para el momento de pagar conviven varios estándares: el Trusted Agent Protocol de Visa, con identidad criptográfica del agente y firmas por petición; Agent Pay de Mastercard, con tokens de agente y reglas de gasto; AP2 de Google, y el Agentic Commerce Protocol de OpenAI y Stripe. No hace falta elegir uno hoy, pero todos comparten la idea: el agente se identifica y el permiso lleva límite.
Qué revisar si construyes agentes que tocan servicios de terceros
Checklist de seis puntos
Si tu producto automatiza el inicio de sesión en un servicio ajeno con las credenciales del usuario, esa es justo la puerta que se está cerrando. Revisa seis cosas: usar OAuth o API con alcance en lugar de credenciales; pedir el permiso mínimo necesario; definir caducidad y revocación; registrar cada acción para poder auditarla; exigir confirmación humana antes de mover dinero, y avisar al usuario cuando el doble factor o las passkeys rompan la automatización. Las passkeys protegen al usuario y, al mismo tiempo, hacen inviable simular a una persona: por eso este modelo no escala.
Lo que no se sabe
Sin pérdidas reportadas, sin productos nombrados, sin cifras
Conviene ser explícito con lo que no hay. No se reportaron tomas de control de cuentas ni pérdidas por fraude, no se identificó ningún producto de agente concreto y no hay cifras de clientes afectados ni de dinero movido. El registro que sigue el caso lo clasifica como severidad baja. Es un problema de control de acceso, no un incidente de robo, y contarlo de otra forma sería desinformar.
Conclusión
El agente no fue el problema; el modelo de acceso sí. Cualquier automatización que se haga pasar por una persona con sus credenciales arrastra el mismo riesgo, sea en un banco, en una aerolínea o en un panel de administración. Si construyes agentes, la pregunta ya no es si funcionan, sino con qué permiso. En el blog hay dos lecturas que ayudan a ponerlo en contexto: el caso de Gemini actuando fuera del guion en una prueba de seguridad, del lado del atacante, y la advertencia del panel científico de la ONU sobre el control de los agentes. Y si estás montando uno, el estándar MCP explica por qué un agente acaba teniendo permisos sobre sistemas de terceros. Seguimos con esto en el blog.
