Autonomous remediation and fix PRs: a safe rollout guide

Safeguard's autonomous remediation opens fix pull requests for vulnerable dependencies, and it is off by default. To use it safely, preview fixes with safeguard fix --dry-run first, then turn on draft PRs with approval and tests required, review each diff like a teammate's change, and keep a tested way to revert before you widen the scope.

You can run every step in this guide with the assistant you already use. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. You can also connect Claude or ChatGPT to the Safeguard MCP server and ask about your findings from the chat you already use.

What you will have at the end

By the end of this guide you will have:

• A safeguard fix dry run on one repository, with a fix report you have read.
• A narrow first rollout: high findings and above, small upgrades, draft PRs, named reviewers.
• AI Remediate settings set the conservative way: approval required and tests run before a PR opens.
• A short review checklist for fix PRs.
• CI on the fix branch that rescans and fails when a gate fails.
• Three rollback routes you have tried once: close the PR, revert the merge, restore an assistant checkpoint.

You need a repository connected to Safeguard (GitHub, GitLab, Bitbucket or Azure DevOps), the Safeguard CLI, and a test suite you trust at least a little. If the CLI is not installed yet, see installing the Safeguard CLI on macOS. On macOS and Linux it is one line:

curl -fsSL https://cli.safeguard.sh/install | bash
safeguard --version

How autonomous remediation works

Safeguard calls the feature AI Remediate. Its docs describe five stages:

1. Analysis. Griffin AI, Safeguard's own model, reads the vulnerability and your codebase.
2. Solution generation. It works out the safest upgrade path for the vulnerable package.
3. Impact assessment. It checks for breaking changes and compatibility.
4. PR creation. It opens a pull request with all the changes.
5. Validation. Automated tests run to verify the fix, when you have configured them.

Most fixes are dependency upgrades: a fixed version, transitive conflicts handled, the lock file updated. The docs also list configuration fixes and, in some cases, code changes such as replacing a deprecated call. Review those last two more carefully, since they touch your own code.

The docs list full support for npm, yarn and pnpm; pip, poetry and pipenv; Maven and Gradle; Go modules; Cargo; Bundler; NuGet; and Composer.

Every fix also gets a breaking change level:

A generated PR includes a title with the CVE reference, a description of the vulnerability, a summary of the changes, any breaking change warnings, test results when tests are configured, and links to the advisories.

There are three ways to start a fix in the web app:

• One vulnerability. Open it, click AI Remediate, review the proposed change, then click Create Pull Request.
• A selection. Select several vulnerabilities, click AI Remediate Selected, review the batched fixes and create the PRs. You get one PR per repository.
• Everything fixable. On the Vulnerabilities page, click AI Remediate at the top. Griffin AI builds a remediation plan for all fixable findings; you review it, then approve and create PRs.

In all three, a person clicks the final button. Autonomous mode removes that click for the fixes you allow, so the rest of this guide is about deciding what you allow.

Step 1: preview fixes locally with a dry run

Before any PR exists, see what a fix would change. The safeguard fix command analyses vulnerabilities, updates vulnerable packages to safe versions, can generate a patched SBOM, and writes a fix report. With --dry-run it previews the changes without modifying files.

1. Go to a clean checkout of the repository and make sure the working tree has no local edits:

   cd ~/code/payments-api
   git status
   

2. Scan it so you know what you are fixing:

   safeguard scan --dir .
   

   Results land as JSON files under ./output, including vuln.json and license.json.

3. Preview the fixes for one manifest:

   safeguard fix --manifest package.json --dry-run
   

4. Read the report. By default it goes to fix-report.json; you can change that with --output:

   safeguard fix --manifest package.json --dry-run --output reports/fix-preview.json
   

The defaults are already conservative, and it is worth knowing them before you change any:

To make the first run even narrower, limit it to patch releases, one severity, one package or one CVE:

# patch releases only, critical findings only
safeguard fix --manifest package.json --patch-only --severity critical --dry-run

# a single package
safeguard fix --manifest package.json --package lodash --dry-run

