SubnetLens

More than just a Network Scanner!

Comment

Inspiration

Network discovery tools are good at finding devices, addresses, ports, and vendor fragments. They are much less helpful with the question someone actually has: What is this unknown device, why might it be here, and what evidence supports that conclusion?

Sending raw network details to a generic chatbot is really not enouph either. It can disclose more than necessary, gives the model no trustworthy target boundary, and can produce persuasive prose without showing where the conclusion came from.

Moreover, we found out that many of our users were asking for a tool that would be capable of identifing unrecognized devices, since no other network scanner was able to identify them.

Thats why we built Subnetlens Device DNA around a different idea: AI can reason about a device, but the local application must remain in control of the target, evidence, permissions, and final result. The goal is not merely an answer. It is an answer a person can inspect!

What it does

Subnetlens Device DNA is a focused Windows edition that turns an unfamiliar network device into a plain-language, evidence-led investigation and more.

  • The user explicitly chooses and connects an AI provider (Local or with an API key). The primary verified path is Codex on this PC, using the user’s existing ChatGPT/OpenAI sign-in without requiring an API key.
  • Nothing contacts Codex or OpenAI, and the local Model Context Protocol runtime does not start until the user presses Connect.
  • A deterministic safe sample lets anyone try the complete experience without scanning a real device or sending packets to a real network.
  • The user asks a normal question such as “What is this device?” or “Why might it be on my network?”
  • Subnetlens represents the selected target and supplies minimized, pseudonymized evidence.
  • Its model-facing tools withhold raw IP and MAC addresses, hostnames, credentials, credential hashes, vault data, raw banners, URLs, payloads, and certificate identity fields.
  • Codex compares possible identities and publishes ranked hypotheses tied to recorded evidence.
  • If another observation would help, Device DNA presents a visible Allow Once or Not Now decision. Text typed into the chat cannot authorize a local action.
  • The application completes only after its local service validates a fresh report against recorded hypotheses and cited evidence. Free-form AI prose cannot replace that result.
  • The result includes the likely identity-or honest uncertainty-along with confidence, supporting and contradictory evidence, conditions that would change the answer, a privacy receipt, and progressively disclosed technical details.

The custom edition can also begin with a device discovered on the user’s network. Our app can already detect most devices, and for those that it cant, Device DNA is here to make the difference.

An optional My OpenAI API key route is implemented through the OpenAI Responses API. A successfully validated user-supplied key is encrypted with Windows secure storage, remains on that computer, and is never sent to a Subnetlens servers, EVER! The Local Codex route is the tested primary submission path; the optional direct API route is not presented as a tested path in this submission.

How we built it

