Human Approval for Agent Actions in Safeguard Desktop and Mobile Apps

Safeguard lets an AI agent do security work on a real machine while a person approves each risky step. The agent runs through the Safeguard CLI (GA) on your computer, and you approve or deny its commands and file edits in the terminal, in the desktop app (early access, beta) or from your phone in the mobile app (early access, beta). Nothing that changes your system runs until someone says yes.

That is the short answer. The longer one matters more, because "a human approves it" is only a control if the approval is informed, scoped and recorded. This post covers what the standards ask for, how the three Safeguard surfaces handle approvals today, a step by step walkthrough from pairing a phone to denying a command, and the limits you should know before you rely on either app.

Key takeaways

• Safeguard CLI and its local runner: GA. The CLI's assistant asks before it writes a file, edits code or runs a command. The /permissions command sets how often it asks.
• Desktop app for Windows, macOS and Linux: early access (beta). It wraps the web app and adds a local panel with Scan, Terminal, MCP, Tasks, Files and Settings tabs. Agent tasks pause for your approval before destructive actions.
• Mobile app for iOS and Android: early access (beta). It sends work to a computer running the CLI and lets you answer each command with Allow once, Allow for turn or Deny. The phone does not run scans itself.
• MCP server with per tenant tool gating: GA. Administrators decide which tools an assistant can see and call; new workspaces start with a small read-only set.
• In-app agentic search, including the browser autonomous agent: early access. It needs typed consent for every session and stops after a fixed number of actions or seconds.
• Agent identity: GA. It tracks which agent holds what access, at what level.
• Autonomous remediation (Griffin fix pull requests): GA, ships off, with every category set to Manual until you change it.
• The EU AI Act Article 14, the NIST AI RMF and OWASP's LLM06 Excessive Agency all point to the same design: least privilege first, then a person who can understand, refuse, override and stop.
• Approvals are only as good as the person giving them. Plan for approval fatigue the way identity teams plan for push notification fatigue.

The problem: agents that act, not just answer

A coding assistant that only suggests text is a reading problem. An agent that runs npm install, edits package.json, pushes a branch or deletes a folder is an operations problem. Once a model can call tools, every output becomes a possible action on a real system, and the failure modes change.

The model can be confidently wrong: it misreads a task, picks the wrong file or chooses a heavier fix than you wanted. It can also be steered. Text inside a README, an issue comment, a dependency's changelog or a web page can carry instructions the model treats as part of its task. Security agents are especially exposed here, because their job is to read untrusted material: advisories, package metadata, exploit write-ups and other people's code.

The usual answer is a person in the loop. That is right but incomplete. Someone who clicks "approve" forty times an hour, or approves from a phone screen that hides half the command, is not reviewing anything. An approval that leaves no record cannot be checked later by an auditor or an incident responder.

So the real problem has three parts:

1. Scope. The agent should only have the tools and permissions the task needs, so most dangerous actions are impossible rather than merely discouraged.
2. Consent. For the actions that remain, a competent person should see what is about to happen and decide, with the option to refuse, override or stop.
3. Evidence. What ran, who approved it and what changed should be reconstructable afterwards.

The standards below describe those three parts in different words.

What the standards say about humans approving agent actions

None of these documents was written for a vulnerability fixing agent on a laptop, but buyers in regulated sectors will ask how your agent setup lines up with them.

EU AI Act Article 14: human oversight

Regulation (EU) 2024/1689, the AI Act, sets human oversight requirements in Article 14 for high-risk AI systems. Most security tooling used inside a company will not fall into the high-risk categories, so treat Article 14 as a design reference unless your legal team tells you otherwise. It is still the clearest statement in law of what "meaningful oversight" means.

The article's main points, read from the text of the regulation:

• Article 14(1) requires high-risk systems to be designed, including with suitable human and machine interface tools, so that natural persons can effectively oversee them while they are in use.
• Article 14(2) says oversight aims to prevent or minimise risks to health, safety or fundamental rights, including under reasonably foreseeable misuse.
• Article 14(4) lists what the people assigned to oversight must be enabled to do. They must be able to (a) understand the system's relevant capacities and limitations, (b) stay aware of automation bias, the tendency to over-rely on the system's output, (c) correctly interpret the output, (d) decide not to use the system, or disregard, override or reverse its output, and (e) intervene or interrupt the system through a "stop" button or similar procedure that brings it to a halt in a safe state.
• Article 14(5) adds, for remote biometric identification systems, that an identification must be separately verified and confirmed by at least two natural persons before anyone acts on it.

