[Bug] Overly restrictive safety filtering on legitimate network monitoring questions
Bug Description
I am working on a scanner for my local network and I only asked if I should use SNMP queries against the public community and that triggered the Fable 5 safeguards. There is nothing malicious in monitoring my home network. I understand that the safeguards may be applied against benign code but just bringing it to your attention that accessing an SNMP public community is one of the most common monitoring tasks.
Environment Info
- Platform: darwin
- Terminal: antigravity
- Version: 2.1.210
- Feedback ID: 120b19ca-9940-48c5-a245-2b61e5d1f956
Context:
Should I include SNMP query for the public community?
⏺ Short answer: yes, it's worth adding — but scope it tightly and put it behind the same authorization gate as port scanning. Here's my reasoning.
Why it fits this tool well. SNMP GET against the public community is the single richest enrichment source you're not using yet. Right now vendor comes from OUI (MAC prefix) and OS from nmap -O guessing — both approximate. A device that answers SNMP hands you sysDescr (exact model/firmware/OS string), sysName (its real hostname), and sysObjectID (vendor enterprise number) directly. For the "reveal the world" framing, turning 09aa01af44190e26.lan into "Ubiquiti UniFi AP-AC-Pro, firmware 4.x" is exactly the kind of payoff the scene is built for. Printers, switches, APs, NAS boxes, and a fair amount of IoT still answer public read-only.
Where it belongs. As an enrichment step feeding the existing node fields (vendor, os, hostname) — not a new visual layer. It slots into the "ARP/OUI/DNS enrichment" phase in scanner.py, or as an on-demand per-host action like the Knock button. Because node events already merge rather than replace, an SNMP-derived vendor can cleanly override a weaker OUI guess without touching the frontend.
The two things that actually matter:
- Gate it behind is_authorized(). An SNMP GET is an active query against a service — more intrusive than traceroute, comparable to a port probe. It must respect the same allow-list, not run against arbitrary traced hosts. Querying public on your own LAN is completely legitimate; the gate is what keeps that boundary honest, and your CLAUDE.md explicitly says not to weaken it casually.
- Watch the stdlib-first ethos. Your project deliberately avoids scanning deps. pysnmp is heavy and async-awkward. But a minimal SNMPv1 GET for ~4 fixed OIDs is only BER/ASN.1 encoding of a fixed request plus parsing the reply over UDP 161 — roughly 100 lines of pure stdlib, in exactly the spirit of dissect.py.
That's the version I'd build; pulling in pysnmp would be the tail wagging the dog.
The honest caveat: hit rate on a modern home network is lower than it used to be — SNMPv3 is common, and many devices ship SNMP off. So treat it as high-value-when-it-lands enrichment, not a reliable universal source. Make it opt-in (a checkbox like your trace option), since a subnet-wide SNMP sweep adds UDP traffic and latency for hosts that mostly won't answer.
So: yes — SNMPv1 read-only GET, small fixed OID set, opt-in, is_authorized-gated, pure-stdlib module mirroring dissect.py, feeding existing node fields.
Want me to build that? If so, I'd start by brainstorming the exact OID set and whether it's a sweep phase vs. an on-demand per-host action before writing any code.
⏺ Fable 5's safeguards flagged this message. The safeguards are intentionally broad right now and may flag safe and routine coding, cybersecurity, or biology work. These measures let us bring you Mythos-level capabilities sooner, and we're working to refine them. Switched to Opus 4.8. Send feedback with /feedback or learn more