Coding agents changed where software work happens. They edit, build, test, lint, and scan inside a developer workspace, often before a hosted runner has even started. But the final trust decision still sees only a Git commit and a claim that the work passed.
Pushgate adds the missing evidence boundary to Git push. Your agents push code. Pushgate checks the proof.
The idea
CI/lock records a command as signed, structured evidence bound to the exact commit. Pushgate sits in front of the repository, verifies the push and the evidence selected by policy, and forwards only a decision it can support.
- The work runs where the agent is already working.
- CI/lock records what ran, its outcome, and the exact Git subject in an in-toto attestation.
- The attestation is signed through the TestifySec platform, timestamped, and stored under its content identity.
- On Git push, Pushgate checks the push identity and the evidence for every proposed commit before delivery.
A test result for one commit cannot be silently reused for another. A display name, tag, command log, or agent-supplied claim is not authority. When Pushgate cannot resolve or verify required provenance, it does not reinterpret that outage as an empty policy or a pass.
What this changes about CI
This is not an argument for deleting every hosted workflow. It is an argument against paying to repeat work solely because the first result was not portable evidence.
Developer tests, linters, and scanners can run with the agent's warm workspace and caches. Central CI remains the right place for privileged release operations, protected deployment credentials, cross-platform matrices, and independent spot checks. Pushgate makes that boundary deliberate instead of treating every job as the same kind of trust.
The security boundary matters
An attestation proves the signed predicate for an exact subject. It does not prove that a test suite is good, turn observed agent metadata into authenticated identity, or make a signing key safe merely because an agent runs in a container.
The signer belongs across a separate boundary from the agent. CI/lock uses short-lived identity and open formats; production agent setups should isolate signing authority behind a constrained daemon or workload identity so the agent can request the permitted signature without obtaining reusable signing material.
Human and agent actions stay distinct. Policy authorship, repository activation, push signing, evidence production, an override, and final delivery observation are separate events. One signature is never stretched into proof of all of them.
Open formats, replaceable implementation
CI/lock is open source and standards based. Its evidence uses DSSE and in-toto statements, keyless identity uses Fulcio/OIDC, and durable signing time uses RFC 3161. You can inspect it, fork it, compile your own version, or implement compatible attestors. Pushgate cares about the verified data model and policy contract, not a closed client binary.
Learn more on the CI/lock page, or inspect the open-source attestor framework on GitHub.
What is available
Pushgate early access supports signed pushes and commit-bound CI/lock test evidence, with block and observe postures and a bounded queue when GitHub delivery is unavailable. Exact custom-policy evaluation and platform-notarized final delivery receipts are rolling out behind strict, fail-closed compatibility checks; we will not market an unbound field as verified while that work lands.
That honesty is part of the product. The gate should make a small number of strong claims, show the exact basis for each one, and say unavailable when the evidence is unavailable.
Put one repository behind the gate.
Start with a real agent workflow, measure the effect on the delivery loop, and keep the CI jobs that still earn their place.
Start with Pushgate.dev