So verhindern Sie, dass Cursor Ihre Datenbank löscht

Das Szenario ist bekannt: ein Prompt, ein harmloser Backend-Fehler, und Sie schauen drei Minuten weg. In der Zwischenzeit entscheidet der Agent, dass der kürzeste Weg zu einem grünen Test ein Neustart mit leerer Datenbank ist. Also führt er im integrierten Terminal supabase db reset aus.

Das Ergebnis: lokale Datenbank gelöscht, Testdaten weg. Die Migration, an der Sie gerade schrieben, gleich mit, und nichts im Gesprächsverlauf hatte Sie gewarnt. Bei einem Kundenprojekt wird der halbe Tag, den Sie gerade verloren haben, trotzdem verrechnet.

Das ist kein Fehler von Cursor. Es passiert einfach, wenn man einem Agenten ein Terminal gibt und darauf zählt, dass eine Textdatei ihn zurückhält. Text ist kein Sicherheitsmechanismus, sondern ein höflich formulierter Wunsch.

Warum eine einfache .cursorrules-Datei Sie nicht schützt

Der erste Reflex nach einem Unfall ist, eine Regel in .cursorrules zu schreiben, die Anweisungsdatei, die der Agent bei jedem Durchgang neu liest. Meist steht dann etwas wie:

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

Das wirkt solide. Es steht sogar am richtigen Ort. Trotzdem ändert es nichts, denn dieser Satz beschreibt ein Verfahren, statt ein Verbot auszusprechen.

Die Illusion der bedingten Regel

Lesen Sie diesen Satz so, wie ihn ein Sprachmodell liest. Sie haben den Befehl nicht verboten, Sie haben ihm eine Bedingung angehängt. Und eine Bedingung ist eine Tür: Sie zeigt, wie man hindurchkommt, nicht, dass man draussen bleiben muss.

Der Agent schreibt den Befehl also in einen Terminal-Block und stellt Ihnen im selben Atemzug die Frage. Sie klicken auf «Akzeptieren» und glauben, die Frage zu beantworten, während der Button gleichzeitig den Befehl ausführt. Die Regel wurde buchstabengetreu befolgt, und die Datenbank ist trotzdem weg.

Die Optimierungslogik des Modells

Dazu kommt ein tiefer liegendes Anreizproblem. Das Modell optimiert auf genau eine Sache: den Fehler verschwinden zu lassen, der es gerade beschäftigt. Bei einem inkonsistenten Schema oder einer Migration, die sich nicht anwenden lässt, ist ein Reset objektiv der kürzeste Weg zurück zu «Grün».

Ihre Testdaten kommen in dieser Rechnung nicht vor. Sie haben für das Modell keinen Wert, weil es nicht wissen kann, wofür sie stehen. Das ist keine Nachlässigkeit, sondern fehlende Information, und fehlende Information behebt man nicht mit einem strengeren Satz.

Deshalb passiert der Unfall auch fast immer lokal. Niemand gibt einem Agenten Zugangsdaten für die Produktion, aber alle lassen ihn auf einer lokalen Datenbank arbeiten, die nirgends gesichert ist. Paradoxerweise ist ausgerechnet die am wenigsten geschützte Umgebung die verwundbarste.

1. Setzen Sie in Ihren Regeln auf absolute Verbote

Wenn Text Ihre erste Verteidigungslinie bleibt, machen Sie aus Ihren Anweisungen echte Verbote. Vergessen Sie «ausser wenn» und «frag zuerst».

Die strikte negative Vorgabe

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

Der Unterschied ist subtil, aber er zählt: Es gibt kein erlaubtes Verhalten mehr, über das sich verhandeln liesse, also auch nichts mehr zu interpretieren. Eine Garantie ist das immer noch nicht, und das will ich auch nicht behaupten. Aber es ist eine Regel, um die das Modell nicht mehr herumargumentieren kann, und das ist schon mehr als ein Wunsch.

2. Sperren Sie die automatische Ausführung im Terminal

Der Agent von Cursor kann Befehle selbst ausführen, um seine Korrekturen zu prüfen. Das macht das Werkzeug angenehm flüssig, aber genau das verwandelt einen Vorschlag in eine unumkehrbare Aktion.

