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 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 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, environment support matrix, and policy reference 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 should manage the same workflow across the rest of your repositories.