Points (d) and (e) map directly onto an approval prompt. Deny is "decide not to use". Interrupting a running agent is the "stop" button. Point (b) is the one most approval designs forget. The law names automation bias explicitly, which means a design that trains people to click yes without reading does not meet the spirit of the article, even if every action technically had an approval.

NIST AI RMF 1.0: Govern, Map and Manage

The NIST AI Risk Management Framework (NIST AI 100-1, January 2023) is voluntary, but it is the reference most US security and risk teams use. Three subcategories matter here:

• GOVERN 3.2: policies and procedures define and differentiate roles and responsibilities for human and AI configurations and oversight of AI systems. In plain terms, someone must own the decision about who approves what.
• MAP 3.5: processes for human oversight are defined, assessed and documented in line with the organisation's policies.
• MANAGE 2.4: mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage or deactivate AI systems whose performance or outcomes are inconsistent with intended use.

The framework also notes, in its discussion of human factors, that human and AI configurations "can span from fully autonomous to fully manual". That is a useful way to read the Safeguard permission modes later in this post: they are points on exactly that range, and the organisation should choose the point deliberately rather than let each engineer drift toward the most convenient one.

NIST's Generative AI Profile (NIST AI 600-1, July 2024) adds detail. It lists "Human-AI Configuration" among the risks unique to or worsened by generative AI, describing automation bias and over-reliance by name, and its suggested actions include defining acceptable use policies for human and AI configurations (GV-3.2-003) and maintaining procedures for escalating incidents when criteria for deactivation or disengagement are met (MG-2.4-002).

OWASP Top 10 for LLM Applications 2025: LLM06 Excessive Agency

OWASP's LLM06:2025 Excessive Agency is the most practical of the three. It defines the risk as damaging actions taken in response to unexpected, ambiguous or manipulated model output, and gives three root causes: excessive functionality, excessive permissions and excessive autonomy.

Its prevention list starts with scope, not approval. Minimise the extensions an agent can call. Minimise what each extension can do. Avoid open-ended extensions such as "run a shell command" where a narrower one will do. Minimise the permissions each extension holds on downstream systems. Execute extensions in the user's own context. Only then does it say require user approval: use human-in-the-loop control so a person approves high-impact actions before they are taken. It closes with complete mediation (enforce authorisation in downstream systems, not in the model) and with logging and monitoring of extension activity.

The order is the lesson. Approval is the last layer, not the first.

The Model Context Protocol specification

The Model Context Protocol, which Safeguard's MCP server and the desktop app's MCP tab both speak, says in its tools specification that "there SHOULD always be a human in the loop with the ability to deny tool invocations". It asks applications to make clear which tools are exposed to the model, to show visual indicators when tools are invoked, and to present confirmation prompts for operations. Its security considerations ask clients to prompt for confirmation on sensitive operations, show tool inputs to the user before calling the server, implement timeouts and log tool usage for audit.

NIST SP 800-63B: what identity teams learned about approvals

NIST SP 800-63B is about authentication, not AI. It earns a place here because identity teams have already lived through the failure mode that agent approvals will hit. In its section on out-of-band authenticators, the current revision states that a method which only asks the user to approve a request on a second device is "no longer considered acceptable", because people approve requests without checking them. It ties this to "authentication fatigue" attacks, where an attacker floods a user with prompts until one is accepted, and says verifiers that send push notifications should limit how many they send.

Swap "login request" for "agent wants to run this command" and the advice transfers directly: show the specific thing being approved, limit how often you ask, and make the risky answer take more thought than the safe one.

Requirement versus what Safeguard does versus what you still own

How Safeguard handles agent approvals today

Three surfaces share one model. The CLI on your computer is where the agent actually works. The desktop app and the phone app are places to give it work and answer its questions. Here is each one, using only what Safeguard's docs and published demos show.

The CLI: where approvals start (GA)

Run safeguard with no arguments and you get the interactive terminal. You sign in with /login, which opens a browser to approve the session, and from then on the machine's built-in runner polls the platform for work assigned to it. Safeguard's docs say your code never leaves the machine; only SBOMs and findings are uploaded.

