Unabhängige Release-Absicherung für Endpoint-Updates
Kestrel ist eine unabhängige Control Plane, die zwischen Ihren Softwareanbietern und Ihrer Produktionsflotte sitzt. Es fängt Anbieter-Updates ab, bevor sie einen Endpoint erreichen, weist die Fehlersignatur der CrowdStrike-Klasse deterministisch nach, regelt den Rollout über Richtlinien, die ein beratendes Modell nicht übersteuern kann, und exportiert einen signierten Evidenznachweis, den ein Vorstand oder eine Regulierungsbehörde erneut ausführen kann. Was Sie hier sehen, ist eine Demo über eine synthetische Flotte von 8,500 Endpoints, keine produktiv bereitgestellte Pipeline.
20 → 21
Die Feldanzahl-Diskrepanz, die die Flotte lahmlegte
CrowdStrike-Ursachenanalyse, RCA August 2024
12/12
Korrekte Release-Entscheidungen
Auf einem gelabelten Testset aus 12 Fixtures, deterministisch
0/6
Fälschliche Blockierungen bei unbedenklichen Updates
6 unbedenkliche Fixtures im selben Set
Die Flotte, der Anbieter SentinelEdge und sein Agent der Falcon-Klasse sind synthetisch. Das C-00000291-Szenario wiederholt die dokumentierte CrowdStrike-Fehlersignatur vom 19. Juli, nicht die Systeme realer Kunden.
Am 19. Juli 2024 brachte eine einzige Rapid Response Content-Kanaldatei von CrowdStrike Millionen von Windows-Rechnern in unter 90 Minuten zum Absturz. Die veröffentlichte Ursache war kein Hack und kein fehlerhaftes Modell. Es war eine Schema-Diskrepanz: Der Cloud-Validator genehmigte ein Update mit 21 Feldern, während der Kernel-Interpreter weiterhin 20 erwartete – was zu einem Out-of-Bounds-Read und einem sofortigen BSOD führte. Da der Absturz so früh im Boot-Prozess auftrat, konnte der abstürzende Agent nie neu initialisieren, um einen Rollback-Befehl zu empfangen, sodass die Wiederherstellung manuelle Reparaturen jedes einzelnen Rechners im Safe Mode erforderte. (CrowdStrike Root Cause Analysis, August 2024.)
Der Validator, der das Update genehmigte, gehörte demselben Anbieter, der es auslieferte. Eine Pipeline, die sich selbst kontrolliert, verfügt über keine unabhängige Instanz, die die Nutzlast auf ihrem Weg in Ihre Produktionsflotte prüft.
SBOM- und SCA-Tools decken Open-Source-Abhängigkeiten ab, nicht die proprietären Kanaldateien eines Anbieters. Content Safety überwacht Prompts und Identity überwacht Zugriffe. Niemand liest das eigene Update des Anbieters beim Eintreffen.
Ein Unternehmen mit 5,000 Endpoints betreibt 8 bis 12 kernel-privilegierte Agenten von Anbietern, die es nicht kontrolliert – jeder davon in der Lage, eine Kanaldatei direkt in ring 0 einzuschleusen. Change Advisory Boards genehmigen Anbieter-Updates im guten Glauben, weil zwischen dieser Pipeline und der Produktion nichts steht.
Ein beratendes Team (Advisory Crew) analysiert jedes Update, kann jedoch nicht entscheiden. Kestrel leitet jedes Paket durch eine Pipeline, die es normalisiert, mit der Flotte abgleicht, die Crew argumentieren lässt und die Entscheidung dann an einen deterministischen Verifizierer und ein Policy-Gate übergibt, die in reinem Python geschrieben sind. Ein beratender Agent, der zur Freigabe neigt, kann einen kritischen deterministischen Befund niemals aufheben – denn das Vertrauen in ein Governance-Produkt darf nicht davon abhängen, dass die überwachte Einheit für sich selbst bürgt.
01 / SCHEMA-COMPATIBILITY DIFF
Die Prüfung vergleicht die deklarierte Feldanzahl eines Updates mit den Erwartungen des bereitgestellten Kernel-Interpreters. Ein 21-Felder-Update, das auf einen 20-Felder-Interpreter trifft, ist die buchstäbliche Ursache vom 19. Juli – erfasst durch reine Arithmetik, bevor auch nur ein einziger Endpoint neu startet.
02 / SANDBOX REBOOT-CYCLE MODEL
Eine simulierte Sandbox modelliert BSOD- und Boot-Loop-Verhalten pro Betriebssystemprofil über Reboot-Zyklen hinweg anhand eines Treiberkompatibilitätssignals, das unabhängig von der Schema-Prüfung ist. Meldet sie ein Scheitern bei 5 von 6 Profilen, untermauert dies den Schema-Befund, anstatt ihn bloß zu wiederholen.
03 / BLAST-RADIUS AND CANARY MATH
Die Prüfung berechnet die erste Welle im Abgleich mit Ihrer Max-Canary-Richtlinie. Ein Rollout an 100 % der Flotte auf einmal oder ohne deklarierten Canary-Plan verletzt die Richtlinie und wird abgewiesen, während eine gestufte erste Welle von 1.2 % den Vorgaben entspricht.
04 / DEAD-AGENT AND CONFLICT DETECTOR
Die Prüfung markiert einen Pre-Boot-Agenten, der selbst der Rollback-Empfänger ist – sodass ein Absturz den Endpoint verwaisen ließe und einen manuellen Safe Mode an jedem einzelnen Rechner erzwingen würde –, und sie erkennt, wenn zwei Anbieter denselben Kernel-Callback im selben Zeitfenster verändern. Dies ist der Fehler, der den 19. Juli in eine manuelle Rettungsaktion verwandelte.
Die Advisory Crew basiert auf Pydantic AI: ein Normalisierer, ein Sandbox-Interpreter und zwei gegnerische Kritiker – einer argumentiert für die Unbedenklichkeit des Updates, der andere prognostiziert einen Absturz. Dieses kontradiktorische Paar unterzieht das Urteil einem Red-Teaming aus beiden Richtungen, bevor der Code entscheidet. Das Urteil selbst ist eine von vier Dispositionen: ALLOW zur Freigabe für die Canary-Phase, HOLD zur Weiterleitung an die Überprüfung, BLOCK zur Verweigerung des Rollouts und ABSTAIN zur Weiterleitung unparsbarer Nutzlasten an einen Menschen – denn das Gate gibt niemals frei, was es nicht beweisen kann.
Die Crew ist anbieterneutral: Anthropic, OpenAI oder Gemini können über eine Umgebungsvariable ausgewählt werden, mit claude-opus-4-8 als Standardmodell, erreichbar über eine lokale Bridge oder die Anthropic-API; zudem läuft sie über einen deterministischen beratenden Fallback auch vollständig offline ohne API-Schlüssel. In jedem Modus bleiben Verifizierer und Gate unverändert und erstellen weiterhin das vollständige Urteil samt Evidenznachweis. Verifizierer und Gate befinden sich ganz bewusst außerhalb des Agent-Frameworks.
Die Demo steuert eine synthetische Flotte, Acme Financial: Global Endpoint Fleet, mit 8,500 Endpoints über 6 Betriebssystemprofile und 8 privilegierte Agenten hinweg, 5 davon auf ring-0. Der Anbieter SentinelEdge pusht zwei Rapid Response Content-Updates. Verfolgen Sie, wie Kestrel jeweils verfährt.
Ein Tab „View Benchmark“ führt das gesamte gelabelte Fixture-Set aus und zählt ein Scoreboard zusammen. Betrachten Sie jede Zahl im Kontext des Geltungsbereichs, den die Demo vorgibt. Dies sind Ergebnisse zur Governance-Abdeckung auf einem festen Set, keine Garantie für die offene Welt – und sie sind deterministisch, sodass dieselben Eingaben bei jedem Durchlauf dieselben Entscheidungen liefern.
| Frage | Was Kestrel in dieser Demo leistet | Was außerhalb dieser Demo bleibt |
|---|---|---|
| Gate-Genauigkeit | 12 von 12 korrekte Entscheidungen auf einem gelabelten Set aus 12 Fixtures, darunter 6 unbedenkliche, mehrere BLOCKs und HOLDs und 1 ehrliches ABSTAIN. | Eine universelle Garantie, dass jedes schädliche Update abgefangen wird. Das Ergebnis bezieht sich auf ein festes Set, nicht auf die offene Welt. |
| Vermiedene Ausfallzeit | Geschätzte $13.3M über das gesamte Set, davon $5M beim blockierten Update der CrowdStrike-Klasse – basierend auf einem Bildschirmmodell aus betroffener Quote mal Stundensatz mal Einstunden-Untergrenze. | Geld, das ein realer Kunde gespart hätte, oder eine garantierte Rendite. Es ist eine synthetische Schätzung auf synthetischen Fixtures. |
| Sandbox-Abdeckung | Ein deterministisches profilweises Ergebnismodell über 5 von 6 Flottenprofilen, bei dem ältere Server 2012-Hosts gekennzeichnet und ausgeschlossen werden, statt sie blind als sicher anzunehmen. | Eine echte Windows-VM-Sandbox-Farm. Die Matrix hier ist ein simuliertes Modell, keine Live-VMs, und die Farm steht auf der Roadmap. |
| Integrationen | Liest den Update-Kanal-Feed eines Anbieters und leitet ihn als Fixture-Stubs an eine ITSM-Queue weiter, und signiert den Nachweis mit einem lokalen SHA-256. | Bidirektionales Live-ITSM, ein echter Anbieter-Feed und Signierung per Enterprise-PKI. Dies sind simulierte Integrationen in der Demo. |
Kestrel ist kein EDR und konkurriert nicht mit Falcon, Defender oder Cortex XDR. Es scannt keine Endpoints, patcht nicht und entfernt keine Schadsoftware, und es benötigt zu keinem Zeitpunkt Kernel-Zugriff. Die Sandbox-Matrix ist ein deterministisches profilweises Ergebnismodell, keine echten Windows-VMs; die Evidenz-Signierung ist ein lokales SHA-256, keine Enterprise-PKI; und der Anbieter-Update-Kanal-Feed sowie die ITSM-Queue sind Fixture-Stubs, keine Live-Konnektoren. Acme Financial, SentinelEdge und der Agent der Falcon-Klasse sind fiktiv, und kein realer Anbieter ist Kunde, Partner oder Referenzgeber von Veriprajna. Die 12 von 12 und 0 von 6 sind Ergebnisse auf einem festen gelabelten Set aus 12 Fixtures, und die Dollarbeträge sind das demomodelleigene Berechnungsmodell für vermiedene Ausfallkosten, keine Zertifizierung, Rechtsberatung oder garantierte Rendite. Eine echte VM-Sandbox-Farm, bidirektionales Live-ITSM, ein Anbietervertrags-Haftungsaudit, formale Kernel-Verifikation und Site-Embed-Hardening stehen auf der Roadmap und sind nicht implementiert. Diese Seite ist eine Erläuterung mit Video, Screenshots, einer Mechanismus-Aufschlüsselung und Antworten – keine Anwendung, die Sie von hier aus bedienen.
Nein. Kestrel ist kein EDR und benötigt zu keinem Zeitpunkt Kernel-Zugriff. Es sitzt eine Schicht über Ihren EDR-, DLP-, Verschlüsselungs- und Patching-Agenten und steuert, was diese Anbieter in Ihre Produktionsflotte ausliefern dürfen. Es scannt keine Endpoints, patcht nicht und entfernt keine Schadsoftware. Es liest das vorgeschlagene Update eines Anbieters, weist nach, ob die Freigabe sicher ist, und steuert den Rollout über Richtlinien – eine Aufgabe, die keiner Ihrer Kernel-Agenten für den übergeordneten Anbieter übernimmt.
Die Unternehmen, die am 19. Juli 2024 lahmgelegt wurden, besaßen nicht die Pipeline des Anbieters, trugen jedoch die Konsequenzen. Die strukturelle Lücke besteht darin, dass keine unabhängige Schicht zwischen der Update-Pipeline des Anbieters und Ihren Produktions-Endpoints liegt: Der Validator des Anbieters kontrolliert sich selbst, SBOM- und SCA-Tools decken Open-Source-Abhängigkeiten statt proprietärer Kanaldateien ab, und Change Advisory Boards winken Anbieter-Updates meist durch. Kestrel ist genau diese fehlende Schicht. Es liest die tatsächliche Nutzlast, die der Anbieter pushen möchte, und entscheidet in von Ihnen kontrolliertem Code, ob sie die Produktion erreicht.
Die Advisory Crew analysiert das Update lediglich beratend. Das Urteil wird von einem deterministischen Verifizierer und einem Policy-Gate festgelegt, die in reinem Python geschrieben sind – nachvollziehbare Arithmetik, die eine Regulierungsbehörde erneut ausführen kann. Ein beratender Agent, der zur Freigabe neigt, kann daher einen kritischen deterministischen Befund niemals aufheben. Da die Entscheidung aus Code besteht und nicht aus einem Selbstbericht des Modells, erzeugt dieselbe Eingabe bei jedem Durchlauf dieselbe Entscheidung und unterliegt keiner Modellvarianz. Die Demo läuft über einen deterministischen beratenden Fallback auch vollständig offline ohne API-Schlüssel; das Gate und sein Urteil bleiben in diesem Modus unverändert.
Es ist ein Gate, kein bürokratischer Pauschalblocker. In der Demo besteht ein unbedenkliches Rapid Response Content-Update desselben Anbieters die Prüfungen und wird innerhalb von Sekunden für einen Canary-Ring von 1.2 % freigegeben, während das gefährliche Update blockiert wird. Bei den 6 unbedenklichen Fixtures im gelabelten Set gab es 0 Falschblockierungen. Kestrel greift nur im Gefahrenfall entschlossen ein, und ältere Legacy-Hosts, die es nicht modellieren kann, werden gekennzeichnet und ausgeschlossen, statt sie ungeprüft als sicher zu behandeln.
Ein Klick exportiert einen signierten Evidenznachweis als HTML-Ansicht plus JSON-Datei – mit einem SHA-256-Inhaltshash, dem Urteil, den deterministischen Beweisen, den Sandbox-Ergebnissen pro Profil, den Urteilen der beratenden Agenten samt Modell-ID, den ausgelösten Richtlinienregeln und einem schrittweisen Evaluierungs-Trace mit der Latenz jedes einzelnen Schritts. Der Datensatz enthält zudem Kontextualisierungen zum EU Cyber Resilience Act, zu SEC-Offenlegungspflichten und zum Delta-Präzedenzfall, sodass er sich nahtlos in Einreichungsgespräche einfügt. Die Signierung ist ein lokales SHA-256 zur Integritätssicherung, keine Enterprise-PKI, und der Nachweis ist darauf ausgelegt, diesen Einreichungsanforderungen zu entsprechen, ohne eine formelle Zertifizierung darzustellen.
Nein. Die Advisory Crew basiert auf Pydantic AI und ist anbieterneutral: Anthropic, OpenAI oder Gemini sind über eine Umgebungsvariable wählbar, mit einem Standardmodell claude-opus-4-8 über eine lokale Bridge oder die Anthropic-API. Sie läuft über einen deterministischen beratenden Fallback auch vollständig offline ohne API-Schlüssel. In jedem Modus bleiben der deterministische Verifizierer und das Policy-Gate unverändert und erstellen weiterhin das vollständige Urteil samt Evidenznachweis, da die Garantie zu keinem Zeitpunkt eine Eigenschaft des Modells war.
Die Forschung hinter dieser Demo – die Architektur, das Verifikationsdesign und die Enterprise-Blaupause.
Vollständige Lösung
Erkunden Sie die Lösung „Software Update Deployment Integrity“ →Wir sind ein KI-Engineering-Team, kein Middleware-Anbieter. Wir entwickeln die unabhängige Schicht, die in Code entscheidet, was ein Anbieter in Ihre Produktionsflotte ausliefern darf – und händigen Ihnen den Beleg aus.
Ein sinnvolles Erstgespräch ist konkret: die kernel-privilegierten Agenten in Ihrer Flotte, die Update-Pfade der Anbieter, die ohne unabhängige Prüfung die Produktion erreichen, und die Rollout- sowie Canary-Richtlinien, die Sie durchsetzen möchten. Wir können die deterministischen Prüfungen, das Policy-Gate und das Format des Evidenznachweises gemeinsam mit Ihren Endpoint- und Compliance-Teams durchgehen.
