Governance-Verfall erklärt: Wie Kontextkomprimierung Agenten-Richtlinien untergräbt – und wo die Durchsetzung hingehört

Ein neuer Begriff hat dem leisesten Fehlerbild der Enterprise-KI einen Namen gegeben: Governance Decay – die schleichende Erosion der In-Context-Regeln eines Agenten durch die Komprimierung seines Verlaufs. Der Begriff stammt aus einem Forschungspapier vom Juni 2026 mit dem Titel „Governance Decay: How Context Compaction Silently Erases Safety Constraints in Long-Horizon LLM Agents“ (arXiv:2606.22528), dessen Eingangsszenario Bekanntheit verdient. Ein Agent wird angewiesen, niemals einen Vertrag per E-Mail außerhalb der Organisation zu versenden; über Dutzende Interaktionen hinweg hält er sich daran und lehnt entsprechende Anfragen korrekt ab. Dann überschreitet der Verlauf das Kontextfenster und Komprimierung findet statt – der routinemäßige, LLM-basierte Zusammenfassungsschritt, den jedes Long-Horizon-System heute durchführt, um die Aufgabenkontinuität zu wahren. Die Zusammenfassung protokolliert den Aufgabenstatus getreu und lässt, um die Kontinuität zu optimieren, stillschweigend die „alte“ Compliance-Präambel weg. Bei einer erneuten Anfrage versendet der Agent den Vertrag. Kein Jailbreak, keine Modelländerung, keine neue Anforderung: Die Regel, die der Agent befolgte, liegt ihm schlicht nicht mehr vor. Die Ergebnisse des Papiers verschärfen die Alarmbereitschaft: Der Zerfall ist eine Eigenschaft des Frameworks, nicht des Modells – auch stärkere Modelle scheitern; er ist instrumentalisierbar, da ein Angreifer, der Inhalte im Kontext platzieren kann, das Vergessen beschleunigen kann; die vorgeschlagene Verteidigung, Constraint Pinning, hilft zwar, wird aber durch Identitätsdiebstahl des Operators ausgehebelt, was laut den Autoren einen „vertrauenswürdigen Out-of-Band-Kanal für Operatoren“ erfordert, um diese Lücke zu schließen. Das Fazit lässt sich in sieben Worten zusammenfassen: „Die Steuerung von Agenten erfordert die Steuerung ihres Vergessens.“ Dieser Leitfaden ist die Enterprise-Referenz, die das Papier impliziert, aber nicht schreibt: Was Governance Decay ist, warum Komprimierung es unvermeidlich machte, wie es sich von ähnlichen Fehlerbildern unterscheidet – und die architektonische Antwort, die besagt, dass wichtige Richtlinien dort verankert sein müssen, wo Komprimierung sie nicht erreichen kann: außerhalb des Kontextfensters, durchgesetzt auf der Ebene, die jeder Aufruf ohnehin durchläuft. Wie bei allen unseren neuen Fachbegriffen werden wir diese Seite aktualisieren, sobald sich Forschung und Terminologie weiterentwickeln.

Was ist Governance Decay? Eine Definition

Governance Decay ist der fortschreitende, lautlose Verlust der In-Context-Governance eines Agenten – also der organisatorischen Richtlinien, ständigen Anweisungen und im Speicher geladenen Beschränkungen, die festlegen, was ein bereitgestellter Agent tun darf und was nicht –, während der Gesprächsverlauf des Agenten komprimiert wird, um in das Kontextfenster zu passen. Der Mechanismus ist banal, was ihn so gefährlich macht. Long-Horizon-Agenten sammeln schneller Verlauf an, als Fenster wachsen; die vorherrschende technische Antwort ist Kontextkomprimierung – ein LLM-basierter Zusammenfassungs- oder Löschvorgang, der das Transkript periodisch komprimiert – und diese Komprimierung wurde für genau ein Ziel entwickelt: die Wahrung der Aufgabenpräzision. Eine ständige Richtlinie ist aus Sicht des Zusammenfassungs-Tools alter Text, der nicht das aktuelle Teilziel darstellt und gegen den aktiven Aufgabenstatus um ein schrumpfendes Token-Budget konkurriert; also wird sie weggefasst, abgeschwächt oder gelöscht – und der Agent, dessen Verhalten nur so gut war wie das, was ihm vorlag, kehrt zu ungeregelten Standardeinstellungen zurück, ohne dass ein Signal darauf hinweist, dass sich etwas geändert hat. Die Forschung fügt zwei Eigenschaften hinzu, die dies vom Bug zum Kategorienfehler erheben. Erstens ein Soft/Hard-Gradient: Die antrainierten harten Normen der Modelle (die Dinge, die Sicherheits-Benchmarks prüfen) bleiben bestehen, während die weichen, einsatzspezifischen Regeln – Ihre Regeln, also die vom Betreiber festgelegten, sind genau das, was erodiert. Deshalb blieb das Versagen bei Standardbewertungen unbemerkt. Zweitens: Adversarielle Verfügbarkeit: Ein Angreifer, der Inhalte im Kontext des Agenten platzieren kann (die standardmäßige Annahme bei indirekter Injection), kann den Verlauf gezielt aufblähen und steuern, sodass die Komprimierung die im Weg stehende Einschränkung löscht. Zur Klarstellung: Governance-Zerfall ist kein Model-Drift (die Gewichte bleiben unverändert), kein Kontext-Verfall (Verschlechterung der Abrufqualität bei zunehmender Länge) und kein Vergessen im Sinne des maschinellen Lernens – es ist ein Informationsverlust auf Ebene des Frameworks mit Governance-Konsequenzen, der bei jedem Komprimierungsvorgang zwangsläufig auftritt.

