Bevor du der KI die Schlüssel gibst: 5 Sicherheitsregeln, die Einsteiger vor Unfällen bewahren

„Räum dieses Projekt mal grob auf.“

Das tippte ich leichten Herzens ein und ging Kaffee machen. Als ich zurückkam, stand das Terminal einen Schritt davor, rm -rf auszuführen. Mein Finger war unbewusst schon auf dem Weg zum Freigabe-Knopf.

Hätte ich in dem Moment auf „Ja“ gedrückt, wären .env und Konfigurationsdateien zusammen weg gewesen.

Claude Code ist klug. Aber Klugheit und Sicherheit sind zwei völlig verschiedene Dinge. Im Gegenteil: Gerade weil es klug ist und schnell die Hand hebt, rennt es auch in die falsche Richtung mit voller Kraft. Genau wie ein gut schneidendes Messer: Je schärfer es ist, desto eher verletzt du dich, bevor du den Umgang gelernt hast.

Dieser Artikel beschränkt sich nur auf die Sicherheitsregeln, die Einsteiger zuerst beherrschen sollten. Schwieriges kommt später. Die fünf, die du zuerst einhältst, schreibe ich verständlich auf – zusammen mit meinen eigenen Patzern.

Was ist überhaupt so gefährlich daran?

Ein normaler Texteditor zeigt nur Zeichen an. Aber Claude Code ist anders. Es ist ein Werkzeug, das in deinem Computer Folgendes „einfach tun kann“:

Dateien lesen, schreiben, löschen
Terminal-Befehle ausführen (rm geht auch)
ins Netz gehen und bei externen Diensten posten

Und das alles läuft, sobald du „Ja“ freigibst. Das Problem: Während du den Freigabe-Knopf dutzende Male drückst, schaust du irgendwann nicht mehr auf den Inhalt. In dem Moment, in dem du im „Jaja, OK“-Rhythmus bist, rutscht eine gefährliche Operation glatt durch.

Sicherheit ist deshalb keine Frage des Aufpassens. Es geht darum, vorher einen Mechanismus zu bauen, der ohne Aufpassen keinen Unfall zulässt. Sehen wir es uns der Reihe nach an.

Hier läuft es einem kalt den Rücken runter (drei)

Drei „gefährliche Situationen“, in die Einsteiger gern geraten. Nichts Besonderes ist dabei.

Situation 1: Du willst einen Fehler beheben lassen und klebst das ganze Log rein

Wenn du „Behebe diesen Fehler“ bittest, kopierst du die Zeichen aus dem Terminal komplett, oder? Aber in diesem Log steckt manchmal eine Zeile wie DATABASE_URL=postgresql://user:echtes_passwort@.... Gemeint hattest du, es der KI zu geben – tatsächlich bleibt im Gesprächsverlauf und im Log das rohe Passwort liegen.

Situation 2: Du lässt es im „Mach-alles-allein“-Modus laufen

Die Freigabe nervt, also stellst du den Modus auf „alles ohne Rückfrage ausführbar“ und stehst auf. Die KI tippt in bester Absicht git push --force, und die Arbeit von jemandem im Team ist weggefegt. Null böse Absicht. Aber das Ergebnis ist das schlimmstmögliche.

Situation 3: Du verwechselst ähnlich benannte Datenbanken

myapp_dev und myapp_prod. Ein Zeichen Unterschied. Bittest du nur „Lösch die alten Daten in der DB“ und die KI prüft nicht, mit welcher sie verbunden ist – dann sind es vielleicht die echten Kundendaten in der Produktion, die verschwinden.

Allen dreien gemeinsam: In dem Moment, in dem ein Mensch „unachtsam“ ist, führt die KI mit voller Kraft aus. Also sorgst du dafür, dass es auch bei Unachtsamkeit nichts macht. Das ist die Maßnahme.

Drei Fehler, die ich selbst gebaut habe

Ich schreibe großspurig, aber auch ich war anfangs voller Unfälle. Ich beichte ehrlich drei.

Der erste. Als ich das automatische Posten zu Qiita baute, klebte ich den Token direkt in den Prompt. „Poste mit QIITA_TOKEN=xxxx.“ Es lief, also war ich zufrieden – aber später dämmerte es mir. Diese Zeichenkette bleibt im Gesprächsverlauf liegen, und auch im Verlauf der kleinen KI, die im Hintergrund läuft (Subagent). Hektisch erstellte ich den Token neu. Heute denke ich daran und mir bricht der Schweiß aus.

