Pushgate.dev

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 its certificate principal, issued by the platform's own certificate authority. Policy is evaluated against signed attestations bound to the specific commit — evidence that tests ran, dependencies resolved to approved sources, or GitHub recorded a review state. A GitHub review record does not by itself prove that a person was present. The exact custom-release evaluator identifies policy by immutable release, envelope gitoid, and payload digest rather than by a mutable name or tag; that path and the final delivery receipt are still in rollout, so custom releases remain disabled until producer and consumer are live together.

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 selected policy. Available built-in controls are AND-composed today. After the exact-release cutover, every enabled custom release joins that composition; its signed policy names the required steps, allowed evidence signers, and evidence rules. The platform VSA contract binds that decision to the tenant, repository, immutable repository ID, commit, nonce, and exact release. A signature that is cryptographically valid but does not satisfy the policy functionary, or a missing 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. The signed-decision rollout requires every real allow or deny to be stored with the evidence descriptors that produced it; infrastructure, trust, storage, and malformed-input failures remain unsigned. The final platform-notarized GitHub delivery receipt is not yet a generally available customer record.

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.
• End-user signing is keyless. Certificates are short-lived — minutes, not months — and the private key behind each one is discarded after use. Repository setup credentials and service-federation credentials are separate, purpose-scoped, and revocable; they are not presented as artifact-signing identity.
• Human and agent identities are a target boundary. Ambient workflow OIDC identifies a workload. Today's local stored-session exchange instead mints an AAL1 creator-email token without proving human presence or a stable agent identity, so agents must not use it. Explicit server-observed human/agent selection remains a follow-up.
• Per-push approval and break-glass. The gate supports bounded approval behavior, but the final receipt projection of exact failed-decision targets, actor, reason, and window is still in rollout. A valid policy denial may be overridden; missing or unverifiable decision provenance may not.

Policy library and activation

Pushgate's policy library is read-only. Cilock is the authoring surface: an agent can inspect the repository and its workflows, query Cilock's tool and attestor catalogs, and prepare policy and evidence commands. On today's local stored-session path, the human must personally run identity-bearing evidence, signing, and publish commands; workflow OIDC may run them as the registered workload.

The agent then directs the human through activation. It can explain the intended release and monitor state without mutation. The signed-in human performs today's onboarding/settings mutation, such as Create gated remote. The target credential-free before/after Apply ceremony, verified artifact-signer display, and durable activation-actor projection are not shipped yet. A release whose complete evaluator is unavailable remains visibly disabled; catalog presence alone never makes it enforceable.

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

When agent-context evidence is present, Pushgate displays the coding-agent process context visible when it was collected. It observes; it never gates. Its output does not block a push on its own, authenticate a stable agent principal, or satisfy an evidence requirement. The first-party Cilock producer for this format is still being integrated.

The record is observational, not hermetic. A same-user process can influence the product, model, and configuration it exposes. Pushgate's claims about agent context are deliberately of the form "this was observed and recorded", never "this identity was authenticated" or "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