Ihr KI-Agent halluziniert weiter und beschädigt das Repository? So geben Sie Claude Code Gedächtnis, Datenzugriff und sichere Leitplanken

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau

Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und ich liefere mit DennisCraft AI Studio produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres. Der typische Schaden entsteht nicht dadurch, dass ein Modell „etwas ungenau“ ist, sondern dadurch, dass ein KI-Agent sehr überzeugend die falsche Datei ändert, eine nicht existierende Tabellenspalte annimmt und den Fehler mit gutem Gewissen in die Arbeitskopie schreibt.

Wenn Claude Code kein Gedächtnis für Ihr Projekt, keinen Zugriff auf aktuelle Fakten und keine erzwungenen Reaktionsmuster vor riskanten Aktionen hat, arbeitet das System wie ein fähiger Junior ohne vollständigen Kontext. Das Problem liegt dann nicht primär im Modell, sondern in der Betriebsarchitektur darum herum.

Warum solche Agenten in realen Codebasen halluzinieren

Im Produktivbetrieb sehe ich meist 3 Ursachen. Erstens fehlt Projektgedächtnis: Modulgrenzen, Namenskonventionen, Regeln für Migrationen, bekannte Stolperstellen. Zweitens fehlen überprüfbare Fakten aus den laufenden Systemen: Datenbankschema, echte API-Antworten, aktuelle Umgebungsgrenzen. Drittens gibt es keine ausführbaren Sperren zwischen „Vorschlag erzeugen“ und „Änderung anwenden“.

Die OWASP Top 10 für LLM-Anwendungen nennt Prompt Injection, unsichere Verarbeitung von Ausgaben und übermäßige Handlungsmacht als wiederkehrende Risikoklassen. Genau dort liegen viele Schäden, die Teams zunächst als „Modellproblem“ einstufen. Quelle: OWASP Top 10 for Large Language Model Applications, 2025, https://owasp.org/www-project-top-10-for-large-language-model-applications/.

Was mit Gedächtnis praktisch gemeint ist

Gemeint ist kein vages Langzeitgedächtnis, sondern überprüfbarer Kontext: eine AGENT_CONTEXT.md, ein Index des Repositorys, Kurzbeschreibungen der Dienste, Abhängigkeitsnotizen, erlaubte Befehle und eine knappe Liste früherer Fehler. Fehlt diese Schicht, beginnt jeder Lauf mit Vermutungen statt mit belastbaren Fakten.

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

cat > AGENT_CONTEXT.md <<'EOF'
Project: versand-ops
Rules:
- Never edit generated files
- Database access only through repository layer
- Migrations require human approval
- Secrets only from environment variables
- Before commit run: pytest -q, semgrep --config p/ci
EOF

git ls-files > .agent_file_index.txt

Gedächtnis ohne Datenzugriff erzeugt weiter Fiktion

Die nächste Schicht ist Zugriff auf Live-Fakten, aber gezielt und lesend. Wenn der Agent das aktuelle Postgres-Schema nicht prüfen kann, erfindet er Spalten. Wenn er keine echte API-Antwort sieht, verarbeitet er Felder, die es nicht gibt. Wenn er nicht weiß, welche Tabellen personenbezogene Daten enthalten, stehen DSGVO-Vorgaben und interne Datenregeln schnell im Konflikt mit dem automatisch erzeugten Code.

Ich trenne in regulierten Umgebungen deshalb 2 Pfade: lesende Systemprüfung und eng begrenzte Schreibpfade. In Supabase oder selbst betriebenem Postgres braucht ein Agent fast nie direkten Schreibzugriff. Er braucht Antworten auf Fragen wie: Welche Tabellen existieren? Welche Fremdschlüssel sind aktiv? Welche Migrationen wurden bereits angewendet?

import os
import psycopg
from psycopg.rows import dict_row

dsn = os.environ["READONLY_DATABASE_URL"]

with psycopg.connect(dsn, row_factory=dict_row) as conn:
    with conn.cursor() as cur:
        cur.execute("""
            select table_name, column_name, data_type
            from information_schema.columns
            where table_schema = 'public'
            order by table_name, ordinal_position
        """)
        rows = cur.fetchall()

for row in rows[:20]:
    print(f"{row['table_name']}.{row['column_name']} -> {row['data_type']}")

Sinnvoll ist dabei ein Werkzeug-Wrapper statt freier SQL-Eingaben. So werden Abfragen protokolliert, begrenzt und über Positivlisten gesteuert. Das passt auch gut zu Anforderungen aus ISO 27001, BSI Grundschutz und NIS2, weil Zugriffe nachvollziehbar und technisch eingeschränkt bleiben.

Sichere Leitplanken müssen ausgeführt werden

Ein häufiger Denkfehler ist, Sicherheit allein in den System-Prompt zu verlagern. Ein Prompt kann Fehlverhalten verringern, aber er kann keinen riskanten Commit zuverlässig stoppen, kein versehentliches Geheimnis aus dem Repository fernhalten und keine unsichere SQL-Zeichenkettenbildung belastbar verhindern. Dafür braucht es ausführbare Kontrollen.

Für Python-lastige Repositories setze ich als Startpunkt meist auf semgrep, bandit und gitleaks. Diese Werkzeuge passen gut zu agentischen Arbeitsabläufen, weil sie typische Wiederholungsfehler automatischer Codeerzeugung früh sichtbar machen.

name: agent-guardrails
on: [push, pull_request]
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: p/ci
      - run: pip install bandit
      - run: bandit -r .
      - uses: gitleaks/gitleaks-action@v2

