Checks

A Check is a detection pattern authored in Forge that the Furl agent runs across your endpoints. When the detection matches, it produces a finding — the same kind of finding a vulnerability scanner would emit.

Scanners cover known CVEs and standard compliance controls. Checks fill the gap when you need to hunt for something specific that no scanner has a signature for: a misconfiguration unique to your environment, an indicator of compromise from a recent incident, or a custom policy your team wants to enforce. You describe the condition in plain language to Forge, refine the detection together, and promote it to a continuously evaluated source of findings.

How Checks fit into the pipeline

Checks are a peer of scanner integrations: both produce findings. Once a Check creates a finding, the rest of the remediation pipeline is unchanged — subject matching, target creation, strategy selection, execution, and efficacy verification all proceed exactly the same way.

Anatomy of a Check

Field	What it is
Detection	The script or osquery query the agent runs on each matching endpoint.
Target template	The shape of each finding the detection produces — product, vendor, and target type — so findings can be matched to a remediation subject.
Severity	critical, high, medium, low, or info. Used by governance and scope filters.
Scope	Optional endpoint filter (OS, tag, etc.). Omit to evaluate against all endpoints.
Schedule	Cron expression for recurring evaluation. Omit for a one-shot Check.
Status	draft, active, paused, or archived.
Classifications	LLM-inferred complexity tags on the detection script (e.g. destructive, requires-elevated-privilege, long-running).

Authoring a Check in Forge

Checks are created from a Forge investigation. The flow is collaborative: you describe what you’re looking for, Forge drafts a detection, and you refine it together before saving.

1. Start an investigation. Tell Forge what you’re trying to find — for example, “are any endpoints running OpenSSH older than 9.6?” or “flag any host where the root account has an unexpired password.”
2. Forge proposes a detection. The assistant drafts a script or osquery query and streams it into an inline approval card.
3. Review the classification badges. The card surfaces tags like destructive, requires-elevated-privilege, long-running, or reversible. Hover any badge for a one-sentence rationale citing the specific command that triggered it. Read-only inspection scripts show no badges at all — that itself is a signal.
4. Approve or refine. Approve to run the detection ad-hoc against selected endpoints, or ask Forge to tighten it (narrow the query, handle a false positive, switch script languages). Once the detection is doing what you want, ask Forge to save it as a Check.
5. Set schedule, scope, and severity. At save time, choose a cron schedule (or leave it one-shot), optionally narrow to specific endpoints, and pick a severity. The severity controls how the resulting findings are weighted by governance and scope filters downstream.
6. Activate. Once the Check’s status is active, the agent runs the detection on every matching endpoint on the configured schedule and emits findings for each match.

Classification badges are informational today — they help you assess the risk of the detection script before saving. They don’t currently gate automatic execution; that integration with the autonomy evaluator is planned.

Status lifecycle

Status	Meaning
Draft	Saved but not running. Useful while you’re iterating.
Active	Evaluated on schedule across endpoints that match the Check’s scope.
Paused	Temporarily not evaluated. Existing findings remain in place.
Archived	Frozen and not evaluated. Kept for audit purposes.

Recurring vs one-shot

A Check without a schedule runs once on activation — useful for verifying a hypothesis or a one-time hunt. A Check with a cron schedule re-evaluates on that cadence: new matches create new findings, and resolutions are reflected when an endpoint that previously matched no longer does. Most Checks meant to enforce ongoing policy are recurring; investigative or incident-response Checks are often one-shot.

Limiting where and when Checks run

A Check’s own scope narrows the endpoints it evaluates against, but you’ll often want broader org-wide rules — “never run this on the CEO’s laptop” or “don’t evaluate Checks during business hours”. Those live in tag-based execution policies. Use static or dynamic endpoint tags to keep Checks off sensitive devices automatically, or attach a time window to prevent recurring evaluations during work hours. Tag-based policies can also gate Checks behind human approval based on the classifications of the detection script.

How findings flow downstream

A finding produced by a Check carries the Check’s target_template shape, so it joins the pipeline the same way a scanner finding does:

1. Furl matches the finding to a remediation subject.
2. A remediation target is created or updated for the affected endpoint.
3. If an active scope matches, Furl picks the highest-confidence strategy and runs it (subject to governance).
4. Efficacy verification confirms the finding is gone.

Nothing downstream needs to know the finding came from a Check rather than a scanner.

Related

• Findings — Checks are an additional source of findings alongside scanner integrations
• Strategy Executions — Check findings flow into the same execution pipeline
• Governance — controls whether remediations triggered by Check findings auto-execute
• Tag-Based Execution Policies — block or gate Check evaluations on specific endpoints or during specific times
• Confidence Score — strategies selected for Check findings still rank by confidence
• Agent — runs Check detections on the endpoint