Subnetlens existed before Build Week and already supplied the Windows scanner, inventory, topology, history, diagnostics, and local device data used as the foundation. ( you can find our website here https://subnetlens.com/ )

We built Device DNA as a separate Electron application edition with its own identity, user-data directory, startup path, package, and judge-focused navigation. The React interface turns the investigation into a familiar conversation: explicit connection, question, visible progress, permission, evidence journey, validated result, and receipt.

The progress messages come from real provider and tool lifecycle events. They do not expose or imitate private chain-of-thought.

Behind the interface:

  • A Node.js provider manager coordinates Local Codex and the optional direct OpenAI route.
  • Local Codex launches one ephemeral codex exec investigation using the existing signed-in desktop-managed client and GPT-5.6 Terra.
  • A loopback-only, bearer-authenticated MCP companion exposes exactly eight typed Device DNA operations.
  • The model never selects an arbitrary IP address or command. The local service resolves the opaque alias, verifies the target binding, enforces attempt limits and approval policy, minimizes results, and validates hypotheses and reports.
  • Local Codex runs through a restricted, read-only configuration with unrelated shell, web, browser, application, and plugin surfaces disabled.
  • A deterministic synthetic fixture provides a reproducible judge path without requiring a particular router, camera, printer, or lab network.
  • Playwright, Vitest, focused bridge and policy tests, responsive visual captures, packaged-application checks, and a dedicated signed Windows build support the release path.

Codex was also central to the development process. We used it to research and challenge the architecture, implement and test the provider and MCP boundaries, diagnose packaged Electron problems, run repeated UI and responsive-design reviews, review privacy claims, improve documentation, and assemble and verify the final demonstration. The owner made the product, safety, design, and scope decisions throughout. We also used codex to push a new upgrade on our main website at the time of OPEN AI build week, from Beta.7 to our new and improved Beta.8 version of our application. It was able to find weak spots and improve animations and solve issues we didnt catch before.

Build Week scope

We deliberately separate the pre-existing Subnetlens foundation from work completed during the event.

The Build Week centerpiece is the complete Device DNA edition: its human-first interface, explicit provider setup, Local Codex bridge, direct Responses bridge, authenticated MCP boundary, evidence minimization, local permissions, report validation, safe sample, live-device handoff, testing, packaging, and submission material.

The event window also included the full beta.8-and-later scope:

  • evaluation-driven desktop and entitlement fixes;
  • reporting and IPAM improvements;
  • motion controls and multiple UI-polish and readability passes;
  • scan-result, exposure, command-palette, network-map, and away-digest workflows;
  • the no-card seven-day Pro trial;
  • attribution, review, changelog, and pre-release-honesty work;
  • the signed beta.8 release;
  • Personal, Team, and Business pricing and activation work;
  • website, analytics, search-discovery, distribution, antivirus, and documentation improvements; and
  • refund, licence-cache, webhook, concurrent-activation, profile/Sentinel, background-service, and scheduled quick-scan hardening.

The complete dated scope is documented in the beta.8-and-later Build Week evidence ledger in the submitted repository.

Challenges we ran into

  • Connecting an online reasoning system to private local evidence without turning it into an unrestricted network scanner.
  • Making permission meaningful across the model request, authorized local target, and visible user decision.
  • Preventing a confident-looking model response from becoming the product’s authoritative result without evidence.
  • Preserving useful context while excluding raw identifiers, credentials, vault data, and arbitrary targets from the model-facing tools.
  • Turning a constrained MCP workflow into something a first-time user can understand without knowing what MCP is.
  • Creating a reproducible demonstration when every real network contains different devices.
  • Keeping the Build Week edition isolated from the standard Subnetlens profile, settings, licence, vault, and updater.
  • Producing a signed, installable Windows candidate and testing it outside the development environment.

Accomplishments that we’re proud of

  • A complete in-app investigation with no prompt copying and no plugin installation.
  • A narrow model-facing schema that excludes raw target identifiers and credentials by construction.
  • Ranked hypotheses, evidence citations, contradictions, change conditions, and a local report-validation gate.
  • Application-owned, expiring permission for every additional live observation.
  • A safe synthetic walkthrough that exercises the real provider and policy boundary without touching a real network.
  • A clear evidence and privacy receipt showing what was observed, inferred, approved, shared, and retained.
  • A dedicated Windows x64 installer signed and timestamped by HELIOSOFT LTD.
  • A final verification run covering 35 test files and 458 tests, production building, the Device DNA Electron flow, responsive visual QA, packaged launch, and a live Local Codex safe-sample investigation.
  • Successful installation and use of the signed candidate on a separate Windows home PC.

What we learned

The safest place to enforce AI policy is not in the prompt. It is in the application-controlled boundary around the model.

Minimization must happen before evidence reaches the model-facing schema. Permission must be a current, visible application decision rather than consent inferred from chat. A locally validated report is more trustworthy than polished free-form prose.

We also learned that security controls become more useful when people can see them. A concise receipt showing evidence, authority, uncertainty, and provenance communicates the architecture better than a wall of technical text.

What’s next for Subnetlens

After the submission, we plan to:

  • integrate Device DNA carefully into the standard Subnetlens application;
  • add Device Drift, showing how a device’s evidence fingerprint and identity confidence change across scans;
  • evaluate more device families, ambiguous and special cases, contradictory evidence, and hostile network strings;
  • complete live end-to-end validation of the optional user-owned API-key route before presenting it as a tested path;
  • expand accessibility, improve visuals, user experience, and varied-display testing; as well as
  • improve recognition coverage while preserving explicit permission.

Autonomous remediation, credential-derived fingerprints, and arbitrary-target scanning remain intentionally out of scope.

Built With

  • azure-trusted-signing
  • cybersecurity
  • electron
  • explainable-ai
  • gpt-5.6
  • human-in-the-loop-ai
  • javascript
  • model-context-protocol
  • network-discovery
  • node.js
  • nsis
  • openai-codex
  • openai-responses-api
  • playwright
  • privacy
  • react
  • tailwind-css
  • vite
  • vitest
  • windows
  • zod
Share this project:

Updates