Datenbanken mit Agenten: sicher statt riskant

Warum Datenbanken besonders riskant sind

Ein Agent, der Code falsch schreibt, produziert einen Bug. Ein Agent, der eine falsche Datenbank-Query ausführt, kann echte Daten löschen oder verändern – oft ohne Möglichkeit, das rückgängig zu machen. Deshalb gelten für Datenbanken strengere Regeln als für normalen Code.

Read-only zuerst

Gib einem Agenten für Recherche und Debugging nur Lesezugriff. Ein Agent, der nur SELECT-Abfragen stellen kann, hilft dir beim Verstehen von Daten und Schema, kann aber nichts zerstören. Schreibzugriff kommt erst dazu, wenn es wirklich nötig ist – und dann eingeschränkt.

Migrations-Disziplin

Schema-Änderungen (Migrationen) gehören nie direkt in eine laufende Datenbank. Sie laufen über versionierte Migrations-Dateien, die geprüft, getestet und erst dann angewendet werden. Ein Agent kann eine Migration vorschlagen und schreiben – ausführen sollte sie ein kontrollierter Prozess, kein spontaner Bash-Befehl.

Nie Prod ohne Gate

Zugriff auf die Produktions-Datenbank braucht immer eine bewusste Freigabe: ein Mensch, der bestätigt, ein separates Zugangs-Token, oder beides. Ein Agent sollte nie automatisch von einer Staging- auf eine Produktionsumgebung wechseln können.

Backups nicht vergessen

Bevor irgendeine Schreiboperation läuft, egal wie klein: ein aktuelles Backup muss existieren. Das ist die letzte Sicherung, wenn alles andere versagt.