What "outbound-only agent" actually means at the TCP level, for the technically skeptical reader

"Outbound-only" and "zero inbound exposure" are the kind of phrases that show up in every RMM vendor's security page, and they mean different things depending on who's writing them. Some vendors mean "the primary function is outbound, but there's also a listener for remote-control sessions." Some mean nothing verifiable at all. If you're the kind of reader who wants the actual claim, not the adjective, here it is at the level of sockets and connections.

What the agent does not do

The Nexus endpoint agent never calls listen() on a socket, and never binds to a port waiting for an incoming connection. There is no service on the endpoint that a port scan from the local network — or from the internet, if the device is exposed — will find open and answering. This is the concrete, verifiable meaning behind "no listening surface": you can run a port scan against a device running the agent and the scan will not find an agent-owned listening port, because there isn't one to find.

What the agent does instead

• The agent initiates a TCP connection outbound, over TLS, to the platform, on a schedule and in response to specific triggers — it is always the client side of the connection, never the server side.
• That connection carries authentication (the agent proves who it is to the platform) and, per our signed-job architecture, cryptographic verification of any job the platform sends back down that same connection.
• Remote-control and live sessions work the same way: the session is a job the agent pulled down over its own outbound connection, not an inbound connection someone opens to reach the agent directly. The agent is still never listening for a peer to find it.
• When there's nothing to report and no job pending, the agent simply doesn't hold an active connection open waiting — it reconnects on its schedule, which limits the window during which any connection exists at all.

The test that actually settles this isn't a claim on a security page. It's a packet capture and a port scan on a device running the agent, before and after install, at a site you control.

Why this is a meaningfully different attack surface than a listening agent

A listening agent is reachable by definition — anything that can route a packet to that port can attempt to talk to it, which means a vulnerability in that listener is remotely exploitable by anything on the local network, and potentially the internet if the firewall in front of it is misconfigured even once. An outbound-only agent has no equivalent target: there is no port to send a malicious packet to, because the agent never accepts an incoming connection to interact with. That doesn't make the agent invulnerable — the outbound connection itself, the platform it connects to, and the job-verification logic all still have to be secure — but it removes an entire class of remote-exploitation path that exists purely because something was listening.

We'd rather you verify this than take our word for it. Ask any RMM vendor, us included, to show you the actual before-and-after firewall rule diff and a port scan result at a real test install. "No inbound access required" should survive that test, not just the marketing page it's printed on.