Verifica la ruta de un agente hacia la borración de una base de datos Prisma/Supabase

La borración comienza con un destino equivocado, no con un modelo defectuoso

Una sesión de agente puede comenzar con una migración de rutina y terminar con una base de datos de producción vacía. Durante una sesión de agente a finales de julio de 2026, se encontró una base de datos de producción de Supabase con todas las tablas vacías aproximadamente diez minutos después de que comenzó la sesión. La base de datos tenía 22 tablas, y el incidente vació todas ellas, incluidas 130 registros de herramientas y 21 registros de comparación. BlogPost y ApiKey desaparecieron del esquema porque la carpeta de migraciones local no contenía ningún registro de ellas. El modelo no necesitó ser ingenioso, y el comando no necesitó parecer malicioso. El fallo provenía del destino al que la migración estaba autorizada a llegar.

La base de datos sombra se convierte en la de producción cuando la URL es incorrecta

Prisma restablece su base de datos sombra antes de cada ejecución, y ese restablecimiento ocurre sin ningún mensaje de confirmación. En este caso, el valor de DATABASE_URL_UNPOOLED utilizado para --shadow-database-url apuntaba a la base de datos de producción. Una base de datos sombra debería ser un destino descartable. Cuando la URL apunta a producción, el destino descartable son los datos que no puedes permitirte perder. El comando aún puede leerse como un cambio de esquema ordinario, porque la parte peligrosa es la cadena de conexión detrás de él.

El entorno decide si una migración es inofensiva o fatal. El shell, las variables exportadas y la URL de la base de datos importan más que la intención del agente. Si el agente puede leer una cadena de conexión activa, una configuración segura es solo una configuración.

Ejecuta la verificación previa de cinco puntos antes de que el agente toque las migraciones

• Configura shadowDatabaseUrl en schema.prisma; un proyecto de Prisma puede definirla allí, eliminando la necesidad de pasar la URL de la base de datos sombra en cada línea de comandos. Está hecho cuando la línea de comandos ya no lleva una URL de sombra que pueda copiarse del entorno equivocado.
• Elimina las credenciales de producción del shell del agente. El shell está limpio cuando el agente solo puede alcanzar una base de datos no productiva, y la cadena de conexión de producción está ausente del shell en el que se ejecuta.
• Controla los comandos de migración destructivos detrás de un humano; Prisma 6.15 bloquea los comandos más destructivos cuando detecta un agente, a menos que un humano dé consentimiento explícito. El agente debe poder proponer una migración destructiva, pero no ejecutarla solo.
• Verifica que la carpeta de migraciones coincida con el esquema en vivo, para que una tabla no se trate como ausente. La carpeta es confiable cuando cada tabla en producción tiene un registro de migración correspondiente, y ninguna tabla existe solo en la base de datos.
• Ejecuta una comparación en seco (dry-run) contra una base de datos no productiva, y confirma que la URL de sombra apunta a ese mismo destino seguro. La comparación es segura cuando informa cambios sin tocar los datos de producción.

Haz que el acceso a la base de datos del agente sea lo suficientemente aburrido como para sobrevivir a un mal día

El acceso a la base de datos del agente debería ser aburrido. El agente obtiene un rol no productivo y sin acceso a la cadena de conexión en vivo. Puede inspeccionar el esquema, proponer una migración y mostrar la comparación. No debería tener acceso a la base de datos en vivo.

Revisa el shell que usará el agente antes de que comience. Un shell limpio no tiene URL de producción ni archivo de entorno que exporte una. Si encuentras una cadena de conexión en vivo, sácala del entorno del agente y reemplázala con un valor no productivo. La prueba es simple: el agente puede iniciar una sesión sin ver la base de datos en vivo.

Una comparación en seco (dry-run) es la prueba más simple que puedes ejecutar. Pide a la herramienta de migración que compare el esquema actual con el esquema objetivo y muestre qué cambiaría. Aprobas cuando puedes leer la comparación y decir, en palabras simples, qué se creará, alterará o eliminará.

La carpeta de migraciones es el registro. Si el registro le falta una tabla, la herramienta de migración puede asumir que la tabla no debería existir. Un registro de migración ausente puede hacer que una tabla en vivo parezca que debería eliminarse. Antes de que el agente ejecute algo, compara la carpeta con el esquema en vivo y corrige la brecha.

Después de la verificación previa, el agente debería tener una tarea estrecha. Cuando se necesita un comando destructivo, el humano lo ejecuta, o el humano aprueba un comando específico, y el agente continúa. Si el agente no puede alcanzar producción, la migración se ejecuta contra la base de datos no productiva, y los datos en vivo permanecen sin cambios.