Independent release assurance for endpoint updates
Kestrel is an independent control plane that sits between your software vendors and your production fleet. It intercepts a vendor update before it reaches any endpoint, proves the CrowdStrike-class failure signature deterministically, gates the rollout with policy an advisory model cannot override, and exports a signed evidence record a board and a regulator can re-run. What you can watch here is a demo over a synthetic 8,500-endpoint fleet, not a deployed pipeline.
20 → 21
The field-count mismatch that crashed the fleet
CrowdStrike root cause, RCA August 2024
12/12
Correct release decisions
On a 12-item labelled fixture set, deterministic
0/6
False-blocks on the benign updates
6 benign fixtures in the same set
The fleet, the vendor SentinelEdge, and its Falcon-class agent are synthetic. The C-00000291 scenario replays the documented CrowdStrike July-19 failure signature, not any real customer's systems.
On July 19, 2024, a single CrowdStrike Rapid Response Content channel file crashed millions of Windows machines in under 90 minutes. The published root cause was not a hack and not a bad model. It was a schema mismatch: the cloud validator approved a 21-field update while the kernel interpreter still expected 20, producing an out-of-bounds read and an instant BSOD. Because the crash hit so early in boot, the crashing agent could never re-initialize to receive a rollback command, so recovery meant hand-fixing machines one at a time in Safe Mode. (CrowdStrike Root Cause Analysis, August 2024.)
The validator that approved the update belonged to the same vendor that shipped it. A self-policing pipeline has no independent party reading the payload on its way into your production fleet.
SBOM and SCA tools cover open-source dependencies, not a vendor's proprietary channel files. Content safety watches prompts and identity watches access. Nobody reads the vendor's own update on the way in.
A 5,000-endpoint enterprise runs 8 to 12 kernel-privileged agents from vendors it does not control, each able to push a channel file straight into ring 0. Change-advisory boards approve vendor updates on trust, because there is nothing between that pipeline and production.
An advisory crew reasons about each update, but it cannot decide. Kestrel routes every package through a pipeline that normalizes it, grounds it against the fleet, lets the crew argue, then hands the decision to a deterministic verifier and policy gate written in plain Python. An advisory agent leaning toward release can never clear a critical deterministic finding, because trust in a governance product must not depend on the thing being governed vouching for itself.
01 / SCHEMA-COMPATIBILITY DIFF
The check compares an update's declared field count against what the deployed kernel interpreter expects. A 21-field update reaching a 20-field interpreter is the literal July-19 root cause, caught by arithmetic before any endpoint reboots.
02 / SANDBOX REBOOT-CYCLE MODEL
A simulated sandbox models BSOD and boot-loop behavior per OS profile across reboot cycles, from a driver-compatibility signal independent of the schema check. When it reports 5 of 6 profiles failing, that corroborates the schema finding rather than echoing it.
03 / BLAST-RADIUS AND CANARY MATH
The check computes the first wave against your max-canary policy. A rollout to 100% of the fleet at once, or one with no canary plan declared, violates the policy and is refused, while a staged 1.2% first wave is within it.
04 / DEAD-AGENT AND CONFLICT DETECTOR
The check flags a pre-boot agent that is itself the rollback receiver, so a crash would orphan the endpoint and force per-machine Safe Mode, and it flags two vendors mutating the same kernel callback in one window. This is the failure that turned July-19 into a manual recovery.
The advisory crew is built on Pydantic AI: a normalizer, a sandbox interpreter, and two opposed critics, one arguing the update is safe to ship and one arguing it will crash. That adversarial pair red-teams the verdict from both directions before code decides. The verdict itself is one of four dispositions: ALLOW to release to canary, HOLD to route for review, BLOCK to refuse the rollout, and ABSTAIN to route an unparseable payload to a human, because the gate never green-lights what it cannot prove.
The crew is provider-neutral, with Anthropic, OpenAI or Gemini selectable through an environment variable and a default model of claude-opus-4-8, and it runs fully offline with no API key through a deterministic advisory fallback. In every mode the verifier and gate are unchanged and still produce the full verdict and evidence record. The verifier and gate deliberately sit outside the agent framework.
The demo governs a synthetic fleet, Acme Financial: Global Endpoint Fleet, of 8,500 endpoints across 6 OS profiles and 8 privileged agents, 5 of them ring-0. The vendor SentinelEdge pushes two Rapid Response Content updates. Watch what Kestrel does with each.
A View Benchmark tab runs the full labelled fixture set and tallies a scoreboard. Read each number with the scope the demo keeps attached to it. These are governance-coverage results on a fixed set, not an open-world guarantee, and they are deterministic, so the same inputs produce the same decisions every run.
| Question | What Kestrel does in this demo | What remains outside the demo |
|---|---|---|
| Gate accuracy | 12 of 12 correct decisions on a 12-item labelled fixture set, including 6 benign, several blocks and holds, and 1 honest abstain. | A universal guarantee that every bad update is caught. The result is on a fixed set, not open-world. |
| Prevented downtime | An estimated $13.3M across the set, $5M of it on the blocked CrowdStrike-class update, from an on-screen model of affected share times a per-hour rate times a one-hour floor. | Money a real customer saved or a guaranteed return. It is a synthetic estimate on synthetic fixtures. |
| Sandbox coverage | A deterministic per-profile outcome model over 5 of 6 fleet profiles, with legacy Server 2012 hosts flagged and excluded rather than assumed safe. | A real Windows VM sandbox farm. The matrix here is a simulated model, not live VMs, and the farm is on the roadmap. |
| Integrations | Reads a vendor update-channel feed and routes to an ITSM queue as fixture stubs, and signs the record with a local SHA-256. | Live bi-directional ITSM, a real vendor feed and enterprise PKI signing. These are simulated integrations in the demo. |
Kestrel is not an EDR and does not compete with Falcon, Defender or Cortex XDR. It does not scan endpoints, patch, or remove malware, and it never needs kernel access. The sandbox matrix is a deterministic per-profile outcome model, not real Windows VMs; the evidence signing is a local SHA-256, not enterprise PKI; and the vendor update-channel feed and the ITSM queue are fixture stubs, not live connectors. Acme Financial, SentinelEdge and the Falcon-class agent are fictional, and no real vendor is a Veriprajna customer, partner or endorser. The 12 of 12 and 0 of 6 are results on a fixed 12-item labelled fixture set, and the dollar figures are the demo's own estimated prevented-downtime model, not certification, legal advice, or a guaranteed return. A real VM sandbox farm, live bi-directional ITSM, a vendor-contract liability audit, kernel formal verification and site-embed hardening are on the roadmap and not built. This page is an explainer with a video, screenshots, a mechanism breakdown and answers, not an app you operate from here.
No. Kestrel is not an EDR and never needs kernel access. It sits one layer above your EDR, DLP, encryption and patching agents and governs what those vendors are allowed to ship into your production fleet. It does not scan endpoints, patch, or remove malware. It reads a vendor's proposed update, proves whether it is safe to release, and gates the rollout with policy, which is a job none of your kernel agents does for the vendor above them.
The enterprises that went dark on July 19, 2024 did not own the vendor's pipeline, but they owned the consequences. The structural gap is that no independent layer sits between a vendor's update pipeline and your production endpoints: the vendor's validator is self-policing, SBOM and SCA tools cover open-source dependencies rather than proprietary channel files, and change-advisory boards tend to wave vendor updates through. Kestrel is that missing layer. It reads the actual payload the vendor is about to push and decides, in code you control, whether it reaches production.
The advisory crew only reasons about the update. The verdict is set by a deterministic verifier and policy gate written in plain Python, re-derivable arithmetic that a regulator can re-run, so an advisory agent leaning toward release can never clear a critical deterministic finding. Because the decision is code and not a model self-report, the same input produces the same decision every run and carries no model variance. The demo also runs fully offline with no API key through a deterministic advisory fallback, and the gate and its verdict are unchanged in that mode.
It is a gate, not a block-everything nanny. In the demo a benign Rapid Response Content update from the same vendor clears the checks and is released to a 1.2% canary ring in seconds, while the dangerous one is blocked. On the 6 benign fixtures in the labelled set there were 0 false-blocks. Kestrel is decisive only on the dangerous turn, and legacy hosts it cannot model are flagged and excluded rather than assumed safe.
One click exports a signed evidence record as an HTML view plus a JSON file carrying a SHA-256 content hash, the verdict, the deterministic proofs, the per-profile sandbox results, the advisory agents' verdicts with their model id, the policy rules that fired, and a per-step evaluation trace with each step's latency. The record also carries EU Cyber Resilience Act, SEC disclosure and Delta-precedent framing so it fits a filing conversation. The signing is a local SHA-256 for integrity, not enterprise PKI, and the record is designed to align with those filing needs rather than being a certification.
No. The advisory crew is built on Pydantic AI and is provider-neutral, with Anthropic, OpenAI or Gemini selectable through an environment variable and a default model of claude-opus-4-8 reached over a local bridge or the Anthropic API. It also runs fully offline with no API key through a deterministic advisory fallback. In every mode the deterministic verifier and policy gate are unchanged and still produce the full verdict and evidence record, because the guarantee was never a property of the model.
The research behind this demo — the architecture, the verification design, and the enterprise blueprint.
We are an AI engineering team, not a middleware vendor. We build the independent layer that decides in code what a vendor is allowed to ship into your production fleet, and hands you the receipt.
A useful first conversation is concrete: the kernel-privileged agents your fleet runs, the vendor update paths that reach production with no independent check, and the rollout and canary policy you want enforced. We can work through the deterministic checks, the policy gate and the evidence-record format alongside your endpoint and compliance teams.
