docs
/

In a nutshell

Zegit in a nutshell

What zegit does, how a single change becomes audit-grade proof, and what that proof honestly does — and doesn't — guarantee.

What it is

Zegit is a governance gateway that sits in front of your existing Git host and turns every release into an audit-grade evidence bundle aligned to the EU Cyber Resilience Act. Instead of re-running your CI, it verifies signed evidence that validation already ran — under a policy defined in Git, by an identity you can prove.

Governance lives in version control, identity is passkey-backed, and every release produces non-repudiable cryptographic proof of the validation and approval chain. The signing and evidence core works today; the passkey-to-certificate path and host-level enforcement are partly built and partly still on the roadmap — this page says which.

Where zegit sits A developer or agent pushes to a Git host. A gateway pre-receive hook enforces policy on push (planned/partly built). A Control Plane issues certificates and handles verification (planned). developer / agent mongoose push + AoV ref Git host gateway (pre-receive) enforces on push planned / partly built verify / revocation Control Plane issues certs · verifies planned works today planned / partly built
Where zegit sits. Dashed = planned or partly built.

Know · work · prove

The platform is three tools that share one evidence vocabulary.

Know · work · prove meerkat (knowledge base, MCP) emits evidence to mongoose (agent harness, runs work), which in turn signs evidence via zegit (signs, gates, bundles). meerkat knows knowledge base · MCP emits evidence mongoose works agent harness · runs work signs evidence zegit proves signs · gates · bundles one shared evidence vocabulary
The three tools share one evidence record.

meerkat is the knowledge base your agent can query over MCP, so work starts from what is actually true at your org. mongoose is the agent harness that runs the work — and emits an evidence record bound to the exact git state for every meaningful step. zegit signs, gates, and bundles what happened into proof. Each tool is useful alone; together, the compliance artifact falls out of good engineering instead of being bolted on.

The lifecycle of one change

A change flows through one chain. You — or an agent in mongoose — write code. zg validate runs your pipeline (lint, tests, security analysis, review agents) and assembles an evidence record bound to the exact commit and tree. The policy engine renders a decision — ALLOW, REQUIRE_REVIEW, or BLOCK.

On ALLOW, the record is signed into an Attestation of Validation and written to refs/zegit/aov/<commit_sha>; a pre-push hook carries it alongside your commits. At release, a Tag Request gathers the required approvals and finalizes a signed tag, which triggers a CRA Evidence Bundle anyone can verify offline. Tag Request orchestration runs locally today; central persistence and quorum enforcement are planned.

The lifecycle of one change A change flows from writing code through validation and evidence assembly to a policy decision, which branches into allow (sign and release), require review (Tag Request), or block (rejected). write code zg validate evidence record policy decision sign AoV → push exit 0 release bundle Tag Request / approval * exit 10 rejected exit 20 ZG_ERR_… * Tag Request orchestration runs locally today; central enforcement is planned.
How one change becomes a signed release — or gets stopped.

One record, three envelopes

The evidence never changes shape. mongoose emits an unsigned record into .mongoose/evidence/<run_id>.jsonl — a free local audit trail with zero zegit. A policy engine evaluates it and stamps a decision, making it validated, still unsigned. zegit wraps that exact same payload in a DSSE signature to make it signed and audit-grade.

One record, three envelopes Three panels of growing height representing unsigned, validated, and signed states. The same record glyph appears in all three, with only the surrounding envelope growing in trust level. unsigned mongoose · local .mongoose/evidence/…jsonl + decision validated policy engine + decision · still unsigned + signature signed zegit · DSSE refs/zegit/aov/<sha> same payload — only the envelope grows
One record escalates from a local log to a signed attestation.

Each hop adds metadata; none reshapes the payload. The escalation is the upgrade path: free unsigned evidence today, signed proof when you adopt zegit.

What "proof" actually means

A signed AoV is a DSSE envelope wrapping an in-toto Statement — standard, interoperable formats, not a proprietary blob. It is verifiable offline: zg evidence verify-bundle checks signatures, the certificate chain to the root, and the git-state binding with no network call.

What v1 actually proves

Version one proves that a passkey-authenticated identity asserts this validation ran under this policy. That is non-repudiable and audit-grade — but it does not yet prove the validation actually executed as claimed. That stronger guarantee needs attested build runners, which is a later phase.

The CRA payoff

Because the proof is generated as a byproduct of validating each change, the compliance artifact assembles itself. A bundle ties together every AoV since the last tag, the effective policy snapshot, ingested SBOMs and vulnerability scans, and a human-readable summary mapped to CRA Annex I — the document a compliance officer takes to an auditor.

Bundle assembly, signing, and offline verification work today. The Annex I mapping exists but has not yet been through CRA-expert review — treat it as a draft, not a certified mapping.

Ready for specifics? See Getting started, the zg CLI reference, and Core concepts.

PreviousOverview

Authoritative reference, generated from the component repos. Spot something stale? Tell us.