Warum Ihre KI-Agenten im Produktivbetrieb scheitern: 5 Integrationsfehler mit Codex, Claude Code und Agentic Harness
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem Studio DennisCraft AI setze ich autonome Multi-Agentensysteme für DACH-B2B-Kunden produktiv ein, mit Claude, Supabase, n8n, Doppler und eigener Postgres-Instanz. Im Live-Betrieb tauchen Fehler auf, die in der Demo-Phase unsichtbar bleiben – und fast immer liegt es am Integrationslayer, nicht am Modell selbst. 1. Fehlender statischer Code-Check für LLM-Generierung Viele Teams vertrauen darauf, dass Codex oder Clau
von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. In meinem Studio DennisCraft AI setze ich autonome Multi-Agentensysteme für DACH-B2B-Kunden produktiv ein, mit Claude, Supabase, n8n, Doppler und eigener Postgres-Instanz. Im Live-Betrieb tauchen Fehler auf, die in der Demo-Phase unsichtbar bleiben – und fast immer liegt es am Integrationslayer, nicht am Modell selbst.
1. Fehlender statischer Code-Check für LLM-Generierung
Viele Teams vertrauen darauf, dass Codex oder Claude Code „sicheren“ Code generieren, und führen diesen direkt im Backend aus. In drei aktuellen Projekten habe ich LLM-erzeugten SQL-Code gefunden, der jede Sicherheitsprüfung für SQL-Injection nicht bestanden hätte. Die Anthropic-Dokumentation 2024 empfiehlt explizit den Einsatz von Tools wie semgrep und bandit – in der Praxis fehlt diese Pipeline jedoch oft.
Statischer Sicherheits-Check im CI einbinden
# Jeden generierten Agenten-Code prüfen:
semgrep --config=auto generated_agent_code.py
bandit -r generated_agent_code.py
gitleaks detect --source .
Ohne diese Checks riskieren Sie Datenbankabstürze oder die unfreiwillige Weitergabe von Geheimnissen – spätestens im Produktivbetrieb.
2. Fehlende Ausführungsisolation und Sandbox
LLM-Output wird oft ohne Absicherung direkt produktiv ausgeführt. Ich habe erlebt, wie ein einzelner, schlecht validierter Payload einen Microservice lahmlegte. Meine Praxis: Agenten laufen immer in dedizierten Containern oder chroot-Umgebungen; für sensible Operationen kommt zusätzlich eine verzögerte Freigabe oder restriktive API zum Einsatz.
Beispiel: Ausführung im Docker-Sandbox-Container
import subprocess
def run_in_sandbox(code: str):
result = subprocess.run(
["docker", "run", "--rm", "-v", "/tmp/agent:/app", "python:3.10", "python", "-c", code],
capture_output=True, text=True, timeout=30
)
return result.stdout
So verhindert man, dass ein einzelner Fehler den Gesamtdienst gefährdet.
3. Fehlender Schutz von Geheimnissen und Umgebungsvariablen
LLM-Agenten behandeln Geheimnisse oft unsorgfältig. Immer wieder sehe ich, dass API-Keys oder Datenbank-URLs geloggt werden, wenn der Prompt nicht ausdrücklich Schutz verlangt. Ohne Doppler oder korrekt konfigurierte Umgebungsvariablen riskieren Sie DSGVO-relevante Vorfälle. In einem Projekt schrieb ein Claude-Agent unbeabsichtigt den DB-URL in ein öffentliches Log, das sofort vom Cloud-Logging-Dienst erfasst wurde.
Geheimnisse sicher weitergeben
import os
def get_db_conn():
conn_str = os.environ.get("DATABASE_URL")
if not conn_str:
raise Exception("DB URL not set")
# Niemals conn_str loggen!
return connect(conn_str)
Automatisierte Checks stellen sicher, dass keine Agenten-Codefragmente sensible Daten loggen oder weiterreichen.
4. Ungenügendes Logging und Fehlertracing
Ohne fein granulierte Logs bleibt das Verhalten Ihrer Agenten im Produktivbetrieb Blackbox. Ein Claude-Code-Agent schrieb etwa Logs in eine Datei, die im Container nicht gemountet war – alle Logs gingen verloren. Ich setze immer auf zentrales Logging (z.B. mit Supabase oder ELK-Stack) und individuelle Trace-IDs pro Agentensitzung. DSGVO-konformes Logging ist Pflicht.
Beispiel für zentrales Event-Logging
import logging
logger = logging.getLogger("agent")
logger.setLevel(logging.INFO)
def agent_action(event):
logger.info(f"Agent started event: {event['id']}")
# ...
logger.info(f"Agent finished event: {event['id']}")
So können Sie Fehler im Ablauf eindeutig lokalisieren.
5. Unvollständige Tests mit produktionsnahen Daten
Daten aus der Demo spiegeln die Komplexität des Produktivbetriebs nie wider. Agenten, die im Test glänzen, scheitern an Edge-Cases im Feld. Ich nutze synthetische Datensätze, die das Produktivsystem realitätsnah simulieren, und prüfe bewusst Ausreißer. In einem Fintech-Projekt akzeptierte ein Agent einen ungültigen IBAN und leitete den Fehler weiter – mangels Validierung im generierten Code.
Test für Datenvalidierung
def test_iban_validation():
invalid_iban = "12345"
try:
validate_iban(invalid_iban)
except ValueError:
assert True
else:
assert False, "Ungültiger IBAN wurde nicht erkannt"
Nur durch solche Tests minimieren Sie Überraschungen im Produktivbetrieb.
| Fehler | Kontrollwerkzeug | Typischer Vorfall |
|---|---|---|
| Kein statischer Code-Check | semgrep, bandit | SQL-Injection, Geheimnis-Leaks |
| Keine Sandbox | Docker, chroot | Dienstabsturz |
| Geheimnisse im Log | Doppler | Key-Exposure (DSGVO) |
| Kein zentrales Logging | Supabase, ELK | Verlust der Nachvollziehbarkeit |
| Nur Demo-Tests | pytest, Edge-Case-Datensätze | Fehler im Produktivsystem |
FAQ
Kann Claude Code für Produktivsysteme genutzt werden?
Ich setze Agenten-Code nie ohne statische Analyse und Sandbox ein. Selbst modernste LLMs generieren bei Edge-Cases unsicheren Code.
Wie erkenne ich instabiles Agentenverhalten?
Detailliertes Logging mit individuellen Trace-IDs je Sitzung. Anomalien lassen sich so gezielt aufspüren.
Welche Tools funktionieren für LLM-Code-Checks?
semgrep und bandit decken ca. 80% der Python-Fehler ab, inklusive Prompt-bedingter Schwachstellen. Für Geheimnisse: gitleaks.
Wie sichere ich die Datenbankanbindung von Agenten?
Nur über Service-Accounts mit minimalen Rechten und Validierung aller Eingaben vor Übergabe an Postgres.
Was tun, wenn Fehler erst im Produktivsystem sichtbar werden?
Alerter für ungewöhnliche Logmuster aktivieren und Fehler in isolierter, produktionsnaher Umgebung nachstellen.
Wo in Ihrem Stack scheitern Agenten am häufigsten: Codegenerierung, Test, Isolation oder Geheimnis-Handling? Gerne werfe ich einen Blick auf Ihre Pipeline – ich biete einen kostenlosen 30-min Stack-Check für DACH-Teams mit KI-Projekten im regulierten Umfeld. Kontaktieren Sie mich auf LinkedIn oder unter @ger_dennis_ai.
Aus einem Ablauf ein System machen, das läuft
Gebaut für den Betriebsalltag, nicht als Demo.