Der zweite. Für eine Untersuchung bat ich „Sieh dir den Inhalt von .env an“. Die KI las brav alles vor. API-Schlüssel und das DB-Passwort, alles auf den Bildschirm und ins Log. In dem Moment, in dem du es lesen lässt, ist es schon „geleakt“. .env öffne sogar ich als Mensch im Alltag nicht.

Der dritte. Ich kopierte die lockeren Einstellungen eines Hobbyprojekts ins Arbeits-Repository. Ergebnis: Das „Schreiben in die Produktion verbieten“, das auf der Arbeitsseite sein sollte, war mit der Hobby-Lockerheit überschrieben. Ich merkte es vor dem Unfall, aber das Wiederverwenden von Einstellungen ist wirklich gefährlich.

Bei allen lag es weniger an fehlendem Wissen als daran, dass ich es nicht per Mechanismus gestoppt hatte. Ab hier der Kern.

Diese fünf hältst du ein. Geh sie der Reihe nach durch

Maßnahme 1: API-Schlüssel gehören „außerhalb des Codes“

Das Wichtigste. API-Schlüssel und Token schreibst du niemals direkt in Code oder Prompt. Du isolierst sie in einer eigenen Datei namens .env und nimmst diese aus der Git-Verwaltung. Allein das verhindert den Großteil der Lecks.

Zuerst das Beispiel, was man nicht tun darf.

// NEIN: direkt in den Quellcode geschrieben (committet = sofort verloren)
const client = new Anthropic({ apiKey: "echten API-Schlüssel direkt einkleben" });

// NEIN: in den Prompt gemischt
// "Poste mit QIITA_TOKEN=echter_token" ← genau mein Patzer

Richtig: Du sammelst die Schlüssel in einer Datei namens .env.

# .env (diese Datei kommt nicht zu Git. Sie liegt nur auf deinem eigenen PC)
ANTHROPIC_API_KEY=hier der echte Wert
QIITA_TOKEN=hier der echte Wert
DATABASE_URL=postgresql://...

Und dann erklärst du diese .env für „Git hebt das auf gar keinen Fall auf“. Das ist das Sicherungsseil.

# Unbedingt in .gitignore schreiben (Versicherung gegen versehentliches Committen der Schlüssel)
.env
.env.*
!.env.example   # nur das Muster darf geteilt werden
*.pem
*.key
*-service-account.json   # auch den Service-Account-Schlüssel der Cloud nicht vergessen

Willst du dem Team nur mitteilen, „welche Schlüssel nötig sind“, legst du ein Muster mit leeren Werten hin.

# .env.example (das darf zu Git. Inhalt ist leer)
ANTHROPIC_API_KEY=
QIITA_TOKEN=
DATABASE_URL=

Aus dem Code lädst du die Werte nicht direkt, sondern als „Umgebungsvariablen“. Das echte Exemplar des Schlüssels taucht im Code nirgends auf.

// OK: aus Umgebungsvariablen lesen. Der Wert steht nirgends im Code
import { config } from "dotenv";
config();

const token = process.env.QIITA_TOKEN;
if (!token) {
  // Fehlt der Schlüssel, gib nicht den Wert, sondern nur "du hast vergessen, ihn zu setzen"
  throw new Error("QIITA_TOKEN ist nicht gesetzt. Prüfe deine .env.");
}

Der Punkt ist einer. Das echte Exemplar des Schlüssels darf nur in .env berührt werden. Code, Prompt und Log kennen alle nur den „Namen“ des Schlüssels. Das ist das A und O.

Maßnahme 2: Gefährliche Befehle nicht „automatisch freigeben“

Als Nächstes irreversible Befehle wie rm -rf (alles löschen) oder git push --force (die Arbeit des Teams überschreiben). Die stellst du auf „vor der Ausführung immer den Menschen fragen“ oder „grundsätzlich nicht ausführbar“.

Claude Code hat einen Mechanismus, mit dem du pro Befehl „OK / Rückfrage / verboten“ festlegst. In .claude/settings.json schreibst du das so.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(curl * | bash)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)"
    ]
  }
}

Das Lesen ist simpel. Du verteilst nur auf drei Kästen.

