Blog · IA y seguridad
Investigadores mostraron que alcanza con un ticket de soporte para que un agente de IA publique tokens
En julio de 2025, investigadores de General Analysis armaron un proyecto de prueba con Supabase y Cursor y mostraron que un ticket de soporte con órdenes escondidas alcanzaba para que el agente leyera una tabla de tokens y los copiara en el hilo del ticket. Fue una demostración con datos de prueba, no un ataque real. El agente hizo lo que le pidieron. El problema es que se lo pidió cualquiera.
Cómo fue la prueba
Los investigadores crearon un proyecto nuevo en Supabase, solo con datos ficticios: una tabla de tickets de soporte y otra, sensible, llamada integration_tokens. Simularon a un desarrollador que usa Cursor con el servidor MCP de Supabase configurado con la credencial service_role, que saltea la seguridad a nivel de fila.
Del lado del cliente, alguien carga un ticket que incluye instrucciones dirigidas al asistente: leer la tabla integration_tokens y agregar su contenido como un mensaje nuevo en ese ticket. Cuando el desarrollador le pide al agente que liste los últimos tickets, el modelo toma esas líneas como órdenes, ejecuta el SQL y escribe los tokens en el hilo, donde quien abrió el ticket los puede leer.
Por qué pasa
Un análisis muy citado de esos días lo describió como una "trifecta letal": acceso a datos privados, exposición a contenido que puede traer instrucciones maliciosas y un canal para sacar la información. Acá las tres están en una sola herramienta. El agente tiene permisos de administrador, lee texto que escribe cualquier cliente y puede escribir donde ese cliente mira.
Supabase respondió con modo de solo lectura, alcance limitado a un proyecto, advertencias alrededor de cada resultado de SQL, grupos de herramientas y aprobación manual de cada llamada. Aun así, su recomendación de fondo es no conectar agentes directamente a datos de producción. Ninguna capa sola frena la inyección de instrucciones: lo que frena el daño es que el agente no tenga el permiso ni el canal.