The Safeguard CLI is a single static binary with no runtime to install, so it fits inside a sandbox image or setup script. It can scan a project from a terminal or pipeline, and it can also write code. Inside a locked-down agent sandbox, allow only the network path it needs to send results, and verify what leaves.
What the CLI is, per the download page
Safeguard's download page lists the CLI as Available, version 1.4.0, and describes it as a way to scan from your terminal or CI/CD pipeline, "a single static binary with no runtime to install." Install is a one-line command on macOS and Linux and a PowerShell command on Windows, and the installer verifies a checksum before putting anything on your PATH. The page says scans run on your machine or in your pipeline and send only the results. One example command on the page is a scan of a project directory.
The page also lists a Local agent and a Cloud agent as Available, and a Cloud CLI that runs the same tool on Safeguard's infrastructure so a scan needs no local runner. Beyond scanning, the CLI can write code. We state that plainly and make no comparison claims about how well it does so.
Why a static binary suits sandboxes
| Property | Why it helps in a sandbox |
|---|---|
| No runtime to install | The setup phase stays small, with fewer packages to pin |
| Single file | Easy to bake into an image and hash |
| Checksum verified install | Part of your supply chain evidence |
| Runs locally or in a pipeline | Works in the same places agents work |
| Sends only results | A smaller data flow to reason about |
A tool that needs a language runtime and a dozen packages adds setup steps, each with its own supply chain risk. A static binary shortens that list, though you still verify the binary itself.
Three places to run it
- Setup phase of a cloud agent. Install in the image or setup script, where network access is normally broader. Scan the repository once the dependencies are in.
- Agent phase, as a tool the agent calls. Useful if you want the agent to check its own changes. This needs a network path for results, so decide whether to allow it.
- Outside the sandbox, on the pull request. The agent pushes a branch and a pipeline step runs the CLI against the diff, before review.
The third is the most conservative. The scan runs where credentials and network are under your control, not inside the environment the agent shapes.
A worked example: scanning an agent's changes
An illustrative flow for a team using a hosted coding agent with default deny network access.
- The setup script installs the CLI by its pinned version and checks the installer's checksum step succeeded.
- The agent works on a task and edits a dependency manifest.
- The agent branch is pushed, and a pipeline job outside the sandbox runs the CLI on the branch.
- The scan results go to the Safeguard service, which the pipeline's network allows.
- A policy gate evaluates the results. A new dependency with a known serious issue blocks the pull request.
- A reviewer sees the finding next to the diff and rejects or asks for a different version.
The agent never needed outbound access to Safeguard, and the check still happened before merge.
Network decisions if you run it inside the sandbox
| Option | Network needed | Tradeoff |
|---|---|---|
| Run only in setup | During setup only | Cannot check changes the agent makes later |
| Run in agent phase | One allowed host for results | Adds a destination to your allowlist |
| Run outside in the pipeline | None in the sandbox | Check happens after the agent finishes |
| Use the Cloud CLI | No local runner | Work runs on Safeguard's infrastructure, which you must be comfortable with |
If you add a destination for results, record an owner and reason, and watch the block log. One host with one purpose is easy to defend.
Credentials
Give the CLI the narrowest credential that works, and do not put it in an environment variable the agent can read if you can avoid it. Use whatever proxy or network secret mechanism your sandbox offers. Check the CLI's current documentation for authentication details, since we do not describe them here.
Using the CLI to write code
Because the CLI can write code, apply the same rules as for any agent that changes files.
- Run it as a dedicated identity with repository limits.
- Let it push to a task branch only.
- Review what it produced like any other pull request, reading workflow and manifest changes first.
- Keep automatic fix pull requests off until you trust the review process. Safeguard's autonomous remediation is off by default, with every category on Manual.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the CLI runs locally and what it reports, then decide where in your sandbox design that run belongs.
Where Safeguard fits
This post is about Safeguard itself: the CLI, the Local agent, and the Cloud agent are listed as Available on the download page, and SBOM and dependency scanning, reachability analysis, policies and gates, and a free scan at gold.safeguard.sh/scan are part of the platform.
Quick check
Does the Safeguard CLI need a language runtime?
No. The download page describes it as a single static binary with no runtime to install.
What leaves the machine when the CLI scans?
The download page says scans run on your machine or in your pipeline and send only the results. Review exactly what your configuration sends before using it on sensitive code.
Can the CLI write code?
Yes. Treat its changes like any agent's, with a dedicated identity, a task branch, and human review before merge.
Sources
Last reviewed: 19 October 2026.
