Endpoint Agent Security Brief

An endpoint management agent is one of the most privileged pieces of software in an estate. It runs elevated, on every machine, and it exists to execute instructions that arrive from somewhere else. Any honest security discussion about this category starts by acknowledging that, rather than by listing encryption algorithms.

This brief describes how AegisOne is built, and — more usefully — the questions you should put to anyone selling you a tool of this kind, including us.

The connectivity posture

AegisOne agents connect outbound to the platform and maintain that connection. The platform never initiates a connection into your network.

The security consequence is the elimination of a whole class of exposure rather than the mitigation of it. There is no listening service on the endpoint to be discovered by a scan, no management port that could be exposed by a firewall change made for another reason, and no requirement to make managed machines reachable from anywhere. Remote terminal sessions travel over the same outbound channel, so reaching a machine on a segregated network does not require making that network reachable.

This is worth checking with any vendor, because the alternative architecture — a listening agent, or a management appliance with an inbound interface — has a materially different risk profile and the difference is not always volunteered.

The authorisation model

Opening a remote session requires a short-lived ticket issued by the platform to an authenticated operator. The session is established with that ticket, bound to the operator identity, and recorded in the agent action log.

Three properties follow. Sessions cannot be initiated anonymously. Sessions cannot be initiated by replaying a captured connection, because tickets are short-lived. And every session is attributable to a named person, which is what turns an audit log from documentation into evidence.

Privileged actions across the platform — not only sessions — are written to an append-only audit log carrying actor, action and target. Credential vault reveals are recorded. Login attempts are recorded whether or not they succeed.

The action surface

The agent executes a fixed set of instructions: patch scan, patch install and uninstall, compliance scan, remediation actions, terminal and screen sessions. It does not execute arbitrary operator-authored code, because there is no script library in the product.

This is simultaneously a real limitation and a real security property, and which one dominates depends on your priorities. A fixed action surface is bounded and analysable. An arbitrary-code surface is neither — a compromised console on a platform with a script library is a remote code execution capability across your entire estate, delivered by design. If you are evaluating tools with scripting, ask specifically what controls sit between a console session and code executing on a production server, and treat "role-based access control" as the beginning of the answer rather than the end of it.

Authentication, stated honestly

Operator authentication is email and password with optional TOTP multi-factor. There is no SAML or OpenID Connect federation in the product today.

The practical consequence is that operator identity does not flow from your identity provider. Deprovisioning a leaver in your directory does not remove their AegisOne access; that is a separate action, and if your process assumes federation it will miss it. Plan for that explicitly rather than discovering it during an access review.

It also means MFA is not optional in practice. A password alone protects a console that can open a shell on every machine you manage. Enrol every operator.

The questions to ask any vendor

Does the agent listen on a port, or connect outbound only? If it listens, what is exposed and to whom?

Can an authenticated operator execute arbitrary code on an endpoint? If so, what stands between a compromised console session and that capability?

Is every remote session attributable to a named individual, and is that attribution recorded in a log the operator cannot modify?

What happens to a credential a technician retrieved before they left? Is retrieval recorded at all?

Does operator authentication support your identity provider, and if not, what is your leaver process?

What can the vendor themselves see or do in your tenant, and is that access logged where you can read it?

Shared responsibility

The platform provides isolation, auditability, an outbound-only posture and a bounded action surface. Whether operator accounts are individually named rather than shared, whether MFA is enrolled, whether leavers are revoked promptly, and who is permitted to open a terminal on a production server are your decisions and cannot be delegated to a product.

It is worth being blunt about where incidents actually come from in this category. They are rarely exploits against the agent. They are an operator account that outlived its owner, protected by a reused password, with no second factor — an entirely preventable failure of process rather than of technology.