Mitigrid is a open-source Proof of Concept/research artifact about a proposed method for qualifying whether a declared patch or compensating control blocks a declared exploit path without breaking declared legitimate functionality.
The V0 gate recorded stop on 2026-07-26 after the 2026-07-24 readiness
deadline was missed: Day 0 never started, no V0 runtime attempt occurred, and
no Docker authorization was granted. It is not a security-product release and
does not authorize a generalized Mitigrid engine, schemas, runner, or CLI. See
the final V0 gate decision.
The repository still contains the historical OpenCEM implementation.
The following preserves the proposed experiment protocol, not engine functionality or planned product work. The Mitigrid engine and CLI were never implemented.
A Mitigrid experiment needs three kinds of input:
- a scenario describing the target, its declared treatments, readiness, and safety limits
- a trusted security probe that attempts one specific, already-known exploit path
- a separate normal-functionality test that exercises behavior users still need
The experiment starts each treatment in an isolated environment, waits for readiness, runs the security probe and normal-functionality test separately, collects bounded observations, and tears down everything it created. Deterministic oracles classify those observations; an expected benchmark answer is ground truth and cannot be used to manufacture the observed verdict.
The accepted benchmark reference contract compares four explicit treatments of a known vulnerability:
- vulnerable baseline
- patched target
- effective infrastructure mitigation
- plausible but ineffective mitigation
The proposed V0 design also considered a smaller operational comparison: a
vulnerable baseline, a patch or mitigation under test, and a legitimate workflow
for both. Its output would have been candidate decision evidence only; it could
not issue a qualified patched or mitigated conclusion. The stop decision
means it will not become a public engine contract.
For each treatment, the proposed method would keep infrastructure validity,
security outcome, and legitimate-functionality outcome separate. A failed
experiment, unreachable target, or broken application must never become evidence
that a mitigation worked. If readiness, probe delivery, evidence collection, or
another required runner operation failed, the cell would be an infrastructure
error rather than a successful mitigation: its execution status would be
infrastructure_error and its qualified classification would remain
inconclusive.
For example, consider an application with a known SSRF path. The security probe asks the application to fetch a unique URL from a private canary service, while the functionality test asks it to fetch an allowed internal content service. Mitigrid would run the same two checks against:
- a vulnerable target, where the canary request should arrive;
- a patched target, where the canary request should be rejected but the allowed fetch should still work;
- an unpatched target behind an effective network boundary, where the canary is unreachable but the allowed service remains reachable; and
- an unpatched target with a plausible control applied in the wrong place, where the canary request still arrives.
The canary's receipt, the probe response, the normal fetch result, readiness,
and runner health are recorded as separate evidence. From those observations,
the classifier can distinguish vulnerable, patched, mitigated,
and inconclusive, while separately reporting infrastructure_error when the
experiment itself failed, instead of treating every failed request as proof of
protection.
Mitigrid consumes trusted reproducers and existing runtimes. It does not discover vulnerabilities, generate arbitrary exploits, replace Docker or VM runtimes, or claim that a system is globally non-exploitable.
The following preserves the pre-Day-0 V0 design as research context only; it does not authorize its planned work. V0 was designed to use hand-authored Docker Compose and the smallest fixed result harness before committing to a generalized engine. Its only proposed experiment was the local network-boundary/SSRF walking skeleton: a canary service was designed to provide affirmative exploit evidence, while a separate allowed fetch was designed to test the legitimate behavior that must survive.
Because this fixed, repository-controlled harness did not implement the generic
Docker admission boundary, any hypothetical V0 result would have been
provisional development evidence. Its Compose definitions would have required a
dedicated safety review before any execution; internal: true would not have
isolated an ordinary bridge from its Docker host. OrbStack would have been
excluded from runtime work, and gate evidence would have required one signed
disposable-Linux host/firewall/live-peer profile plus a create-before-start
lifecycle.
No offline or Docker V0 execution is authorized or will occur. The proposed V0 host profile would have been a rootful Engine on disposable Linux; rootless would have required separate review. Its planned lifecycle would have created containers stopped, inspected derived network facts, installed a run-scoped firewall and verified a live owned sentinel, started containers, verified the boundary, run the declared workflows, then cleaned up and verified both Docker and host-control state.
The proposed walking skeleton would have run the four benchmark treatments three
times and injected dead-target, broken-functionality, missing-evidence, timeout,
collection, and cleanup failures. None could produce a patched or mitigated
claim. The final V0 outcome is stop; no portfolio, independent-authoring, or
generalized-engine work follows.
- Final V0 gate decision records the stopped, frozen PoC/research status.
- V0 viability sprint preserves the former falsification plan and gate.
- Positioning, roadmap, and development plan preserve the proposed product and implementation context; none authorizes new work.
- Experiment semantics, network-boundary reference design, threat model, and V0 safety addendum remain methodology and safety references, not runtime authorization.
M0 preserved the old product boundary and settled repository identity, benchmark ground-truth separation, stable identifiers, safe execution policy, and documentation ownership. V0 stopped before Day 0; it produced no runtime evidence or qualified result. Generalized schemas, Rust domain types, deterministic planning, runner abstractions, and the Mitigrid CLI remain unimplemented and are not planned.
The following is the unexecuted proposed sequence retained for research context:
preserve and decide
-> falsify or validate the method with a hand-built Docker experiment
-> test one real portfolio decision and independent use
-> define and test generalized experiment semantics
-> migrate the validated experiment into an admitted Docker runner
-> measure method and corpus viability
-> validate one repeated-use integration
-> publish a maintainable benchmark
OpenCEM v0.1 is the repository's preserved historical computational-engineering
evidence workflow. Its implementation includes the opencem CLI, LabTrace,
requirements and test-record imports, reports, provenance, and evidence packs.
It is not the active product direction.
The audited historical snapshot is commit 3e03738, marked by the annotated
tag opencem-v0.1.0, which has been published to the Git repository. A separate
formal GitHub Release remains optional and is not claimed here. Verification
details, test results, and the source-archive checksum are recorded in the
OpenCEM v0.1 preservation record.
Historical usage and contracts should be read from that tag rather than treated as Mitigrid documentation.
The workspace commands below exercise only the preserved historical OpenCEM implementation:
cargo test --workspace --locked
cargo run -p opencem-cli -- --helpNo Mitigrid runtime or implementation commands are authorized.
The project is licensed under the Apache License 2.0. Contribution expectations are documented in CONTRIBUTING.md, and security reporting guidance is documented in SECURITY.md.