Auch die Dokumentation von Anthropic zu Tool Use zeigt denselben Grundsatz: Das Modell soll Werkzeuge aufrufen, wenn externe Fakten benötigt werden, statt Lücken mit Annahmen zu füllen. Quelle: Anthropic Documentation, Tool Use, 2024–2025, https://docs.anthropic.com/.

Ein belastbares Muster für Claude Code im Produktivbetrieb

1. Geben Sie dem Agenten Betriebswissen im Repository

Mindestens nötig sind AGENT_CONTEXT.md, Dienstübersicht, Regeln für Migrationen, erlaubte Befehle und bekannte Fehlermuster. Dieses Wissen muss mit dem Code gepflegt werden, nicht in einer veralteten Wissensseite.

2. Erlauben Sie Werkzeuge zur Verifikation, nicht zur Spekulation

Lesender Zugriff auf Postgres-Metadaten, Suche im Repository, Testausführung und Zugriff auf einen internen API-Katalog reichen oft für den Start. Breiter Shell-Zugriff sollte erst folgen, wenn Protokollierung und Richtlinien sauber stehen.

3. Trennen Sie Erzeugung, Anwendung und Commit

Claude Code kann zunächst einen Patch oder Plan erstellen. Ein separater Schritt wendet Änderungen an. Ein weiterer Schritt erstellt den Commit. Diese Trennung verbessert Nachvollziehbarkeit und Freigabefähigkeit.

4. Protokollieren Sie nicht nur Aktionen, sondern auch Entscheidungsgrundlagen

Wichtig ist nicht nur, welche Datei geändert wurde, sondern auch, auf welche Fakten sich der Agent gestützt hat: Schemaprüfung, Dateiverweise, Testergebnisse, Richtlinienkontrollen. Nur so lässt sich später klären, ob Datenzugriff fehlte, Gedächtnis veraltet war oder Leitplanken zu schwach waren.

type Action = "read" | "patch" | "commit";

function requireApproval(action: Action, path: string) {
  const sensitive = path.includes("migrations") || path.includes(".github");
  if ((action === "patch" || action === "commit") && sensitive) {
    throw new Error(`Human approval required for ${action} on ${path}`);
  }
}

requireApproval("patch", "db/migrations/20261110_add_users.sql");

Was in regulierten europäischen Märkten tatsächlich trägt

In Logistik, Fintech und industrieller Automatisierung gewinnt nicht der „kreativste“ Agent, sondern der vorhersehbarste. Mehr Autonomie wird intern meist erst akzeptiert, wenn Zugriffe, Prüfungen und menschliche Eingriffspunkte sauber nachvollziehbar sind. Im Kontext von DSGVO, EU AI Act und internen Revisionsanforderungen ist das kein Zusatzwunsch, sondern Teil der Betriebsfähigkeit.

Auch das OpenAI Cookbook empfiehlt wiederholt, Werkzeuge und Retrieval einzusetzen, wenn sachliche Genauigkeit zählt, statt sich auf Modellgedächtnis allein zu verlassen. Quelle: OpenAI Cookbook, 2024, https://cookbook.openai.com/. In der Praxis ist dieser Ansatz günstiger als spätere Ursachenanalyse nach einem fehlerhaften automatischen Eingriff.

FAQ

Reicht ein guter System-Prompt aus?

Nein. Ein guter Prompt hilft, ersetzt aber weder aktuelle Fakten noch technische Kontrollen. Bei echter Arbeit am Repository entstehen Fehler meist genau dort, wo Annahmen auf veralteten Kontext treffen.

Brauche ich für Claude Code zwingend RAG?

Nicht zwingend. Viele Teams kommen mit Repository-Index, AGENT_CONTEXT.md und lesendem Schema-Zugriff bereits weit. RAG wird sinnvoll, wenn viele Dienste, lange interne Dokumentationen und häufige Regeländerungen zusammenkommen.

Sollte ein Agent direkten Zugriff auf Postgres erhalten?

Ich empfehle den Start mit einer lesenden Rolle und schmalen Wrappern. Direkter Schreibzugriff aus einem Coding-Agenten in die Datenbank ist im Produktivbetrieb nur selten zu rechtfertigen.

Welche Kontrollen sollte ich zuerst einführen?

semgrep, bandit und gitleaks decken viele typische Wiederholungsfehler ab. Danach folgen Freigaben für Migrationen, Änderungen an CI und destruktive Dateioperationen.

Woran erkenne ich veraltetes Agenten-Gedächtnis?

Wenn der Agent wiederholt nicht existierende Module anfasst, alte Tabellen referenziert oder bereits behobene Fehler neu erzeugt, ist die Kontextschicht nicht mehr synchron. Das Betriebswissen muss im selben Änderungsprozess aktualisiert werden wie der Code.

An welcher Stelle Ihrer LLM-Pipeline fangen Sie heute die meisten Probleme im Produktivbetrieb ab: bei der statischen Analyse, in einer Laufzeit-Sandbox oder erst in der menschlichen Freigabe vor riskanten Schritten? Mich interessiert das ernsthaft, gerade im Vergleich zu den Mustern, die ich in DACH-B2B-Systemen sehe.
Ich biete einen kostenlosen 30-minütigen Stack-Audit für DACH-Gründer und Führungsteams an, die KI in regulierten Märkten aufbauen. Schreiben Sie mir auf LinkedIn oder an @ger_dennis_ai.