AI security

Suspicion is not certainty. The response should say so.

Machine learning is good at noticing that something is unusual and bad at being sure. Most products resolve that by picking a threshold and dropping traffic past it — which turns the model into an attack surface, because anyone who can make legitimate traffic look unusual can make the firewall block it. SecureGuard resolves it by making the response proportional.

Confidence

Four signals, deliberately independent

Each candidate source gets a confidence score from 0 to 100, fused from signals that do not share a failure mode. That independence is the whole design: a drifting model, a false-positive-happy feed or an evasion crafted against one detector cannot carry a decision by itself.

Signal	Where it comes from	Contribution
Signature severity	Suricata EVE events, collected by flowd	High at severity 1
Threat-intel reputation	A match in a configured feed — block feeds are strong, suspect feeds are grey	High / medium
Behavioral anomaly	Deviation from the baseline learned on this network	Scaled by deviation
Off-box model risk	Coming soon — not shipping. Deep model score when an analysis endpoint exists	Coming soon

The corroboration rule. A high-confidence automatic action requires at least two independent positive signals. A lone signal — however loud — caps at the grey band, where the worst it can do is slow something down. A threat-feed hit on its own is never an outright block.

Coming soon

Application control — Named applications, not only hostname, SNI, and DNS.
Anti-spam — Not on the appliance today.
Identity in policy — User or group as a traffic match. Directory login on Business+ already ships; this does not.
Off-box analysis — Behavioral models beyond on-box propose/commit.
Orchestrator / fleet hub — Free Linux download today (firewalls dial out; hub never dials in). Not a Business license feature and not a paid CM SKU.
Endpoint email-alert ingest — Orchestrator will capture AI-summarized alerts from any endpoint protection email stream. Coming soon. Not shipping.

Not App-ID. Not AntiSpam.

Graduated response

Observe → Suggest → Throttle → Block

Confidence maps to a tier, and the tier is bounded by an autonomy ceiling you set. The throttle band is the one most products skip, and it is the one that makes automatic response safe to turn on: if the call was wrong, the cost is a slow connection instead of an outage.

Observe

Low or medium confidence — log it and move on

The event is recorded and surfaced in the console. Nothing about the running configuration changes. During the initial learning window the whole layer stays here, because there is no baseline yet to judge against.

Suggest

High confidence — propose a change for a human

The harness drafts the block or rule as a config diff with its rationale and a risk rating. An operator approves it, and it goes through the same validate → render → apply path as any hand-made change.

Throttle

Grey and suspect — degrade it, do not cut it

The source joins the greylist table, which is piped to a slow dummynet queue. If that was a false positive the collateral is a slow connection, not an outage. Repeat offenses or rising confidence escalate to a block; quiet sources age out.

Block

Two independent signals agree — drop it, with a timer

The source lands in the blocklist table that a single top-of-ruleset rule drops. Automatic blocking needs an opted-in category and corroboration; management addresses, HA peers and operator allowlists are never eligible. Every entry expires and every action has one-click undo.

What each autonomy level is allowed to do

Autonomy level	Grey / suspect traffic	High confidence, opted-in category
`observe`	Log it	Log it
`suggest — the default`	Propose	Propose
`auto-throttle`	Throttle automatically	Propose a block
`auto-mitigate`	Throttle automatically	Block automatically, with a TTL

Escalation and de-escalation are both automatic: repeat offenses or rising confidence inside a window move a source from throttle to block, and a source that goes quiet ages out of both lists. Observe and suggest are available on every tier, including the free one; automatic mitigation is a paid entitlement. See the tiers →

Enforcement

Two pf tables, not bespoke rule surgery

An AI action is an entry in a table with an expiry — not a rule the model wrote into your ruleset. That is deliberate. Table entries are trivially auditable, trivially reversible, and they cannot reorder or shadow the policy you wrote.

Tier	Mechanism	Notes
Block	`rubix_blocklist` pf table	A single rule at the top of the ruleset drops everything in it. The same table flood and recon protection already use.
Throttle	`rubix_greylist` pf table	Piped to a slow dummynet queue — the QoS dataplane the box already ships. Degraded, not cut.
Feed match	pf tables from the feed fetcher	Refreshed on a schedule, and mirrored into an on-box reputation index the scorer consults.

Guardrails

The parts that are not configurable

An allowlist that always wins

Management addresses, HA peers, the firewall's own addresses and any operator-defined critical sources are never throttled and never blocked. Not "rarely" — never.

A rate cap with a safe mode

Automatic blocks are rate-limited. A flood of them is treated as a fault in the scorer, not a busy night: the layer drops to observe-only and raises an alert.

Cold start means hands off

Until there is a baseline to judge against, the layer stays in observe/suggest. It will not act on a network it has not learned yet.

Failure degrades, in one direction

If the analysis endpoint or a feed is unreachable, enforcement falls back to the deterministic path — signatures plus flood and recon protection. It does not fail open, and it does not silently fail closed.

Model routing

Your models, or ours, per purpose

The appliance runs no model weights and no ML runtime — an edge device's job is passing packets. Inference happens on backends you name: a private OpenWebUI deployment, a frontier API, or both at once.

Analysis tasks are then routed by role, so speed and depth are separate decisions. triage wants fast and cheap for inline scoring of event batches; deep-analysis wants the strongest model available to investigate one incident and explain it; summarize handles digests. An unset role falls back to the default.

Which means privacy is a routing choice you make, not a property you inherit: sensitive telemetry can stay on the private model while summarization goes to a frontier one. API credentials are references into the secret store, never inlined in the config document.

The full design

Preconfigured, because "safe defaults" should not be homework. A fresh appliance arrives at these values and everything is tunable.

ai_security:
  autonomy: suggest          # no surprise actions
  learning: on
  cold_start_window: enforced
  throttle_grey: on
  confidence:
    grey_at: 50
    block_at: 80
    min_signals_to_auto_block: 2
  auto_block_categories:
    # clearly-malicious Suricata classes only
  feeds:
    block: [reputable, redistributable]
    suspect: [grey-listed]
    geoip: off  # needs your MaxMind key

Only feeds whose license terms permit redistribution on an appliance ship enabled. The rest are listed, disabled, with a note explaining why — so a feed you are entitled to use is one toggle away and one you are not is never quietly shipped.

Underneath all of it

The layer that does not need a model

AI augments the deterministic controls; it never replaces them. Flood and reconnaissance protection are always on, enforced by pf and Suricata, and they are what remains if every clever part of the system is unavailable.

Flood

Answered before it lands

pf's SYN proxy answers SYNs on behalf of your hosts, so half-open floods never reach them. Per-source state and connection-rate limits overload offenders into the blocklist table.

Reconnaissance

Port scans and host sweeps

Fast scans trip the connection-rate limit in pf; signature-based scan and sweep detection runs in Suricata over an interval and threshold, with the same action vocabulary as Palo Alto's zone protection: allow, alert, block, block-ip.

Exclusions

Your scanners are not attackers

Source exclusions list the vulnerability scanners and monitoring systems that are never scored, so your own tooling does not spend its life in the blocklist.

Sensible thresholds are pre-filled, so protection is on out of the box rather than waiting for someone to read a manual. Thresholds and rendered pf →

Watch it explain itself before you let it act

Install the appliance, leave the autonomy level at suggest, and read what it proposes for a week. Nothing is applied without you until you decide otherwise.

Get a free license Read the design