Teams often ask how Safeguard blocks a risky change. The answer has two parts. Policy gates decide whether a product's scan results are acceptable. PR Guard reviews the diff of a pull request. They are different features, and the docs are careful to keep them apart.
Policies and gates
A policy is a rule that evaluates your SBOMs and generates findings. A gate is a checkpoint that enforces policies. Gates are evaluated by the platform on the scans it runs for your connected repositories, so connecting the repository is what puts them to work. Nothing has to run in your pipeline for that.
Policy conditions listed in the docs include vulnerability severity, CVSS score, EPSS score, license, component age, maintenance status and SLSA level. There are templates such as No Critical Vulnerabilities, License Compliance, No Abandoned Packages and SLSA Level 2. Create one under Settings, Policies, with the visual builder or YAML.
Actions and outcomes
Each policy has one Action that decides what a failure does to the gate.
| Action | When the policy fails |
|---|---|
| Block | The gate fails |
| Warn | The gate passes, with a warning naming the policy |
| Notify | The gate passes and a notification goes to your configured channels |
The gate's own outcome follows a fixed order. No linked policies means Not evaluated. Any failed Block policy means Failed. Otherwise an error on any policy means Error. Otherwise a policy not yet evaluated means Not evaluated. Otherwise a failed Warn policy means Warning, and everything else is Passed. An Error is never counted as a pass, and a gate that has never run shows Not evaluated, never Passed.
Policy outcomes are switched on per workspace by Safeguard. If you do not see an Outcome column, ask your Safeguard contact.
Failing a CI build on a gate
With outcomes on, the policy outcomes page documents this command:
safeguard ci scan --wait --fail-on-gate "<gate name or id>"
It waits for the scan and for the gate's policies to be evaluated on the new data, exits zero when the gate is Passed or Warning, and exits non-zero when it is Failed, Error or Not evaluated. The CI/CD page makes a related point: the plain safeguard scan command reports findings and does not fail a build on them, and there is no published Safeguard GitHub Action for the CLI yet. Check both pages for what your CLI version supports.
Exceptions
When a legitimate exception is needed, a developer clicks Request Exception, picks the policy and finding, gives a business justification and an expiration date, and submits it. Approvers are notified, review it and grant or deny it, and an audit trail is recorded.
PR Guard
PR Guard is AI code review for pull requests. It analyzes the diff and returns a score, a summary and comments tied to a file and line, each with a severity (critical to info) and a category such as security, bug or maintainability, and optionally a suggested fix.
It appears as a PR Guard tab on a project's detail page. Pick a pull request and click Run Review. Check Post to GitHub if you want the comments published onto the pull request itself. The docs say PR Guard is currently wired to GitHub pull requests and shows a notice for other providers. Runs move through Queued, Running, Completed or Failed, and past runs are kept in a History tab.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
A policy with the Warn action fails. Does the gate fail?
No. The gate passes with a Warning that names the policy.
Where are gates evaluated?
By the platform, on the scans of your connected repositories, not by a command inside your pipeline.