Kasten	Bedeutung	Was hineinkommt
`allow`	ohne Rückfrage OK	nur lesende, sichere Operationen
`ask`	jedes Mal ordentlich fragen	Schreiben, Commit, Push
`deny`	gar nicht zulassen	Löschen, Force-Push, Produktions-DB

Im Zweifel merk dir: Nur Lesen ist allow, Schreiben ist ask, Löschen ist deny. Anfangs zurrst du es knallhart zu, und nur die Operationen, von denen du erkannt hast „ah, das ist sicher“, stufst du später auf ask oder allow hoch. Die Gegenrichtung (anfangs locker, später zuziehen) kommt erst nach dem Unfall, also fängst du unbedingt aus der Richtung des Zuziehens an.

Maßnahme 3: Den „Bereich“ von Lesen und Schreiben eng ziehen

Sieh dir das deny aus Maßnahme 2 genau an. Ganz vorne stehen solche Zeilen.

"deny": [
  "Read(./.env)",
  "Read(./.env.*)",
  "Read(./secrets/**)"
]

Das ist die Einstellung „.env und der Ordner secrets dürfen nicht einmal gelesen werden“. Mein Patzer „.env lesen lassen“ wäre mit dieser einen Zeile nie passiert. Selbst wenn du „Sieh es dir an“ bittest, wird es an der Tür abgewiesen.

Den Bereich eng ziehen heißt: vorher eine Linie ziehen zwischen Orten, die man zeigen darf, und Orten, die man nicht zeigen darf. Der Ordner mit den Schlüsseln, die Produktionskonfiguration, die Kundendaten. Machst du die von vornherein „gar nicht anfassbar“, ist es selbst bei einer unachtsamen Bitte sicher.

Zusätzlich schreibst du die Dateien, die auf gar keinen Fall bearbeitet werden sollen, auch in die Projektregeln (CLAUDE.md) auf Deutsch – das beruhigt.

## Nicht zu bearbeitende Dateien (in CLAUDE.md schreiben)

