The Safeguard CLI scans from your terminal or a CI pipeline and can also write code. The download page lists a Local agent and a Cloud agent as Available, plus a local sandbox and a hosted cloud sandbox. Use local options when work needs your machine, and cloud options when you want nothing to install.
What the download page lists
This post uses only what the Safeguard download page states on 19 October 2026. The page headline lists versions for the desktop app (3.2.2) and the CLI (1.4.0), and groups ways to run Safeguard by where they execute.
| Where | Item | Page description |
|---|---|---|
| Local | CLI | One static binary. Scan from your terminal or wire it into a CI/CD pipeline. A curl installer is shown for macOS and Linux |
| Local | Sandbox | An isolated local sandbox to try scans and fixes against throwaway state |
| Local | Computer | The native desktop app for Windows, macOS and Linux |
| Cloud | Cloud sandbox | A hosted, isolated sandbox tenant against a seeded demo repo |
| Cloud | Cloud CLI | The CLI running on Safeguard's infrastructure, so a scan needs no local runner |
| Cloud | Cloud browser | A remote browser session running Safeguard, streamed to your tab |
| Agents | Local agent | Listed as Available |
| Agents | Cloud agent | Listed as Available |
The page also says every branch controls the same Safeguard, with the same data, the same agents and the same guardrails, and that sensitive steps wait for a person and every action is logged whoever or whatever took it.
The CLI also writes code
Safeguard's CLI is more than a scanner. It can also write code, which means it belongs in the same review as any other coding agent. That includes the questions in this series: which files can it edit, which commands can it run, what identity does it act as, where do approvals sit, and what is logged. Nothing here is a comparison with other tools, and no benchmark is claimed. It is simply a reason to apply the same checklist to a tool you may trust more because it comes from a security vendor.
Local versus cloud, in this context
The local-or-remote reasoning from the decision guide applies directly.
| Situation | Leaning |
|---|---|
| Scan a repository on your laptop before pushing | Local CLI |
| Scan in a CI pipeline | CLI wired into the pipeline |
| Try scans and fixes without touching real state | Local sandbox, or the hosted cloud sandbox |
| No install allowed on a locked down machine | Cloud CLI or cloud browser |
| Unattended work while devices are off | Cloud agent |
| Work needing local files and tools | Local agent |
Step by step: evaluating the agents in a pilot
- Start in a sandbox, local or hosted, against throwaway state.
- Read what the agent can access: repositories, files, commands, network.
- Run a small task, such as finding and proposing a fix for one vulnerable dependency.
- Check the log for the actions taken and the identity used.
- Confirm that sensitive steps wait for a person, as the page states, and test one.
- Check that automatic fixes are off or on Manual until you decide otherwise. In Safeguard, autonomous remediation with fix PRs is off by default and every category is on Manual.
- Move to a real repository with a narrow scope and a named owner.
- Record the results in your scorecard, using the same criteria as for any other agent.
A worked example
A developer wants to see what an agent would do about a vulnerable dependency without risking a real project. She starts the local sandbox, points the CLI at the throwaway state, and asks for a fix. She reviews the proposed change, the log and the approval prompt. Satisfied, she runs the same task on a small internal service with fix pull requests set to Manual, so every change waits for review. A week later, the team compares what the agent proposed with what developers would have done and decides which categories to loosen.
What to record for audits
If an auditor or customer asks how you govern AI coding tools, show a short record for each agent you allow: what it is for, where it runs, who owns it, which repositories it may touch, what approvals apply and where its log lives. For the Safeguard CLI and agents, that record sits next to the same record for any other assistant, so the answer reads consistently. Add the date you last tested the controls and the version you tested. Safeguard's compliance and evidence automation can hold these records alongside your other control evidence, and a reviewer reading them should see the same discipline applied to every tool.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a command line run reports its results, and think about which of your own tasks you would try first.
Where to start
You can run a free scan at gold.safeguard.sh/scan to see your dependency picture, then try the CLI from the download page. Safeguard's MCP Guardrail and agent identity features cover access control for agents that connect through MCP.
Quick check
Does the CLI only scan?
No. It scans from a terminal or CI pipeline and can also write code, so review it like any coding agent.
What is the difference between the local and cloud agent?
The page lists both as Available without further detail. Ask Safeguard for specifics on access, identity and logging, then test them as you would any agent.
Are automatic fixes on by default?
No. Autonomous remediation with fix PRs is off by default, with every category on Manual.
Sources
Last reviewed: 19 October 2026.
