# Introducing Pushgate: Evidence Before a Push Is Accepted

Source: https://www.testifysec.com/blog/introducing-pushgate

Author: TestifySec

Published: 2026-08-25

Updated: 2026-10-06

Give developers and agents the same requirements at the Git push boundary, with decisions you can inspect.

Editorial update · October 6, 2026

Consolidated from Pushgate and revised by TestifySec Editorial on October 6, 2026. Original publication date and URL slug retained. Use the linked documentation for supported commands and deployment behavior.

- [Current documentation →](https://www.testifysec.com/docs)
- [Trust model →](https://www.testifysec.com/docs/concepts/trust-model)

Developers and coding agents build, test, lint, and scan in their working environments. A Git commit alone does not tell the receiving repository whether the required checks ran for that change.

 

Pushgate puts a decision at that boundary. It checks the evidence required by the gate’s assigned policy before accepting the push for delivery.

 

## The idea

 

CI/lock captures configured work and produces attestations. Pushgate evaluates the required evidence for the proposed change. The TestifySec platform manages gates, policies, identities, and evidence across repositories.

 

The useful outcome is an inspectable decision: what was required, which evidence was evaluated, and why the push was accepted or refused. Evidence for another commit does not satisfy a requirement for this one merely because a filename or display label matches.

 

## What this changes about CI

 

Teams can use evidence from work on their own compute or hosted infrastructure, where the gate’s policy permits that producer and environment. Central CI remains useful for independent checks, release operations, deployment credentials, and platform-specific test matrices.

 

Start by identifying a repeated check and the trust boundary it needs. Any decision to reuse a result should consider the exact subject, relevant inputs, producer identity, and protection of the execution environment. Measure the effect in your workflow; this article makes no universal time or cost claim.

 

## The security boundary matters

 

A valid signature binds a statement to a signer. It does not make the statement true, establish that a test suite is adequate, or prove that the code is safe. An agent that controls a trusted producer may still fabricate evidence.

 

Protect the producer and signing authority according to the claim you need. Keep observed agent metadata separate from authenticated identity. Keep evidence production, policy signing, publication, repository activation, push signing, override authority, and delivery observation distinct.

 

A gate’s acceptance decision is also separate from the upstream Git service completing delivery. Inspect the appropriate record for each outcome. The [trust documentation](https://www.testifysec.com/docs/concepts/trust-model) explains those limits.

 

## Open formats, inspectable evidence

 

CI/lock builds on in-toto attestation formats. Teams can inspect the signed records and evaluate them with the supported verification tools. Compatibility depends on the predicate and verifier versions, identity rules, and policy being used.

 

See the [architecture](https://www.testifysec.com/docs/concepts/architecture) for how collection, signing, storage, and verification fit together.

 

## What is available

 

This is a dated product introduction, not a release matrix. Use the [setup guide](https://www.testifysec.com/docs/pushgate/setup), [environment support matrix](https://www.testifysec.com/docs/concepts/support-matrix), and [policy reference](https://www.testifysec.com/docs/pushgate/trust/policy) to evaluate the supported configuration for your deployment.

 

Start with one repository and one set of requirements. Exercise complete evidence, a missing result, and evidence for the wrong commit. Then decide how the [platform](https://www.testifysec.com/product) should manage the same workflow across the rest of your repositories.