VisiLoop
Built at Meta Global AI Developer Hackathon · Oct 26, 2026 · Remote

**VisiLoop: Your security tools may be blind. VisiLoop finds out why, fixes it, and proves it.** *Track: Indie Developer · Theme: Build for Your World* **The problem** Security tools such as IDS, NDR and SIEM can only detect what the network feeds them. In real deployments, those feeds from TAPs, SPAN ports and packet brokers are often silently broken: packets dropped during bursts, duplicated, missing one direction of a conversation, untagged, cut short by slicing, still wrapped in tunnel headers, or encrypted beyond what the tool can inspect. The tools keep running and their dashboards look normal, so nobody notices that detection has quietly failed. Broker consoles show port counters and security tools show alerts, but nothing connects the two to answer "is my security tool wrong because of its feed?" Finding the cause takes an expert hours, and fixing it means hand-writing packet broker rules. I have worked in network visibility and security across APAC for years, and I see this gap in almost every deployment. **What VisiLoop does** VisiLoop is an AI visibility engineer that closes the loop from diagnosis to a verified fix. *See.* The engineer uploads the network diagram. SAM 3.1 finds every device box; the boxes are numbered on the image and Muse Spark reads it into an inventory of devices, links, speeds and capture points, including which direction each TAP or SPAN mirrors. *Diagnose.* Nine checks measure a capture from the tool's input: duplicates, one-way traffic, packet drops, tool overload, encrypted share, missing VLANs, packet slicing, tunnel headers and oversize frames. Two more read standard interface counters (SNMP) from the switches and brokers along the feed's path, so VisiLoop names the device and port where packets are lost. Every check is tool-aware: slicing harms an IDS but is fine for a SIEM. A Muse Spark agent calls the checks as tools, explains the root cause and pins each fault onto the customer's own diagram, with the packets that prove it. *Fix.* Each fault gets a vendor-neutral packet broker change with settings calculated from the measurements: deduplication, aggregating both TAP legs, replacing a SPAN with a passive TAP, a sized load-balanced tool group, preserving VLAN tags, turning off slicing, or stripping tunnel headers. For a 6.5 Gbps burst on a 1 Gbps IDS port, it sizes a 13-port tool group with symmetric hashing, or one 10 Gbps port. *Prove.* A simulated broker applies the fixes and every tool port is re-checked; if a fix reveals a fault the broken feed was hiding, it plans another round. Then Suricata runs on the feed before and after: in our breach scenario, a test signature hidden in the reply direction of an RX-only SPAN raises 0 alerts on the broken feed and 1 alert after VisiLoop's fix. *Monitor.* In continuous mode, VisiLoop reads the counters on a schedule, keeps history and alerts when a feed degrades or recovers, naming the place, by log, Teams or Slack. Every change needs engineer approval and nothing is pushed to equipment. Only check results go to the model, never packet contents. **How we used Meta's models** - **SAM 3.1** segments every device on the diagram, so faults are pinned exactly where they occur. - **Muse Spark (vision)** reads the numbered diagram into a structured inventory, including small labels such as "mirror (RX only)". - **Muse Spark (agent)** calls the checks and the tool profile as tools and returns a structured, grounded diagnosis. - **Muse Code** helped build the application. **How it's built** VisiLoop runs on VisiKit, an open framework where each check and each fix is a small plug-in. Proven open-source tools (tshark, editcap, Suricata) do the packet work; VisiKit adds diagnosis, tool-aware reasoning and closed-loop verification. A guard removes any finding no check returned, so the agent cannot invent faults. **Results** - **200-case benchmark** (nine faults, alone and combined, with near-threshold cases that must not alarm): the checks are right on 200/200; Muse Spark diagnosed 200/200 and chose a sound fix 235/235 times. - **Counter benchmark** (100 feed paths): the loss is located to the right device and port on 100/100. - **Diagram stress test** (36 diagrams in 9 drawing styles): 534 of 536 devices found. - **Real traffic, no equipment:** I built a "soft lab", a virtual switch and packet broker on real Linux network interfaces carrying real web, DNS and file-transfer traffic, read over real SNMP. VisiLoop got 16/16 capture tests and 5/5 counter tests right, and its monitor raised each fault once, at the right place, with no false alarms. Building it found four real bugs in VisiLoop, all fixed: slicing hidden by a receive-only SPAN, ordinary network loss reported as monitoring loss, counter readings taken too far apart, and alerts that did not say where. - Each diagnosis costs about US$0.01 and takes about 9 seconds. **Who it helps** Enterprise security and network teams get proof that their tools see the traffic they are paying to protect. Resellers, integrators and managed service providers, who often support several vendors, get one vendor-neutral tool that turns a scarce specialist skill into a repeatable service. **What's next** A lab day on real Cisco and Cubro equipment (the test plan is ready), broker adapters for major vendors, an on-premises mode with Meta open-weights models, and support for cloud traffic mirroring and industrial (OT) networks. **Links:** Video https://youtu.be/Jd9V8uX0U1g · Update since the video (73 s) https://youtu.be/gEjxrXi8b6c · Live demo https://visiloop.streamlit.app/ · Code https://github.com/jlimwh2020/visiloop