Claude Code kann im Produktivbetrieb in Slack, WordPress und .env auslaufen: 10 Guardrails vor dem ersten Start

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect aus Freiburg im Breisgau, Germany, und ich betreibe mit DennisCraft AI Studio produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Der heikelste Vorfall sieht in diesem Umfeld oft nicht wie ein klassischer Angriff aus: Ein Agent liest die falsche Datei, veröffentlicht den falschen Entwurf in WordPress oder kopiert Teile einer .env nach Slack, weil vor dem ersten Start keine Grenzen für Werkzeuge und Datenflüsse gesetzt wurden.

Sobald Claude Code auf Repository, Shell, CMS, Datenbank und Kommunikationskanal zugreifen darf, ist ein Datenabfluss kein theoretisches Thema mehr, sondern eine Frage der Leitwege. OWASP nennt in der LLM Top 10 für 2025 ausdrücklich sensitive information disclosure und excessive agency als eigene Risikoklassen: https://genai.owasp.org/llm-top-10/. Für DACH-Unternehmen kommt hinzu, dass solche Fehler schnell DSGVO-, NIS2- oder ISO-27001-relevante Folgen haben. Im Folgenden sind die 10 Guardrails, die ich vor dem ersten Produktivstart aktiviere.

1. Zuerst den Wirkungsbereich verkleinern, dann Werkzeuge freigeben

Der häufigste Konstruktionsfehler ist ein zu großer Wirkungsbereich. Claude Code erhält Zugriff auf das ganze Arbeitsverzeichnis, mehrere Zugangsdaten und allgemeine Systemrechte, während der Schutz allein über den Prompt erfolgen soll. Im Produktivbetrieb trenne ich Arbeitsverzeichnis, Dienstkonto, Speicherpfade und Berechtigungen je Aufgabe.

Guardrail 1: isoliertes Arbeitsverzeichnis

Der Agent läuft in einem dedizierten Verzeichnis oder Container. Home-Verzeichnis, SSH-Schlüssel und gemeinsam genutzte Volumes werden nicht eingebunden. Das gilt besonders dann, wenn auf demselben Host noch Sicherungen, SQL-Dumps oder WordPress-Dateien liegen.

Guardrail 2: Allowlist für Befehle und Pfade

Der Agent darf nur die Verzeichnisse lesen und schreiben, die für die Aufgabe erforderlich sind. Für Shell-Befehle setze ich auf eine Allowlist statt auf eine Sperrliste. Sperrlisten übersehen im Produktivbetrieb regelmäßig Umwege.

#!/usr/bin/env bash
set -euo pipefail

export WORKDIR="/srv/agent-task"
mkdir -p "$WORKDIR/out"

allowed_cmds=("python3" "pytest" "git" "ls" "cat")
cmd="${1:-}"

if [[ ! " ${allowed_cmds[*]} " =~ " ${cmd} " ]]; then
  echo "blocked command: $cmd" >&2
  exit 1
fi

cd "$WORKDIR"
exec "$@"

2. Geheimnisse dürfen nicht in den Modellkontext gelangen

Ein wiederkehrendes Muster im Betrieb ist banal und gefährlich zugleich: Der Agent sieht das Repository, daneben liegt eine .env, das Modell liest sie zur Fehlersuche, und anschließend tauchen Fragmente in Slack-Nachrichten oder Entwürfen auf. Das ist kein Sonderfall des Modells, sondern eine vermeidbare Fehlkonstruktion.

Guardrail 3: Geheimnisse nur zur Laufzeit einspielen

Doppler, Umgebungsvariablen des Prozesses und kurzlebige Token sind geeignet. Eine .env im Arbeitsverzeichnis des Agenten ist es nicht. Selbst schreibgeschützte Dateien können über Ausgaben oder Zusammenfassungen nach außen gelangen.

Guardrail 4: Geheimnisprüfung vor jedem Lauf

Vor jedem Start lasse ich gitleaks über das Arbeitsverzeichnis laufen. Bei Treffern wird der Lauf sofort abgebrochen. Das ist einfach umzusetzen und fängt genau die Fälle ab, in denen ein Zugangsschlüssel „nur kurz“ im Verzeichnis lag.

#!/usr/bin/env bash
set -euo pipefail

gitleaks detect \
  --source /srv/agent-task \
  --no-banner \
  --exit-code 1 \
  --redact

echo "No secrets detected in workspace"

3. Veröffentlichungen nach außen brauchen eine Prüfschicht

Slack und WordPress sind nicht deshalb problematisch, weil sie unsicher wären, sondern weil sie direkte Ausgabekanäle nach außen sind. Wenn das Modell Text falsch einordnet, gelangen Geheimnisse, ungeprüfte Aussagen oder personenbezogene Daten ohne Zwischenstopp nach außen. Im Sinne der DSGVO und des BSI Grundschutzes ist das bereits ein relevantes Steuerungsproblem.

Guardrail 5: zweistufige Veröffentlichung

Der Agent veröffentlicht nicht unmittelbar. Er erzeugt zunächst einen Entwurf in Postgres oder Supabase. Ein separater Prozess prüft Regeln und gibt den Inhalt erst danach für Slack oder die WordPress-API frei.

Guardrail 6: Inhaltsfilter für typische Abflussmuster

Ich prüfe auf E-Mail-Adressen, API-Schlüssel, JWTs, Passwortzuweisungen, Verbindungszeichenfolgen und .env-ähnliche Textteile. Das ersetzt keine vollständige DLP-Lösung, schließt aber typische Lücken im Produktivbetrieb.

import re