# a single advisory, by its identifier from your scan
safeguard fix --manifest package.json --cve CVE-ID-FROM-YOUR-SCAN --dry-run

The command also takes --sbom and --scan-result for an SBOM or scan result you already have, and --patched-sbom writes the SBOM as it would look after the fix.

In the preview, every upgrade should map to a finding, no package should move further than it needs to, and nothing unexpected should appear. If the preview surprises you, the PR would have too.

Step 2: fix one finding with the assistant, and watch every step

The dry run shows what changes. The interactive CLI shows how, one approval at a time, which builds trust before you automate. This recorded session shows the loop on a sample project called payments-api:

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

In that session the CLI is installed with the curl command (checksum verified), safeguard --version confirms it, and safeguard opens the interactive terminal. The request is "fix the lodash CVE in this repo". The assistant reads the finding, the files and the advisory, then asks before each command, and you press y or n. It edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and prints a summary with a suggested commit message. It pushes nothing. The session ends with /permissions, /model and /scan .. If your tests do not catch a broken upgrade here, they will not catch it in a fix PR either.

The /permissions command sets how often the assistant asks. The modes in the current CLI are:

Start remediation work in Ask or the default Auto. There is also a --yolo flag that approves everything; keep it for throwaway sandboxes only.

Before you commit, run safeguard review, which reviews the working tree changes for correctness and security, or safeguard review --base main to review a branch against main. For more, see review AI generated code before merge.

Step 3: open your first fix PR as a draft

When the dry run and a manual fix both look right, let safeguard fix open a pull request. Start with a draft, a narrow scope and named reviewers.

1. Give the CLI a token for your source host. The help says --scm-token falls back to the GITHUB_TOKEN or GITLAB_TOKEN environment variable. Use a token scoped to the one repository you are trying, with only the access needed to push a branch and open a pull request, and load it from your secret store rather than typing it into a command.

2. Open the PR:

   safeguard fix \
     --manifest package.json \
     --severity high \
     --patch-only \
     --create-pr \
     --draft \
     --repo-url https://github.com/your-org/payments-api \
     --base-branch main \
     --reviewers alice,bob \
     --labels security,dependencies
   

   --pr-branch and --pr-title set your own branch name and title; without them both are generated.

3. Keep the fix report (fix-report.json by default) with the PR, or put its summary in --pr-body.

Leave --auto-approve (approves all fixes automatically) and --auto-merge (enables auto merge where the repository allows it) off for now. On day one they remove exactly the checks you are trying to build.

Step 4: turn on autonomous fix PRs in the platform

For fix PRs across many repositories, use the platform. Autonomous remediation is off by default, so nothing opens on its own until someone in your workspace changes these settings.

In the web app, open Settings, then AI Remediate. The docs list five settings:

A rollout order we suggest:

1. Week one: manual only. Leave Auto-Create PRs off. Use AI Remediate on single findings and AI Remediate Selected for a handful. Review every PR by hand.
2. Week two: approval gate. Turn on Auto-Create PRs for safe fixes, with Require Approval and Test Integration on. A person still approves each PR before it opens.
3. Later: fewer clicks for the routine ones. When safe, patch level fixes have merged cleanly for a while, decide with repository owners whether they still need the approval step. Keep major and critical changes manual.

This matches the docs' best practices: enable tests, start with safe fixes, review major changes rather than auto merging them, and watch your fix success rate.

Set Branch Naming early. A fixed prefix makes fix PRs easy to find and lets CI filters target them.

Step 5: review a fix PR in five minutes

A fix PR is still a code change, but it arrives with most of the evidence attached. This checklist keeps review short without making it shallow.

1. Match the CVE to a real finding. The title carries the CVE reference. Check that the finding exists in your project and affects the version you ship.
2. Read the change summary, then the diff. For a dependency fix you should see the manifest and the lock file change, and little else. Anything else in the diff needs a reason.
3. Check the size of the jump. Patch and minor bumps inside the same major line are the usual case. A major bump should carry a breaking change warning; if it does not, ask why.
4. Check the lock file moved. A manifest change without a matching lock file change ships nothing new.
5. Read the breaking change warnings. For Major or Critical, pull in the code owner.
6. Look at test results. With Test Integration on, results are in the PR. Your own CI should run too.
7. Look for code changes. Configuration fixes and code modifications get the same review as any hand written change.

