Ihr Coding-Agent wurde zum Einstiegspunkt in Ihre Infrastruktur: Was Sie nach dem Backdoor-Vorfall bei Claude Code/Cursor prüfen sollten

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und mein Stack in Produktivsystemen besteht aus Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Wenn Ihr Coding-Agent bereits Quellcode lesen, Secrets sehen, Migrations vorbereiten und mit lokalen Werkzeugen arbeiten kann, dann ist der Vorfall rund um Claude Code/Cursor kein reines Entwicklerproblem mehr, sondern ein möglicher Zugang zu Ihrer Infrastruktur.

Genau an dieser Stelle unterschätzen viele Teams die Lage. Ein Coding-Agent wird intern noch als Assistenz für die Entwicklung behandelt, hat in der Praxis aber oft Einblick in Repositories, Build-Prozesse, CI-Variablen, Shell-Befehle, Protokolle und produktionsnahe Konfigurationen. Nach einem solchen Vorfall sollten Sie deshalb nicht nur nach auffälligem Code suchen, sondern den gesamten Berechtigungsrahmen prüfen.

1. Zuerst den tatsächlichen Wirkungsradius bestimmen

Mein erster Schritt nach einem solchen Ereignis ist nicht die Suche nach einer einzelnen verdächtigen Codezeile. Ich erfasse den Wirkungsradius. Welche Repositories waren sichtbar? Welche Branches waren beschreibbar? Welche Zugangsdaten lagen in .env-Dateien, in Doppler, in CI-Umgebungen, in Supabase-Schlüsseln oder in Postgres-Verbindungsdaten vor? Wenn Ihr Team diese Fragen nicht schnell beantworten kann, fehlt Ihnen zunächst eine belastbare Zugriffsübersicht.

OWASP nennt in den “LLM Top 10” für 2025 ausdrücklich das Muster der excessive agency, also zu weitreichende Handlungsbefugnisse modellgestützter Systeme. Quelle: OWASP GenAI Security Project, 2025, https://genai.owasp.org/. Genau dieses Muster sehe ich in produktiven Agentensystemen regelmäßig: Nicht der einzelne Modellaufruf ist das Hauptproblem, sondern die Summe unnötiger Rechte drumherum.

2. Secrets rotieren, bevor die Ursachenanalyse abgeschlossen ist

Wenn der Coding-Agent Zugriff auf Secrets hatte, sollten Sie diese als potenziell kompromittiert behandeln. Warten Sie nicht auf lückenlose Beweise. In produktiven B2B-Systemen ist eine verspätete Rotation oft folgenschwerer als eine noch unvollständige forensische Einordnung. Ich teile die Reaktion in 3 Gruppen: sofort widerrufbare Tokens, dienstbezogene Zugangsdaten mit Abhängigkeiten und langlebige Infrastrukturkonten.

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

echo "Priorisierte Rotation"
echo "1) Git-Tokens widerrufen"
echo "2) Supabase Service-Role-Key rotieren"
echo "3) Postgres-Anwendungskennwort ändern"
echo "4) Doppler-Service-Token ersetzen"
echo "5) n8n-Credentials neu ausstellen"

for item in git supabase postgres doppler n8n; do
  printf "queued: %s\n" "$item"
done

echo "Anschließend Worker neu starten und Sessions invalidieren"

Die Reihenfolge ist wichtig. Zuerst unterbinden Sie weiteren Zugriff. Dann tauschen Sie die Zugangsdaten, deren Änderung den Betrieb beeinflusst. Erst danach dokumentieren Sie sauber, was wann sichtbar war. Dieses Vorgehen passt auch gut zu Anforderungen aus ISO 27001, BSI Grundschutz und NIS2, weil es auf nachweisbare Eindämmung und nachvollziehbare Verantwortlichkeiten einzahlt.

3. Bereits erzeugten Code erneut prüfen

Der stille Risikobereich liegt häufig nicht im neuesten Vorschlag des Agents, sondern im bereits übernommenen Code der letzten Wochen. Ich würde Datenzugriffsschichten, Shell-Helfer, CI-Skripte, Dateiverarbeitung und Eingabevalidierung priorisieren. In mehreren produktiven Agentenprojekten habe ich denselben Fehler immer wieder gesehen: zusammengesetzte SQL-Strings in ansonsten sauberem Anwendungscode.

Das OpenAI Cookbook betont in den Materialien zu Tool-Nutzung und Function Calling seit 2024 durchgehend, dass Validierung und Begrenzung auf Anwendungsebene erfolgen müssen, nicht allein auf Modellebene. Quelle: OpenAI Cookbook, 2024, https://cookbook.openai.com/. Diese Regel gilt hier genauso. Vertrauen Sie nicht auf die Formulierung des Prompts, sondern auf technische Schranken beim Ausführen.

import os
import psycopg
from psycopg.rows import dict_row

conn = psycopg.connect(os.environ["DATABASE_URL"], row_factory=dict_row)

def get_order(order_id: str):
    with conn.cursor() as cur:
        cur.execute(
            "select id, status from orders where id = %s",
            (order_id,)
        )
        return cur.fetchone()

def update_status(order_id: str, status: str):
    with conn.cursor() as cur:
        cur.execute(
            "update orders set status = %s where id = %s",
            (status, order_id)
        )
    conn.commit()