RISK_PATTERNS = [
    r"AKIA[0-9A-Z]{16}",
    r"-----BEGIN [A-Z ]+ PRIVATE KEY-----",
    r"postgres(ql)?://[^\\s]+",
    r"(?i)password\\s*=",
    r"(?i)api[_-]?key\\s*[:=]",
    r"[A-Za-z0-9-_]+\\.[A-Za-z0-9-_]+\\.[A-Za-z0-9-_]+"
]

def is_publishable(text: str) -> bool:
    return not any(re.search(pattern, text) for pattern in RISK_PATTERNS)

sample = "draft message for Slack"
if not is_publishable(sample):
    raise ValueError("Blocked by content policy")

4. Generierten Code wie normalen Code behandeln

Claude Code kann lauffähigen Code erzeugen, der im Positivpfad funktioniert und dennoch SQL Injection, Shell Injection oder unsichere Dateiverarbeitung einführt. Genau hier sind semgrep und bandit im Alltag wirksamer als zusätzliche Anweisungen im System-Prompt.

Guardrail 7: statische Analyse für jede erzeugte Änderung

Semgrep eignet sich gut für Python, JavaScript, TypeScript und YAML. Bandit ergänzt Python sinnvoll. Wenn der Agent n8n-Workflows oder SQL-Migrationen erzeugt, sollten auch dafür passende Prüfungen ergänzt werden.

Guardrail 8: Richtlinien für gefährliche Senken

Änderungen werden blockiert, wenn sie subprocess mit shell=True, rohe SQL-Zeichenketteninterpolation, Schreibzugriffe auf .env, direkte Webhook-Aufrufe oder Massenänderungen ohne where-Klausel enthalten.

version: "3"
tasks:
  scan:
    cmds:
      - semgrep --config p/owasp-top-ten .
      - bandit -r . -q
      - gitleaks detect --source . --no-banner --exit-code 1 --redact
    silent: true

5. Laufzeitkontrollen sind wichtiger als elegante Prompts

Die Dokumentation von Anthropic zum Werkzeuggebrauch ist hier ein guter Bezugspunkt: Das Modell soll über beschriebene Werkzeuge und strukturierte Aufrufe arbeiten, nicht über weitreichende implizite Rechte. Dieses Muster begrenzt den Schadensradius. Ein guter Prompt ersetzt keine technische Kontrolle in der Ausführung.

Guardrail 9: jeden Werkzeugaufruf protokollieren

Ich protokolliere Prompt, Werkzeugname, Argumente, Werkzeugantwort und Seiteneffekt. Ohne diese Spur wird jede Ursachenanalyse ungenau: Ist der Datenabfluss über Slack, WordPress, Supabase oder Shell-Ausgabe erfolgt?

Guardrail 10: Abschaltsignal und Budgetgrenzen

Jeder Lauf braucht Grenzen für Anzahl der Werkzeugaufrufe, Laufzeit und Kosten. Wenn die Ausführung abdriftet, muss sie automatisch beendet werden, bevor vier Kanäle mit fehlerhaften Inhalten gefüllt sind.

type ToolEvent = {
  tool: string;
  args: Record;
  timestamp: string;
};

const MAX_CALLS = 12;
const events: ToolEvent[] = [];

export function recordToolCall(tool: string, args: Record) {
  if (events.length >= MAX_CALLS) {
    throw new Error("tool budget exceeded");
  }
  events.push({ tool, args, timestamp: new Date().toISOString() });
  console.log(JSON.stringify(events[events.length - 1]));
}

FAQ

Reicht ein guter System-Prompt aus?

Nein. Ein Prompt unterstützt die Aufgabeninterpretation, beschränkt aber weder Dateisystem, Netzverkehr noch Veröffentlichungsrechte. Produktive Kontrollen müssen außerhalb des Modells liegen.

Braucht jede externe Veröffentlichung eine menschliche Freigabe?

Nicht zwingend. Inhalte mit geringem Risiko können über Regelprüfungen und einen Entwurfsstatus laufen. Bei personenbezogenen Daten, Finanzvorgängen oder öffentlichen Aussagen im Namen des Unternehmens empfehle ich jedoch eine ausdrückliche Freigabe.

Was ist wichtiger: Sandbox oder statische Analyse?

Beides adressiert unterschiedliche Fehlerklassen. Eine Sandbox begrenzt Schäden zur Laufzeit, statische Analyse findet gefährliche Muster vor der Ausführung. Im Produktivbetrieb sollten beide Ebenen vorhanden sein.

Welche regulatorischen Anker sind in DACH relevant?

Je nach Branche und Größe betreffen solche Systeme DSGVO, NIS2, ISO 27001, BSI Grundschutz und perspektivisch auch den EU AI Act. Entscheidend ist, dass Datenflüsse, Berechtigungen und Freigaben nachvollziehbar dokumentiert sind.

Womit sollte ein Team beginnen, wenn das System bereits live ist?

Beginnen Sie mit einer Karte aller Werkzeuge und Ausgabekanäle. Halten Sie fest, welche Aufrufe möglich sind, welche Verzeichnisse gelesen werden und wohin geschrieben werden darf. Danach folgen Allowlists, Geheimnisprüfung und Veröffentlichungslogik.

An welcher Stelle Ihrer LLM-Pipeline finden Sie heute die meisten Fehler im Produktivbetrieb: bei der statischen Analyse erzeugter Änderungen, bei Laufzeitregeln oder erst nach einer Veröffentlichung in Slack oder CMS? Ich würde das gern mit den Mustern vergleichen, die ich in DACH-B2B-Umgebungen sehe. Ich biete einen kostenlosen 30-minütigen Stack-Audit für Gründerinnen und Gründer sowie Technologieteams im DACH-Raum an, die KI in regulierten Märkten bereitstellen. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.