You ask for things in plain language, for example "fix the lodash CVE in this repo". The assistant has tools for your local files and for your Safeguard data. The docs are specific about what happens next: tools that change things, such as writing a file, editing code or running a command, ask before they act.

The /permissions command sets how often they ask. The interactive terminal docs list these modes:

The current mode always shows in the bar under the input, and /status reports it alongside the user, tenant, runner, uptime and job counts. Run /permissions in your installed version to see the exact list it offers, since the CLI ships often.

Two more entry points matter for approvals:

• safeguard exec "..." runs one agent turn and exits, for scripts and CI. Its default permission mode is strict: nothing is asked, and anything the policy file has not pre-approved is denied. That is the right default for a pipeline with no human watching.
• safeguard runner start --workspace ./path/to/repo starts the runner without the terminal UI and serves assistant turns for that workspace. Its --permission-mode flag sets how much the assistant may do without asking, on a range the docs describe as running from supervised to autonomous.

The desktop app: web view plus a local panel (early access, beta)

The desktop app is an Electron application for Windows, macOS and Linux. It does not replace the web app; it wraps it. One window holds two views: the hosted Safeguard web app on the left, loading app.safeguard.sh unmodified, and a local panel on the right that can reach things a browser tab cannot, such as your filesystem, a local shell and MCP servers. Ctrl+Shift+S (or Cmd+Shift+S on macOS) toggles the panel.

The panel has six tabs:

The app also registers a safeguard:// deep link protocol. safeguard://scan, safeguard://terminal, safeguard://mcp, safeguard://tasks, safeguard://files and safeguard://settings open the panel on that tab, and safeguard://dashboard navigates the web view. For example, from a shell:

open "safeguard://scan"      # macOS
start "" "safeguard://scan"  # Windows
xdg-open "safeguard://scan"  # Linux

For approvals, three design choices matter more than the feature list.

Scope is enforced before approval is asked. The app can only read folders you have granted through your operating system's file picker. Every file operation is checked against that list, and path traversal out of a granted folder is rejected. The Terminal tab only runs binaries on a fixed allowlist (Safeguard tools, git and gh, container tools, common package managers, common runtimes and a set of system utilities), and the working directory must sit inside a granted folder. A command outside the list, or a working directory outside every granted folder, is rejected before it starts, and the docs note that neither check is configurable per user. This is OWASP's "minimise functionality" and "avoid open-ended extensions" applied at the app level.

Agent tasks pause on destructive steps. In the Tasks tab you describe a job in plain language. The app matches it to a built-in workflow (local repository scan, MCP configuration audit, dependency watch, container scan or IDE extension check) or breaks it into generic steps. Subtasks run in sequence with live status. When a subtask is about to take a destructive action, the task pauses and raises an approval request describing what it is about to do; you approve or deny before it continues. You can cancel a running task at any point.

The web view cannot drive the panel. Both views run with Node integration off, context isolation on and the sandbox on. The web app only sees a minimal detection and panel control interface. It cannot read your files, run shell commands or drive the panel's native features. The web view also only navigates within *.safeguard.sh; external links open in your default browser.

The desktop docs also describe screen control features with their own safety rules: per app permission before the app can take mouse and keyboard control, banking, crypto, password manager and trading apps blocked by default, every action logged with before and after screenshots, and screen content checked for prompt injection patterns before the agent acts on it. Treat these as part of an early access app and test them in your own environment before depending on them.

The mobile app: send work, answer prompts (early access, beta)

The mobile app runs on iOS and Android. In the approval story it plays one specific role: it sends work to a computer running the Safeguard CLI, and it answers that computer's approval prompts. Safeguard's recorded Android demo shows exactly this. You see your desktop and CLI sessions, send a task to your computer, and when the agent wants to run a command the phone shows the prompt with three answers:

• Allow once. Approve this action only. The next action asks again.
• Allow for turn. As the label says, a broader approval tied to the agent's current turn, so you are not asked again for the rest of that piece of work.
• Deny. Refuse the action. The agent does not run it.

The scan, the command and the file edit all happen on the computer, under the CLI's own rules. The phone does not run scans itself. It is a remote control and an approval device, which is also why it is useful: you can let a long remediation run on a workstation and still be the person who says yes to npm install.

