cd /news/ai-agents/pushgate · home topics ai-agents article
[ARTICLE · art-136997] src=pushgate.dev ↗ pub= topic=ai-agents verified=true sentiment=· neutral

Pushgate

Pushgate launched as a checkpoint that sits between a coding agent and GitHub, blocking pushes that fail a repository's configured tests and security checks. The product verifies signed evidence for the exact change and returns unmet requirements to the agent's working loop, with no per-agent fees and support for existing Git workflows. Pushgate states it checks only pushes sent through it, so repository permissions must prevent unauthorized direct pushes to GitHub.

read3 min views1 publishedSep 22, 2026
Pushgate
Image: source

Tests & coverage

Unit tests, integration tests, coverage thresholds and mutation tests using your project’s tools.

Pushgate is a checkpoint between your coding agent and GitHub. Choose the tests and security checks you require. Pushgate blocks pushes through it that don’t meet your rules.

✓ Keep your Git workflow ✓ No per-agent fees

Bring the agentsyou already work with.

					A missing check becomes the next step.

Watch a push go from missing evidence

to an accepted change.

A commit, with evidence attached.

Missing requirement? A clear reason.

Complete the work. Submit the evidence.

Inspect the decision and its evidence.

repository acme/checkout-service

commit a81f9c2

status ready to push

Run the example to see the gate in action.

Return the unmet requirement directly to the working loop. Evaluate the change against the repository’s selected policy.

Understand the checks and evidence behind the decision.

A policy is your repository’s list of requirements.

Use a built-in check or bring your own commands. Built-in secret scanning. Go vulnerability checks and other dependency scanners use a custom command policy.

Require your formatter, linter or type checker to pass before a push goes through. Check dependency rules, API contracts or module boundaries with your team’s scripts.

Run your infrastructure validators, container checks and configuration tests.

Add an accessibility check, a performance budget or a project-specific validation command.

These are examples of requirements you can configure, not checks that all run automatically. A coverage or performance threshold needs a command that fails when the limit is missed. Pushgate verifies the signed result for the exact change.

Your team decides what a change must prove. Select a policy for each repository and give agents a consistent answer.

See each repository and its selected requirements.

Review the exact policy before changing a repository’s requirements.

Connect each result to the policy used to evaluate it.

						Illustrative configuration only. This example does not change any repository or show a current bulk rollout feature. Today, an
						authorized person selects and approves each repository’s policy. [Explore available policies →](https://pushgate.dev/policy)

					When trusted checks have already run for

this change, verify their evidence and run

what remains. Explore the difference.

Reusable means valid evidence for this exact change, from an execution environment your policy accepts.

less waiting per verification cycle

Both paths satisfy the same defined check requirements. Timing starts after the change and any reusable check results exist; that earlier work is excluded equally. CI queues and reruns all checks. The Pushgate path runs the remaining checks immediately in an approved environment and adds an illustrative 3 seconds for evidence verification. We approximate reusable execution time linearly. Any additional queue, evidence-production overhead, merge checks, hardware tests, release checks or human approval must be included in a real measurement. This is a scenario, not a benchmark or a promise of delivery-time savings.

See the evidence behind an accepted change.

Understand the boundaries of the guarantee.

It means the supplied evidence satisfied the configured requirements. It does not prove all possible bugs were found, that the tests were sufficient, or that the change is ready for every deployment environment.

A signature identifies a signer; trust also depends on the evidence producer and execution environment. A policy must define which evidence it accepts. The signed result alone does not make a weakened test suite reliable.

						Pushgate checks only pushes sent through it. Your repository permissions must prevent unauthorized direct pushes to GitHub.
						A gated remote cannot enforce requirements on a route that bypasses it. [Check the entire route during setup.](https://pushgate.dev/docs#protect-the-route)

Start with one repository and one requirement. Keep the integration, environment and release checks you need. Reuse results only where they provide equivalent evidence for the required check.

Prove the workflow on one repository, then bring the team.

One private repository.

Up to 3 developers. Unlimited agents.

Billed annually.

$39 per developer when billed monthly.

Custom annual agreement.

Deployment and support scoped with you.

Paid plans use a sales-assisted handoff. View full pricing and plan details → Connect one repository. Send a signed push. Choose your rules.

── more in #ai-agents 4 stories · sorted by recency
── more on @pushgate 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/pushgate] indexed:0 read:3min 2026-09-22 ·