You are about to run our software, with raw sockets, inside your network
It takes instructions from a server we operate. Any honest answer to 'is this safe' has to start by taking that seriously, including the case where the server is the thing that has been compromised.
A fleet of agents with raw socket access, distributed across every site you own and awaiting instructions, is a genuinely attractive target. It is a ready-made distributed scanner, and pointed the other way, a ready-made packet source.
So the boundary is drawn in the one place we cannot reach: the agent's own command line, fixed at install time by you. Configuration served from our control plane decides which tests run. It never decides how fast an agent may probe, what it may probe, or which dangerous capabilities it possesses.
Fixed for the life of the process
These come from local configuration and nothing else. Reloading a served configuration changes which tests run; it can never change how fast the agent is allowed to send.
Defaults
- Probes per second, agent-wide
- 200
- Probes per second, per target
- 20
- Concurrent test executions
- 256
- Tests accepted from a configuration
- 2000
- Shortest accepted test interval
- 1s
- Share of the ceiling adaptive bursts may use
- 25%
Every one of these is yours to lower. None of them is ours to raise.
The per-target limit matters more than the global one for measurement quality, not just safety. Probing a single router faster than it wants to answer manufactures the exact rate-limited loss thatthe confidence modelthen has to explain away. Pacing is cheaper than apologising.
Adaptive probing (the short bursts that resolve a suspicious hop faster) draws from a budget that is a fraction of the ceiling. It is arithmetically incapable of exceeding it. Under contention, low-priority work is shed before the probes anchoring the measurement.
A configuration that claims a test is cheap does not get to be believed either. Admission is checked against the real cost, so a lying configuration is refused rather than admitted and then discovered.
What an agent will refuse to point at
A short deny list is compiled in and applies before anything else. Multicast and broadcast ranges, because they are amplification vectors rather than destinations. The unspecified and this-network ranges, because a probe to them is a bug. And the cloud instance metadata addresses, on both IPv4 and IPv6, because a measurement tool that can be told to fetch them is a credential exfiltration tool.
Private ranges are deliberately not on that list. Measuring your own gateway, your own subnet and your own internal infrastructure is the primary use of this product, and a tool that refused to look at RFC 1918 space would be useless for it.
If you want the tighter posture, you can invert the model entirely and supply an exhaustive allow list, after which everything not named is refused.
The bypass we closed
A target policy that only inspects literal addresses is decorative. Anyone able to write a test definition simply names a hostname instead, and the resolver hands back whatever they wanted to reach.
So hostnames are deferred to a guarded resolver that applies the same policy to whatever the name actually resolves to, at the moment it resolves. A name that lands on the metadata address is refused just as the literal address would be.
This is the sort of detail that decides whether a control is real, and it is worth asking any vendor how they handle it.
Dangerous things require your hands on the keyboard
Some checks legitimately need to do something you would not want enabled remotely. Each of those is gated behind a grant that exists only on the agent's command line, with no code path from served configuration to any of them.
- Disable TLS verification
- Required before an HTTP or API test may skip certificate checking. Useful against an appliance with a self-signed certificate, and exactly the sort of thing that should never be switchable from a server.
- Custom trust store
- Point the agent at your own certificate authority bundle, which is the correct answer to an internal CA and is not the same as turning verification off.
- Skip SSH host key verification
- And, separately, a grant for an agent-local known-hosts file. The safe version and the unsafe version are different grants so that allowing one does not allow the other.
- Consume DHCP leases
- A full DHCP exchange takes a real address out of a real pool. Ordinary DHCP checks do not need this; the lease-consuming variant refuses to be constructed without it.
- Run browser and script plugins
- Executing a real browser, or operator-signed script bundles, is opt-in at install time. Separate grants cover running a browser without its sandbox and allowing insecure TLS inside it.
The enforcement is deliberately blunt. A configuration requesting a capability the agent was not granted does not run in a reduced mode or log a warning and continue; the test refuses to be constructed at all, with a message naming the grant it would need. Which grants an agent holds is reported in its startup log and in its capability report, so an auditor can read it off the host rather than taking our word for it.
TLS is not sufficient, so it is not what we rely on
When an agent fetches its configuration over the network, that document is signed, and the agent verifies it against a public key pinned at install time. Verification happens before parsing, and a signature failure is a hard rejection with no fallback to running it unsigned.
The agent refuses to start with a remote configuration source and no pinned key, rather than defaulting to trusting the transport.
The reason is that transport security answers a narrower question than people assume. Corporate interception proxies terminate TLS by design. Certificates get mis-issued and stolen. A signature pinned to a key you hold means that anything able to impersonate our servers still cannot tell your agents what to do.
If our control plane were fully compromised
- It could not raise any probe rate ceiling.
- It could not reach a denied target, by address or by name.
- It could not disable TLS verification on an agent that was not granted it.
- It could not execute a script or a browser where those were not granted.
- It could not issue a configuration at all without the signing key.
None of which makes an agent harmless. Software you install can do what the account it runs as can do. These controls narrow the blast radius; they are not a substitute for treating the install as the trust decision it is.
Take this to your security reviewer
These are the questions they will ask. We would rather they arrived already answered, and that you asked the same ones of everybody else on the shortlist.