Use Allow once as your default on the phone. Small screens truncate long commands, and "Allow for turn" on a turn you have not fully read is exactly the pattern SP 800-63B warns about for push approvals.

The browser autonomous agent: a bounded cousin (early access)

Inside the web app's Griffin AI Search, part of the in-app agentic search features (early access), there is also an autonomous agent that watches a shared screen and acts in steps. It is worth knowing because its consent model is strict and well documented:

• Each run starts with a consent dialog: you type a goal and tick a box authorising browser actions for that session. Consent is not remembered across sessions.
• It can only act inside the Safeguard tab you shared. Share anything else and it only suggests actions with an on-screen marker, because the browser's same-origin rules stop it reaching other content. When in doubt, it suggests rather than acts.
• A session ends after 30 actions or 60 seconds, whichever comes first, and stopping is handled on your side, so it works even if the backend is slow.
• Every step is recorded with the reason the agent gave for it.

That is Article 14(4)(e) in miniature: a stop button that works regardless of the server, plus hard limits on a single run.

Where MCP tool gating fits (GA)

If you connect an outside assistant to Safeguard's MCP server, or run the bundled Safeguard MCP server in the desktop app's MCP tab, a second layer applies before any prompt reaches a human. Each MCP tool has its own per tenant feature flag. A new workspace starts with a small default set of read-only tools; every other tool, including ones that add an integration or start a scan, ships disabled until an administrator turns it on under Feature Flags. A tool that is not enabled does not appear in the tool list and a call to it is rejected. If tool resolution fails, the server falls back to the small default set, so an outage cannot widen what an assistant can do.

This is OWASP LLM06's "minimise extensions" done at the server. It means your human approver only sees prompts for tools the organisation has already decided the agent may use at all.

Step by step: pair a phone, send a task, approve one command, deny another

This walkthrough follows what Safeguard's docs and recorded demos show. Where the docs do not show a specific screen, the steps describe the outcome rather than inventing a menu name.

1. Install the CLI on the computer that will do the work. On macOS or Linux, Safeguard's docs give the one-line installer. If you prefer to read the script first, which the docs themselves recommend, download it and inspect it:

   curl -fsSL https://cli.safeguard.sh/install -o install.sh && less install.sh
   bash install.sh
   

   On Windows:

   irm https://cli.safeguard.sh/install.ps1 | iex
   

2. Sign in and start the runner. Open the interactive terminal and sign in:

   safeguard
   

   Type /login, approve the session in the browser that opens, and the runner starts polling for work assigned to this machine. The first run also downloads the scanner tools and the vulnerability database. /whoami confirms the account.

3. Choose the approval mode before you leave the desk. Type /permissions and pick Ask if you want every action to come to you, or keep Auto if you only want new kinds of action to prompt. Check the bar under the input to confirm the mode. If you would rather run the computer without the terminal open, the headless form serves assistant turns for one workspace:

   safeguard runner start --workspace ./path/to/repo
   safeguard runner status
   

4. Install the phone app and sign in to the same workspace. Install from the App Store or Google Play, as the download page directs, and sign in with the account you used on the computer. Safeguard's Android demo then shows your desktop and CLI work on the phone, so you can see which computer you are about to send work to.

5. Send a task to the computer. Describe the job in plain language, for example "check this repository for reachable critical vulnerabilities and propose a dependency upgrade". The task runs on the computer, not on the phone. In the desktop app's recorded demo the same flow asks which computer and which folder to use; pick the repository folder, not your home directory.

6. Approve the first command with Allow once. When the agent wants to run something that changes state, such as a package install or a test run, the phone shows the prompt. Read the full command and the target folder. If it matches what you asked for, choose Allow once. The command runs on the computer and the agent continues.

7. Deny the second command. Suppose the next prompt is something you did not ask for, such as a push to a remote branch or a command touching a folder outside the repository. Choose Deny. The command does not run. The agent has to work around the refusal or stop and report back, and you can follow up from the computer later.

8. Review what happened at the computer. Read the end of the session in the terminal, run git diff and git status, and use /jobs for recent scan history. In Safeguard's CLI demo the assistant prints a summary and pushes nothing on its own.

9. Interrupt if anything looks wrong. In the interactive terminal, esc interrupts whatever is running without exiting. In the desktop app, cancel the task from the Tasks tab. Both are your stop buttons.

