Los bancos bloquean a los agentes de IA, un SBOM que no pudo delimitar un incidente Shai-Hulud, passkeys que no cierran el problema de identidad, cuánto tiempo conservar los registros y un fallo puntuado con 2.7 que los desactivó.
En esta edición
- 01Los bancos están bloqueando a los agentes de IA en las cuentas de clientes.
- 02El SBOM no les dijo qué había ejecutado realmente.
- 03Las passkeys cierran el problema de la contraseña. No cierran el problema de identidad.
- 04El SOC quiere todos los registros para siempre. El DPO quiere seis meses.
- 05Un fallo puntuado con 2.7 desactivó los registros, y nadie lo habría parcheado.
Recibe el próximo GRC Brief en tu correo.
Suscribirse a The GRC BriefLos bancos están bloqueando a los agentes de IA en las cuentas de clientes.
Axios informó el 22 de octubre que los principales bancos estadounidenses están detectando agentes de IA de terceros operando dentro de cuentas de clientes, generalmente porque el propio cliente les facilitó su nombre de usuario y contraseña. El consejero delegado de JPMorgan declaró que permitir la entrada de agentes externos arbitrarios supondría un riesgo demasiado elevado para los clientes y para el banco. Bank of America ha recordado a sus clientes que, si comparten sus credenciales, son responsables de las consecuencias. Muchos bancos están migrando hacia el acceso de solo lectura. Una opinión discrepante, procedente de Bianco Research, sostiene que la banca minorista se beneficia de la inercia del cliente, y que un agente que traslada efectivo inactivo a un fondo del mercado monetario representa un coste para el banco.
Fuente: Axios · 22 Oct 2026
Mi análisis
Ambas explicaciones pueden ser ciertas a la vez, y lo que subyace a ellas es más interesante que cualquiera de las dos por separado. Un cliente minorista no dispone de ningún mecanismo para otorgar a un agente una autorización limitada, de modo que entrega la credencial completa. Ese es el problema de identidad de máquina del que escribí en septiembre: una identidad por agente con credenciales acotadas a una tarea. El titular de la cuenta no cuenta con ninguna de esas herramientas y el banco no puede distinguir a su agente de un atacante. El acceso de solo lectura resuelve la mitad del problema. Un agente que puede leer los extractos también puede divulgarlos si queda comprometido o manipulado, y bloquear una transferencia y proteger la confidencialidad son dos trabajos distintos.
El SBOM no les dijo qué había ejecutado realmente.
En el ISC2 Security Congress, Deepam Kanjani, responsable de seguridad de producto en Atlassian, expuso un caso real de respuesta ante un incidente Shai-Hulud. El paquete malicioso se encontraba tres niveles por debajo en el árbol de dependencias, invisible para el análisis de primer nivel. Cuando comenzó el incidente, el SBOM del equipo ya estaba desactualizado y no había telemetría en tiempo de ejecución, por lo que no podían determinar qué había ejecutado a lo largo de más de 400 servicios. Su recomendación es concreta: mantener los SBOMs desplegados con una antigüedad inferior a 72 horas en más del 98 por ciento de los servicios en producción, y detectar cargas de módulos desconocidos en tiempo de ejecución.
Fuente: Dark Reading · J. Vijayan, 27 Oct 2026
Mi análisis
Este año ya les he dicho dos veces que traten el SBOM como un inventario en tiempo real, no como un artefacto de auditoría. Aquí está el número que me faltaba. Setenta y dos horas. Si el suyo se genera en el momento de la compilación y el último despliegue fue en septiembre, describe un sistema que ya no están ejecutando. Noten qué mitad falta casi en todas partes. El inventario de componentes registra lo que se entregó. Nadie está monitorizando lo que se carga. Durante un incidente las únicas dos preguntas son qué ejecutó y a dónde llegó, y una lista de dependencias no responde a ninguna de las dos.
Las passkeys cierran el problema de la contraseña. No cierran el problema de identidad.
Una advertencia previa: este artículo es una columna de opinión de un experto del lado del proveedor, no una información periodística. El argumento es válido de todos modos. Las passkeys eliminan el secreto reutilizable y resisten el phishing, lo que cierra la mayor parte de la superficie de ataque sobre credenciales. Lo que no tocan es todo lo que rodea al autenticador: si la cuenta se creó de forma legítima en primer lugar, qué ocurre cuando cambia el dispositivo, qué acepta como prueba la vía de recuperación y si una sesión puede ser secuestrada tras un inicio de sesión completamente limpio. A medida que las organizaciones eliminan las contraseñas, los atacantes se desplazan hacia esos flancos.
Fuente: SecurityWeek · T. George, expert column, 30 Oct 2026
Mi análisis
Ya han visto la versión concreta de esto dos veces. En agosto, un kit de phishing que enrolaba su propia passkey en la cuenta de la víctima y sobrevivía al restablecimiento de contraseña. El mes pasado, un proveedor externo de MFA fraudulento que superaba la verificación mientras el segundo factor nunca llegaba a producirse. Ninguno atacó la criptografía. Ambos fueron directamente contra el enrolamiento y la recuperación. Así que desplieguen passkeys, siguen siendo la decisión correcta. Luego respondan las dos preguntas que determinan si aguantan: quién tiene autorización para enrolar una en una cuenta, y qué acepta el servicio de atención cuando alguien llama para decir que ha perdido su dispositivo.
El SOC quiere todos los registros para siempre. El DPO quiere seis meses.
Escribí sobre este tema esta semana. Cuando PHP2Shell se hizo público el 21 de octubre, el equipo de inteligencia de amenazas de Amazon indicó a los equipos de respuesta que investigaran desde al menos el 17 de octubre, cuatro días antes. Si los registros de su servidor web rotan semanalmente, nunca sabrán si fueron afectados antes de que se anunciara nada. Pregunte a su DPO cuánto tiempo conservar esos mismos registros y obtendrá una respuesta distinta, porque están llenos de direcciones, identificadores y a veces cuerpos de solicitud completos. Cinco fuentes normativas dan cinco cifras diferentes, y ninguna de ellas ofrece una respuesta universal.
Fuente: My full breakdown · cyberacademy.net
Mi análisis
Lo que las cinco piden en cambio es lo mismo: un periodo vinculado a una finalidad, documentado con una justificación. El error habitual es fijar la retención por herramienta, porque «el SIEM conserva 90 días» es una decisión de licencia disfrazada de criterio de seguridad. Fíjenla por finalidad: detección, investigación, trazabilidad de accesos privilegiados, base legal, y que gane la más exigente que puedan justificar realmente. Luego usen los dos mecanismos que nadie toca: registren el evento sin el propio dato personal, y estratifiquen el almacenamiento para que menos personas puedan acceder a los datos más antiguos. Un patrón que veo en casi todas las auditorías que realizo: al DPO nunca se le consultó. El artículo 38 dice que debería haberse hecho.
Un fallo puntuado con 2.7 desactivó los registros, y nadie lo habría parcheado.
Broadcom puntúa CVE-2026-41709 con 2.7 sobre 10. Es un fallo de registro insuficiente en VMware ESX que permite a alguien que ya tiene acceso de administrador en un host ejecutar determinadas operaciones sin que aparezcan en los registros. El 28 de octubre CrowdStrike reveló que el grupo vinculado a China Warp Panda lo había utilizado como zero-day a principios de 2026, durante intrusiones de espionaje contra despachos de abogados estadounidenses, con el objetivo específico de reducir lo que mostraría el rastro de auditoría. Broadcom publicó un parche el 29 de julio. CISA lo añadió al catálogo de vulnerabilidades explotadas conocidas el mismo día en que CrowdStrike publicó su informe, con un plazo federal límite del 11 de noviembre.
Fuente: CrowdStrike · 2026 Legal Threat Landscape Report, 28 Oct 2026
Mi análisis
Leído junto al punto anterior, los dos forman el problema completo. Se puede calibrar la retención a la perfección, consultar al DPO, documentar la finalidad y el periodo, y aun así quedar ciegos porque alguien desactivó la grabación por debajo, a nivel de hipervisor. Luego piensen en qué habría hecho su propio proceso con este fallo. Un 2.7 está por debajo del umbral de la mayoría de las políticas de parcheo, así que nunca habría entrado en la cola. Broadcom lo corrigió en julio y nada se movió hasta que un informe de inteligencia de amenazas nombró al grupo tres meses después. Conviene hacer una comprobación adicional: las fuentes públicas ni siquiera coinciden en la puntuación, y algunas la cifran en 7.6. Una diferencia de cinco puntos en el mismo CVE decide si su política llega a verlo alguna vez.