Pushgate

Pushgate is an admission gate for git push. It presents as a git remote: developers and coding agents push to it, it judges each push against signed policy at the edge, and it either forwards the change to the upstream repository or refuses it with a reason a machine can act on.

The decision is evidentiary, not heuristic. Every push carries a certificate naming the pushing identity, issued by the platform's own certificate authority. Policy is evaluated against signed attestations bound to the specific commit — evidence that tests ran, that dependencies resolve to approved sources, that a human reviewed the change. The verdict itself is signed and retained as a verification summary attestation (VSA), so every admission decision is a checkable record rather than a log line.

How a push is decided

Three checks run in sequence:

1. Verify the push certificate. The certificate chains to the platform's Fulcio certificate authority and is validated against the platform's RFC 3161 timestamp authority. Identity is a precondition of the gate, not an add-on.
2. Retrieve the attestations bound to the commit. Evidence produced during development and build — test results, dependency resolution, reviews, scans — is signed and bound to the commit it describes.
3. Evaluate the witness policy. The policy names which steps are required, which identities may sign each one, and what rules the evidence must satisfy. A signature that is cryptographically valid but produced by the wrong identity, or missing a required step, fails.

A refusal returns structured remediation rather than a failure message, so a coding agent can correct the problem and retry without a human translating the error. Every decision — allow or deny — is recorded as a signed verdict with the evidence that produced it.

Identity and sessions

• The platform runs its own PKI. Signing certificates are issued by the platform's Fulcio certificate authority, and signatures are timestamped by the platform's RFC 3161 timestamp authority. No public certificate authority or hosted timestamp service is in the trust path. See Trust architecture and PKI.
• Signing is keyless. Certificates are short-lived — minutes, not months — and the private key behind each one is discarded after use. There is no long-lived pushing credential to steal, leak, or inherit.
• Sessions use a device authorization flow. A developer or agent establishes a session by completing a device grant; the session, not a stored secret, is what authorizes pushes.
• Per-push approval and break-glass. Policy can require an explicit approval for each push. A break-glass bypass exists for emergencies: the push is admitted, and the bypass itself is recorded in the decision trail rather than disappearing into one.

Fast because it verifies

A gate is only as useful as it is fast. A control that adds ten minutes to every push gets routed around, disabled, or made advisory within a quarter. One that answers in under a second becomes part of how people work.

Pushgate decides at the edge, and it is fast for a structural reason rather than an optimization: it verifies evidence rather than regenerating it. Checking a signature chain, retrieving attestations bound to a commit, and evaluating a policy are cheap operations measured in milliseconds. Running the test suite that produced the evidence is not. The gate never re-runs the work; it checks the claim.

That distinction matters most for agentic development. When a refusal returns in under a second with machine-readable remediation, an agent corrects and retries inside its own working loop. When it returns in ten minutes, the agent has moved on, the developer has context-switched, and the failure has to be picked up by a human later. Enforcement at machine speed is what allows remediation at machine speed. The sub-second figure is a measurement of the edge decision itself; end-to-end time depends on how quickly the evidence store answers.

Two further properties follow from verifying instead of re-running:

• Local test evidence can substitute for repeating the same checks in cloud CI. If a test ran and produced signed evidence bound to the commit, the gate verifies that evidence instead of paying for the run twice.
• Nothing about the existing review workflow changes. Pull requests, reviews, CODEOWNERS, and merge queues are untouched. The gate sits in front of the repository, not inside the review process.

What Pushgate observes about agents

The agent-context attestor records which coding agent produced a push. It observes; it never gates. Its output does not block a push on its own — it is a record that policy and reviewers can consult, bound to the commit like any other attestation.

The record is observational, not hermetic. It documents the agent context that was visible when the push was made; it does not prove what the agent did or did not do outside that record. Pushgate's claims about agents are deliberately of the form "this was observed and recorded", never "this could not have happened". The security coverage page carries this posture through the full threat taxonomy.

One policy, three enforcement points

Pushgate is the first of three points where the same signed policy and the same attestations can be evaluated.

• Push time — Pushgate, this product. Decided at the edge, sub-second.
• Sign time — verification in front of an artifact signer, so a build that fails policy never reaches the key. Seconds, dominated by evidence retrieval.
• Deploy time — a Kubernetes admission webhook evaluating the same policy before a workload runs. Planned; not yet generally available.

In this section