Zegit in a nutshell

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.

Know · work · prove#

The platform is three tools that share one evidence vocabulary.

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 CP quorum enforcement is live when ZEGIT_CP_URL is set.

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.

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.

With attested runners#

Today the developer signs the AoV, so it proves who asserted a validation, not that the pipeline actually ran — a developer could point .zegit/config.yaml at a check that trivially passes and still produce a valid AoV. The fix is to move the signature off the developer and onto a trusted builder.

ZeGit's build runner images — signed OCI images, pinned by digest — are the vehicle. When validation runs inside a Tier 2 Verified image, the AoV is signed by the attested runner identity instead of the developer (a runner-signed AoV). Now the decision comes from a known-good, digest-pinned runner the committer can't trivially forge, and a policy can require that protected refs carry one — closing the v1 gap. Tier 3 adds TPM-backed runner attestation and hermetic builds on top.

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.