Los bancos están bloqueando a los agentes de IA. Lo que deberíamos aprender quienes construimos pagos
Grandes bancos de EE. UU. restringen a los agentes de IA que entran como el cliente. Por qué es un problema de identidad y cómo resolverlo con acceso acotado.
Esta semana Axios publicó que algunos de los bancos más grandes de Estados Unidos, entre ellos JPMorgan, Bank of America y Morgan Stanley, están restringiendo a los agentes de IA de terceros. El motivo: encontraron agentes operando dentro de cuentas de clientes. Algunos entraban con las credenciales del propio cliente, algo que va contra las reglas de los bancos. Otros llamaban a las líneas de soporte o hacían cosas que el usuario nunca pidió.
Por ahora la respuesta es defensiva. Morgan Stanley está bloqueando a los agentes de terceros. JPMorgan, Bank of America y Citi los están restringiendo, y la mayoría de los bancos se está moviendo hacia un acceso de solo lectura.
Hay un detalle de la noticia que no se me va de la cabeza. La mayoría de los casos eran agentes que el usuario sí había autorizado, no ataques. Pero un ejecutivo de uno de los bancos dijo que les está costando distinguir unos de otros. Para mí, ese es el verdadero titular.
Es un problema de identidad, no de IA
Cuando un agente entra con tu usuario y tu contraseña, el banco ve que eres tú. No tiene forma de saber que hay un software actuando en tu nombre, qué le pediste ni hasta dónde llega tu permiso. Así que, desde el lado del banco, un agente útil y uno malicioso se ven exactamente igual.
Eso no se arregla con un modelo mejor. Un modelo más inteligente seguiría entrando como si fuera una persona. El problema es que les dimos a los agentes el tipo de llave equivocado. Una contraseña dice "soy esta persona". Lo que necesitamos es una credencial que diga "soy un agente, actúo en nombre de esta persona y tengo permiso para hacer estas cosas concretas".
En pagos ya resolvimos una versión de esto
Trabajo en infraestructura de pagos en Payabli, construyendo componentes de pago embebidos, portales para partners y clientes, y funcionalidades como tokenización, ACH y billeteras digitales. Buena parte de ese trabajo se resume en una idea: nunca compartas el secreto real si basta con un sustituto con alcance limitado.
La tokenización es el mejor ejemplo. Un comercio no necesita el número de la tarjeta para cobrarle otra vez a un cliente. Recibe un token que solo funciona en un contexto específico y que se puede revocar. Las tarjetas virtuales siguen una lógica parecida: una tarjeta que existe para un propósito, con límites.
Los agentes necesitan lo mismo. Darle a un agente la contraseña de tu banco es como darle a un comercio el número real de tu tarjeta y esperar que solo te cobre lo acordado. En pagos dejamos de hacer eso por buenas razones.
Empezar con solo lectura es lo correcto
También construyo flujos asistidos por IA, como la gestión de disputas e integraciones internas que usan servidores MCP y agentes. Mi forma de verlo: MCP le da al agente acceso a un sistema, y un Skill le da el conocimiento para usarlo bien. Normalmente quieres las dos cosas. Pero el acceso es la parte que te puede hacer daño, y ahí es donde empiezo a ser estricto.
Los bancos que se mueven a solo lectura están haciendo lo que yo le recomendaría a cualquier equipo. Deja que el agente lea, junte contexto, resuma y prepare. Las acciones que mueven dinero o cambian datos tienen que ir detrás de un paso separado y explícito. Si expones herramientas de lectura y de escritura por la misma puerta y con los mismos permisos, ya tomaste la decisión que los bancos ahora intentan deshacer.
Que un agente "vaya más allá de sus instrucciones" casi nunca significa que el modelo tenga malas intenciones. Significa que es demasiado servicial y tiene demasiado acceso. Eso se arregla con límites, no con mejores prompts.
Cómo podría ser un marco mejor
Bloquear agentes da tiempo, pero no va a durar. Los clientes quieren que los agentes se encarguen de las tareas financieras aburridas, y esa demanda va a seguir creciendo. Entonces, ¿cómo debería verse el camino autorizado? Desde el punto de vista de quien construye, yo querría al menos estas piezas:
- Identidad del agente. El agente presenta su propia credencial, separada del login del usuario, para que el banco siempre sepa cuándo está actuando un software.
- Permisos acotados y revocables. Acciones específicas, límites de monto y fecha de vencimiento. El usuario puede verlos y cancelarlos cuando quiera.
- Confirmación humana para mover dinero. Transferir fondos o hacer una compra debería pedir una confirmación dentro de la propia interfaz del banco, igual que un pago con billetera digital te pide Face ID antes de completarse.
- Un registro de auditoría. Cada acción vinculada al agente, al usuario y al permiso que la autorizó.
Ese tercer punto es donde el trabajo de frontend importa más de lo que la gente cree. La pantalla de confirmación es la última línea de defensa. Si es ambigua, el usuario va a aprobar cosas que no entiende. Tiene que decir con claridad qué quiere hacer el agente, por cuánto y a quién, en lenguaje sencillo.
Lo que me llevo como builder
Si estás construyendo agentes que tocan sistemas financieros, no los diseñes para que entren como si fueran el usuario. Ese camino se está cerrando, y está bien que se cierre. Diseña pensando en acceso acotado desde el primer día: primero herramientas de lectura, las de escritura detrás de una confirmación, y cada acción trazable.
Los bancos no les están diciendo que no a los agentes para siempre. Les están diciendo que no a los agentes que no pueden identificar. Los equipos que construyan bien la capa de identidad y permisos serán con los que los agentes podrán trabajar cuando las puertas se vuelvan a abrir.