10. Put the computer back into a stricter mode. If you loosened the mode for a supervised session, set it back with /permissions before you walk away again.

How CLI permission modes combine with phone approvals

The phone does not override the CLI's mode. It answers the questions the CLI decides to ask. That gives you a simple way to reason about combinations:

Within a session, the phone's three answers add a second dial. Allow once keeps every new action in front of you. Allow for turn trades some review for fewer interruptions on one piece of work. A practical team rule: use Allow for turn only when you have read the plan for the turn and the mode on the computer is Ask or Auto, never as a way to clear a queue of prompts you have not read.

For CI, the strict default of safeguard exec answers "who approves when nobody is watching": the policy file decides in advance, which keeps the decision outside the model, as OWASP's complete mediation principle asks.

What is logged, and how to review what was approved

Evidence is where most approval setups are weakest, so it is worth being precise about what Safeguard's docs describe.

On the computer (CLI). The CLI writes safeguard.log, by default under ~/.sg/logs; the LOG_DIR variable moves it. The interactive terminal keeps the session transcript, and /resume picks the session back up the next time you open the terminal in the same folder. /jobs shows recent scan history and /status shows the approval mode in force. Your version control is the most important record of all: every file the agent edited shows up in git diff, and nothing is pushed unless someone pushes it.

In the desktop app. The Tasks tab shows each subtask's status and result as it runs. For screen control features, the docs say actions are logged with before and after screenshots.

In the browser autonomous agent. Every step, executed or only suggested, is recorded in a live session log with the reason the agent gave.

On the platform. Safeguard's enterprise readiness features include an append-only audit log (GA), alongside SSO, roles and permissions.

What the docs do not describe. The desktop and CLI docs pages do not describe a central history view of phone approval decisions (who chose Allow once or Deny, on which device, for which command). Until you have confirmed with Safeguard what your tenant's audit log captures for these apps, treat the computer's own log, the terminal transcript and your git history as the record, and copy them into your normal log retention.

A workable routine today: after any remote session, read the transcript, run git diff and git log on every repository the agent touched, and archive safeguard.log with your other workstation logs.

How to install each app and verify the download

All three installs start from safeguard.sh/download, which reads the same release feed as the desktop docs.

Desktop app

At the time of writing the desktop release is 3.2.2. The download page and docs list:

• Windows: a universal per-user installer that picks x64 or ARM itself and needs no administrator rights, plus smaller single architecture installers. Windows builds are not yet code-signed, so SmartScreen shows "Windows protected your PC". The docs say to choose More info, then Run anyway, and to verify the checksum if you want certainty.
• macOS: separate Apple Silicon and Intel disk images, signed with Safeguard.sh Inc's Developer ID and notarized by Apple. The download page lists macOS 12 or later.
• Linux: an x86_64 AppImage. Mark it executable and run it. The download page notes it needs FUSE and the Safeguard CLI installed and on your PATH.

Verify before you run. The release publishes a SHA256SUMS manifest beside the installers. With that file in the same folder as your download:

# macOS / Linux
shasum -a 256 -c SHA256SUMS

# Windows: compare the output against SHA256SUMS by eye
certutil -hashfile Safeguard-<version>.exe SHA256

On Linux the download page also shows:

sha256sum Safeguard-3.2.2-x86_64.AppImage

On macOS you can also confirm the notarization after installing:

spctl -a -vvv -t exec /Applications/Safeguard.app
# expect: accepted, source=Notarized Developer ID

Mobile app

Install from the App Store (iPhone and iPad) or Google Play (phones and tablets). The download page says the stores handle signing, updates and rollback. At the time of writing, Apple's listing names the seller as Safeguard.sh Inc and requires iOS 16.4 or later, and the Google Play listing's data safety section states that the developer declares no data collected and none shared with third parties; as Google notes on every listing, that is the developer's own declaration.

For Android phones without Google Play, or for organisations that distribute apps themselves, the download page also offers an APK with its SHA-256 shown beside it. Two cautions from the page: you have to allow installs from your browser when Android asks, and updates for that APK come from the download page, not from Google Play. Check the hash before installing, exactly as you would for the desktop builds.

CLI

