CGB-1 · 6 contrôles
Sensibilité et Rédaction
Les identifiants, données personnelles et identifiants réglementés ne doivent jamais franchir la frontière de confiance. Détection, rédaction et les garanties qui y sont associées.
Les CIS Benchmarks définissent ce qu'est un serveur durci. Le Context Governance Benchmark définit ce qu'est un pipeline de contexte gouverné : 32 contrôles mesurables et neutres par rapport aux outils à travers 6 domaines, notés selon quatre niveaux de maturité. Citable par les équipes de sécurité, l'approvisionnement et la presse — gratuit sous CC-BY 4.0.
Statut : v1.0-draft, pré-examen. Le catalogue est publié et ouvert aux retours ; v1.0-final nécessite ≥ 3 examinateurs externes nommés. D'ici là, ne le citez pas comme une norme publiée — citez la version brouillon.
Chaque contrôle énonce une exigence, pourquoi elle est importante, une méthode de mesure concrète et un niveau. Trois niveaux se construisent les uns sur les autres : Basic (le socle des 12 contrôles), Hardened (15 contrôles pour les données clients ou réglementées) et Audited (5 contrôles avec assurance vérifiable par un tiers).
CGB-1 · 6 contrôles
Les identifiants, données personnelles et identifiants réglementés ne doivent jamais franchir la frontière de confiance. Détection, rédaction et les garanties qui y sont associées.
CGB-2 · 5 contrôles
Pour toute interaction avec un modèle : ce qui est entré dans le contexte, d'où cela vient-il, a-t-il été modifié ? Attribution de la source, divulgation des transformations, preuve de falsification.
CGB-3 · 5 contrôles
Un seul prompt se propage en de multiples appels d'outils et sous-agents. Limites, attribution et arrêt de la consommation incontrôlée avant la facture.
CGB-4 · 6 contrôles
Les affirmations de gouvernance ne sont aussi solides que les enregistrements qui les soutiennent. Ce qui est journalisé, comment il est protégé, et si un tiers peut le vérifier.
CGB-5 · 5 contrôles
Ce qu'un agent peut atteindre, sur quelle autorité ? Limites du système de fichiers, de l'exécution de commandes, du réseau et des outils — assistant, pas shell root non audité.
CGB-6 · 5 contrôles
Caches, magasins de sessions, mémoire à long terme, connaissances partagées : comment l'état accumulé est délimité, expiré, supprimé et maintenu honnête au fil du temps.
Les contrôles notent Atteint (1.0), Partiel (0.5, écart décrit) ou Non atteint (0). Le score d'un niveau est le nombre de points sur les contrôles applicables. La note est le plus haut seuil que le pipeline franchit — en dessous de C1, il n'est simplement pas noté.
Foundational
Basic ≥ 75%
Managed
Base ≥ 90% et Renforcé ≥ 50%
Hardened
Base = 100%, Renforcé ≥ 80%, Audité ≥ 40%, chaque contrôle Atteint lie des preuves
Audited
Base = 100%, Renforcé = 100%, Audité ≥ 80%, vérifié de manière indépendante
À partir de C3, chaque affirmation Atteinte est liée à des preuves qu'un réviseur peut ouvrir. À partir de C4, l'évaluation elle-même est vérifiée de manière indépendante — les auto-évaluations s'arrêtent au C3 par conception.
La spécification est neutre quant aux outils ; cette partie ne l'est pas. LeanCTX s'auto-évalue par rapport à la version v1.0-draft au C2 — Géré : Base 96% · Renforcé 80% · Audité 50%. Lorsqu'une affirmation n'a pas pu être vérifiée de manière rigoureuse, le contrôle est noté en baisse, et non en hausse.
Les lacunes publiées comprennent CGB-1.4 (la couverture de la rédaction en mode fail-closed est conventionnelle, non prouvée structurellement par une passerelle CI) et plusieurs contrôles au niveau Audited qui attendent une vérification tierce. Les résultats complets par contrôle — y compris chaque Partial et Not met — sont dans l'auto-évaluation publique.
Évaluez votre propre configuration : lean-ctx policy coverage --benchmark cgb vérifie statiquement votre paquet de politiques résolu par rapport aux contrôles testables — des fixtures synthétiques, pas une confiance basée sur le nom du modèle.
Les identifiants de contrôle sont permanents et ne sont jamais réutilisés. Les changements substantiels passent par un processus de type RFC avec une fenêtre de commentaires de 14 jours et un désaccord enregistré. Le catalogue est révisé annuellement ; les brouillons sont toujours étiquetés. Licence : CC-BY 4.0.
Comité de révision — appel ouvert. v1.0-final sera publié une fois que ≥ 3 évaluateurs externes nommés (spécialistes en sécurité, conformité ou ingénierie des plateformes, sans intérêt commercial unique fournisseur) auront examiné chaque domaine. Les évaluateurs sont nommés dans la spécification publiée. Devenir bénévole via un problème →
Un catalogue versionné et neutre par rapport aux outils de 32 contrôles mesurables dans 6 domaines (sensibilité et rédaction, provenance, contrôle budgétaire, audit et preuve, portée d'accès, cycle de vie et rétention) qui définit ce qu'est un pipeline de contexte gouverné — à la manière dont les CIS Benchmarks définissent ce qu'est un serveur durci. Il est publié sous CC-BY 4.0 et noté selon quatre niveaux de maturité, C1 à C4.
Les mainteneurs de LeanCTX éditent la spécification, mais les contrôles sont délibérément neutres par rapport aux outils : aucun concept LeanCTX n'apparaît dans un contrôle, un linter de neutralité en fait respecter cela dans CI, et tout pipeline fournisseur ou interne peut s'auto-évaluer. LeanCTX publie sa propre auto-évaluation comme document séparé — y compris les lacunes.
Selon la v1.0-draft, LeanCTX s'auto-évalue à C2 — Géré (Base 96 %, Durci 80 %, Audité 50 %), avec les lacunes publiées : parmi elles, la couverture de rédaction en cas d'échec est conventionnelle plutôt que structurellement prouvée, et plusieurs contrôles au niveau Audit nécessitent une vérification tierce. Un auto-score parfait dirait plus sur l'évaluation que sur le produit.
Non — la v1.0-draft est publiée et ouverte à l'examen. La version devient v1.0-final une fois qu'au moins trois évaluateurs externes nommés (spécialistes en sécurité, conformité ou ingénierie des plateformes) auront examiné chaque domaine. En attendant, les évaluations doivent citer le statut de brouillon. Vous voulez être un évaluateur ? Ouvrez un problème dans le dépôt de spécification.
Clonez la spécification, passez en revue les 32 contrôles avec le modèle d'évaluation, et notez chaque contrôle comme Atteint, Partiel, Non atteint ou N/A en utilisant sa méthode de mesure déclarée. Les utilisateurs de LeanCTX peuvent automatiser une partie : lean-ctx policy coverage --benchmark cgb vérifie statiquement le paquet de politiques résolu par rapport aux contrôles testables et affiche les résultats par contrôle.
Lisez la spécification, évaluez votre pipeline, signalez des problèmes — ou voyez comment LeanCTX implémente les contrôles localement, gratuitement pour toujours. CGB définit les contrôles ; le Open Context Protocol définit le format de transmission ; les mappages de conformité relient les deux à l'AI Act de l'UE, ISO 42001 et SOC 2.