So verhindern Sie, dass Cursor Ihre Datenbank löscht

Ein Prompt, ein harmloser Backend-Fehler, und Sie schauen für drei Minuten weg. Der Agent entscheidet eigenständig, dass der schnellste Weg zu einem erfolgreichen Test eine leere Tabelle ist — und führt supabase db reset im integrierten Terminal aus.

Lokale Datenbank gelöscht. Testdaten verloren. Die Datenbankmigration, an der Sie gerade geschrieben haben, ist weg. Nichts im Chatverlauf hat Sie vorgewarnt. Bei einem Kundenprojekt war der verlorene halbe Arbeitstag bereits budgetiert.

Das ist kein Fehler in Cursor. Es passiert unweigerlich, wenn man einem Agenten ein Terminal überlässt und glaubt, eine Textdatei könne ihn aufhalten. Ein Textdokument ist kein Sicherheitsmechanismus, sondern lediglich eine höflich formulierte Bitte.

Warum Textregeln in .cursorrules keinen Agenten stoppen

Der erste Reflex nach einem solchen Vorfall ist das Ergänzen einer Regel in .cursorrules, jener Instruktionsdatei, die der Agent bei jeder Anfrage liest. Die Formulierung unterscheidet sich kaum von Projekt zu Projekt:

Always ask for explicit confirmation before running any destructive database commands.

Sie klingt solide. Sie steht am richtigen Ort in der Datei, die der Agent konsultiert. Dennoch ändert sie nichts am Ausgang, weil sie einen Ablauf beschreibt, anstatt ein striktes Verbot auszusprechen.

Die Illusion der bedingten Regel

Lesen Sie den Satz so, wie ein Sprachmodell ihn liest. Sie haben den Befehl nicht verboten; Sie haben ihn an eine Bedingung geknüpft. Eine Bedingung ist eine offene Tür: Sie zeigt dem Modell, wie es durchkommt, nicht, dass es draussen bleiben muss.

Der Agent schreibt den zerstörerischen Befehl in einen Terminalblock und stellt Ihnen gleichzeitig die Frage im Chat. Sie klicken auf Akzeptieren in der Annahme, die Frage zu beantworten — doch die Schaltfläche führt den Befehl sofort aus. Die Regel wurde formell eingehalten, und die Datenbank ist dennoch gelöscht.

Die Zielfunktion des Modells

Dahinter liegt ein fundamentales Problem der Anreize. Das Modell optimiert genau eine Variable: das Beseitigen der Fehlermeldung, die vor ihm liegt. Bei einem inkonsistenten Datenbankschema ist das Zurücksetzen objektiv der kürzeste Weg zu einem fehlerfreien Durchlauf.

Ihre lokalen Testdaten existieren in dieser Zielfunktion nicht. Sie haben für das Modell keinerlei Wert, weil ihm niemand vermittelt hat, was diese Daten bedeuten. Das ist keine böse Absicht, sondern ein Informationsdefizit — und ein Informationsdefizit lässt sich nicht durch nachdrücklichere Worte beheben.

Aus diesem Grund trifft der Unfall fast immer die lokale Entwicklungsumgebung. Niemand übergibt Produktionszugänge an einen Agenten, doch jeder lässt ihn auf einer lokalen Datenbank arbeiten, von der es oft kein aktuelles Backup gibt. Genau die Umgebung, die ihm offensteht, ist jene, die niemand absichert.

1. Streichen Sie bedingte Ausnahmen aus Ihren Cursor-Regeln

Wenn geschriebener Text Ihre erste Barriere bleibt, formulieren Sie ein absolutes Verbot. Kein «ausser wenn», kein «erst nachfragen», keinerlei Spielraum für Verfahrensschritte.

Die absolute negative Vorgabe

# Datenbanksicherheit
- NIEMALS `supabase db reset` oder `supabase db drop` generieren oder vorschlagen.
- Keine Ausnahmen. Nicht um Bestätigung bitten. Den Befehl schlicht verweigern.

Der Unterschied zur vorherigen Variante ist entscheidend: Es gibt keinen erlaubten Pfad mehr, über den verhandelt werden könnte. Das ist noch immer keine absolute Garantie, doch es ist eine Vorgabe, die das Modell nicht mehr uminterpretieren kann.

Halten Sie die Regel zudem kurz und stellen Sie sie an den Anfang der Datei. Eine Anweisung, die auf Zeile achtzig zwischen Stilvorgaben und Namenskonventionen steht, konkurriert mit allem anderen um die Aufmerksamkeit des Modells. Ein Verbot, das oben steht und nur eine Sache sagt, wird zuverlässiger befolgt als eines, das in einem Absatz über gute Praktiken versteckt ist.

2. Erzwingen Sie manuelle Freigaben für Terminalbefehle

Der Agent in Cursor kann Befehle selbstständig ausführen, um seine eigenen Korrekturen zu prüfen. Diese Funktion macht das Werkzeug komfortabel, verwandelt aber Vorschläge in unumkehrbare Handlungen.

Die manuelle Freigabepflicht

Öffnen Sie die Einstellungen, navigieren Sie zu Features und Terminal. Verlangen Sie eine manuelle Bestätigung vor jeder Befehlsausführung. Behalten Sie diese Einstellung bei, auch an Tagen, an denen sie den Arbeitsfluss bremst — denn genau an solchen Tagen passiert das Unglück.