You can do the same review locally with the CLI:

git fetch origin
git switch security/fix-high-patch
safeguard review --base main

You do not have to be at your desk. A CLI session is live: it shows in the web app, the desktop app and the phone app, and from the desktop or phone you can send work to a computer running the CLI and approve each command and file edit there. This recorded desktop session shows that flow:

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

The CLI session shows in the desktop app's conversation list, and "2 connected" shows the computer, the browser and Safeguard cloud. You ask for work on your computer, it asks which computer and folder, you pick the folder, and you Approve or Deny each command and file edit. It ends with the upgrade done and the tests passing. The desktop app guide covers setup.

Step 6: run tests and gates on every fix branch

Tests decide whether a fix is safe to merge. Gates decide whether it is safe to ship.

Tests. Turn on Test Integration so tests run before a PR is created, and let your normal CI run on the fix branch too. A fix PR should never have a lighter path to main than a human PR.

A rescan on the branch. Confirm the finding is really gone. With --local, safeguard ci scan scans the checkout on the runner and uploads only the results, never the source:

safeguard ci scan --local --wait --fail-on high

With --wait it polls until the scan finishes, and --fail-on fails the step when a vulnerability at or above that severity remains.

Gates. Policies and gates are evaluated in the platform, not by the CLI. When policy outcomes are enabled for your workspace, this fails the CI step when a gate fails:

safeguard ci scan --wait --fail-on-gate Release

A gate fails when a policy with the block action fails. Warn policies pass with a warning naming the policy, and notify policies pass and send a notification. Block on the policies that matter, warn on the rest, and let fix PRs prove they leave the gate green.

A plain safeguard scan does not fail on findings: it exits 0 when the scan ran, 2 when results were written but the vulnerability scan did not run, and 1 when the command failed.

For an assistant summary on each fix PR, safeguard exec "summarise what this branch changes compared with main" runs one turn without prompting, in strict mode by default. See running the Safeguard CLI in CI with safeguard exec.

Step 7: know your rollback routes before you need them

There are three moments when you might want to undo a fix, and each has its own route.

Before merge: close the PR. Close it, delete the branch and leave a comment saying why. If the finding is real but cannot be fixed yet, request a policy exception in the platform with a justification and an expiry date. Approvers are notified and the decision is recorded in an audit trail.

After merge: revert it. On GitHub, open the merged pull request and click Revert near the bottom. GitHub's docs explain that this creates a new pull request that reverts the original merge commit, with history intact. You need write access to see the button; if the revert conflicts, revert individual commits instead. The default merge method for safeguard fix is squash, so an auto merged fix lands as one commit:

git switch -c revert-security-fix
git revert <commit-sha>
git push origin revert-security-fix

Open that branch as a PR so the revert goes through the same CI and gate as the original.

On your machine: restore a checkpoint. When the assistant edits files in an interactive session, each file is snapshotted before each change. You can list and restore those checkpoints:

safeguard checkpoints list --session <id>
safeguard checkpoints restore <checkpoint> --session <id> --dry-run
safeguard checkpoints restore <checkpoint> --session <id> --files-only

--dry-run shows what would change as a diff. --files-only puts the files back without rolling back the conversation; without it, the transcript rolls back too, as /rewind does. A restore keeps the state it overwrites as a new checkpoint, so a restore can itself be undone.

One limit matters for dependency fixes: files the agent writes or edits are snapshotted, but anything a shell command writes is not. After the assistant edits package.json and runs npm install, the lock file and node_modules are not in the checkpoint. Use git for those:

git restore package-lock.json
npm ci

safeguard fix also backs up original files by default (--backup). Try each route once on a test repository before you turn on Auto-Create PRs.

