Yes. The Safeguard CLI scans locally or in a pipeline and can also write code. A tool that both finds problems and edits code deserves the same gates as any coding agent: data path, execution, reach, evidence, and control. Test those before rollout, and keep human review of every change.
What the download page states
Safeguard's download page lists the CLI at version 1.4.0 as a single static binary with no runtime to install. It offers a curl installer for macOS and Linux, a PowerShell installer for Windows, and direct binary downloads with published checksums. The page describes the CLI as scanning on your machine or in your pipeline and sending only the results. It also lists a Local agent and a Cloud agent as available. The company has confirmed that the CLI can also write code. This post makes no comparisons or performance claims and only describes the shape of the tool.
Why a scanning tool that writes code needs the same gates
A scanner reads. A tool that edits files and proposes fixes acts. The moment a tool acts, the questions in our evaluation framework apply.
| Gate | Question | How to test it |
|---|---|---|
| Data path | What leaves the machine? | Read the documentation, then watch network traffic in a test run |
| Execution | What commands can it run? | Ask for a task outside its expected scope and see what happens |
| Reach | Which files and tokens can it touch? | Run it in a container with only a test project mounted |
| Evidence | What does it record? | Run a task and export the record |
| Control | Who can restrict or disable it? | Try to set a policy for a test group |
A worked example: a one week trial
| Day | Activity | What you learn |
|---|---|---|
| 1 | Install from the official installer on a test machine, verify the checksum | Supply chain hygiene of your own install |
| 2 | Run a scan on a throwaway repository with known vulnerable dependencies | Whether findings match what you expect |
| 3 | Run it with the network restricted | What it needs to reach |
| 4 | Ask it to write a small fix, review the diff | Quality and scope of changes |
| 5 | Run it in your pipeline on a branch | How it behaves in automation |
| 6 | Try planted hostile text in a file | Whether it holds up |
| 7 | Review logs, write the decision record | Evidence for approval |
Verify the installer like any download
Whichever tool you try, verify what you install. Use the published checksum, prefer a pinned version over the latest, and avoid piping an installer script to a shell on a machine that holds credentials. Do the first install in a throwaway environment. Our post on vetting an MCP server covers the same habits for other tooling.
Where it fits in a developer workflow
| Stage | Role of a CLI |
|---|---|
| Local development | Scan before committing, propose fixes in a branch |
| Pull request | Run in a pipeline job so results are visible to reviewers |
| Scheduled | Re-scan on a timer for newly disclosed issues |
| Incident | Check which projects contain an affected package |
Whatever writes code, put the pull request gate in front of the merge. A policy gate applies the same rules to a human and to a tool.
Keep review human
A tool that can write code does not change who is accountable. The person who launched it owns the pull request, and a second person reviews. Autonomous remediation with fix pull requests is a Safeguard capability that is off by default, with every category set to manual, so changes appear as reviewable pull requests.
Writing the decision record
At the end of the trial, capture the outcome in a page that a later reader can follow.
| Section | Contents |
|---|---|
| Scope | Which repositories and environments are covered |
| Gates | Result of each of the five gates, with evidence |
| Controls | Container, network rule, approval settings, branch protection |
| Owners | Named engineering owner and security reviewer |
| Limits | What the tool is not approved to do, such as pushing to protected branches |
| Review date | When the decision is revisited |
What to log when a tool both scans and edits
Because the same binary reads and writes, log both. Record each scan run, with the target and result, and each proposed change, with the files touched and the person who launched it. If the tool runs in a pipeline, keep the job log and the pull request together so a reviewer can see what was found and what was changed in one place.
Common questions from reviewers
- Does a scan result prove a change is safe? No. A finding explains why a change was proposed. Tests and review decide whether to merge it.
- Should scans run before or after the change? Both. Scan before to see the problem, scan after to confirm it is gone.
- Who can approve the pull request? A human other than the author, enforced by branch protection.
- What if the tool is offline? Plan a fallback so work does not stall, and so people do not paste code into other tools.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and notice what the CLI does on your machine and what leaves it.
Where to start
Download the CLI from the Safeguard download page, or try the free scan at gold.safeguard.sh/scan first.
Quick check
Does the CLI send my code to Safeguard?
The download page says it scans on your machine or in your pipeline and sends only the results. Confirm the specifics for your setup in the documentation and by watching traffic in a test.
Should a CLI that writes code be allowed to push?
No. Let it propose changes on a branch and require a human reviewer before anything merges.
How do we install it safely?
Verify the published checksum, pin the version, and try it first in a throwaway environment.
Sources
Last reviewed: 19 October 2026.