Folgende auf keinen Fall bearbeiten. Wenn nötig, immer bei mir (dem Menschen) rückfragen.
- .env (enthält Schlüssel und Passwörter)
- wrangler.toml (Veröffentlichungs-Einstellung der Produktion)
- .github/workflows/*.yml (Einstellung des automatischen Deployments)

Per Konfigurationsdatei maschinell blocken und per Regeltext der KI auch die Absicht mitteilen. Mit diesem zweistufigen Aufbau sinken die Lücken.

Maßnahme 4: Geheimes nicht ins Log ausgeben

Das ist weniger eine Einstellung als eine kleine Schreib-Angewohnheit. Wenn du eine Fehlermeldung schreibst, gib den „Wert“ des Schlüssels nicht mit aus.

// NEIN: der API-Schlüssel landet so im Fehlerlog
throw new Error(`Auth fehlgeschlagen: token=${process.env.TOKEN}`);

// OK: den Wert nicht ausgeben, nur sagen, wo man hinschauen soll
throw new Error("Auth fehlgeschlagen: prüfe die Umgebungsvariable TOKEN");

Nur eine Zeile Unterschied, aber bei der oberen leakt der Schlüssel in dem Moment, in dem du das Log jemandem zeigst.

Und noch etwas. Wenn du der KI ein Log gibst, klebst du es nicht roh hinein. Bei Zeilen mit Schlüsseln oder Passwörtern ersetzt du den Wert durch Sternchen, bevor du es übergibst.

# So umschreiben, dann übergeben. Die KI muss nur die Struktur "hier sind DB-Zugangsdaten" verstehen
DATABASE_URL=***maskiert***
QIITA_TOKEN=***maskiert***

„Was man geben darf“ und „was nicht“ grob in eine Tabelle. Klebst du die in CLAUDE.md, fällt dir bei jeder Bitte das Kriterium wieder ein.

Geben OK	Geben verboten
Fehlerart, Reproduktionsschritte, Dateiname	API-Schlüssel, Passwörter, Session-Cookies
`.env.example`, die „Namen“ der Einstellungspunkte	URL der Produktions-DB, Kundendaten
das mit Sternchen ersetzte Log	echte Token, die .json-Datei des Service-Accounts

Maßnahme 5: Die Produktion „gesondert behandeln“

Zum Schluss. Übung (Entwicklung) und Produktion trennst du klar. Um die Verwechslung von myapp_dev und myapp_prod zu verhindern, wirkt es, dem Schreiben in die Produktion einen zusätzlichen Handgriff abzuverlangen.

// scripts/db-query.mjs
const env = process.env.NODE_ENV ?? "development";

// Will jemand in die Produktion schreiben, stoppe es, sofern kein eigenes Flag da ist
if (env === "production" && process.argv.includes("--write")) {
  console.error("Zum Schreiben in die Produktion ist das Flag --force-production nötig.");
  process.exit(1);
}

Das „versehentlich Produktion“ blockst du mit dem zusätzlichen Handgriff eines Flags physisch. Diese Umständlichkeit ist das Sicherungsseil. Produktionsdaten kommen nach dem Löschen nicht zurück.

Wenn du anfangen willst, dann hier (Schritte)

Du musst nicht alle fünf heute machen. Der Reihe nach bist du in 30 Minuten fertig.

Im Projekt eine .env anlegen und alle Schlüssel dorthin verschieben
.env in .gitignore eintragen (Maßnahme 1)
.claude/settings.json anlegen und in deny rm -rf und das Lesen von .env aufnehmen (Maßnahme 2 und 3)
Schreiben und Commit in ask aufnehmen (Maßnahme 2)
In CLAUDE.md die Tabelle „geben OK / verboten“ und die nicht zu bearbeitenden Dateien kleben (Maßnahme 4)

Allein die ersten drei Schritte stoppen den rm -rf-Unfall und das .env-Leck vom Anfang. Ziel nicht auf Perfektion, erst mal eines. Das ist schon genug Fortschritt.

Willst du die Rechte-Einstellung feiner ausarbeiten, schau in den Leitfaden zu Claude-Code-Berechtigungen; willst du die ungeschönten Geschichten echter Unfälle, lies die Fälle von Sicherheitsfehlern bei Claude Code. Für die genaue Spezifikation der Einstellungen ist immer die offizielle Dokumentation am besten.

Was beim Ausprobieren herauskam

Seit dem rm -rf-Schreckmoment am Anfang habe ich aufgehört, mich mit der Frage „Soll ich der KI vertrauen oder nicht“ herumzuschlagen. Worauf ich stattdessen schaue, ist: an welchem Türsteher es gestoppt hat.

Seit ich das Lesen von .env in deny aufgenommen habe, zieht sich die KI brav zurück, selbst wenn ich „Prüf die Umgebungsvariablen“ bitte. Dieses peinliche „alles vorlesen“ passiert kein zweites Mal.

Ehrlich, an dem Tag, an dem ich die Einstellungen schrieb, dachte ich „Ist das nicht übertrieben?“. Aber es war umgekehrt. Gerade weil es die Absicherung gibt, kann ich beruhigt nachlässig sein. Den Freigabe-Knopf kann ich leichten Herzens drücken, weil ich weiß, dass die gefährliche Operation vorher per deny gestoppt wird. Statt mich anzustrengen, die kluge KI zu meistern, leg ich zuerst einen Boden aus, auf dem ich mich beim Hinfallen nicht verletze. Das ist am bequemsten und am schnellsten – das ist mein heutiges Fazit.

Fazit

Was Einsteiger zuerst einhalten, sind allein diese fünf, und das reicht.

Was du einhältst	Wie
API-Schlüssel nicht leaken	in `.env` isolieren + `.gitignore`
Gefährliche Befehle nicht Amok laufen lassen	`rm -rf` / Force-Push in `deny`
Den Bereich von Lesen und Schreiben eng ziehen	`.env` und secrets in `deny`, Produktionsdateien bearbeiten verboten
Geheimes nicht ins Log ausgeben	Wert nicht ausgeben, mit Sternchen übergeben
Die Produktion gesondert behandeln	Schreiben in die Produktion per Flag blocken

Bei „Sicherheit“ verkrampft man, aber zu tun ist nur: „vorher einen Mechanismus bauen, in dem kein Unfall passiert“. Einmal eingebaut, beschützt er dich, auch wenn du ihn danach in Ruhe lässt. Heute 30 Minuten. Damit löschst du einen großen Unfall der Zukunft aus.

Wenn du grübelst „Wie streng sollen wir es im Team zurren?“, gibt es auch Material und Unterstützung. Schau erst mal in die Materialübersicht.