Collector architecture and roadmap

Overview

The collector is designed as a small, single static binary that runs unattended on customer infrastructure with no inbound network exposure. Its architecture prioritizes a minimal attack surface, predictable resource use, and a clean separation between discovery/assessment modules and the trust relationship with the AssurIQ control plane.

Why Go

The initial collector implementation is built in Go. Go compiles to small, dependency-free static binaries, cross-compiles cleanly to the target operating systems and architectures without a separate build environment per platform, and its goroutine model suits the highly concurrent, I/O-bound nature of network discovery, SNMP polling and parallel target probing.

• Static binaries simplify distribution: no runtime, interpreter or shared library dependencies on the target host.
• Cross-compilation from a single toolchain supports Windows, Linux and future architectures from the same codebase.
• Lightweight concurrency primitives make it straightforward to poll many targets in parallel within a bounded concurrency limit.

Outbound trust model

The collector never accepts inbound connections. It enrolls once using a random, single-use, short-lived token — of which the control plane only ever stores a SHA-256 hash — and exchanges that token for a permanent collector credential. Today that credential is used as a bearer token over HTTPS; the designed target model is a per-collector mutual TLS device certificate, issued and rotated by the control plane, with the current transport implementation marked as a mock of that model pending full certificate lifecycle tooling.

Module system

Collector functionality is organized as discrete modules, each responsible for one kind of evidence or discovery activity. A given deployment runs only the modules relevant to its scope; not every module needs to be enabled at every site.

Roadmap

The collector is being built out in phases, moving from a working outbound-only agent with bearer-token trust toward the fully designed mTLS device-identity model and broader platform coverage.

Related reading

• Choosing collector placement
  How many collectors a site needs, where to run them, and why one per routed security boundary is the default.
• Firewall and egress requirements
  The collector is outbound-only. What to allow, on which ports, and why no inbound rules are ever needed.
• Collector health states explained
  Healthy, Degraded, Offline, Enrollment Pending, Update Required and Revoked — what each state means and what to check.
• What the v0.1 collector does today
  A plain list of what the native v0.1 collector supports right now versus what is designed but not yet active, and what the DEV build badge means.
• Collector API v1 reference
  Request/response shapes for the collector-facing API v1 endpoints: enroll, heartbeat and observations, plus tenant/site binding rules and error codes.