Qué pasó después de que 2k personas intentaran hackear a mi asistente de IA

Artículo original ↗ Discusión en Hacker News ↗

Un experimento que invitó a la gente a “hackear” un asistente de correo con IA que manejaba un archivo secreto oculto, al parecer resistió alrededor de 6.000 intentos de inyección de prompts sin filtrar los datos. Los comentaristas valoran el esfuerzo, pero sostienen que la configuración era poco realista: se le indicó al agente que no respondiera, operaba en un contexto donde casi todas las entradas eran maliciosas y no tenía herramientas ni canales de salida habilitados, lo que lo hacía más seguro pero mucho menos útil. El debate gira en torno a cómo probar de forma significativa la seguridad de agentes LLM en condiciones reales, donde los modelos deben distinguir entre solicitudes legítimas y maliciosas, admitir interacciones de varios pasos y, al mismo tiempo, controlar los costes.

Reacción general

  • A muchos les pareció que el experimento era divertido e interesante, pero la mayoría pensó que el optimismo sobre la inyección de prompts estaba exagerado.
  • El resultado de “no se filtraron secretos en ~6k intentos” se vio como sugerente, pero lejos de ser concluyente.

Preocupaciones sobre el diseño experimental

  • Solo correos de un solo intento; no hubo interacciones multimensaje tipo “hervir la rana”, que varios consideran el verdadero peligro.
  • El agente, por diseño, en su mayor parte no respondía a los correos para ahorrar coste. Los críticos sostienen que, si un asistente nunca responde, es fácil que sea “seguro” pero inútil.
  • Casi todas las entradas eran maliciosas, a diferencia de las bandejas de entrada reales, donde predominan los correos legítimos. Esto permite que el modelo trate todo el canal como hostil.
  • Solo se probó de forma significativa la exfiltración directa, en banda, vía correo; los canales indirectos (herramientas, solicitudes web, sistema de archivos, otra exfiltración por red) estuvieron en gran medida ausentes.
  • El procesamiento por lotes temprano contaminó el comportamiento; las ejecuciones posteriores usaron un contexto nuevo por correo, lo que algunos sintieron que empujaba al modelo a un modo de “paranoia” poco realista.

Interpretación de seguridad y limitaciones

  • Los comentaristas subrayaron que 0 fallos en 6k intentos aleatorios no acota la tasa de éxito de ataques en el peor caso; los modelos estocásticos con una tasa baja de fallos aún pueden mostrar ningún fallo en muestras pequeñas.
  • La conclusión de “estar menos preocupados por la inyección de prompts” fue ampliamente cuestionada; la gente enfatizó el riesgo en la cola, métodos de jailbreaking de primera categoría aún desconocidos y ataques de confusión de roles.
  • Varios señalaron que es poco probable que los atacantes con buenos jailbreaks los quemen en un concurso público de bajo riesgo, especialmente con recompensas modestas.

Utilidad frente a seguridad

  • Varios comentarios argumentaron que la prueba no medía la compensación clave: distinguir instrucciones maliciosas de legítimas sin dejar de hacer trabajo útil.
  • La gente quería métricas sobre falsos positivos/falsos negativos y pruebas de que los flujos de trabajo normales basados en correo seguirían funcionando.

Coste, operaciones y privacidad

  • El coste (~$500) y el riesgo de “denegación de cartera” se mencionaron repetidamente; algunos sugirieron modelos más baratos o canales distintos.
  • El filtrado de spam de Google y la suspensión de la cuenta reforzaron que estos agentes deberían ejecutarse en cuentas desechables.
  • Publicar direcciones de correo parcialmente redactadas en el registro de ataques planteó preocupaciones de privacidad y ética.

Sugerencias para mejores seguimientos

  • Reproducir el mismo corpus en varios modelos (incluidos los más pequeños/locales) y publicar resultados comparativos.
  • Permitir que el agente actúe y responda de verdad, conectar herramientas/acceso web reales, mezclar correos benignos y maliciosos, y probar ataques de horizonte más largo y de varios pasos.