Pushgate.dev documentation
Pushgate verifies the proof attached to an exact Git commit before it forwards the update to GitHub.
On this page
Mermaid source
flowchart LR
A[Agent workspace] -->|runs the work| C[CI/lock witness]
C -->|signed in-toto / DSSE| T[TestifySec platform]
T -->|signed policy decision| P[Pushgate edge]
P -->|accepted update| G[GitHub]Start to finish
- Connect a repository. Pushgate creates a repository-specific Git remote and the narrow service relationships needed for that repository.
- Make the agent produce proof. Run the relevant build, test, lint, or security command through CI/lock using your approved signing workflow.
- Push normally. The agent sends the exact refs and Git pack to the Pushgate remote.
- Verify before delivery. Pushgate checks the push identity, the evidence for each proposed commit, and the selected policy decision before an accepted update reaches GitHub.
Repository setup is the source of commands.
The Pushgate setup screen generates the remote and CI/lock instructions for the connected repository and the deployed CLI version. Copy those instructions instead of constructing a broader credential or guessing a command not shown there.
Read the trust model
The rest of this section follows one push through the system. Start with the trust path, then use the evidence and policy pages as embedded contracts when you integrate another attestor, CI workflow, or verifier.
Core terms
- Attestation
- A signed in-toto Statement describing an observed command, result, subject, or material.
- Policy
- A signed document describing which evidence and identities are required.
- VSA
- A signed verification summary that binds a policy outcome to the exact push context.
- gitoid
- A content identifier computed from the exact bytes of a stored envelope.