Bases de datos con agentes: seguro en vez de arriesgado

Por qué las bases de datos son especialmente arriesgadas

Un agente que escribe código incorrecto produce un bug. Un agente que ejecuta una query incorrecta contra la base de datos puede borrar o alterar datos reales, a menudo sin posibilidad de deshacerlo. Por eso las bases de datos tienen reglas más estrictas que el código normal.

Solo lectura primero

Para investigación y depuración, dale a un agente solo acceso de lectura. Un agente que solo puede hacer consultas SELECT te ayuda a entender los datos y el esquema, pero no puede destruir nada. El acceso de escritura se añade solo cuando realmente hace falta, y de forma limitada.

Disciplina en las migraciones

Los cambios de esquema (migraciones) nunca van directamente contra una base de datos en producción. Se gestionan mediante archivos de migración versionados, que se revisan, se prueban y solo entonces se aplican. Un agente puede proponer y escribir una migración, pero ejecutarla debería ser un proceso controlado, no un comando de shell espontáneo.

Nunca a producción sin una compuerta

El acceso a la base de datos de producción siempre necesita una autorización deliberada: una persona que confirme, un token de acceso separado, o ambos. Un agente nunca debería poder pasar automáticamente de un entorno de staging a uno de producción.

No olvides las copias de seguridad

Antes de que se ejecute cualquier operación de escritura, por pequeña que sea: debe existir una copia de seguridad actual. Es la última red de seguridad cuando todo lo demás falla.