Automated Actions

Automated actions are the bridge between the LLM’s verdict (or an automation rule’s match) and the firewall. This chapter explains when the appliance acts on its own without asking an operator, when it waits, and the safety toggles that gate the whole pipeline.

Two subsystems can produce an action without operator confirmation:

1. The LLM anomaly detector — when an analysis finishes, the verdict carries a recommended action and a risk score. If auto-execute is on and the score crosses the configured threshold, the Action Manager applies the action immediately.
2. The automation engine — rules can have direct action types (block, throttle, deny, monitor, allow). When a rule with one of those types matches a device, the action runs without any LLM involvement. See Automation (chapter 16).

Both paths converge in the same Action Manager and write to the same mac_actions table and the same nftables sets. The Actions Timeline on a device’s detail page (chapter 14) shows every applied action regardless of which path produced it; the Executor column tells you whether the source was llm, automation, or a username.

---

Auto-Execute — The Master Toggle

Auto-execute is the single switch that decides whether the LLM’s recommended actions are applied automatically or just recorded for review.

Auto-execute is an operational setting and lives under Settings > LLM Actions in the GUI. Two related toggles work together:

Toggle	Role	Effect when off
LLM Actions Active	Operator control — is the action pipeline running at all?	Verdicts are recorded but no action is ever produced.
Auto-Execute	Operator control — when an action is produced, should it run automatically?	Verdicts are recorded with a recommended action attached, but nothing happens to the firewall. An operator must apply the action manually from the Device Analysis page or the Actions page (chapter 15).

The shipped default is both on. New installations will analyse and act automatically. Turn auto-execute off if you want a review-first workflow during initial deployment, then re-enable it once you trust the LLM’s verdicts.

Auto-execute applies only to the LLM path. Automation rules with a direct action type (block, throttle, etc.) always run their action when they match — that is the whole point of having a rule. If you want a rule to produce a review-only signal, set its action_type to analyze and rely on the LLM auto-execute toggle to gate the resulting verdict.

---

Risk-Score Thresholds

When auto-execute is on, the risk score the LLM produces decides which action runs. The thresholds that drive that mapping are operator-tunable.

A higher risk score drives a more aggressive action: the most severe scores map to Block, mid-range scores to Throttle, lower scores to Monitor, and scores below the monitoring band leave the device alone. A device the backend judges harmless (the lowest possible score) is promoted to the trusted set for a long duration. How aggressively each band maps to an action is operator-tunable under Settings > LLM Actions.

Tuning Auto-Execute Aggressiveness

The mapping is an operational setting. Adjust it under Settings > LLM Actions; changes take effect on the next analysis cycle without a restart.

Practical adjustments:

• More aggressive — lower the band at which the backend blocks, so devices are blocked at “high risk” rather than only at “critical.”
• More conservative — raise the block band to keep automated blocks rare, and tune the throttle band to your noise floor so the backend throttles before it blocks.
• Log-only — push the block and throttle bands out of range so the system still produces verdicts but never blocks or throttles automatically.

---

Recommended-Action Override

The LLM does not just produce a risk score — it also produces a specific recommended action. The Action Manager prefers the LLM’s recommendation over the threshold mapping, provided the recommendation is a known action type.

For example, an LLM verdict with recommended_action = "throttle" and risk_score = 0.97 will throttle, not block, even though the score would normally cross the block threshold. The reasoning is that the model has more context than a single number and may have decided that throttling is the right response despite a very high score (e.g. for a chatty but recoverable device).

If the LLM’s recommendation is unknown (not in the system’s action catalogue) the threshold mapping is used as a fallback.

The recommended duration follows the same rule: if the LLM returned recommended_duration = 3600 it will be respected; if it returned 0 (or omitted the field) the action’s default duration is used.

---

Action Durations

Every action has a default duration baked into the appliance’s action catalogue. The LLM can override it; an operator can override it; if neither does, the default is used.

Action	Default duration	What it does at the firewall
Block	2 hours	Drop all DHCP packets for this device; events still recorded.
Deny	Permanent	Drop all DHCP packets and suppress event emission entirely.
Throttle	1 day	Rate-limit to 10 packets/min; excess dropped.
Monitor	7 days	Log packets but do not restrict.
Allow	30 days	Bypass all enforcement chains (trusted).

Action durations are also operational settings — change them under Settings > Actions. The values shown above are what new installations ship with.

Action default vs nftables set timeout. Each enforcement action has two durations: the action default duration (written to mac_actions and used by the Action Manager) and the nftables set timeout cap (the longest an entry can live in the kernel set regardless of what the action requested). The set timeout always wins. See Key Concepts (chapter 3) for the full table.

---

Lifecycle of an Auto-Executed Action

Walking through what happens when the LLM produces a high-risk verdict on a fresh device.

ASCII fallback

  LLM verdict          Action Manager           nftables
  risk=0.97       +-----------------------+
  rec=block  ---->| 1. Resolve action     |
                  |    (use rec or thresh)|
                  | 2. Resolve duration   |
                  | 3. Write mac_actions  |
                  | 4. Add to llm_*_marks |--> kernel drops
                  | 5. Bell + audit log   |    packets immediately
                  +-----------------------+

