Assurance indépendante des déploiements pour les mises à jour de terminaux
Kestrel est un plan de contrôle indépendant qui s'intercale entre vos éditeurs de logiciels et votre parc en production. Il intercepte une mise à jour d'éditeur avant qu'elle n'atteigne le moindre terminal, prouve de manière déterministe la signature de défaillance de type CrowdStrike, filtre le déploiement selon une politique qu'un modèle consultatif ne peut contourner, et exporte un registre de preuves signé qu'un conseil d'administration et un régulateur peuvent réexécuter. Ce que vous pouvez observer ici est une démonstration sur un parc synthétique de 8 500 terminaux, et non un pipeline déployé en production.
20 → 21
L'incompatibilité du nombre de champs qui a paralysé le parc
Cause fondamentale CrowdStrike, RCA août 2024
12/12
Décisions de déploiement correctes
Sur un jeu d'épreuves étiqueté de 12 scénarios, déterministe
0/6
Faux blocages sur les mises à jour bénignes
6 scénarios bénins dans le même jeu d'épreuves
Le parc, l'éditeur SentinelEdge et son agent de classe Falcon sont synthétiques. Le scénario C-00000291 rejoue la signature de défaillance documentée de CrowdStrike du 19 juillet, et non les systèmes d'un client réel.
Le 19 juillet 2024, un unique fichier de canal Rapid Response Content de CrowdStrike a fait planter des millions de machines Windows en moins de 90 minutes. La cause fondamentale publiée n'était ni un piratage ni un modèle défaillant. Il s'agissait d'une non-concordance de schéma : le validateur cloud a approuvé une mise à jour de 21 champs alors que l'interpréteur noyau n'en attendait que 20, provoquant une lecture hors limites et un BSOD instantané. Le plantage survenant si tôt au démarrage, l'agent en échec n'a jamais pu se réinitialiser pour recevoir une commande de rollback, de sorte que la reprise a nécessité la réparation manuelle des machines, une par une, en Safe Mode. (CrowdStrike Root Cause Analysis, août 2024.)
Le validateur ayant approuvé la mise à jour appartenait à l'éditeur même qui l'a déployée. Un pipeline auto-régulé ne dispose d'aucun tiers indépendant pour inspecter la charge utile lors de son acheminement vers votre parc de production.
Les outils SBOM et SCA couvrent les dépendances open source, et non les fichiers de canal propriétaires d'un éditeur. La sécurité des contenus surveille les prompts et la gestion des identités contrôle les accès. Personne n'inspecte la mise à jour propre à l'éditeur à son entrée.
Une entreprise comptant 5 000 terminaux exécute 8 à 12 agents avec privilèges noyau fournis par des éditeurs qu'elle ne contrôle pas, chacun pouvant injecter un fichier de canal directement dans le ring 0. Les comités consultatifs des changements approuvent les mises à jour d'éditeurs sur la base de la confiance, car rien ne s'intercale entre ce pipeline et la production.
Une équipe consultative d'agents raisonne sur chaque mise à jour, mais elle ne peut pas décider. Kestrel achemine chaque paquet à travers un pipeline qui le normalise, le confronte au contexte du parc, laisse l'équipe débattre, puis confie la décision à un vérificateur déterministe et à une barrière de politique écrits en pur Python. Un agent consultatif favorable au déploiement ne peut en aucun cas lever une constatation déterministe critique, car la confiance envers un produit de gouvernance ne doit pas reposer sur l'auto-cautionnement de l'entité gouvernée.
01 / SCHEMA-COMPATIBILITY DIFF
Ce contrôle compare le nombre de champs déclaré par une mise à jour à celui attendu par l'interpréteur noyau déployé. Une mise à jour à 21 champs atteignant un interpréteur à 20 champs constitue la cause fondamentale exacte du 19 juillet, détectée par calcul arithmétique avant même qu'un terminal ne redémarre.
02 / SANDBOX REBOOT-CYCLE MODEL
Une sandbox simulée modélise les comportements de BSOD et de boucle de redémarrage par profil d'OS sur plusieurs cycles de redémarrage, à partir d'un signal de compatibilité de pilote indépendant de la vérification de schéma. Lorsqu'elle signale l'échec de 5 profils sur 6, cela corrobore le constat du schéma au lieu de simplement le répéter.
03 / BLAST-RADIUS AND CANARY MATH
Ce contrôle calcule la première vague par rapport à votre politique de canary maximal. Un déploiement sur 100 % du parc en une seule fois, ou sans plan de canary déclaré, enfreint la politique et se voit refusé, tandis qu'une première vague échelonnée de 1.2 % y est conforme.
04 / DEAD-AGENT AND CONFLICT DETECTOR
Ce contrôle signale un agent pré-démarrage qui est lui-même le récepteur du rollback, de sorte qu'un plantage rendrait le terminal orphelin et imposerait un passage machine par machine en Safe Mode, et il détecte si deux éditeurs modifient le même rappel noyau (kernel callback) dans une même fenêtre. C'est cette défaillance qui a transformé l'incident du 19 juillet en une reprise manuelle.
L'équipe consultative repose sur Pydantic AI : un normalisateur, un interpréteur de sandbox et deux évaluateurs critiques opposés, l'un plaidant que la mise à jour peut être déployée en toute sécurité et l'autre soutenant qu'elle provoquera un plantage. Ce binôme contradictoire soumet le verdict à un examen approfondi sous les deux angles avant que le code ne tranche. Le verdict lui-même correspond à l'une des quatre décisions : ALLOW pour autoriser le déploiement en canary, HOLD pour orienter vers un examen, BLOCK pour refuser le déploiement, et ABSTAIN pour renvoyer une charge utile non analysable vers un opérateur humain, car la barrière ne valide jamais ce qu'elle ne peut prouver.
L'équipe est indépendante des fournisseurs, avec le choix entre Anthropic, OpenAI ou Gemini via une variable d'environnement et un modèle par défaut claude-opus-4-8, et elle fonctionne entièrement hors ligne sans clé API grâce à un mécanisme consultatif déterministe de repli. Dans chaque mode, le vérificateur et la barrière restent inchangés et continuent de produire l'intégralité du verdict et du registre de preuves. Le vérificateur et la barrière sont délibérément positionnés en dehors du framework d'agents.
La démonstration supervise un parc synthétique, Acme Financial: Global Endpoint Fleet, composé de 8 500 terminaux répartis sur 6 profils d'OS et 8 agents privilégiés, dont 5 en ring-0. L'éditeur SentinelEdge pousse deux mises à jour Rapid Response Content. Observez le traitement réservé par Kestrel à chacune d'elles.
Un onglet View Benchmark exécute l'ensemble du jeu d'épreuves étiqueté et dresse un tableau de résultats. Interprétez chaque chiffre selon le périmètre que la démonstration lui associe. Il s'agit de résultats de couverture de gouvernance sur un ensemble fixe, et non d'une garantie universelle en conditions réelles ; ils sont déterministes, de sorte que les mêmes entrées génèrent les mêmes décisions à chaque exécution.
| Question | Ce que Kestrel fait dans cette démonstration | Ce qui reste en dehors de la démonstration |
|---|---|---|
| Précision de la barrière | 12 décisions correctes sur 12 sur un jeu d'épreuves étiqueté de 12 scénarios, comprenant 6 bénins, plusieurs blocages et suspensions, et 1 abstention légitime. | Une garantie universelle que chaque mauvaise mise à jour soit interceptée. Le résultat porte sur un ensemble fixe, et non en environnement ouvert. |
| Temps d'arrêt évités | Une estimation de $13.3M sur l'ensemble du jeu, dont $5M sur la mise à jour de type CrowdStrike bloquée, issue d'un modèle affiché à l'écran basé sur la part affectée multipliée par un taux horaire avec un plancher d'une heure. | Des sommes économisées par un client réel ou un retour garanti. Il s'agit d'une estimation synthétique sur des scénarios synthétiques. |
| Couverture de la sandbox | Un modèle de résultat déterministe par profil sur 5 profils de parc sur 6, les hôtes hérités Server 2012 étant signalés et exclus plutôt que présumés sans risque. | Une véritable ferme de sandbox de VM Windows. La matrice ici est un modèle simulé, et non des VM réelles, et la ferme figure sur la feuille de route. |
| Intégrations | Lit un flux de canal de mise à jour d'éditeur, l'achemine vers une file ITSM sous forme de bouchons de test (stubs), et signe le registre avec un SHA-256 local. | Un ITSM bidirectionnel en temps réel, un véritable flux d'éditeur et une signature par PKI d'entreprise. Ce sont des intégrations simulées dans la démonstration. |
Kestrel n'est pas un EDR et ne concurrence pas Falcon, Defender ou Cortex XDR. Il n'analyse pas les terminaux, n'applique pas de correctifs et ne supprime pas de logiciels malveillants, et il n'a jamais besoin d'accès au noyau. La matrice de sandbox est un modèle de résultat déterministe par profil, et non de véritables machines virtuelles Windows ; la signature des preuves repose sur un SHA-256 local, et non sur une PKI d'entreprise ; et le flux de canal de mise à jour d'éditeur ainsi que la file d'attente ITSM sont des bouchons de test simulés, et non des connecteurs en direct. Acme Financial, SentinelEdge et l'agent de classe Falcon sont fictifs, et aucun éditeur réel n'est client, partenaire ou approbateur de Veriprajna. Les scores de 12 sur 12 et de 0 sur 6 sont des résultats obtenus sur un jeu d'épreuves étiqueté fixe de 12 scénarios, et les montants en dollars relèvent du modèle d'estimation des temps d'arrêt évités propre à la démonstration, et non d'une certification, d'un conseil juridique ou d'un rendement garanti. Une véritable ferme de sandbox de VM, un ITSM bidirectionnel en direct, un audit de responsabilité contractuelle des éditeurs, la vérification formelle du noyau et le durcissement de l'intégration sur site sont inscrits sur la feuille de route mais non encore développés. Cette page est une présentation explicative avec vidéo, captures d'écran, analyse détaillée du mécanisme et réponses aux questions, et non une application exécutable directement depuis cette interface.
Non. Kestrel n'est pas un EDR et ne requiert aucun accès au noyau. Il se positionne une couche au-dessus de vos agents d'EDR, de DLP, de chiffrement et de gestion des correctifs, et régit ce que ces éditeurs sont autorisés à déployer sur votre parc en production. Il n'analyse pas les terminaux, n'applique pas de correctifs et ne supprime pas de logiciels malveillants. Il examine la mise à jour proposée par un éditeur, prouve si son déploiement est sûr et filtre la diffusion selon votre politique, ce qu'aucun de vos agents noyau ne réalise pour l'éditeur situé au-dessus de lui.
Les entreprises paralysées le 19 juillet 2024 ne maîtrisaient pas le pipeline de l'éditeur, mais elles en ont subi toutes les conséquences. La faille structurelle réside dans l'absence de couche indépendante entre le pipeline de mise à jour d'un éditeur et vos terminaux en production : le validateur de l'éditeur s'auto-régule, les outils SBOM et SCA couvrent les dépendances open source plutôt que les fichiers de canaux propriétaires, et les comités consultatifs des changements ont tendance à approuver les mises à jour sans examen approfondi. Kestrel constitue cette couche manquante. Il lit la charge utile exacte que l'éditeur s'apprête à injecter et décide, au moyen d'un code que vous contrôlez, si elle doit parvenir à la production.
L'équipe consultative se limite à raisonner sur la mise à jour. Le verdict est arrêté par un vérificateur déterministe et une barrière de politique codés en pur Python — une arithmétique vérifiable qu'un régulateur peut réexécuter —, de sorte qu'un agent consultatif enclin au déploiement ne peut en aucun cas effacer une constatation déterministe critique. Puisque la décision est du code et non une auto-évaluation du modèle, une même entrée produit strictement la même décision à chaque passage, sans la moindre variance liée au modèle. La démonstration s'exécute également hors ligne sans aucune clé API via un mode consultatif déterministe de repli, dans lequel la barrière et son verdict demeurent strictement identiques.
C'est une barrière de contrôle, pas un filtre aveugle qui bloque tout. Dans la démonstration, une mise à jour Rapid Response Content bénigne du même éditeur franchit avec succès les contrôles et est déployée sur un cercle canary de 1.2 % en quelques secondes, tandis que la mise à jour dangereuse est bloquée. Sur les 6 scénarios bénins du jeu étiqueté, il n'y a eu aucun faux blocage (0 sur 6). Kestrel n'intervient de manière tranchée que sur les anomalies critiques, et les hôtes hérités qu'il ne peut modéliser sont signalés et exclus plutôt que présumés sans risque.
Un simple clic permet d'exporter un registre de preuves signé sous forme de vue HTML et de fichier JSON intégrant une empreinte de contenu SHA-256, le verdict, les preuves déterministes, les résultats de sandbox par profil, les avis des agents consultatifs avec leur identifiant de modèle, les règles de politique activées et une trace d'évaluation étape par étape avec la latence de chaque phase. Ce registre intègre également les cadres du règlement européen sur la cyberrésilience (EU Cyber Resilience Act), des déclarations SEC et du précédent Delta pour s'intégrer directement dans un échange réglementaire. La signature utilise un SHA-256 local garantissant l'intégrité, et non une PKI d'entreprise, et ce document est conçu pour répondre aux exigences de ces dossiers réglementaires sans constituer pour autant une certification.
Non. L'équipe consultative s'appuie sur Pydantic AI et reste neutre vis-à-vis des fournisseurs : Anthropic, OpenAI ou Gemini peuvent être sélectionnés via une variable d'environnement, avec pour modèle par défaut claude-opus-4-8 accessible via une passerelle locale ou l'API d'Anthropic. Elle fonctionne également de manière totalement autonome hors ligne sans clé API grâce à une solution consultative déterministe de repli. Quel que soit le mode retenu, le vérificateur déterministe et la barrière de politique restent rigoureusement identiques et génèrent l'intégralité du verdict et du registre de preuves, car la garantie apportée n'a jamais reposé sur les propriétés intrinsèques du modèle.
Les recherches à l'origine de cette démonstration : l'architecture, la conception de la vérification et le schéma directeur d'entreprise.
Solution complète
Découvrir la solution Software Update Deployment Integrity →Nous sommes une équipe d'ingénierie en IA, pas un éditeur de middleware. Nous concevons la couche indépendante qui décide par le code de ce qu'un éditeur a le droit de déployer sur votre parc en production, tout en vous fournissant le justificatif opposable.
Un premier échange utile doit être concret : les agents dotés de privilèges noyau exécutés sur votre parc, les circuits de mise à jour d'éditeurs atteignant la production sans contrôle indépendant, et la politique de déploiement progressif (canary) que vous souhaitez faire appliquer. Nous pouvons définir les vérifications déterministes, la barrière de politique et le format du registre de preuves en concertation étroite avec vos équipes chargées des terminaux et de la conformité.