Die obligatorische manuelle Freigabe

Gehen Sie zu Settings > Features > Terminal (der genaue Ort kann je nach Version variieren) und aktivieren Sie die obligatorische Bestätigung vor jeder Ausführung. Lassen Sie diese Einstellung aktiv, auch an Tagen, an denen sie Sie bremst, denn genau dann, wenn man die Deckung fallen lässt, passiert der Unfall.

Dem Agenten nimmt das nichts von seinem Nutzen. Er liest weiterhin Ihre Dateien und schlägt Befehle vor und erspart Ihnen damit mühsames Suchen in der Dokumentation. Er verliert nur die Fähigkeit, zu handeln, während Sie woanders hinschauen, und genau das wollten Sie ihm nehmen.

Der Preis ist real: Sie klicken öfter. Das ist der Tausch, den Sie eingehen. Bei einem Wegwerfprojekt lohnt er sich vielleicht nicht; bei einem Kundenprojekt immer.

3. Fangen Sie kritische Befehle auf Shell-Ebene ab

Die einzige Regel, die ein Agent nicht uminterpretieren kann, ist eine, die er gar nie zu lesen bekommt. Verlegen Sie die Vorgabe also aus dem Modell hinaus, direkt in die Umgebung, die die Befehle tatsächlich ausführt.

Ein Zsh-Wrapper, der den Befehl blockiert

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, laden Sie sie mit source ~/.zshrc neu, und der Befehl wird gestoppt, bevor er Supabase überhaupt erreicht.

Ein Hinweis: Dieser Schutz gilt nur für Shells, die Ihre ~/.zshrc lesen. Das integrierte Terminal von Cursor tut das in der Regel, ein Unterprozess oder ein Skript, das direkt sh aufruft, könnte aber daran vorbeikommen. Legen Sie dieselbe Sperre auch in ~/.bashrc an und betrachten Sie das Ganze als wirksame Bremsschwelle, nicht als unüberwindbare Mauer.

Die einzige echte Barriere: die Berechtigungen

Shell-Tricks verhindern die Unfälle, die Sie vorhergesehen haben. Berechtigungen verhindern die, an die Sie nicht gedacht haben, und genau die tun immer weh.

Destruktive Rechte lokal entziehen

Das Konto, mit dem sich Ihre lokale Umgebung verbindet, hat keinen Grund, ein DROP ausführen zu dürfen. Ebenso haben Zugangsdaten für die Produktion auf Ihrem Entwicklungsrechner nichts verloren, auch nicht in einer .env-Datei, die nur Sie öffnen.

Backups müssen nach Zeitplan laufen, nicht nach Ihrem Gedächtnis. Eine Entwicklungsdatenbank, die sich mit einem Befehl aus einer versionierten Seed-Datei neu aufbauen lässt, ist kein Verlust mehr, sondern eine Minute Arbeit. Solange Ihre Testdaten nur auf Ihrem Rechner existieren, bleiben sie Ihr Schwachpunkt.

Setzen Sie diese drei Ebenen um, und was der Agent tippt, wird zweitrangig. Das ist dieselbe Logik hinter jeder ernsthaften KI-Automatisierung : zuerst die Vorgaben, dann das Tempo. Wer den ersten Schritt überspringt, hat nichts automatisiert, sondern das Risiko nur dorthin verschoben, wo man es nicht mehr sieht.

Bereit, Ihre Umgebung abzusichern, bevor der Agent loslegt?

«Zero Trust» heisst nicht, dem Modell zu misstrauen, sondern sich so zu organisieren, dass man ihm nicht vertrauen muss. Text sagt dem Agenten, was Sie bevorzugen würden; Berechtigungen entscheiden, was möglich ist. Bauen Sie auf Letzteres, und Sie können endlich aufhören, jeden Terminal-Block mit dem Finger über der Escape-Taste zu lesen.

👉 Brauchen Sie dieselben Leitplanken für die Automatisierungen, die Sie produktiv einsetzen? Schreiben Sie mir