A pull request gate is a check that runs in your repository or pipeline and blocks, warns or asks for approval. It does not run on a phone. What a phone can do is let a person review the result and approve an exception. Safeguard's mobile app is in early access beta, so check what it covers today.
What is a pull request gate?
A gate is a rule attached to a checkpoint. At the pull request, the checkpoint is the merge. The rule might say that no new critical vulnerability with a known exploit may be added, or that a leaked credential blocks the merge outright. The action can be to block, to warn, to notify, or to require approval.
Safeguard's model separates policies, which generate findings, from gates, which enforce at checkpoints. A CI gate action is available for pipelines. The enforcement happens where the code is built, so it works whether or not anyone is holding a phone.
PR Guard is a related feature. The docs describe it as AI code review for a pull request: it analyzes the diff and returns a scored summary and comments tied to a file and line, with optional suggested fixes, and results can be posted back onto the pull request. The current implementation is wired to GitHub pull requests, and review actions are disabled for projects on other providers.
What does mobile add?
Gates fail at inconvenient times. A release is waiting, the person who owns the exception is away from a desk, and the pipeline sits red. This is where a phone is useful.
The web app documentation says mobile web coverage is focused on review and notification workflows: reviewing and approving remediations that Griffin proposes, acknowledging alerts, reading findings and advisories, and approving exceptions. It says heavy operations, such as writing workflows, editing policies and deep SBOM inspection, are best done on desktop.
The dedicated mobile app for iOS and Android is early access beta. We do not describe its screens here, because the beta is changing. Treat the web app documentation above as the confirmed baseline for what review on a phone looks like, and check the app itself for anything beyond it.
How should you design an approval you can trust on a small screen?
Keep exceptions narrow and expiring. An approval from a phone should be easy to give and easy to audit. Four rules help.
Make the reviewer see the reason. A bare "approve" button invites mistakes. The screen should show the finding, the affected component and the proposed exception.
Set expiry by default. An exception with no end date becomes policy by accident.
Limit who can approve. Only named owners should be able to waive a gate, and the audit log should record who did and when.
Do not use a phone for first-time policy changes. Edit gate rules on a desktop, with review, and test them on a branch.
See how a gate behaves in the pull request gate demo.
What to do
- Decide the rules: which findings block a merge, which warn, which need approval.
- Add the gate to the pipeline and run it in warn mode for a week.
- Turn on blocking for the rules the team agreed to.
- Name the people who can approve exceptions and require a reason and an expiry.
- Test an approval from a phone end to end, including the audit record.
- Keep policy edits on desktop, and review them like code.
Quick check
Can the mobile app block a merge?
Blocking is enforced by the gate in your repository or pipeline. A phone is for review and approval of the outcome.
Is the mobile app generally available?
It is in early access beta. Confirm current availability before you build a process around it.
Sources
- Safeguard docs: Web Application, fetched 18 October 2026
- Safeguard docs: PR Guard, fetched 18 October 2026
Last reviewed: 18 October 2026.