Troubleshooting

The dry run proposes nothing. Check the severity. The default is high, so medium and low findings are skipped unless you pass --severity medium or --severity low. Also check that --manifest points at the right file in a monorepo.

The fix you expected needs a major upgrade. Major upgrades are off by default. Add --major-upgrades only for that package, with --package, and open the PR as a draft.

PR creation fails. Check --repo-url, and that a token with push access is available through --scm-token, GITHUB_TOKEN or GITLAB_TOKEN.

Tests pass locally but fail on the fix branch. Look for a lock file that did not change, a cache restoring old packages, or an environment difference. Run npm ci (or your ecosystem's equivalent clean install) on the branch.

safeguard exec refuses to run. It needs a git repository. Run it from the checkout, or pass -C with the path. Only use --skip-git-repo-check if you accept that there is no way to undo what it changes.

A gate shows Not evaluated. --fail-on-gate fails on Failed, Error and Not evaluated. It needs the policy outcomes feature; check that it is enabled for your workspace. If something else is off, run safeguard doctor to check health and connectivity.

Common mistakes

Turning on Auto-Create PRs before anyone has read a fix PR. Run manual rounds first to learn what normal looks like.

Using --auto-approve and --auto-merge on day one. They remove the human review you need while building trust.

Treating a green fix PR with no tests as safe. A fix PR with no test results tells you nothing about behaviour. Turn on Test Integration and keep your own CI on the branch.

Allowing major or breaking upgrades in bulk. Keep --major-upgrades and --breaking-changes for single packages, with an owner reviewing.

Assuming a checkpoint covers everything. Checkpoints cover files the agent wrote or edited, not files a shell command changed. Use git for lock files and build output.

FAQ

Is autonomous remediation on by default?

No. Fix PRs are off by default. Nothing opens on its own until someone in your workspace turns on the settings under Settings, then AI Remediate. You can still start fixes by hand with AI Remediate on any vulnerability.

What is the difference between AI Remediate in the web app and safeguard fix?

AI Remediate runs in the platform and opens PRs across connected repositories, with settings for approval, tests, breaking changes and branch naming. safeguard fix runs on your machine or a CI runner, with flags for severity, upgrade size, packages, CVEs and PR options. A sensible split is the CLI for previews and one off fixes, the platform for ongoing PRs.

Can I use my own AI plan for the interactive fixes?

Yes. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. See the CLI docs or run /model to choose the model. You can also connect Claude or ChatGPT to the Safeguard MCP server and ask about your findings from there.

Does a fix PR merge itself?

Not unless you allow it. The --auto-merge flag on safeguard fix enables auto merge where the repository allows it, and it is off unless you pass it. In the platform, Require Approval keeps a person in the loop before a PR is created. Keep major and critical breaking changes manual.

How do I undo a fix that already merged?

Revert it like any other change. On GitHub, click Revert on the merged PR to open a pull request that reverts the merge commit, then merge it after CI passes. Or run git revert on the commit. On your own machine, safeguard checkpoints restore puts back files the assistant edited.

Does my source code leave my machine when I run fixes locally?

With safeguard ci scan --local, the scan runs on the CI runner and only the results are uploaded, never the source. When the local runner runs platform scan jobs, only SBOMs and findings are uploaded. Opening a PR does push the fix branch to your own source host, which is the point of a PR.

Try it yourself

This walkthrough sets up the runner on your own machine: pick the platform, start it, approve it with its device code, then use the same CLI to scan from the terminal.

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

When you are ready, download the CLI from safeguard.sh/download, read the CLI docs, and start with one repository and a dry run. If you also use other coding agents, check coding agent changes with the Safeguard CLI before you merge them.

Quick check

Sources

• Safeguard CLI overview
• Safeguard CLI usage guide
• Safeguard CLI interactive terminal
• Safeguard CLI slash commands
• Safeguard AI Remediate
• Safeguard policies and gates
• Safeguard downloads
• GitHub Docs: reverting a pull request

Last reviewed: 21 October 2026.