● zegit · proves
zegit
CRA-aligned governance for the Git you already have. zegit sits in front of your existing Git host and turns every release tag into an audit-grade evidence bundle — without migrating where code lives.
zegit (pronounced [ʒə ɡʲɪt]; the CLI is zg) is the governance layer of the ecosystem. It is built for two workflows that PR/CI-centric platforms underserve: trunk-based development (where main is always deployable) and agentic workflows (which need deterministic, local validation, not remote CI round-trips).
Core bets
| Principle | What it means |
|---|---|
| Execution at the edge | Checks run locally or on your runners. zg validate runs on the dev machine. |
| Verify, don't re-run | The gateway verifies cryptographic evidence rather than re-running CI. |
| Governance as code | Policy lives in Git — a per-repo ZEGITFILE, activated as a protected ref (refs/zegit/policy) under an owner quorum, with an optional organization baseline a repository may tighten but never loosen. Weakening a policy takes the same owner quorum as any other change; the gate has had holes here (zegit#265, fixed in v0.1.27) and one known gap is still open. |
| Hardware-backed trust | Passkeys / WebAuthn; short-lived signing certs; a fresh passkey touch for release approvals. No passwords, no long-lived tokens. |
| CRA-grade evidence | Every release tag produces a downloadable, Annex I–mapped evidence bundle. |
The three components
zegit ships three deployable pieces:
zg — the CLI
The developer/agent surface. Runs validation, signs AoVs, drives Tag Requests.
CLI referenceThe Gateway
A pre-receive enforcer for self-hosted Git, or zegit's own SSH gateway that mirrors accepted pushes to your forges. Verifies AoVs and enforces quorum.
Gateway docsControl Plane
IAM, release policy, Tag Requests, attestations, the audit log and evidence pages — hosted at zegit.io or self-hosted (z-backend).
ComplianceHow it fits together
The model is edge-first and governance-centric. Identity is passkey-bound: a WebAuthn ceremony makes the Control Plane issue a short-lived X.509 signing certificate; zg validate signs AoVs with that cert; the gateway verifies the chain to the Root CA, checks revocation, and accepts or rejects the push. The full identity model — cert anatomy, delegating a session to an agent, automation identities — is on Identity & certificates.
developer / agent gateway (pre-receive) control plane
zg validate ──signs──▶ verify AoV → Root CA IAM · policy
git push ─────────▶ check revocation + quorum Tag Requests
ALLOW → accept audit log
BLOCK → reject ZG_ERR_* bundle genFail-closed by default
For protected refs, a gateway whose revocation list is staler than the max staleness (default 60s) must fail closed (ZG_ERR_REVOCATION_LIST_STALE), as must an unreachable Control Plane. The shipped gateway has no offline grace period.
Where the gate runs today
In production the gate is the z-gateway-server SSH gateway: it hosts the bare repository itself and forwards every accepted push to GitHub and Gitea, once the Control Plane has re-verified the tip; the forges become read mirrors, and the zegit-gateway GitHub App (and its Gitea credential) is the only identity allowed to write the protected branch. z-gateway install gitea|gitlab|generic installers ship as well, but no customer host runs them yet and the GitLab one has never been exercised. Enforcing directly on GitHub.com and GitLab.com (shadow mode first) and on GitHub Enterprise Server is on the roadmap. zegit governs its own repositories — zegit, zg, watchsong and Common — this way — every commit on master carries a verified AoV, and every release is a quorum-approved Tag Request.
Releases: zg, z-backend and z-gateway ship as signed archives on github.com/zegit-zoo/zg; the source repository is private. Security contact and coordinated-disclosure terms: zegit.io/.well-known/security.txt.
Dig in
Authoritative reference, generated from the component repos. Spot something stale? Tell us.