Some repositories cannot be handed to a cloud service. Maybe the policy says no, maybe the repo is private and nobody wants to grant OAuth access, maybe the network only allows outbound HTTPS. The Safeguard local runner exists for those cases.
The idea is simple. The platform schedules a scan, your machine does the work, and only the results travel back. Your source code never leaves.
What it is
The runner is not a separate product. It is part of the Safeguard CLI. You open the interactive terminal, sign in, and your machine starts polling the platform for jobs assigned to it.
When a job arrives, the runner pulls the repository onto your machine, runs the scan with its own local scan server, and pushes only encrypted results back. According to the docs, those results are the SBOM and the findings. Source code stays where it is.
It supports three modes: interactive, headless and agent.
Use it when:
- Your repository is private and you cannot or will not give a cloud service OAuth access.
- You work in a restricted network where only outbound HTTPS is allowed.
- You want the assistant to fix vulnerabilities in code you have not pushed yet.
How the connection works
All traffic is outbound HTTPS that the runner opens. Nothing connects in to your machine. The runner sends a heartbeat, polls for jobs, executes a claimed job locally, uploads the result files and reports the job status.
That matters for review. A security team can read "outbound HTTPS only, no inbound listener" and check it with a firewall rule instead of trusting a sentence in a vendor document.
How to use it
Install
The runner ships with the CLI. There is no separate runner package, so use the one-line installer.
# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
# Windows
irm https://cli.safeguard.sh/install.ps1 | iex
The docs state plainly that there is no Homebrew formula, winget package or container image for the runner itself. Read the script before piping it into a shell if that is your habit.
Interactive mode
safeguard
Type /login. Your browser opens, you approve the session, and the runner starts. The first run also downloads the scanner tools and the vulnerability database. The bar above the input shows whether the runner is idle and polling or busy with a scan, and /status prints the user, tenant, runner, uptime and job counts. /jobs shows recent scan history.
You can run safeguard runner to open the same terminal.
Headless mode
For a server, a build agent or a workstation that stays on, skip the terminal interface.
# Serve assistant turns for this workspace, no terminal UI
safeguard runner start --workspace ./path/to/repo
# Is it running, and what is it doing
safeguard runner status
# Drain in-flight work and stop
safeguard runner stop
The runner long-polls by default. On a network that forbids held connections, pass a poll wait of 0 to poll at a fixed interval instead. The default interval is 10 seconds, controlled by the SAFEGUARD_POLL_INTERVAL variable.
safeguard runner start --workspace ./path/to/repo --poll-wait 0
A permission mode flag sets how much the assistant may do without asking, from supervised to autonomous. Start supervised.
Agent mode
The assistant can act on the code in the workspace.
# Interactive, in this workspace
safeguard agent "fix the critical CVEs in this repository"
# One turn, no prompts, for scripts and CI
safeguard exec "summarise the critical findings"
safeguard exec defaults to strict permissions. Nothing is asked, and anything the policy file has not pre-approved is denied. That default is the right one for unattended use.
Inside the interactive terminal, /permissions picks the approval mode: ask, auto or yolo. Auto is the default and approves known actions. Yolo approves everything and never asks, so keep it for throwaway sandboxes.
Zero AI works too
The CLI scanner can use an LLM for source analysis, but it does not need one. In Zero AI mode everything runs without a model. For code that must not be sent to a model at all, that is a useful choice, and we cover it in a separate post on choosing how Safeguard uses models.
Keep it current
safeguard self-update
Note that safeguard update is different. It refreshes the vulnerability databases, not the binary.
Checking the claim yourself
Do not take "source stays on the machine" on faith. Test it.
- Run a scan on a throwaway repo that contains a unique string in a source file, such as a comment with a random word.
- Open the files in the output folder. You will find the SBOM and findings, and the findings describe packages and vulnerabilities, not your source files.
- Watch outbound connections with your usual tool while the scan runs. Every connection should be outbound HTTPS to Safeguard.
Try it yourself
Click through the demo to see how a local runner scan is set up and what comes back to the platform. Then repeat the steps above on a real repo.
Click through it at your own pace, or open it full screen.
Quick check
What does the runner send back to the platform?
Encrypted results: the SBOM and the findings. Source code stays on your machine.
Does anything connect in to a machine running the runner?
No. The runner opens all connections itself, as outbound HTTPS.
Which permission mode is the default for safeguard exec?
Strict. Nothing is asked, and anything the policy file has not pre-approved is denied.