The whole sequence happens inside a single analysis cycle, on the order of seconds:

1. The cycle parses the verdict and reads recommended_action. If empty, falls back to the threshold mapping for the score.
2. Resolves the duration — LLM-provided > action default.
3. Writes a new row to mac_actions with executed_by = 'llm', the verdict’s evidence as the reason, and the recommended duration.
4. Inserts the device’s mark into the matching nftables set (llm_blocked_marks, llm_throttled_marks, etc.) with the action’s effective timeout. The kernel begins enforcing on the very next packet.
5. Emits an entry to the audit log (chapter 30) and raises an action alarm (chapter 11) so operators can see what the LLM just did.

If the action is cleanup, the device’s marks are removed from every enforcement set instead — the LLM has decided the device is no longer interesting.

If the action is monitor, no nftables change is made. The action is recorded for visibility but the device is not enforced against.

---

Manual vs Automatic Execution

A verdict with recommended_action = block does not always end in a block. The system has three ways to refuse to act automatically.

Refusal source	What it does
Auto-execute off	The verdict is recorded with the recommended action, but the Action Manager does not apply it. An operator must apply manually.
LLM Actions Active off	The whole pipeline is paused. Verdicts are still recorded if the LLM cycle is running; actions are not applied even with auto-execute on.
Score below thresholds	The verdict applies a monitor or normal outcome rather than enforcement — see the threshold table above.

When auto-execute is off, the Device Analysis page (chapter 17) still shows the recommended action with a clickable button. Pressing it applies the action through the normal manual path, recorded with the operator’s username as the executor.

---

Re-Application During Cooldown

A device that was analysed recently does not get re-analysed by the LLM, but its action still gets refreshed.

When the anomaly detection cycle picks up a device that is inside its cooldown window (see chapter 24), it does not call the LLM. Instead, it reads the previous verdict and reapplies the same action — extending the timeout in the nftables set so the device remains under the same enforcement. This is what keeps a blocked device blocked without the LLM having to weigh in every minute.

Re-application is governed by the same auto-execute toggle. If auto-execute is off, the cooldown re-application path also goes silent — the existing enforcement entry will simply expire when its timeout runs out.

---

How Automation Rules Differ

Automation rules with a direct action type bypass the LLM entirely. The auto-execute toggle does not apply to them.

Automation rules with action_type of block, throttle, deny, monitor, or allow always run their action when they match. The rule’s action_duration field overrides the action default, and the rule’s name becomes the source attribution shown in the Actions Timeline.

Rules with action_type = analyze are different: they do not act directly. They queue the matched device for the LLM cycle, and whatever the LLM ultimately decides goes through the auto-execute toggle described above. This is the typical pattern — a cheap detection rule does the candidate selection, and the LLM does the verdict.

One device, multiple rules. If several automation rules match the same device in the same cycle, the rule with the highest priority wins and its action runs once. Lower-priority rules are skipped. See Automation (chapter 16) for the priority semantics.

---

Safety Checklist Before Enabling Auto-Execute

A short list of things to verify before flipping auto-execute on in production.

1. Run with auto-execute off for at least a day. Watch the Device Analysis page for verdicts on devices you know are healthy. False positives on legitimate devices will be obvious in the analysis stream before they hit the firewall.
2. Confirm your trusted devices are flagged correctly. Critical infrastructure — DHCP servers, relays, network management — should never produce high risk scores. If one does, the analysis profile needs work or the device’s vendor class is unusual; consider adding it to the Allow list pre-emptively.
3. Sanity-check the bands. The shipped block band is conservative. If you want the backend to block more readily, lower the block band gradually and watch for false positives.
4. Verify the action durations match your network’s lease times. A 2-hour block is fine for client-side noise but can cause confusion on a 30-minute-lease network if the blocked device is legitimate.
5. Make sure alarms are routed. Action alarms (chapter 11) should land somewhere an operator will see them. If the LLM blocks a misclassified device at 3 a.m. and no one notices until business hours, the impact is larger than the security gain.

---

Where to Watch Auto-Execution in Action

GUI page	What it shows
Device Analysis (chapter 17)	Live verdicts as they come out of the LLM, with the recommended action and risk score.
Actions (chapter 15)	The Actions history filtered by executor = llm shows every auto-applied action with its source verdict, evidence, and timestamps.
Alarms (chapter 11)	Action alarms show one row per enforcement event — block, throttle, deny — useful for spotting clusters.
Device Details (chapter 14)	Per-device Actions Timeline shows the full sequence of automated and manual actions on a single MAC.
Audit Log (chapter 30)	Records every action the system or an operator applied, with timestamps and reason.

---

Related Chapters

• Key Concepts (chapter 3) — actions, nftables sets, and how durations are enforced at the kernel.
• Alarms (chapter 11) — how action events surface as alarms.
• Actions (chapter 15) — the Actions page, history, and per-MAC enforcement modal.
• Automation (chapter 16) — scheduled detection rules that can drive automated actions directly or via the LLM.
• Device Analysis (chapter 17) — the GUI page where LLM verdicts surface.
• Anomaly Detection (chapter 24) — the cycle that produces the verdicts.