Skip to content
Furl Docs

Autonomous Remediation

Autonomous remediation is what Furl does with everything it learns about your environment: it takes the problems your tools surface and fixes them, continuously, without you driving each fix by hand. This section explains that flow end to end and shows you how to set it up.

The core idea is a pipeline with four moving parts — signals come in, become targets, are matched by scopes, and are fixed by strategies:

signals → targets → scopes (policy) → strategies (the fix)

1. Signals come in

Section titled “1. Signals come in”

A signal is anything that tells Furl something on an endpoint needs attention. Furl consumes signals from the tools you already run, through integrations:

  • Vulnerability findings — CVEs reported by scanners like CrowdStrike, Qualys, Rapid7, Microsoft Defender, or the built-in Furl Vulnerability Scanner.
  • Configuration and posture issues — compliance failures and misconfigurations, such as a CIS benchmark control that isn’t met.
  • Other sources — end-of-life software warnings, and custom detections you author as Checks when no scanner has a signature for what you need to find.

Furl records each of these as a finding: a specific issue linked to a specific device. Findings are the “why” behind remediation, but they are not what Furl acts on directly. Multiple findings often point to the same fix.

2. Signals become targets

Section titled “2. Signals become targets”

Furl correlates and normalizes findings into remediation targets — the actionable units of the pipeline.

Where a finding is a signal (“Chrome 119 has 5 CVEs”), a target is the concrete thing to fix on one endpoint: “Chrome 119 on this MacBook, at this install path, manageable via Homebrew.” Furl deduplicates across scanners, so when three tools report the same software on the same device you get one target, not three. It also matches each target to a remediation subject — the canonical definition of the software or configuration — which is what makes a fix reusable across every endpoint that has it.

Once a target is identified and matched to a subject, it is actionable: ready to be picked up and remediated.

3. Scopes select targets — policy

Section titled “3. Scopes select targets — policy”

A remediation scope is a standing policy that describes what Furl should keep healthy. Think of it as a rule: “keep Chrome updated on all Windows laptops in engineering.” Scopes are how you turn a pile of targets into governed, ongoing remediation.

A scope selects targets with three filters:

Filter Question it answers Example
Subject What to remediate? Chrome, or all software by Mozilla
Endpoint Where to remediate? Windows laptops tagged “engineering”
Finding What triggers remediation? Critical and high vulnerabilities only

Scopes are event-driven, not scheduled. When you activate a scope it evaluates every existing target against its filters. From then on, each new target is matched against your active scopes as soon as it appears — so new vulnerabilities are picked up automatically as scanner data flows in.

You can create a scope two ways:

  • Manually, through the Furl UI — see Creating a remediation scope.
  • Conversationally, with the Forge assistant, which composes the filters from a plain-language description of the rollout.

4. Strategies do the fix

Section titled “4. Strategies do the fix”

When a target matches a scope, Furl picks a remediation strategy — the method for fixing it (update, patch, uninstall, configure, or a manual procedure). It chooses the highest-confidence strategy the endpoint supports, checks your governance rules to decide whether to run automatically or wait for approval, dispatches the work to the Furl agent, and verifies the finding actually resolved. Each outcome feeds back into the strategy’s confidence score, so future selections get smarter.

If a scope has an update ring policy, matched endpoints are remediated in ordered stages rather than all at once.

Where ticketing fits

Section titled “Where ticketing fits”

You can link a scope to your ticketing system so the remediation work Furl does shows up in the queue your team already tracks. Furl opens one ticket per scope and keeps it updated as each remediation completes. Linking is optional and doesn’t change how a scope behaves. See Ticketing in a remediation scope.

In this section

Section titled “In this section”
Section titled “Related”