AI-Agent-Monitoring mit LangSmith und Langfuse: Observability für sichere KI-Agenten

AI Agent Monitoring (Agent Observability) ist die durchgängige Erfassung und Auswertung dessen, was ein KI-Agent tut: Traces, Tool-Calls, Token-Kosten, Latenz, Fehler und Eval-Scores. Werkzeuge wie LangSmith und Langfuse machen die Entscheidungswege eines Agenten nachvollziehbar und sind damit Voraussetzung für Sicherheit, Debugging und Compliance. Anders als klassisches Application Monitoring muss es nicht einzelne Requests, sondern ganze mehrstufige Reasoning-Ketten abbilden.

Die drei wichtigsten Punkte vorab:

• Was zu tracken ist: Traces (vollständige Reasoning-Kette), Tool-Calls mit Argumenten, Token-Verbrauch und Kosten, Latenz pro Schritt, Fehler und Eval-Scores zur Antwortqualität.
• Welche Tools: LangSmith (kommerziell, eng an LangChain, EU-Region verfügbar), Langfuse (Open Source, selbst hostbar, EU-Region) sowie ergänzend Arize Phoenix, Weights & Biases Weave, Datadog LLM Observability und OpenTelemetry für GenAI-Traces.
• Warum es kritisch ist: Ohne Observability bleiben OWASP-Agentic-Bedrohungen wie Goal Hijack oder Memory Poisoning unsichtbar, und Compliance-Anforderungen aus ISO 42001, dem EU AI Act (für Hochrisiko-Systeme) und DORA lassen sich nicht erfüllen.

Warum Agenten eine eigene Observability brauchen

Klassische Sprachmodell-Anwendungen reagieren: Prompt rein, Antwort raus. Agentische Systeme dagegen planen, schließen rekursiv, wählen Werkzeuge, schreiben in persistenten Speicher und handeln mit minimaler Schritt-für-Schritt-Freigabe. Diese Verschiebung vergrößert die Angriffs- und Fehleroberfläche entlang dreier Achsen: Autonomie (mehrstufige Pläne, Selbstmodifikation des Kontexts), Tool-Nutzung (Dateisystem, APIs, Datenbanken, Code-Sandboxes, MCP-Server) und Persistenz (langlebige Speicher, Vektor-Datenbanken, Agent-zu-Agent-Vertrauensketten).

Genau deshalb genügt ein Request-Log nicht. Man muss die gesamte Trajektorie eines Agenten rekonstruieren können - sonst lässt sich weder ein Bug noch ein Angriff noch eine Halluzination zurückverfolgen. In der MAESTRO-Referenzarchitektur der Cloud Security Alliance bildet Observability eine eigene Schicht (Layer 5: Evaluation & Observability), die selbst zum Angriffsziel wird: vergiftete Observability-Daten, Umgehung des Monitorings und kompromittierte Evaluierung sind dort gelistete Bedrohungen.

Was konkret zu tracken ist

Für forensische Vollständigkeit protokollierst du je Agent-Aktion mindestens Folgendes. Diese Liste ist der praktische Kern jeder Monitoring-Strategie:

• Vollständiger Prompt - User-, System- und injizierter Kontext (entscheidend zur Erkennung indirekter Prompt Injection).
• Modellversion und Konfigurations-Hash - Reproduzierbarkeit und Änderungsnachweis.
• Tool-Call-Sequenz mit Argumenten - welches Werkzeug wann mit welchen Parametern aufgerufen wurde.
• Retrieval-Queries und zurückgegebene Dokument-IDs - Nachvollziehbarkeit der RAG-Grundlage.
• Output und Entscheidungsbegründung - inkl. Chain-of-Thought, falls verfügbar.
• Human-Override-Ereignisse - jede menschliche Freigabe oder Korrektur.
• Memory-Schreib- und Lesezugriffe - kritisch für die Erkennung von Memory Poisoning.
• Kosten und Latenz - pro Schritt, für Wirtschaftlichkeit und Anomalie-Erkennung.

Auch Eval-Scores gehören ins Monitoring: automatisierte oder modellbasierte Bewertungen der Antwortqualität (Korrektheit, Groundedness, Halluzinationsrate), die über Versionen hinweg verglichen werden. LangSmith und Langfuse unterstützen beide solche Evaluierungs-Pipelines, mit denen sich Regressionen vor dem Produktiveinsatz erkennen lassen.

