CGB-1 · 6 Controls
Sensitivität & Schwärzung
Zugangsdaten, personenbezogene Daten und regulierte Identifikatoren dürfen die Vertrauensgrenze niemals überschreiten. Erkennung, Schwärzung und die Garantien drumherum.
Offener Standard · v1.0-draft
Wie sieht eine kontrollierte Kontext-Pipeline eigentlich aus?
CIS-Benchmarks definieren, was ein gehärteter Server ist. Der Context Governance Benchmark definiert, was eine kontrollierte Kontext-Pipeline ist: 32 messbare, tool-neutrale Controls über 6 Domänen, bewertet in vier Reifegraden. Zitierbar von Security-Teams, Einkauf und Presse – kostenlos unter CC-BY 4.0.
Status: v1.0-draft, vor Review. Der Katalog ist veröffentlicht und offen für Feedback; v1.0-final erfordert ≥ 3 benannte externe Reviewer. Bis dahin zitiere ihn nicht als veröffentlichten Standard – zitiere den Draft.32 Controls, 6 Domänen.
Jedes Control benennt eine Anforderung, warum sie zählt, eine konkrete Messmethode und ein Level. Drei Level bauen aufeinander auf: Basic (die 12-Control-Untergrenze), Hardened (15 Controls für Kunden- oder regulierte Daten) und Audited (5 Controls mit durch Dritte verifizierbarer Zusicherung).
CGB-2 · 5 Controls
Provenienz & Integrität
Für jede Modell-Interaktion: Was gelangte in den Kontext, woher kam es, wurde es verändert? Quellenangabe, Offenlegung von Transformationen, Manipulationsnachweis.
CGB-3 · 5 Controls
Budget- & Ressourcenkontrolle
Ein Prompt fächert in viele Tool-Calls und Sub-Agents auf. Limits, Zuordnung und das Stoppen ausufernden Verbrauchs – vor der Rechnung.
CGB-4 · 6 Controls
Audit & Nachweis
Governance-Aussagen sind nur so stark wie die Aufzeichnungen dahinter. Was protokolliert wird, wie es geschützt ist und ob ein Dritter es verifizieren kann.
CGB-5 · 5 Controls
Zugriffs-Scoping
Worauf darf ein Agent zugreifen, auf wessen Autorität? Grenzen für Dateisystem, Befehlsausführung, Netzwerk und Tool-Oberfläche – Assistent, keine unauditierte Root-Shell.
CGB-6 · 5 Controls
Lebenszyklus & Aufbewahrung
Caches, Session-Stores, Langzeitspeicher, geteiltes Wissen: wie akkumulierter Zustand begrenzt, abgelaufen, gelöscht und über die Zeit ehrlich gehalten wird.
Vier Grade, kein C0 zum Verstecken.
Controls werden mit Met (1.0), Partial (0.5, Lücke beschrieben) oder Not met (0) bewertet. Der Score eines Levels ist Punkte über den anwendbaren Controls. Der Grad ist die höchste Schwelle, die die Pipeline erreicht – unter C1 ist sie schlicht ungradiert.
Foundational
Basic ≥ 75%
Managed
Basic ≥ 90% und Hardened ≥ 50%
Hardened
Basic = 100%, Hardened ≥ 80%, Audited ≥ 40%, jedes Met-Control verlinkt Nachweise
Audited
Basic = 100%, Hardened = 100%, Audited ≥ 80%, unabhängig verifiziert
Ab C3 verlinkt jede Met-Aussage Nachweise, die ein Reviewer öffnen kann. Ab C4 wird die Bewertung selbst unabhängig verifiziert – Selbstbewertungen enden per Design bei C3.
The benchmark for responsible AI context management.
Wir bewerten uns selbst C2 – und zeigen die Lücken.
Die Spec ist tool-neutral; dieser Teil ist es nicht. LeanCTX bewertet sich gegen v1.0-draft mit C2 – Managed: Basic 96% · Hardened 80% · Audited 50%. Wo eine Aussage nicht hart verifiziert werden konnte, wird das Control herab- statt heraufgestuft.
Veröffentlichte Lücken umfassen CGB-1.4 (fail-closed-Schwärzungsabdeckung ist konventionell, nicht strukturell durch ein CI-Gate bewiesen) und mehrere Controls auf Audited-Level, die auf Verifikation durch Dritte warten. Die vollständigen Befunde pro Control – inklusive jedes Partial und Not met – stehen in der öffentlichen Selbstbewertung.
Bewerte dein eigenes Setup: lean-ctx policy coverage --benchmark cgb prüft deinen aufgelösten Policy-Pack statisch gegen die testbaren Controls – synthetische Fixtures, kein Vertrauen auf Pattern-Namen.
Versioniert wie eine Spec.
Control-IDs sind dauerhaft und werden nie wiederverwendet. Substanzielle Änderungen durchlaufen einen RFC-light-Prozess mit 14-tägigem Kommentarfenster und protokolliertem Widerspruch. Der Katalog wird jährlich überarbeitet; Drafts sind stets gekennzeichnet. Lizenz: CC-BY 4.0.
Review-Board – offener Aufruf. v1.0-final erscheint, sobald ≥ 3 benannte externe Reviewer (Praktiker aus Security, Compliance oder Platform-Engineering, ohne kommerzielles Single-Vendor-Interesse) jede Domäne durchgearbeitet haben. Reviewer werden auf der veröffentlichten Spec genannt. Per Issue mitmachen →
Der Benchmark, beantwortet. answered.
The standard, its scoring, and how to assess a context pipeline.
Ein versionierter, tool-neutraler Katalog aus 32 messbaren Controls über 6 Domänen (Sensitivität & Schwärzung, Provenienz, Budgetkontrolle, Audit & Nachweis, Zugriffs-Scoping, Lebenszyklus & Aufbewahrung), der definiert, was eine kontrollierte Kontext-Pipeline ist – so wie CIS-Benchmarks definieren, was ein gehärteter Server ist. Er ist unter CC-BY 4.0 veröffentlicht und in vier Reifegrade C1 bis C4 bewertet.
LeanCTX-Maintainer pflegen die Spec, aber die Controls sind bewusst tool-neutral: kein LeanCTX-Konzept taucht in einem Control auf, ein Neutralitäts-Linter erzwingt das in der CI, und jeder Anbieter oder jede interne Pipeline kann sich selbst bewerten. LeanCTX veröffentlicht seine eigene Selbstbewertung als separates Dokument – inklusive der Lücken.
Gegen v1.0-draft bewertet sich LeanCTX mit C2 – Managed (Basic 96%, Hardened 80%, Audited 50%), mit veröffentlichten Lücken: darunter ist die fail-closed-Schwärzungsabdeckung konventionell statt strukturell bewiesen, und mehrere Controls auf Audited-Level brauchen Verifikation durch Dritte. Ein perfekter Selbst-Score würde mehr über die Bewertung aussagen als über das Produkt.
Nein – v1.0-draft ist veröffentlicht und offen für Review. Das Release wird zu v1.0-final, sobald mindestens drei benannte externe Reviewer (Praktiker aus Security, Compliance oder Platform-Engineering) jede Domäne durchgearbeitet haben. Bis dahin müssen Bewertungen den Draft-Status zitieren. Willst du Reviewer werden? Öffne ein Issue im Spec-Repository.
Klone die Spec, arbeite die 32 Controls mit der Bewertungs-Vorlage durch und bewerte jedes Control mit Met, Partial, Not met oder N/A anhand seiner angegebenen Messmethode. LeanCTX-Nutzer können einen Teil automatisieren: lean-ctx policy coverage --benchmark cgb prüft den aufgelösten Policy-Pack statisch gegen die testbaren Controls und gibt Ergebnisse pro Control aus.
Govern the layerthat feeds your models.
Lies die Spec, bewerte deine Pipeline, melde Issues – oder sieh, wie LeanCTX die Controls lokal umsetzt, für immer kostenlos. Der CGB definiert die Controls; das Open Context Protocol definiert das Wire-Format; die Compliance-Mappings verbinden beides mit EU AI Act, ISO 42001 und SOC 2.