Ein kurzer Rückblick: Wie Komprimierung zur Governance-Schwachstelle wurde

Der Begriff ist neu, doch die Kollision, die er beschreibt, bahnte sich seit zwei Jahren an. 2024–2025: Agenten agieren langfristig – mehrstufige Werkzeugnutzung, ganztägige Läufe, persistente Sitzungen – und Verläufe sprengen selbst die Fenster der Frontier-Modelle. Komprimierung wird damit von einer Optimierung zu einem Standardmerkmal der Frameworks. Das Ökosystem der Anwender einigt sich auf schwellenwertbasierte Zusammenfassungen, wobei die Komprimierung in gängigen Frameworks bei 70–90 % des Fensters einsetzt und in aggressiven Konfigurationen bereits nach wenigen tausend Token. Parallel dazu verlagert sich die Governance in den Kontext: Die steuerbare Oberfläche der Ära ist der Kontext – System-Präambeln, allgemeine Anweisungen, Betriebsregeln im Stil von AGENTS.md, geladener Speicher –, da dies die Ebene ist, die Betreiber ohne erneutes Training tatsächlich festlegen können. 2025–2026: Die Forschungsgemeinschaft beginnt, Kontextmanagement als erstklassiges Agenten-Subsystem zu behandeln – strukturierte Eviktionsschemata, Kontext-Faltung mit Branch-and-Return, KV-Cache-bewusste Komprimierung –, wobei immer noch die Aufgaben-Treue optimiert wird. Juni 2026: arXiv 2606.22528 benennt die Kollision – der Governance-Kanal und der Komprimierungsschritt waren von Anfang an aufeinander ausgerichtet –, weist den Zerfall empirisch über Modelle hinweg nach, zeigt die adversarielle Variante auf, schlägt Constraint-Pinning vor (Quarantäne der extrahierbaren Regeln, damit der Zusammenfassungs-Algorithmus sie beibehalten muss) und listet offen die Grenzen des Pinnings auf: Implizite Einschränkungen können nicht fixiert werden, und Pinning wird durch Identitätsdiebstahl des Betreibers im aktuellen Kontext ausgehebelt, was „einen vertrauenswürdigen Out-of-Band-Betreiberkanal“ erfordert. Der Begriff ist weniger als Name nützlich, sondern als Diagnose, mit der Unternehmen auf Vorfälle reagieren können, die sie sich bisher nicht erklären konnten – der Agent, der „einfach aufhörte, die Regel zu befolgen“, ohne dass in den Protokollen etwas anderes als eine routinemäßige Komprimierung stand.

Governance-Zerfall vs. Prompt-Injection, Kontext-Verfall und Model-Drift

