So verhindern Sie, dass Cursor Ihre Datenbank löscht
Eine Eingabe. Ein kleiner Backend-Fehler. Sie schauen kurz weg — und der Agent führt supabase db reset aus.
Lokale Datenbank weg. Seed-Daten weg. Die Migration, an der Sie gerade arbeiteten — weg.
Das ist kein Cursor-Bug. Das passiert, wenn Sie einem Agenten ein Terminal geben und erwarten, dass eine Textdatei ihn aufhält.
TL;DR — .cursorrules retten Sie nicht. Regeln sind Vorschläge, und eine Regel mit « erst fragen » ist eine Regel, die erlaubt. Drei harte Stopps stattdessen: eine Regel ohne Ausnahme, Terminal-Bestätigung in Cursor aktiviert und ein Shell-Block, der den Befehl verweigert — unabhängig davon, was das Modell entscheidet. Die echte Mauer sind Datenbankberechtigungen.
Warum .cursorrules nicht reichen
Das ist die Regel, die die meisten schreiben:
Immer eine ausdrückliche Bestätigung einholen, bevor destruktive Datenbankbefehle ausgeführt werden.
Lesen Sie sie so, wie ein Modell sie liest. Sie haben den Befehl nicht verboten. Sie haben eine Bedingung daran geknüpft.
Eine Bedingung ist eine Tür.
Der Agent schreibt den Befehl in den Terminal-Block und fragt Sie im selben Atemzug. Sie klicken auf Akzeptieren und glauben, die Frage zu beantworten. Es war beides.
Dann das Anreizproblem. Das Modell optimiert auf eine Sache: den Fehler loswerden. Unordentliches Schema, Migration läuft nicht — Reset ist der kürzeste Weg zu Grün. Ihre Seed-Daten stehen nicht in der Zielfunktion.
1. Die Bedingung aus der Regel entfernen
Wenn Text Ihre erste Grenze ist, machen Sie ihn absolut. Kein « ausser wenn ». Kein « erst fragen ».
# Database safety
- NEVER generate, write, or suggest `supabase db reset` or `supabase db drop`.
- No exceptions. Do not ask for confirmation. Refuse to write the command. Das ist immer noch keine Garantie. Es ist eine Regel, die das Modell nicht durch Auslegung umgehen kann — und das ist schon etwas anderes.
2. Auto-Run abschalten
Der Cursor-Agent kann Terminalbefehle selbst ausführen, um Fixes zu testen. Praktisch — bis es das nicht mehr ist.
Einstellungen → Features → Terminal (oder unter Composer, je nach Version). Bestätigung vor Terminalbefehlen verlangen. So lassen.
Sie klicken mehr. Das ist der Kompromiss.
3. Im Shell blockieren
Die einzige Regel, die ein Agent nicht neu interpretieren kann, ist die, die er nie liest. Packen Sie sie in die Shell.
supabase() {
if [[ "$1" == "db" && "$2" == "reset" ]]; then
echo "❌ BLOCKED: supabase db reset is disabled."
return 1
fi
command supabase "$@"
} source ~/.zshrc — und der Befehl stirbt, bevor er Supabase erreicht, egal was das Modell geschrieben hat.
Ein Hinweis, weil er zählt. Das gilt nur für Shells, die Ihre ~/.zshrc lesen. Das integrierte Cursor-Terminal tut das meist. Ein vom Agenten gestarteter Subprozess oder ein direkter sh-Aufruf vielleicht nicht. Spiegeln Sie den Schutz in ~/.bashrc und behandeln Sie ihn als Bremse, nicht als Mauer.
Die Mauer steht in der Datenbank
Shell-Tricks stoppen den Unfall, den Sie sich vorstellen können. Berechtigungen stoppen die, die Sie nicht können.
Das Konto Ihrer lokalen Umgebung sollte kein DROP dürfen. Produktions-Zugangsdaten sollten gar nicht auf Ihrem Rechner liegen. Backups sollten nach Plan laufen, nicht nach Ihrem Gedächtnis.
Stimmt das, spielt es keine Rolle mehr, was der Agent getippt hat.
Dieselbe Reihenfolge gilt für jede KI-Automatisierung , die es wert ist, in Produktion zu gehen. Erst die Einschränkungen. Dann die Geschwindigkeit. Überspringen Sie den ersten Teil, und Sie haben nichts automatisiert — Sie haben das Risiko nur dorthin verlagert, wo Sie es nicht sehen.
Bereit, den Agenten laufen zu lassen?
Zero Trust heisst nicht, dem Modell zu misstrauen. Es heisst, ihm nicht vertrauen zu müssen. Text sagt dem Agenten, was Sie vorziehen würden. Berechtigungen entscheiden, was möglich ist. Bauen Sie für das Zweite — dann müssen Sie nicht mehr jeden Terminal-Block mit dem Finger auf Escape lesen.
👉 Sie wollen dieselben Schutzmechanismen für die Automatisierungen, die Sie in Produktion betreiben? Kontakt aufnehmen