How Setup Works and Where AI Is Used

Every server's setup is different: the platform, the bridges, VLANs, bonds and how each guest is attached. Frabs uses AI once, during install, to read that setup and propose a plan. Fixed code then checks the plan, and you confirm it. After that the sensor runs on its own, with no AI.

The steps

1. 1Identify the platform. The installer reads, without changing anything: the OS and kernel, the names and versions of virtualisation and networking packages, running services, every network link (name, type, bridge, MAC), and each platform's own guest list.
2. 2Read the guests. Each platform's own tools or files are the only source: Proxmox's /etc/pve for that node, libvirt's live state, vzlist, prlctl, the LXD or Incus API, or xl. If a platform cannot be read, that is reported as a failure, never as "no guests".
3. 3Plan. Claude (by Anthropic) reads those facts and proposes how to attach: the platform, how interfaces map to guests, which bridges to leave alone, and notes on anything unusual. The list of interfaces to watch is always built by fixed code from the facts, not by the AI.
4. 4Check. Fixed install checks run on every server. A failed check blocks confirming.
5. 5Confirm. You review the plan in the panel. Nothing is watched or changed on the server until you choose Confirm and Start Protecting.
6. 6Run locally. The sensor counts traffic, detects abuse and acts by your rules on the server itself. It reports incidents and health to Frabs, and keeps protecting during an outage.

What Claude does

• Reads the facts the installer collected, once per install (and again only if Reconnect finds a changed layout that the fixed rules cannot plan)
• Identifies the platform and how its guests are attached
• Works through the checklist for that platform and flags anything that does not pass
• Notes anything unusual a careful engineer would want to know: mixed platforms, passthrough NICs, VLAN-tagged guest NICs, Open vSwitch, very large guest counts, leftovers that look stale

What Claude never does

• Run commands on your server: it only returns a plan in a fixed format
• Invent an interface or bridge: every name it gives is checked against the facts
• Decide what to watch: the watch list comes from fixed code
• Turn anything on: only you confirm the plan
• Watch traffic or make decisions while the sensor runs: detection and actions are fixed rules on the server

What is sent to Claude

Only the setup facts: OS and kernel versions, virtualisation package names, network link names and types, and each guest's ID, name, MAC and IP addresses. Never traffic, never anything from inside a guest. On servers with many guests only a sample is sent, with the totals.