En algún punto de la pila antifraude de un banco estadounidense esta semana se abrió una sesión con un usuario válido, una contraseña válida y un código de un solo uso válido. Todas las comprobaciones pasaron. El problema es que no había ningún humano detrás.
Axios informó el 22 de octubre de que grandes bancos de EE. UU., entre ellos Morgan Stanley, Bank of America, JPMorgan y Wells Fargo, están detectando agentes de IA de terceros operando dentro de cuentas de clientes. En la mayoría de los casos el propio cliente entregó sus credenciales, que es exactamente lo que prohíben las condiciones de servicio de cualquier banco. Algunos agentes han llamado a los centros de atención. Otros han ejecutado acciones que parecen independientes de lo que pidió el usuario. Los ejecutivos usaron la palabra "espeluznante".
Léelo otra vez. Las credenciales eran reales. El consentimiento era real, al menos al principio. Y el banco seguía sin poder responder la única pregunta que importa a las 2 de la mañana: ¿autorizó el titular esta acción concreta?
El problema nunca fue la autenticación
Pasamos veinte años haciendo difícil falsificar un inicio de sesión. Contraseñas, luego MFA, luego passkeys. Todo responde una sola pregunta: ¿esta persona es quien dice ser?
Los agentes parten esa pregunta en dos. El inicio de sesión sí es el cliente. La acción puede que no. Y una vez que un agente sostiene un token de sesión, se ve idéntico a un humano muy rápido, salvo que actúa a velocidad de máquina y nunca se cansa ni sospecha.
Los bancos quedan atrapados en un hueco de control que no se tapa con mejor MFA, porque la parte humana ya salió bien. Lo que falta es atar la autorización a una acción concreta, no a una sesión. Eso no es un problema de autenticación. Es un problema de autorización y atribución, y casi todas las organizaciones fuera de la banca tienen el mismo agujero.
Qué están haciendo los bancos ahora mismo
La primera respuesta es bloquear. Morgan Stanley ha empezado a negar el acceso de agentes de terceros a sus plataformas. JPMorgan, Bank of America y Citi los están restringiendo. La postura de Chase es tajante: nunca entregues tu usuario y contraseña a nadie.
La segunda respuesta es reducir la apertura. La mayoría de los bancos avanza hacia el acceso de solo lectura, el mismo modelo que ya permite a herramientas como Quicken ver saldos sin mover dinero. Leer es un riesgo mucho menor que escribir, y los bancos lo saben.
La tercera respuesta es planificar escenarios. Varias entidades ensayan el día después de un incidente: cómo bloquear a un cliente rápido, cómo restaurar el acceso, cómo probar qué pasó. Es un instinto maduro y también una admisión de que la prevención sola no alcanza.
Por qué la atribución es la parte difícil
El detalle incómodo del informe de Axios: muchos bancos no pueden determinar si la actividad del agente fue dirigida por el usuario. Les cuesta distinguir un agente de otro, y mucho más si un agente tenía permiso o simplemente tenía credenciales.
Eso es un defecto de diseño, no de personal. Si tu único registro de una acción es "sesión autenticada realizó transferencia", no tienes una pista de evidencia. Tienes una marca de tiempo.
Compáralo con lo que registraría un plano de control consciente de agentes:
- Quién es el agente: una identidad de cliente registrada con su propia clave, no una sesión humana prestada.
- Qué pidió el humano: la instrucción real, capturada en el punto de intención.
- Qué alcance se concedió: un permiso estrecho por acción, con tope de importe y caducidad.
- Qué ocurrió realmente: la acción ejecutada, correlacionada con el permiso que la habilitó.
Con esos cuatro registros, un banco responde la pregunta de las 2 de la mañana en segundos. Sin ellos, solo puede adivinar, y adivinar significa bloquearlo todo.
Qué significa fuera de la banca
Si gestionas nóminas, facturación, compras, CRM o infraestructura, el mismo patrón ya está en tu stack. Un asistente o agente que sostiene una credencial de larga vida puede hacer todo lo que esa credencial puede hacer. Escribimos sobre este mismo modo de fallo ayer, cuando LiteLLM publicó un ladrón de credenciales en PyPI y puso tokens vivos frente a cualquiera que lo instalara.
La lección se repite porque la arquitectura se repite. Se dan credenciales humanas a los agentes porque es fácil, y las credenciales humanas son todo o nada.
Una forma mejor se ve así:
- Identidad separada por agente. Una cuenta de servicio o cliente OAuth con su propia clave, revocable sin tocar el login de una persona.
- Permisos acotados y de vida corta. Solo lectura por defecto. Escritura concedida por tipo de acción, con límites y caducidad en minutos, no en meses.
- Consentimiento en el momento de la acción. Si el agente va a mover dinero, el humano aprueba esa transferencia, no "el agente puede usar mi cuenta".
- Una auditoría que nombre el permiso. Cada acción relevante debe apuntar al objeto de permiso que la autorizó, para que un revisor pueda reproducir la decisión.
- Interruptores de corte que no exijan cambiar contraseñas. Revoca el agente y mantén al humano trabajando.
Nada de esto es exótico. Es diseño de autorización corriente, aplicado a un tipo de cliente que no existía cuando se construyeron la mayoría de estos sistemas.
La conclusión
La verdad incómoda del caso bancario es que los agentes no estaban entrando por la fuerza. Se les estaba dejando entrar, con credenciales reales e intención real del usuario, y las instituciones no tenían lenguaje para la diferencia entre "mi cliente pidió esto" y "algo con la sesión de mi cliente hizo esto".
Toda organización que despliega agentes va a necesitar ese lenguaje. Empieza asumiendo que tu agente hará algún día algo que no querías, y diseña el registro que querrías leer a la mañana siguiente. Si no puedes responder quién autorizó una acción, qué alcance tenía y qué tocó, todavía no tienes seguridad de agentes. Tienes un agente y una esperanza.
Si estás mapeando el acceso de agentes en tu stack y quieres una segunda opinión sobre el diseño de permisos, ese es exactamente el trabajo que hacemos en aratech.