Als Mindestmaß empfehle ich semgrep, bandit und gitleaks über die aktiven Repositories laufen zu lassen und danach die Module manuell zu prüfen, die der Agent besonders häufig berührt hat. semgrep findet bekannte unsichere Muster, bandit ist für Python-Stacks hilfreich, gitleaks liefert einen schnellen Blick auf versehentlich eingecheckte Secrets.

semgrep --config auto .
bandit -r app/
gitleaks detect --source . --verbose
git log --since="90 days ago" --stat -- '*.py' '*.ts' '*.sql'

4. Nicht nur den Prompt anpassen, sondern die Ausführungsumgebung begrenzen

Nach öffentlichen Vorfällen wird oft zuerst der System-Prompt überarbeitet. Das reicht nicht aus, wenn der Agent weiterhin Shell-Zugriff, freie Netzwerkverbindungen, eingebundene Secrets und Schreibrechte in vertrauenswürdigen Branches besitzt. Wirksame Begrenzung entsteht in der Laufzeitumgebung.

Ein pragmatischer Mindeststandard

Ich empfehle 4 Ebenen. Erstens eine Umgebung mit geringen Rechten für Agentenaufgaben. Zweitens getrennte Lese- und Schreibzugänge je nach Aufgabe. Drittens kein direkter Zugriff auf die Produktionsdatenbank aus der Umgebung des Coding-Agents. Viertens menschliche Freigaben für Migrationsschritte, Credential-Änderungen und Infrastrukturänderungen.

agent_runtime:
  git_access: read_only
  network_egress: allowlist
  database:
    prod_direct_access: false
    staging_role: read_write
  secrets:
    mount_env_files: false
    use_doppler_service_token: true
  approvals:
    require_human_for:
      - migrations
      - credential_rotation
      - infra_changes

Wenn Sie Supabase einsetzen, trennen Sie die Verwendung von Service-Role-Schlüsseln sauber nach Ausführungskontext. Bei selbst betriebenem Postgres sollten Sie einen eigenen Nutzer nur für Staging anlegen und Kennwörter nie zwischen Umgebungen wiederverwenden. Wenn Sie n8n nutzen, prüfen Sie alle gespeicherten Credentials und Webhook-Flows erneut. Genau dort wird aus einem lokalen Vorfall schnell ein systemischer.

5. Protokolle und Prompt-Historie gehören zum Vorfall dazu

Viele Teams prüfen Repositories und Secrets, vergessen aber Prompt-Protokolle, Erweiterungsprotokolle der Entwicklungsumgebung, CI-Artefakte und Traces. Das ist riskant. Gerade dort liegen häufig SQL-Fragmente, interne URLs, Kundendaten oder Tokens. Im DACH-Markt ist das nicht nur technisch problematisch, sondern berührt schnell DSGVO, Auftragsverarbeitung und interne Informationssicherheitsvorgaben.

Nach einem solchen Ereignis mache ich deshalb immer eine kurze Datenflussprüfung: Welche Daten hat der Agent gesehen, welche konnten an externe APIs übertragen werden, wo wurden sie protokolliert, wie lange bleiben sie gespeichert und wer hat Zugriff darauf? Dieser Schritt ist unspektakulär, liefert aber oft die entscheidenden Hinweise für eine belastbare Sicherheitsprüfung.

FAQ

Sollten Sie Coding-Agents nach einem solchen Vorfall vollständig abschalten?

Nicht zwingend. Wenn das Werkzeug im Produktivbetrieb echten Nutzen bringt, können Sie es weiter einsetzen, aber erst nach Neuordnung der Rechte, Rotation der Zugangsdaten und Begrenzung der Ausführungsumgebung. Ein bloßes Abschalten ohne Architekturänderung verschiebt das Problem nur.

Reicht Git-Lesezugriff als Schutzmaßnahme?

Es ist ein sinnvoller Anfang, aber keine vollständige Antwort. Schon Lesezugriff auf Quellcode, Konfigurationen und Commit-Historien offenbart oft interne Architekturdetails, Endpunkte und Muster im Umgang mit Secrets.

Müssen Sie alle alten Pull Requests prüfen, an denen der Agent beteiligt war?

In der Regel nicht lückenlos. Starten Sie mit einem Fenster von 60 bis 90 Tagen und priorisieren Sie Änderungen an SQL, Shell-Skripten, Authentifizierung, CI-Logik, Secret-Verarbeitung und Infrastrukturcode.

Welches Werkzeugset ist für eine erste Prüfung ausreichend?

Für einen schnellen, belastbaren Anfang genügen häufig semgrep, bandit, gitleaks und eine manuelle Prüfung besonders kritischer Module. Danach richtet sich die Vertiefung nach Ihrem Stack und Ihren regulatorischen Anforderungen.

Ist das nur ein Problem von Claude Code und Cursor?

Nein. Es handelt sich um eine Risikoklasse für jeden Coding-Agenten oder jede IDE-Integration mit Zugriff auf Quellcode, Laufzeitkontext und Werkzeuge. Der Produktname ändert Details, nicht das Grundproblem.

An welcher Stelle Ihrer LLM-Pipeline werden die meisten kritischen Fehler im Produktivbetrieb tatsächlich erkannt: in der statischen Analyse, durch Laufzeitbegrenzung oder erst in der menschlichen Prüfung vor dem Merge? Das würde ich gern mit den Mustern vergleichen, die ich bei B2B-Agentensystemen in regulierten Märkten sehe.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.