Tag-Based Execution Policies

A tag-based execution policy is an organization-level rule that controls when Checks and ad-hoc Forge actions are allowed to run. Each policy combines three optional matchers — endpoint tags, script classifications, and a time window — with a single action: block, require approval, or auto-execute.

Use policies to keep recurring evaluations off sensitive devices, restrict execution to non-business hours, gate risky scripts behind human approval, or carve out tag-based exceptions to stricter org-wide defaults.

What a policy matches on

A policy can match on any combination of three conditions. Conditions are joined with AND — the policy applies only when every configured condition is true.

Matcher	What it captures
Endpoint tags	Tags assigned to the endpoint the execution is targeting. Static and dynamic tags both count.
Script classifications	LLM-inferred risk tags on the script being run (e.g. destructive, requires-elevated-privilege, long-running, reversible).
Time window	Days of the week and a start/end time in a chosen timezone.

A policy without any matcher always applies. A policy with only a time window applies during that window, regardless of endpoint or script.

Static vs dynamic tags

Furl supports two kinds of endpoint tags, and policies treat them identically once membership is resolved:

• Static tags are assigned manually — one endpoint at a time, or in bulk from the endpoints list.
• Dynamic tags carry a rule expression evaluated against endpoint properties (CIDR ranges, OS version, owner, agent presence, other tags). Membership is recomputed automatically as endpoints change.

This means you can express both kinds of intent with the same policy mechanism:

• “Don’t run destructive scripts on endpoints tagged executive-laptop” — a static tag applied to specific devices.
• “Don’t run any Check on endpoints in the prod-network CIDR range during business hours” — a dynamic tag whose membership tracks the network the endpoint reports in from.

Actions

Action	Effect on a matching execution
Block	The execution is rejected outright.
Require approval	The execution enters pending_approval and must be approved by the endpoint owner or an admin before it runs.
Auto-execute	The execution proceeds automatically. Used to carve narrow exceptions out of broader block or require approval rules.

What policies apply to

Each policy targets one or both of:

• Forge actions — ad-hoc scripts the Forge assistant proposes during an investigation.
• Check executions — scheduled or one-shot runs of saved Checks.

By default a new policy applies to both. Narrow it to one if you want, for example, Forge actions to remain unrestricted while Check executions are tightly governed.

Ordering matters

Policies are evaluated in admin-defined order, top to bottom. The first match wins and later policies are skipped. Use ordering to layer broad defaults with narrow exceptions:

1. Auto-execute reversible scripts on lab-fleet endpoints.
2. Block destructive scripts everywhere.
3. Require approval for anything that mutates a device.

A lab-fleet endpoint running a reversible script hits rule 1 and proceeds; the same endpoint running a destructive script hits rule 2 and is blocked.

Examples

Protect VIP devices from destructive operations

• Endpoint tags: executive-laptop
• Script classifications: destructive, process-disruption
• Action: Block

Keep recurring Checks out of business hours

• Applies to: Check executions only
• Time window: Mon–Fri, 09:00–17:00, America/New_York
• Action: Block

Gate elevated-privilege scripts

• Script classifications: requires-elevated-privilege
• Action: Require approval

Related

• Checks — execution policies control when Check evaluations run and on which endpoints
• Governance — the broader system that layers org policies with end-user autonomy preferences
• Strategy Executions — the lifecycle states (pending_approval, blocked) policies can drive an execution into