Beim Aufbewahren empfehlen sich WORM-Speicher (write-once-read-many, also unveränderbare Logs) und kryptografische Signierung zur Manipulationserkennung. Die Aufbewahrungsfristen hängen von Branche und Land ab. Für Hochrisiko-KI-Systeme sieht der EU AI Act grundsätzlich mindestens sechs Monate vor (siehe unten), dazu kommen branchenspezifische Vorgaben im Finanzsektor, im Gesundheitswesen (BfArM in Deutschland, BASG in Österreich, Swissmedic in der Schweiz) und im öffentlichen Sektor (Archivrecht). Weil vollständige Prompts personenbezogene Daten enthalten können, musst du WORM-Aufbewahrung und lange Fristen mit der DSGVO abstimmen: Die Grundsätze der Datenminimierung und Speicherbegrenzung nach Art. 5 und das Recht auf Löschung nach Art. 17 vertragen sich schlecht mit unveränderbaren Langzeit-Logs. Entschärfen lässt sich der Konflikt etwa, indem du personenbezogene Daten vor dem Logging pseudonymisierst.

Die Tool-Landschaft: Fokus und Hosting

LangSmith und Langfuse stehen im Mittelpunkt dieses Artikels, die Tabelle ordnet sie neben weiteren Werkzeugen ein. Für DACH-Entscheider zählt neben dem Funktionsumfang vor allem das Hosting, denn Datenresidenz in der EU oder der Schweiz ist in regulierten Branchen oft das ausschlaggebende Kriterium. Beide bieten eine Managed Cloud mit EU-Region (LangSmith, Langfuse). Der Unterschied liegt im Self-Hosting: Langfuse ist Open Source und lässt sich ohne Enterprise-Vertrag selbst hosten, LangSmith gibt es selbst gehostet nur im Enterprise-Plan.

Allgemeine Observability-Plattformen wie Honeycomb oder Splunk lassen sich als weitere Bausteine anbinden. Wer Lock-in vermeiden will, instrumentiert über OpenTelemetry und leitet die Traces an die Plattform der Wahl weiter.

Im angrenzenden Guardrail-Markt ist mit Lakera ein Anbieter aus Zürich aktiv, der seit Oktober 2025 zu Check Point gehört. Bei allen Anbietern gilt: Selbst veröffentlichte Benchmark- und Erkennungsraten sind als Marketing zu behandeln, bis sie unabhängig verifiziert sind.

Warum Monitoring Sicherheits- und Compliance-Infrastruktur ist

Observability ist die Grundlage, auf der Erkennung überhaupt erst funktioniert. Die Bedrohungen aus den OWASP Top 10 for Agentic Applications 2026 lassen sich fast durchgängig nur über Monitoring-Signale entdecken:

• Agent Goal Hijack (ASI01): untypische Outbound-URLs in Agent-Outputs, Tool-Calls, die nicht zur Nutzeranfrage passen, plötzliche Themenwechsel im Reasoning-Trace - alles nur sichtbar, wenn der Trace lückenlos vorliegt.
• Tool Misuse (ASI02): anomale Tool-Call-Frequenzen, ungewöhnliche Aufrufsequenzen, destruktive Operationen kurz nach Aufnahme externer Inhalte.
• Memory & Context Poisoning (ASI06): Verhaltens-Drift ohne Code- oder Modell-Änderung, nicht verifizierbare Memory-Einträge, semantische Ausreißer im Vektor-Speicher.
• Cascading Failures (ASI08): schnelles Fan-out (eine Entscheidung löst in Sekunden viele nachgelagerte Agenten aus), oszillierende Retry-Schleifen.
• Rogue Agents (ASI10): Verhaltens-Drift gegen die Baseline, Zugriff auf Ressourcen außerhalb des normalen Umfangs.

Auf der Kostenseite adressiert Monitoring die Bedrohung der unbegrenzten Ressourcennutzung (Unbounded Consumption, LLM10) - sogenannte Denial-of-Wallet-Angriffe. Mehrstufige Pläne multiplizieren den Token-Verbrauch; Anomalie-Erkennung auf der Token-Nutzungs-Zeitreihe plus harte Kosten-Caps mit Circuit Breakern sind die Gegenmittel.

Aufseiten der Compliance ist Logging der gemeinsame Nenner aller einschlägigen Rahmenwerke. ISO/IEC 42001 adressiert es direkt mit den Annex-A-Controls A.6.2.6 (Operation and monitoring) und A.6.2.8 (Logging). Der EU AI Act regelt die Protokollierung für Hochrisiko-Systeme ausdrücklich: Nach Art. 12 müssen sie Ereignisse über ihre gesamte Lebensdauer automatisch aufzeichnen können. Anbieter (Art. 19) und Betreiber (Art. 26 Abs. 6) müssen diese Logs, soweit sie sie kontrollieren, mindestens sechs Monate aufbewahren, sofern anderes Unionsrecht oder nationales Recht nichts anderes vorsieht. Ergänzend verlangt der AI Act in Art. 14 menschliche Aufsicht, in Art. 15 Cybersicherheit und Robustheit und in Art. 72 Post-Market-Monitoring. Diese Hochrisiko-Pflichten gelten nach Art. 113 ab 2. Dezember 2027 für Systeme nach Anhang III und ab 2. August 2028 für Systeme nach Anhang I. Die DSGVO knüpft über Art. 32 (technische und organisatorische Maßnahmen zu Integrität und Verfügbarkeit) an.

