Can the Safeguard local runner gate a pull request?

Not by itself. The Safeguard local runner executes platform assigned scan jobs on your own machine and uploads just the SBOM and findings. The block or warn decision comes from the platform's policy gates, so the runner is where the scan happens, not where the verdict is made.

What does the runner do?

According to the Safeguard docs, the runner "executes the platform's scan jobs and assistant turns on your own machine." Source code stays on that machine. What leaves it is the resulting SBOM and findings, sent over outbound HTTPS that the runner opens. Nothing connects in to the runner.

This is useful when a team cannot or will not give a hosted service access to its repositories, but still wants the same findings and policies in one place.

Where does the gate come from?

Gates live in the platform. The Guardrails and Enforcement page describes guardrails that can run at six enforcement points: IDE, commit, CI, registry, admission and runtime. Runtime is early access, and the admission controller is not yet available. The effects are BLOCK, WARN or AUTO_FIX. Policies are written in YAML with a target, one or more rules and an effect.

For CI, the docs say gates are evaluated by the platform on the scans it runs for your connected repositories. They are not a step you add to your pipeline. The CLI has no gate command.

How do you set the runner up?

The documented steps, from the Local Runner page:

curl -fsSL https://cli.safeguard.sh/install | bash
safeguard

Then type /login inside the session and approve it in your browser. The first run downloads the scanner tools and the vulnerability database. To run it without the terminal interface for one repository:

safeguard runner start --workspace ./path/to/repo
safeguard runner status
safeguard runner stop

On Windows the installer is irm https://cli.safeguard.sh/install.ps1 | iex. The page adds that there is no Homebrew formula, winget package or container image for the runner.

What about the pull request itself?

PR Guard is a separate feature. It reviews a pull request's diff and returns severity ranked findings inline in Safeguard, and it can post them back to GitHub through the Post to GitHub option. It requires a GitHub connected repository. The PR Guard page does not describe merge blocking, required status checks or approvals, so confirm with Safeguard support whether it can block a merge before you rely on that.

So there are three pieces, and each has one job:

• The runner scans where your code lives.
• Policy gates turn findings into block, warn or fix actions.
• PR Guard reviews the diff and posts comments.

What are the limits?

The runner docs do not mention gates or pass or fail enforcement. They do not state that a pull request automatically triggers a runner job either. Test your own flow end to end: open a pull request that adds a known vulnerable dependency, watch whether a job reaches the runner, and check what the platform reports.

Try the walkthrough at /demos/local-runner-cli.

What to do

1. Install the CLI with the one line installer and run safeguard, then /login.
2. Start the runner for one repository with safeguard runner start --workspace and the path.
3. Check safeguard runner status to confirm it is running.
4. In the platform, connect the repository and review which policies and gates apply.
5. Open a test pull request with a known vulnerable dependency.
6. Record what the runner uploaded and what the gate decided. Adjust the policy effect from WARN to BLOCK once the results look right.
7. Ask support whether PR Guard can block merges in your setup, and write the answer down.

Quick check

Sources

• Safeguard docs: Local Runner, fetched 18 October 2026
• Safeguard docs: Guardrails and Enforcement, fetched 18 October 2026
• Safeguard docs: PR Guard, fetched 18 October 2026
• Safeguard docs: CI/CD Integration, fetched 18 October 2026

Last reviewed: 18 October 2026.