H2 Labs01 / THE WHOLE SYSTEM
Runtime Assurance
Observe what is running, verify it against policy, and act with explicit authority. Runtime Assurance connects identity, system evidence, controlled response and recovery into one operating cycle.
Where it fits: the overall system. Identity Core supplies identity and authorization; netwatch supplies connection observations; signed probes inspect selected state; scoped controls apply and verify a response.
Assurance comes from specific checks and evidence. A clean scan cannot prove that a machine is uncompromised.
02 / WHAT MAY RUN
Execution Integrity
What executes? Who authorized it? Does the artifact match the approved signature? What can it read, change or contact?
Where it fits: probe verification, launcher isolation, workload identity and execution policies. Our launcher verifies signed probe artifacts, confines their access and bounds execution. Identity Core sign-in connects an approved response to an identified person and application permissions.
Tested foundation: signed probe execution, rejected tampering, denied writes and network access, and resource limits in an isolated Linux lab. Complete workload identity binding and the integrated execution-policy lifecycle remain development work. Signatures establish provenance and integrity, not freedom from defects.
03 / WHAT WE OBSERVE
Compute Integrity Monitoring
Inspect processes, files, configuration and connections. Collect evidence of suspicious activity and unexpected changes, using focused checks with explicit collection boundaries.
Where it fits: isolated probes, process inspection, file checks and netwatch. The pilot collects bounded file and socket evidence; live netwatch observations are imported from a Linux host with source timestamps and loss information.
Scheduled inspection and continuous connection observation answer different questions. Neither makes incomplete evidence complete. Our current probes are a tested foundation, not a comprehensive threat-detection catalogue.
Detection architecture: isolated, signed probes and agentless inspection →
04 / WHAT MAY CHANGE
Drift Control
Compare observed state with an approved baseline. Decide which changes are expected, which need approval and which call for a corrective action.
Where it fits: configuration baselines, permission changes, network policy and remediation workflows. A finding provides evidence; a separate authority permits a change. Responses need an exact target and scope, expiry, verification and a recovery path.
Tested foundation: file-change detection and Identity Core browser approvals that block and restore narrowly scoped traffic in a disposable container. One-use approvals, permission checks and independent outcome verification are exercised. General fleet remediation and automatic policy-driven responses remain planned.
05 / WHAT THE EVIDENCE SUPPORTS
Runtime Truth
An evidence view that tells you what was observed, where it came from, how old it is and what is missing. An action request, an execution result and a verified effect are different facts.
Where it fits: observation views, investigation timelines and response records. The pilot offers an authenticated netwatch evidence view and a durable action journal. A unified investigation timeline is still to be built.
The name describes our commitment to traceable evidence, not an infallible view of a host. Unknown state, dropped events and unverified outcomes must stay visible.
One system. Distinct responsibilities.
Identity Core establishes who is acting. Application policy decides which target and operation they may approve. Netwatch and probes supply evidence. The local enforcer applies a scoped change and checks its effect.
askd provides a separate execution transport for probe jobs. We are exercising the local approval and enforcement path without askd first, so its behaviour can be tested independently before integration.
These five terms describe connected responsibilities, not five separate products. Remote attestation, broader containment and fleet recovery need their own implementations and validation; they are not implied by the name Runtime Assurance.
Built around evidence. Developed in the open about its limits.
The Linux lab has exercised isolated signed probes, real Identity Core OIDC sign-in with a virtual passkey, scoped approvals, rejection of unauthorized actions, firewall block and restore, and receiver-side checks of the result. Live netwatch ingestion has been tested separately.
The complete observation-to-response chain across a real fleet is still being developed. Independent production validation and hardware attestation remain separate work.
Linux first. Sovereignty by design.
We see Linux as the platform of the future: an open foundation organisations can own, inspect and operate under their own control. It is where we choose to concentrate our engineering effort and deliver the most closely integrated experience.
Windows and macOS are also possible targets. Selected components already work on these systems, and exploratory testing has demonstrated feasibility for parts of the architecture. That work establishes a starting point for broader support; it was not intended to validate complete coverage.
Our priority is deliberate. When a concrete need arises, we can allocate effort to those platforms or integrate existing operating-system tools that already do the job well. Linux remains the centre of our work, with other platforms supported according to actual requirements.
Explore the inspection architecture, Linux isolation demonstrations and Linux for companies.