The installer detects your operating system and verifies the archive against the release's published checksums.txt, refusing to install on a mismatch. The docs flag one difference worth knowing: on macOS and Linux a missing checksums file makes the install fail closed, while on Windows it warns and continues. If that matters in your environment, verify the archive yourself against the release's checksums.txt before running the binary. SAFEGUARD_SKIP_CHECKSUM=1 turns verification off and is never the default; reserve it for an air-gapped mirror that does not carry the file. SAFEGUARD_VERSION pins an exact release.

What beta means here

Safeguard labels both apps early access, and the offering describes both as beta. The store listings and download page do not carry a beta banner, so here is what the label means in practice, based on what the docs and download page say today:

• Platform gaps. Windows desktop builds are not code-signed yet. The Linux desktop build is x86_64 only and needs FUSE and the CLI on your PATH. The desktop Scan tab can fall back to manifest-based analysis when the bundled CLI binary is not available for your platform, which the docs describe as reduced functionality.
• Features that may change. Tab layouts, approval wording and the list of built-in task workflows are the kind of detail that moves between releases. The desktop app checks for updates on launch and every four hours; "Ask before install" is the default.
• Admin controls you should confirm. Some features in these apps are switched on per workspace by an administrator. Confirm what is enabled for your tenant before you write a process around it.
• What not to rely on yet. Do not make either app the only place an approval can happen, the only record of what was approved, or the only way to stop an agent. Keep the CLI and its local log as the system of record, keep esc and task cancellation as your stop buttons, and treat the phone as a convenience that lets the right person answer at the right time.

A sensible pattern for a regulated team: design the control around the GA pieces (CLI, local runner, MCP server), then add the desktop and phone apps as early access ways to reach them.

What Safeguard does not do

• It does not make approvals meaningful on its own. An approval prompt records that someone said yes. Whether they understood the command is a training, staffing and workload question. If one engineer answers hundreds of prompts a day, the control has failed regardless of the tool.
• The phone does not run scans or agent work. Everything happens on a computer running the CLI. If that computer is off, asleep or offline, the phone has nothing to approve.
• It does not replace least privilege on the machine. The desktop app's folder grants and command allowlist help, but the CLI runs as your user. If your account can push to production or read cloud credentials, an approved command can too. Run agents under accounts and on machines scoped to the task.
• It does not provide a documented central approval history for the phone today. The docs pages for the CLI and desktop app do not describe one. Keep the CLI log, the transcript and your git history, and confirm with Safeguard what your tenant's audit log captures before you tell an auditor it is there.
• It does not make either app GA. Desktop and mobile are early access (beta). Plan for change, test updates before rolling them out, and keep a CLI-only path that works if an app release misbehaves.
• It does not decide your AI Act classification. Whether any system you run is high-risk under Regulation (EU) 2024/1689, and who your Article 14 oversight persons are, is a legal and organisational decision. Safeguard gives you approval points and records; it does not assign competence or authority.
• It does not turn on autonomous remediation by itself. Autonomous remediation (GA) ships switched off, with every category set to Manual. Any move toward more autonomy is a deliberate change your team makes.

Common mistakes

• Treating Yolo as a productivity setting. It approves everything. On a machine with real credentials it removes the one control this whole post is about.
• Approving long commands from a phone without scrolling. If the prompt is truncated, either scroll to the end or Deny and handle it at the computer.
• Using Allow for turn to clear a backlog. If you are approving to make prompts stop, the agent has more scope than the task needs. Narrow the task or the mode instead.
• Granting the desktop app your whole home folder. Grant the repository, not everything around it. Path traversal is blocked, but only relative to what you granted.
• Leaving every MCP tool on. Tool gating exists so an assistant cannot even see tools it should not call. Start from the read-only default and widen deliberately.
• Running agents in CI with prompts expected. Nobody is there to answer. Use safeguard exec with its strict default and a policy file that pre-approves exactly what the job needs.
• Skipping checksum verification because a store or notarization exists. For the APK, the Windows installer and the Linux AppImage, the published hash is your integrity check.
• Assuming the approval is the audit trail. Without the transcript, the CLI log and git history, a "yes" at 22:14 is hard to tie to what actually changed.

FAQ

Can I approve Safeguard agent commands from my phone?

Yes. The Safeguard mobile app (early access, beta) sends work to a computer running the Safeguard CLI and shows that computer's approval prompts. You answer each one with Allow once, Allow for turn or Deny. The work itself runs on the computer.