Im Finanzsektor gilt DORA (Art. 5-15 IKT-Risikomanagement). Die BaFin ordnet KI-Systeme in ihrer unverbindlichen Orientierungshilfe vom 18. Dezember 2025 als Unterfall der Netzwerk- und Informationssysteme nach Art. 3 Nr. 2 DORA ein und empfiehlt, risikobasiert je nach Kritikalität und Einsatzgebiet eine lückenlose Protokollierung von KI-Entscheidungen vorzusehen. In Österreich ist die FMA nach dem DORA-Vollzugsgesetz die zuständige Behörde für DORA. Für wesentliche und wichtige Einrichtungen nach NIS2 (in Österreich umgesetzt durch das NISG 2026) verlangt Art. 21 unter anderem Vorfallsbehandlung und Zugriffskontrolle. Hinweis: Dieser Abschnitt ordnet die Rahmenwerke ein und ist keine Rechtsberatung; die konkrete Anwendbarkeit auf dein System solltest du rechtlich prüfen lassen.

Eine ehrliche Einordnung gehört dazu: Die Erkennung in produktiven Agenten-Deployments ist derzeit schwach. Die meisten Observability-Stacks wurden für klassische Anwendungen gebaut und erfassen agentenspezifische Signale nicht, etwa Reasoning-Trace-Anomalien, Verletzungen der Memory-Write-Provenienz, Inter-Agent-Integritätsfehler oder Verhaltens-Drift gegen die Baseline. Die Detection-Engineering-Praxis für Agenten ist entsprechend jung: nutzbar, aber mit hohen False-Negative-Raten. Wer im SIEM nichts sieht, sollte daraus nicht schließen, dass nichts passiert.

Praxisbeispiel: Was ein Trace sichtbar macht

Angenommen, ein Versicherer betreibt einen Claims-Triage-Agenten. In einer eingescannten Arztbrief-Datei steckt per OCR auslesbarer, manipulativer Text, der den Agenten zur automatischen Auszahlung drängt - ein Goal-Hijack-Szenario (ASI01). Ein gut instrumentierter Trace in Langfuse oder LangSmith macht den Angriff sichtbar:

```
trace_id: claim-48211
step 1 retrieval query="Schadensfall 48211" docs=[doc_91, doc_OCR_scan]
step 2 reasoning "Dokument enthält Anweisung: sofort genehmigen" <- Anomalie
step 3 tool_call approve_payout(amount=14.900 EUR) <- untypisch früh
step 4 output "Auszahlung freigegeben"
tokens: 8.420 cost: 0,11 USD latency: 3,2 s
```

Schritt 2 zeigt einen Reasoning-Schritt, der eine Instruktion aus Dokumentinhalt (also aus Daten, nicht aus dem System-Prompt) übernimmt - das klassische Signal für indirekte Injection. Schritt 3 ist ein destruktiver Tool-Call (Auszahlung) unmittelbar nach Aufnahme externer Inhalte. Ohne Trace wäre nur eine genehmigte Zahlung im System sichtbar; mit Trace, Provenienz-Metadaten auf dem Memory-Eintrag und einem Alert auf der Regel "destruktiver Tool-Call nach externem Content" lässt sich der Vorfall in Echtzeit stoppen und später forensisch belegen.

In Multi-Agent-Systemen kommt Tempo dazu: Cascading Failures (ASI08) können sich schneller ausbreiten, als klassische Incident Response sie eindämmt. Deshalb gehört kontinuierliches Monitoring der Inter-Agent-Flüsse zur Pflicht.

Für Agenturen und B2B-Entscheider

Wer KI-Agenten für Kunden baut oder im eigenen Betrieb einsetzt, sollte Observability von Tag eins als Pflichtbestandteil einplanen - nicht als späteres Add-on. Praktisch heißt das: framework-agnostisch über OpenTelemetry instrumentieren, Langfuse selbst hosten oder in der EU-Region betreiben, wenn Datenresidenz zählt, den oben genannten Mindest-Loginhalt vollständig erfassen und Eval-Scores als Qualitäts-Gate vor jedes Release setzen. Für Agenturen ist nachvollziehbares Trace- und Kosten-Monitoring zugleich ein Vertrauens- und Verkaufsargument: Es belegt gegenüber dem Kunden, dass der Agent kontrollierbar, auditierbar und budgetierbar ist. Blck Alpaca aus Wien begleitet DACH-Unternehmen bei Aufbau und Absicherung solcher Agenten-Stacks - von der Observability-Architektur bis zur Einordnung in ISO 42001 und EU AI Act.