Si tienes una instancia de Datasette publicada en internet, actualízala. Y si en esa instancia conviven tablas públicas y tablas privadas, hazlo hoy.
Qué ha pasado
El 11 de septiembre Simon Willison publicó dos versiones de parche de seguridad: 1.0a39, para la serie alfa en curso, y 0.65.4, para la familia estable. Dos ramas mantenidas a la vez, así que si estás en 0.65.x no tienes que saltar a la alfa para estar cubierto.
El origen fueron avisos de Sevban Dönmez. A partir de ahí, Alex Garcia y Willison hicieron una auditoría amplia del código apoyándose en tres modelos distintos —Claude Fable 5.1, GPT-5.6 y GPT-6 Astra— y dedicaron casi una semana a arreglar y revisar lo que salió. Su valoración: los modelos sacaron fallos muy sutiles. Su conclusión: van a incorporar auditorías con modelos punteros a todo su desarrollo de ahora en adelante.
Y un detalle de método que es, para mí, lo mejor del anuncio. Trabajaron en un repositorio privado compartido y en la mayoría de los problemas se repartieron así: uno escribía el test automático que dejaba el fallo en evidencia y el otro implementaba el arreglo. Cada issue pasó por dos personas distintas, además de por agentes con modelos distintos. Puedes leer el anuncio original y las notas de las versiones.
Por qué importa
El test lo escribe quien no arregla
Esto es lo que me llevo a mi forma de trabajar. Cuando la misma persona encuentra el fallo, escribe el test y aplica el parche, el test acaba demostrando que el parche funciona —no que el fallo existía—. Es un sesgo silencioso y muy común: el test se escribe mirando el arreglo.
Separar los dos papeles convierte el test en un contrato. Reproduce el problema desde fuera, sin saber por dónde va a venir la solución. Y tiene un efecto secundario aún mejor: te obliga a explicarle el bug a otra persona con suficiente precisión para que lo pueda reproducir. No hay mejor detector de "esto en realidad no lo he entendido".
Yo trabajo solo, así que no tengo a nadie al otro lado. Lo que hago es acercarme: primero un commit con el test en rojo, fechado, antes de tocar una línea de la corrección; y cuando uso un agente para la segunda opinión, le paso el test y el comportamiento observado, nunca mi arreglo. Si le enseñas tu parche, te lo aplaude.
Tres modelos no es coleccionismo
Pasar tres modelos por el mismo código no es capricho. Fallan en sitios distintos y se solapan menos que dos pasadas del mismo modelo, así que la unión cubre más superficie. El precio es ruido: cada pasada devuelve hallazgos que no son nada, y alguien tiene que descartarlos. Ahí está, me imagino, buena parte de esa semana casi entera. Auditar es rápido; triar y revisar, no.
El patrón que deberías mirar en tu app
El aviso concreta mucho: el riesgo aprieta cuando una misma instancia mezcla lo público y lo privado. Ahí vive esta clase de fallo. No en el endpoint que devuelve la tabla secreta —ese lo tienes protegido—, sino en todo lo que la rodea: esquemas, nombres de columnas, mensajes de error, conteos, facetas, sugerencias de autocompletado, rutas de exportación. Cualquier cosa que revele la existencia o la forma de algo que no deberías poder ver.
Si tu aplicación decide permisos por tabla o por fila dentro del mismo endpoint, esto te toca de lleno. Lo que haría yo esta semana: listar todas las rutas que devuelven metadatos y pasar cada una con un usuario sin permisos, comprobando no solo que no hay datos, sino que no hay pistas. Los tests de autorización suelen cubrir el dato y casi nunca el metadato.
Que la auditoría no dependa de que alguien te avise
El orden de esta historia es el habitual: llega un reporte externo y entonces se audita. Funciona, pero es el camino caro, porque la ventana entre el fallo y el aviso la pones tú. La parte copiable de la decisión de Willison es convertir la auditoría en rutina del ciclo de desarrollo en vez de en reacción a un correo.
Qué no cambia
- Esto no es un pentest. Una auditoría con modelos sobre tu propio código no sustituye a una auditoría formal ni a un test de intrusión contra el sistema desplegado. Aquí funcionó porque dos personas con conocimiento profundísimo del proyecto dirigían la sesión y sabían qué merecía la pena mirar.
- No sabemos cuántos fallos eran ni de qué gravedad. El anuncio no da número ni clasificación. Si tienes que evaluar riesgo real para tu instalación, ve a las notas de las versiones y no a lo que te cuente un resumen.
- El coste humano sigue estando. Casi una semana de dos personas, después de la auditoría. Quien venda que los modelos parchean solos no está mirando la factura de tiempo.
- 1.0a39 sigue siendo una alfa. Que traiga parches de seguridad no la convierte en estable.
- Y al revés: si alguien te cuenta esto como "la IA encontró vulnerabilidades", se queda corto. El titular es el proceso —dos revisores humanos, modelos distintos, test y arreglo separados— y eso sí te lo puedes llevar a tu equipo mañana.
Cualquier duda me dices y lo vemos.
Un saludo, Vicente.