Does the Safeguard mobile app run scans on the phone?

No. The phone is for sending tasks and answering approvals. Scans, commands and file edits run on the computer where the CLI is signed in.

What are the Safeguard CLI permission modes?

Safeguard's interactive terminal docs list Ask (prompt before every action), Auto (approve known actions and ask for anything new, the default) and Yolo (approve everything). safeguard exec defaults to a strict mode that never asks and denies anything the policy file has not pre-approved. Run /permissions to see the list your installed version offers.

What does "Allow for turn" mean compared with "Allow once"?

Allow once approves only the action in front of you, so the next one asks again. Allow for turn is the broader choice, tied to the agent's current turn, so you are not prompted again for that piece of work. Use Allow once by default.

How do I stop a Safeguard agent that is doing the wrong thing?

In the interactive terminal, press esc to interrupt without exiting. In the desktop app, cancel the task from the Tasks tab. For the browser autonomous agent, click Stop or end screen sharing in your browser; it also stops on its own after 30 actions or 60 seconds.

Is the Safeguard desktop app safe to give access to my files?

It only reads folders you grant through your operating system's file picker, rejects path traversal outside them, and runs only allowlisted commands inside granted folders. The web view cannot reach your files at all. It is still early access, so grant the smallest folder that does the job.

How do I verify the Safeguard desktop download?

Download the release's SHA256SUMS file and run shasum -a 256 -c SHA256SUMS on macOS or Linux, or certutil -hashfile on Windows and compare by eye. On macOS, spctl -a -vvv -t exec /Applications/Safeguard.app confirms Apple's notarization.

Does using approval prompts make us compliant with EU AI Act Article 14?

Not by itself. Article 14 applies to high-risk AI systems and asks for oversight people who can understand, interpret, override and stop the system, with awareness of automation bias. Approval prompts are one building block. Classification, competent staff and documented procedures are on you.

Related reading

For more on these surfaces, see Safeguard on your phone (beta), remote device control from the mobile app, the desktop app guide, mobile versus web versus desktop and human approval gates for risky agent actions. In this series, choosing between a repo connection, the CLI or the local runner explains where the agent's work happens, and putting a policy proxy in front of MCP servers covers the tool traffic side.

When you are ready to try it, start at safeguard.sh/download and keep docs.safeguard.sh open for the current flags and screens.

The approval flows above usually end with the agent proposing a dependency change, so the same question follows every approved fix: what if the safe version does not exist yet? The block below is Safeguard's standard answer for the open source components you build and ship, and it applies whether a person approves the fix from a terminal, a desktop panel or a phone.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Android session. It shows the phone listing your desktop and CLI work, sending a task to a computer, and approving the resulting command from the phone with Allow once, Allow for turn or Deny. It is the clearest view of steps 4 to 7 in the walkthrough above.

Click through it at your own pace, or open it full screen.

The second demo is a real desktop app session. The CLI session appears in the desktop app's conversation list, the app asks which computer and folder to use, and you Approve or Deny each command and file edit until the upgrade is done and tests pass. It shows the same approval model on a larger screen, where long commands and diffs are easier to read before you answer.

Click through it at your own pace, or open it full screen.

The third demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it ask before each command as it edits package.json, runs npm install and npm test, prints a summary and pushes nothing. It ends with /permissions, /model and /scan ., which is where you set the approval mode the phone and desktop apps work within.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: Desktop Application
• Safeguard docs: CLI interactive terminal
• Safeguard docs: CLI slash commands
• Safeguard docs: CLI usage
• Safeguard docs: CLI installation
• Safeguard docs: Local Runner
• Safeguard docs: Safeguard CLI overview
• Safeguard docs: Autonomous Agent
• Safeguard docs: MCP tool availability and gating
• Safeguard: Download page
• Safeguard demo: Safeguard on your phone, recorded live
• Safeguard demo: The Safeguard desktop app, recorded live
• Apple App Store listing: Safeguard.sh
• Google Play listing: Safeguard
• EU AI Act Article 14, Human Oversight (text of Regulation (EU) 2024/1689 as reproduced by the AI Act Explorer)
• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST AI 600-1, Generative Artificial Intelligence Profile
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• Model Context Protocol specification: Tools
• NIST SP 800-63B, Authentication and Authenticator Management

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.