One agent. Zero inbound.

ApexAI · Product & Security · 2026

The agent paradox

To manage and secure endpoints, you deploy an agent to each one. That agent needs authority to change the device, connectivity to a control plane, and a trust relationship with the platform. Every one of those is also a potential foothold. The tool you installed to reduce risk has, in the wrong architecture, quietly expanded your attack surface across every machine you own.

This is the agent paradox, and it's why agent-based tooling is such an attractive target: compromise the agent or its control channel, and you inherit privileged access to the entire fleet at once.

The management agent with authority over every device is the most valuable thing on your network. Its architecture is not a detail.

Inbound is the enemy

Most of the danger concentrates in one place: inbound connectivity. Agents that listen for connections, expose management ports, accept push callbacks or rely on transport client certificates all give an attacker something to reach and something to spoof. Inbound rules have to be maintained across firewalls and network segments; every open port is a door that must be watched forever.

Remove inbound entirely and a large share of the risk disappears with it. There is nothing listening to attack, nothing to port-scan, no inbound rule to misconfigure, and nothing exposed when a device roams onto an untrusted network.

Outbound-only by design

ApexAI takes the opposite approach to the norm: each agent holds a single encrypted, outbound-only connection to the control plane over HTTPS/WSS on port 443. Nothing listens for inbound connections. There are no inbound firewall rules to manage, and the design survives TLS-inspecting proxies — or no internet at all, running fully air-gapped.

Because the connection always initiates from inside the trust boundary, the network posture is simple to reason about and simple to defend: outbound 443, and nothing else.

Identity without the network

Removing inbound connectivity only helps if trust doesn't secretly depend on the network anyway. So identity is enforced at the application layer, not the transport. Each agent proves itself with an Ed25519 key it holds locally — a cryptographic proof of possession — rather than a transport client certificate or a shared bearer secret sitting on the wire. There is no reusable secret to steal in transit, and identity holds even across proxies and air gaps.

Signed jobs and enrolment

Authority flows the same way. Every job the platform issues is cryptographically signed and verified on the device before it runs, so an operator — or an attacker who reached the channel — cannot push unsigned or tampered work. Devices enrol with a single-use, hashed token: identity is written on first run and the token is cleared, leaving nothing reusable behind. Trust is established once, locally, and proven cryptographically from then on.

A genuine zero-trust posture

Zero trust is often reduced to a login screen. At the architecture level it means something stronger: no implicit trust from network position, verified identity on every interaction, and least-privilege by construction. Outbound-only connectivity, app-layer identity, signed-and-verified jobs and single-use enrolment deliver exactly that — not as policy layered on top, but as properties of how the system is built. Combined with strict isolation in the data layer, cross-boundary access isn't merely blocked; it isn't expressible.

The strongest control is the one an attacker can't reach to subvert — because it was never exposed in the first place.

Fewer moving parts, less to attack

Good security architecture removes attack surface rather than adding monitoring to compensate for it. One lightweight agent, one outbound channel, cryptographic identity and signed jobs mean fewer moving parts, fewer doors, and far less to defend. The agent stops being your biggest liability and becomes what it should have been all along: the smallest, hardest-to-abuse point of control over your estate.