The hard questions

No. Packs are verified and forwarded; nothing about your source is kept. While a push is queued (upstream down, or the GitHub app not yet installed) the verified pack sits encrypted at rest in storage until it delivers, then it is deleted. What we keep is the evidence trail — identities, commit digests, verdicts, timestamps — because that trail is the product.

It cannot forge the platform's signature, reuse another commit's attestation (the commit digest is inside the signed record), or backdate one (the timestamp comes from the timestamp authority, not the agent's clock). The honest limit: an attestation proves what ran on the agent's machine under the signing identity. It does not prove your test suite is good — and an owner of the signing identity could attest a different command. That is why identities are scoped and revocable, and why keeping one CI runner as a random spot check — rather than a toll booth every push pays — is a reasonable posture.

Nothing, until you add the branch rule — and we say this loudly because a gate everyone can bypass protects nobody while looking like it does. With the GitHub app installed, a repository ruleset restricting pushes to the app's identity makes the gate the only way in. Without it, this is an advisory control and the pushes page shows what WOULD have been refused.

Your agents do not stop. The gate serves ref advertisements from its own cache, verifies pushes at the edge, stores the packs durably, and answers in milliseconds. Delivery is asynchronous and FIFO per repository; when GitHub returns, the queue drains in order. An agent can chain pushes on top of commits GitHub has never seen — we have done it live.

Delivery halts at the first conflict rather than delivering around it — queued packs chain, so skipping one would corrupt the sequence — and the conflicted push is surfaced on the pushes page asking exactly that question. The branch rule above prevents the situation entirely.

It replaces CI-as-proof. The agent already ran the tests; cilock signed the record; the gate verified it for the exact commit. Re-running the same suite on a runner to establish the same fact is paying twice. Runners stay useful for what agents cannot do locally — cross-platform matrices, release builds — and as spot checks.

Not to try it: connect a repository, point an agent at it, and watch the pushes page — no signup. Enforce mode (verifying test evidence) uses the TestifySec platform as the evidence store, which is where an account and your own tenant come in; cilock login creates both.

The signing and verification stack — cilock, the attestors, the policy engine — is open source (github.com/aflock-ai/rookery). The gate itself is a hosted service today. If you need it inside your walls, talk to us; the architecture does not require our edge to be the edge.

Closest is FINOS GitProxy — a push proxy used in production by several banks, built around human approval workflows for data-loss prevention. GitLab has server-side push rules inside GitLab. github.com itself supports neither pre-receive hooks nor push certificates, which is much of why this is a proxy. Nothing we know of combines an in-front-of-your-remote gate with cryptographic evidence, agent-repairable refusals, and a delivery queue.

While in early access: free. The intent is a per-repository price for the gate with the evidence store metered separately, and we will publish it before charging anyone. Nothing you connect now gets held hostage — disconnecting is one click and your remote is unchanged.