Collectors and integrations
Not everything has an API, and some of what matters is behind a firewall that should stay closed. Three things cover that: an agent on the machine, an agentless collector on the network, and scanners that push their own results in.
All of it is outbound. Nothing we run opens a port on your network or needs an inbound rule, and there is no tunnel back to us. A collector talks to the platform, never the other way round.
The endpoint agent
One agent per platform, for Windows and for Linux. It inventories the host and its software, reports posture such as disk encryption and endpoint protection state, and answers the checks a control needs. It ships as a signed package, updates itself from a signed package, and runs only the collection jobs assigned to it.
There is one agent rather than a collection of scripts, and new capability arrives as a job inside it. That matters operationally: you approve one thing once instead of a new executable every time a check is added.
Collectors
A collector is an agent given a set of jobs rather than a single purpose. One box on a network segment can run a discovery sweep, reach an on-premises Active Directory, and pull from a local scanner, so a site with one reachable machine is a site you can collect from.
Network discovery
An agentless sweep of the local network, for the things that will never take an agent: printers, switches, cameras, industrial equipment, and the server nobody remembers. It finds what answers, identifies what it can, and files the rest as unidentified rather than silently dropping it.
Unidentified is the useful part. An asset register that only contains what you already knew about is a list, not a register.
Pushed results
Scanners that already run in your pipeline can push instead of being polled. There is an ingest API with its own token, and SARIF is accepted directly, so a scanner that emits standard output needs no adapter. Every push is attributed to the token that made it.