El código generado por IA envió controles pero omitió la verificación.

      Una prueba de penetración en una firma de servicios financieros que gestiona miles de millones de dólares en activos de clientes ha encontrado un fallo crítico en el código generado por IA. La parte interesante es lo que el código acertó.

      Sygnia, la firma de respuesta a incidentes, evaluó una aplicación de incorporación de clientes construida sustancialmente con Claude. Manejó identificaciones emitidas por el gobierno, datos de verificación de identidad, detalles de pago y números de Seguro Social.

      El fallo permitió que un solicitante accediera al registro de otro solicitante.

      Lo que realmente falló

      La aplicación resolvió un problema real. Las personas inician una solicitud, se van y regresan antes de tener una cuenta, por lo que el sistema debe restaurar su progreso sin una contraseña.

      Claude produjo un modelo de acceso temporal para eso. El fallo radicaba en cómo el modelo decidía quién merecía un token.

      El 💜 de la tecnología de la UE

      Los últimos rumores de la escena tecnológica de la UE, una historia de nuestro sabio fundador Boris y un arte de IA cuestionable. Es gratis, cada semana, en tu bandeja de entrada. ¡Regístrate ahora!

      La posesión del identificador único global de un solicitante, o GUID, contaba como prueba suficiente para emitir o restaurar un token de acceso para ese solicitante.

      “De hecho, el GUID se convirtió en un secreto portador”, escribió Sygnia en su investigación.

      Un GUID identifica un registro. No prueba que quien lo posee controle la sesión, el dispositivo, la identidad o el canal de contacto verificado asociado a él.

      Cualquiera con el GUID de otro solicitante podría acceder a nombres, detalles de contacto, estado de la solicitud, detalles financieros, datos de verificación de identidad, información de pago, números de Seguro Social y registros de co-solicitantes.

      Los co-solicitantes merecen una pausa. Son personas cuyos datos estaban en el sistema porque alguien más los nombró.

      Los controles estaban todos ahí

      Aquí está lo que hace que el hallazgo sea inusual, y no es la historia que la mayoría de los fallos de codificación de IA cuentan.

      La implementación no carecía de seguridad. Sygnia describe un plan que cubre tokens temporales, expiración, limitación de tasa, registro de auditoría, restauración de sesión y detección de actividad sospechosa.

      Cada uno de esos es un control real. Ninguno de ellos responde a la pregunta que el sistema realmente necesitaba responder.

      “¿Qué debe probarse antes de que el backend emita o restaure un token de acceso para un solicitante?” preguntan los investigadores.

      La vulnerabilidad existía antes de la emisión, en el momento en que el sistema decidía si el solicitante merecía un token en absoluto.

      “El problema no era que el sistema careciera de controles de seguridad”, escribió Sygnia. “El problema era que los controles estaban envueltos alrededor de la decisión de confianza equivocada.”

      Un token de corta duración aún causa daño cuando llega a la persona equivocada. Los registros de auditoría ayudan a una investigación posterior y no previenen nada.

      Por qué los escáneres pasan por alto esto

      Las herramientas de pruebas de seguridad de aplicaciones estáticas buscan patrones de codificación inseguros y flujos de datos inseguros. Esto no fue ninguno de los dos.

      El fallo era arquitectónico. Vivía dentro de una suposición sobre la confianza, escrita en un código que seguía convenciones de marco familiar y pasaba controles básicos.

      “El código funcional no es lo mismo que el código seguro”, dijo Zach Mead, el tester de penetración de Sygnia que realizó la evaluación.

      “El código generado por IA puede compilarse, seguir convenciones familiares y pasar controles básicos, mientras aún hace suposiciones erróneas sobre límites de confianza, autorización, estado, propiedad o integraciones de terceros”, dijo.

      Su instrucción a los equipos de seguridad es contundente. Trata la salida generada por IA como no confiable hasta que se valide.

      Un LLM encontró lo que un LLM construyó

      Sygnia no captó esto a mano. Ejecutó un modelo de lenguaje en partes de la base de código del cliente, buscando problemas de límites de confianza y fallos en la lógica empresarial.

      El modelo sacó a la luz el problema del token de solicitante directamente.

      El resumen de Sygnia sobre eso es la línea más aguda en la investigación. Se identificó un fallo de arquitectura de seguridad codificado por vibraciones a través de una revisión de código codificada por vibraciones.

      Corta en ambas direcciones, y la firma lo dice. Si un defensor puede preguntar a un modelo dónde faltan los límites de confianza, cualquiera que tenga código fuente filtrado o notas de implementación robadas también puede.

      Cisco ha estado apuntando modelos de peso abierto a la caza de errores por la misma razón. Una capacidad, dos usos.

      El problema del tempo

      Esta investigación se sitúa junto a un segundo caso de Sygnia, y la combinación sostiene el argumento.

      En una intrusión en la nube que la firma investigó, la primera señal no fue un exploit. Fue el ritmo.

      El descubrimiento de credenciales, la enumeración en la nube, la revisión de código fuente, la exploración de CI/CD, el acceso a bases de datos y la interrupción operativa se ejecutaron al mismo tiempo. Se asemejaba a varios operadores en lugar de uno.

      Era una persona, trabajando con agentes.

      Junta los casos y la forma es clara. La IA está acelerando cómo se escribe el código, cómo se encuentran los fallos y cuán rápido una debilidad se convierte en una ruta de ataque. Ya hemos rastreado cuatro ataques separados que comparten un único fallo subyacente.

      Lo que Sygnia dice a los clientes que hagan

      No prohibir las herramientas. Las prohibiciones empujan el uso a cuentas personales, donde nadie puede verlo.

      La firma sugiere marcar las solicitudes de extracción que la IA generó o modificó sustancialmente, nombrando la herramienta y señalando el trabajo que toca la autenticación, los pagos, las exportaciones de datos o la información regulada del cliente.

      El consejo más concreto se refiere a los prompts. Pedir “tokens de acceso temporales para solicitantes” es una instrucción incompleta.

      Un prompt más seguro establece que los identificadores de solicitantes no deben tratarse como secretos, que la emisión de tokens requiere prueba independiente del control del solicitante y que las pruebas negativas deben demostrar que un solicitante no puede obtener acceso para otro.

      El requisito de seguridad debe estar en el prompt, porque el modelo no inferirá el modelo de riesgo de una institución por sí solo.

      Una advertencia que vale la pena mencionar

      Este es un informe de proveedor sobre un cliente no nombrado, publicado junto a un nuevo servicio comercial.

      Sygnia lanzó Servicios de Ciberseguridad de IA el mismo día, cubriendo evaluación de postura, gobernanza y pruebas de penetración de aplicaciones de IA. Nadie puede verificar independientemente los hallazgos, y ninguna otra firma ha informado sobre este caso.

      El mecanismo que describe es verificable, sin embargo, y ecoa nuestra cobertura anterior sobre fallos de seguridad codificados por vibraciones, escapes de sandbox en agentes de codificación e inyección de prompts en una acción de GitHub de Claude Code.

      Lo que separa este caso es dónde estaba el fallo. Esos eran vulnerabilidades en las herramientas. Este fue un código generado por IA que llevaba el fallo a producción, en un negocio regulado, alrededor de datos que los clientes están obligados a entregar.