Diese Hürde nimmt dem Agenten keineswegs seinen Nutzen. Er analysiert weiterhin Dateien, formuliert Befehle und erspart Ihnen das Nachschlagen in der Dokumentation. Er verliert lediglich die Möglichkeit zu handeln, während Sie wegschauen.

Der Preis dafür ist spürbar: Sie klicken häufiger, und der Komfort einer vollautomatischen Schleife entfällt. Das ist der Kompromiss, den Sie eingehen. Bei einem schnellen Wochenendexperiment mag man darauf verzichten; bei einem echten Kundenauftrag niemals.

Allowlist statt Denylist

Wer auf die automatische Ausführung nicht ganz verzichten will, beschränkt sie auf eine Liste erlaubter Befehle: Tests starten, den Linter laufen lassen, Dateien auflisten. Alles, was nicht auf dieser Liste steht, verlangt weiterhin Ihre Bestätigung. Für Routinearbeit ist das der vernünftige Mittelweg.

Der umgekehrte Weg, eine Liste verbotener Befehle, wirkt einfacher, hält aber nicht. Ein Eintrag für supabase db reset erfasst weder npx supabase db reset noch ein Skript, das den Befehl intern aufruft, noch ein psql mit DROP SCHEMA. Eine Sperrliste zählt nur die Wege auf, an die Sie gedacht haben; eine Erlaubnisliste schliesst alle anderen aus.

3. Blockieren Sie gefährliche Befehle direkt in der Shell

Die einzige Regel, die ein Agent nicht uminterpretieren kann, ist eine Regel, die er niemals zu Gesicht bekommt. Verlegen Sie die Schranke aus dem Modell in die Umgebung, die den Befehl physisch ausführt.

Der abfangende Zsh-Wrapper

supabase() {
  if [[ "$1" == "db" && "$2" == "reset" ]]; then
    echo "BLOCKIERT: supabase db reset ist deaktiviert."
    return 1
  fi
  command supabase "$@"
}

Fügen Sie diese Funktion in Ihre ~/.zshrc ein und laden Sie die Konfiguration mit source ~/.zshrc neu. Der Befehl bricht ab, bevor er Supabase erreicht — ganz gleich, wie der Agent ihn aufgerufen hat.

Ein technisches Detail bestimmt die Reichweite dieser Massnahme: Die Sperre greift nur in Shells, die Ihre rc-Dateien tatsächlich laden. Das integrierte Terminal von Cursor tut dies in der Regel, ein direkter Subprozess oder Skripte mit Aufruf über sh hingegen nicht. Hinterlegen Sie die Funktion auch in Ihrer ~/.bashrc und betrachten Sie den Wrapper als Bremsschwelle, nicht als Festung.

Strikte Berechtigungen sind die einzig unüberwindbare Wand

Shell-Tricks verhindern Fehler, die Sie vorhersehen können. Saubere Datenbankberechtigungen verhindern jene, an die Sie nicht gedacht haben — und genau diese richten den grössten Schaden an.

Destruktive Rechte lokaler Rollen entziehen

Das Benutzerkonto Ihrer lokalen Entwicklungsumgebung braucht keine Berechtigung für ein DROP. Produktionsdaten haben auf einem Entwicklungsrechner nichts verloren, auch nicht in einer lokalen .env-Datei. Backups müssen über automatisierte Zeitpläne laufen, nicht über Ihr Gedächtnis.

Eine lokale Datenbank, die sich mit einem einzigen Seed-Befehl aus dem Git-Repository rekonstruieren lässt, bedeutet im Ernstfall keinen Verlust, sondern eine Minute Wartezeit. Solange Ihre Testdaten nur lokal auf der Festplatte existieren, bleiben sie das schwächste Glied im gesamten System.

Vor jeder Agenten-Sitzung ein Snapshot

Die letzte Sicherung kostet Sekunden. Bevor Sie dem Agenten eine Aufgabe übergeben, die das Schema berührt, ziehen Sie mit pg_dump einen Abzug der lokalen Datenbank in einen Ordner ausserhalb des Projekts. Geht etwas schief, spielen Sie ihn zurück und haben statt eines halben Tages nur eine Kaffeepause verloren.

Machen Sie daraus eine Gewohnheit statt einer Entscheidung. Ein kurzes Skript, das den Abzug mit Datum im Dateinamen ablegt und ältere Abzüge nach einer Woche löscht, läuft vor jeder Sitzung, ohne dass Sie daran denken müssen. Auch hier gilt: Was vom Gedächtnis abhängt, fehlt genau an dem Tag, an dem es gebraucht wird.

Setzen Sie diese drei Punkte um, verliert das Verhalten des Agenten sein Risikopotenzial. Es ist dieselbe Reihenfolge wie bei jeder soliden KI-Automatisierung für den Produktivbetrieb: erst die Restriktionen, dann die Geschwindigkeit.

Bereit, den Agenten mit echten Leitplanken starten zu lassen?

Zero Trust bedeutet nicht, dem Modell zu misstrauen, sondern gar nicht erst auf Vertrauen angewiesen zu sein. Text sagt einem Agenten, was Sie bevorzugen würden; Berechtigungen bestimmen, was tatsächlich machbar ist. Bauen Sie auf Letzteres, und Sie müssen nicht mehr mit dem Finger auf der Escape-Taste sitzen.

👉 Möchten Sie dieselben Sicherheitsmechanismen für Ihre produktiven Automatisierungen aufbauen? Schreiben Sie mir