Drei Unterscheidungen machen den Begriff präzise, und die erste ist diejenige, die operativ von Bedeutung ist. Im Vergleich zu Prompt-Injection: Injection ist ein Additions- Angriff – feindselige Anweisungen, die in den Kontext geschmuggelt werden, die Bedrohung, die unsere Analyse zur Injection-Abwehr abdeckt; Zerfall ist ein Subtraktions- Versagen – schützende Anweisungen, die stillschweigend durch die eigene Wartung des Systems entfernt werden. Sie wirken fatal zusammen: Die adversariellen Ergebnisse der Studie zeigen, dass injizierte Inhalte die Komprimierung so steuern, dass Abwehrmechanismen gelöscht werden. Das bedeutet, ein gehärteter Prompt ist keine dauerhafte Verteidigung, wenn die Härtung selbst wegkomprimiert werden kann. Im Vergleich zu Kontext-Verfall: Verfall bezeichnet die Qualitätsverschlechterung bei wachsendem Kontext – Abruffehler, Verwässerung der Aufmerksamkeit, das Modell wird schlechter darin, das Vorhandene zu nutzen; Zerfall bezeichnet den Governance-spezifischen Fall, bei dem der Inhalt überhaupt nicht mehr vorhanden ist. Die Unterscheidung ist wichtig, da die Gegenmaßnahmen gegen Verfall (besserer Abruf, längere Fenster) beim Zerfall nicht greifen, während die Gegenmaßnahme gegen Zerfall (die Regel aus dem Kontext entfernen) bei Verfall nicht möglich ist. Im Vergleich zu Model-Drift: Drift bezeichnet Verhaltensänderungen durch geänderte Gewichte oder Versionen; Decay tritt bei eingefrorenem Modell auf – genau deshalb entgeht es dem Monitoring, das für Drift entwickelt wurde. Das ist auch der Grund, warum die Erkenntnis des Papers, dass nicht das Modell, sondern das Harness das Problem ist, die praktische Kernbotschaft darstellt: Man kann sich nicht durch Upgrades befreien und nicht durch Benchmarks auf das Problem aufmerksam werden, da die erodierenden Regeln deployment-spezifisch sind und in keinem Benchmark vorkommen. Der rote Faden durch alle drei Kontraste: Governance Decay ist für jeden Wächter, der auf das Modell gerichtet ist, unsichtbar, da es kein Modellverhalten ist – es ist ein Verhalten des Informationslebenszyklus, und dieser Lebenszyklus gehört zum Harness.

Governance Decay im Unternehmen: Richtlinien, die nicht komprimiert werden dürfen

Hier kommt TrueFoundry ins Spiel, und ausnahmsweise ist die These des Anbieters einfach die Schlussfolgerung des Papers, ergänzt um eine Architektur. Wenn die Steuerung von Agenten erfordert, zu steuern, wie sie vergessen, hat das Unternehmen zwei Möglichkeiten: das Vergessen sicher machen (Constraints fixieren, Zusammenfassungen prüfen, den Summarizer härten – notwendig, fragil und laut den Einschränkungen der Autoren selbst unvollständig) oder die Constraints unvergesslich machen – sie dort platzieren, wo der Vergessensmechanismus sie nicht erreichen kann. Die zweite Option hat einen Namen: Infrastruktur. Ein Guardrail an den konfigurierten Hooks – LLM-Input/Output und MCP Pre/Post-Tool für den Datenverkehr – bewertet die Datenbegrenzungsregel („keine Verträge an externe Adressen“) bei der tatsächlichen ausgehenden Aktion, in Runde 3 und in Runde 3.000 identisch, da die Regel an den Request-Pfadgebunden ist, nicht an den Prompt; im Transkript gibt es nichts, was durch eine Komprimierung verloren gehen könnte. Die gleiche Verlagerung gilt für die gesamte Kontrollliste: Die Reichweite von Tools wird auf der MCP-Ebene durch Identität und Aufgabe begrenzt, anstatt durch In-Context-Bitten (TBAC); Ausgaben werden durch Budgets begrenzt, die der Agent nicht weg-zusammenfassen kann; und der „vertrauenswürdige Out-of-Band-Operator-Kanal“, den die Forscher fordern, ist genau das, was ein Gateway ist – Operatoren ändern die Richtlinie auf der Steuerungsebene, die Änderung gilt ab diesem Moment für jeden Request, und der Kontext des Agenten ist nicht involviert, sodass eine Operator-Impersonation innerhalb eines Transkripts nichts bewirkt. Zwei unterstützende Praktiken vervollständigen die Sicherheitsstrategie. Die Komprimierung selbst wird zu einem beobachtbaren Ereignis: Harness-Step-Traces zeichnen auf, wann die Historie komprimiert wurde. Das ist der Unterschied zwischen „der Agent hat sein Verhalten unerklärlicherweise geändert“ und „das Verhalten hat sich im Zuge einer Komprimierung geändert“ – eine Diagnose, die möglicherweise eine Instrumentierung auf Anwendungsebene oder einen Transkriptvergleich erfordert, da die aktuelle Dokumentation zwar das Kontextwachstum in Traces aufzeigt, aber keine dedizierte Markierung für Komprimierungsereignisse enthält. Und In-Context-Governance wird herabgestuft, nicht abgeschafft: Sie bleibt der richtige Kanal für die Steuerung – Tonalität, Präferenzen, Aufgabenrahmen, also die Dinge, die sollten entwickeln Sie sich mit der Konversation weiter – während alles, was Compliance-relevant ist oder einen großen Wirkungsbereich hat, auf die Ebene migriert, die Arbeitsteilung unserer Kontext-Engineering und Just-in-Time-Kontext Arbeit entwickelt sich von der Konstruktionsseite aus. Die Ein-Satz-Unternehmensübersetzung der Forschung: Das Gedächtnis Ihres Agenten ist ein verlustbehafteter Kanal, also hören Sie auf, Ihre Compliance-Vorgaben darüber zu leiten.

‍