29.03.2026
Aktualisiert 27.07.2026
Threat
Cascading Failures
Lokale Fehler oder manipulierte Zustände können sich über Handoffs, Memory, Tools und Folgeagenten ausbreiten und zu systemischem Schaden eskalieren.
Was Cascading Failures sind
Cascading Failures sind Fehlerkaskaden, bei denen ein lokaler Defekt nicht isoliert bleibt. Ein falscher Output, manipulierter Kontext oder fehlerhafter Tool-Rückgabewert wird über Handoffs, Shared Memory, Queues und Folgeagenten weiterverwendet.
In agentischen Systemen werden Ausgaben häufig direkt zu Eingaben oder Aktionen im nächsten Schritt. Ohne Validierung und Stop-Grenzen kann deshalb ein kleiner Ursprungsfehler weit entfernt von seiner Quelle Daten, Berechtigungen und produktive Prozesse beeinträchtigen.
Wie die Fehlerkaskade entsteht
Auslöser können Angriffe wie Prompt Injection und Memory Poisoning sein. Ebenso möglich sind Halluzinationen, Timeout-Fallbacks, falsche Tool-Ergebnisse oder Orchestrierungsfehler.
Ursprungsfehler
Ein Ergebnis oder Zustand ist falsch
Ungeprüfter Handoff
Der nächste Agent übernimmt die Annahme
Ausbreitung
Memory, Tools und Queues tragen sie weiter
Systemwirkung
Mehrere Prozesse handeln fehlerhaft
Mögliche Folgen
Gemeinsame Zustände werden verfälscht
Tools führen Folgefehler aus
Betriebsabläufe fallen aus
Kritisch ist nicht nur der Trigger, sondern die fehlende Begrenzung zwischen den Schritten. Unsichere Übergaben verbinden das Risiko daher eng mit Insecure Inter-Agent Communication und Tool Misuse.
Lokaler Fehler oder Fehlerkaskade?
Begrenzt
Lokaler Fehler
Ein einzelner Agent oder Schritt erzeugt ein falsches Ergebnis, das an seiner Grenze gestoppt wird.
Blast Radius bleibt auf einen Schritt begrenzt
Ursache und Wirkung liegen nah beieinander
Systemisch
Cascading Failure
Mehrere Komponenten übernehmen denselben falschen Zustand und verstärken seine Wirkung.
Symptome treten weit vom Startpunkt entfernt auf
Retries und Parallelität können die Kaskade beschleunigen
Der ursprüngliche Fehler kann funktional oder bösartig sein. Zur Sicherheitsbedrohung wird er durch unkontrollierte Propagation und reale Folgewirkung.
Drei typische Fehlerszenarien
Ein falsches Ticket vergiftet Folgeprozesse
SupportMehrere Agenten übernehmen dieselbe falsche Risikoeinstufung und lösen unnötige Sperren oder Benachrichtigungen aus.
Ein Tool-Fehler verändert Zahlungen
FinanceEin fehlerhafter Rückgabewert wird nicht plausibilisiert und fließt in Freigabe, Buchung und Reporting ein.
Ein riskanter Fix erreicht die Produktion
DevOpsReview-Agent, Test-Agent und Deployment vertrauen demselben fehlerhaften Zwischenresultat und vervielfachen den Schaden.
Was wirklich schützt
Resilienz entsteht durch Grenzen an jedem Übergang. Teams müssen Fehler früh zurückweisen, ihre Reichweite begrenzen und laufende Kaskaden kontrolliert stoppen können.
Nachrichten, Tool-Ergebnisse und Zustände gegen Schemas, Provenienz, Plausibilität und erlaubte Empfänger prüfen.
Agenten, Datenräume, Queues und Tool-Rechte segmentieren; Retries, Fan-out und Budgets verbindlich beschränken.
Circuit Breaker, sichere Checkpoints, Rollback und einen getesteten Kill Switch für kritische Workflows vorsehen.
Ein Fehler darf einen Handoff erreichen. Er darf sich aber nicht unbegrenzt vervielfachen oder irreversible Aktionen ohne unabhängige Kontrolle auslösen.
Kritische Aktionen brauchen zusätzlich Human-in-the-Loop. Korrelierbare Trace-IDs, Zustandsänderungen und Tool-Ereignisse aus Monitoring & Observability verkürzen Erkennung und Wiederherstellung.
Wie Teams Kaskaden erkennen und testen
- Übergaben überwachen: Schemafehler, neue Kommunikationspfade und ungewöhnliche Handoff-Raten alarmieren.
- Gemeinsame Symptome korrelieren: Retries, Queue-Lag, Kosten, Tool-Fehler und menschliche Overrides entlang einer Trace-ID verbinden.
- Zustandsausbreitung verfolgen: Herkunft und Leser von Memory-, RAG- und Workflow-Änderungen erfassen.
- Failure Injection einsetzen: Falsche Tool-Werte, Timeouts und vergiftete Handoffs gegen Isolation, Circuit Breaker und Rollback testen.
Früherkennung funktioniert an den Übergabepunkten besser als am finalen Output. Agent Observability muss deshalb Ursprung, Ausbreitung und Endwirkung gemeinsam zeigen.