● 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. "Policy cannot be weakened" is a cryptographic property. |
| 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. Self-hosted deployments can set an offline grace period for unprotected refs only.
Where the gate runs today
Two shipped shapes: the z-gateway pre-receive hook on Gitea or GitLab self-managed, or the z-gateway-server SSH gateway that hosts the bare repository itself and forwards every accepted push to GitHub and Gitea, which become read mirrors — the zegit-gateway GitHub App is then the only identity allowed to write the protected branch. Enforcing directly on GitHub.com via a GitHub App ("shadow mode") is on the roadmap. zegit governs its own repository 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.