Platform overview
One agent, one platform, one console
Most endpoint estates are managed by an accumulation of tools that were each reasonable on their own day — a monitoring agent here, a remote support tool there, a spreadsheet reconciling what any of it costs. AegisOne is built as a single path from the endpoint to the record, so that the thing you detect, the thing you fix and the thing you can later prove are the same thing.
20 capabilities shipping today · 14-day demo · No credit card required
Architecture
How the pieces relate
Three layers, one connection between them. The design constraint is that no layer holds state the layer above it cannot account for — which is what makes an audit trail possible at all.
- 01
Endpoint agent
A compiled Go binary on Windows, Linux and macOS (Apple Silicon and Intel). Enrols with a signed token and holds an outbound connection.
- Inventory
- Health
- Patch
- Remote terminal
- Compliance scan
Outbound only — no inbound firewall rules on the endpoint
- 02
AegisOne platform
Receives agent telemetry, holds the estate model, drives remediation, and produces the evidence and reporting layer.
- Estate model
- Remediation
- Reconciliation
- Evidence
- Audit log
Every privileged action written to an append-only audit trail
- 03
Console & API
The operator console, the client portal, and the same documented REST surface the console itself uses.
- Operator console
- Client portal
- REST API
- Exports
Multi-factor authentication on operator accounts
Directory context pulled in
- Active Directory
- Microsoft Entra ID
- Microsoft 365
These three are live today. Everything else on our integrations page is labelled Beta, Coming soon or Planned.
Read it downwards and it is a data path: the endpoint tells the platform what it sees, the platform keeps the record. Read it upwards and it is a control path: an operator asks the console for something, the platform authorises it and the agent carries it out. Both directions travel over the same outbound connection the agent opened when it enrolled, which is why AegisOne does not need a VPN, a jump box or a firewall exception at every site you support.
Deployment model
Enrol an endpoint, not a network
AegisOne is delivered as a hosted platform. There is no appliance to rack, no collector to keep patched at every site, and no inbound path into a customer network.
Step one
Issue an install token
Enrolment is token-based, and the token has a configurable lifetime. That matters more than it sounds: an install token that expires is an install token that cannot quietly circulate in a runbook for three years.
A single token can cover a batch, so onboarding a client site does not mean touching every machine by hand.
Step two
Install the agent
The agent is a compiled binary with no runtime to install alongside it — no framework, no interpreter, no version of anything else you now have to keep current. On macOS it arrives as a signed installer package with a managed uninstall path.
For fleets, the same install is scriptable and runs unattended through whatever deployment mechanism you already trust.
Step three
Work from the console
Once enrolled, the endpoint appears against its client, site and department, and begins reporting health, inventory and patch position on a rolling interval.
Nothing else needs opening. Terminal sessions, patch operations and remediation all travel over the connection the agent already holds.
The agent connects outbound to the platform. It does not listen for inbound connections, which means supporting a customer site does not require a VPN tunnel, a port-forward or a firewall exception on their perimeter.
Supported operating systems
Four native builds, one feature surface
Cross-platform in this category too often means a first-class Windows product with an apologetic note about macOS. AegisOne compiles a native binary per target, including a separate build for Apple Silicon.
| Platform | Build | Notes |
|---|---|---|
| Windows | Native Windows binary | Patch scan, install and uninstall, terminal, screen capture and Windows-specific inventory collection. |
| macOS — Apple Silicon | arm64 build | A dedicated arm64 binary rather than a translated Intel one, delivered through a signed installer package. |
| macOS — Intel | amd64 build | The same feature surface as the Apple Silicon build, for estates still running Intel hardware. |
| Linux | Native Linux binary | Server and workstation enrolment with health reporting, terminal access and remediation dispatch. |
What the agent does everywhere
- Health and internet reachability reporting on a rolling interval
- Hardware, software and warranty inventory collection
- Interactive terminal sessions authorised per operator
- Patch scan, install and uninstall driven from the console
- Remediation actions dispatched against a rule
- Every action written to the agent action log
What is still in evaluation
BetaRemote screen access is implemented per platform and compiled into the shipped binaries, and you can use it today. We hold it at beta because multi-monitor selection and the end-user consent prompt are not finished, and calling it generally available before those land would misrepresent what you would get.
Remote terminal, by contrast, is generally available and is what most troubleshooting actually runs on.
What that adds up to on one machine
The list above is per-capability. On an actual endpoint it collapses into a single record: the specs and warranty position the agent collected, its current resource pressure, where it stands on patching, and who last touched it. Every operator action is attributed by name and written to the audit log, which is what makes the compliance layer downstream possible at all.
Device
- Operating system
- Windows 11 Pro 24H2
- IP address
- 10.24.6.118
- Last user
- r.santos
- Uptime
- 9d 4h
- Serial
- MNL-7734-QX
- Warranty
- Expires 14 Mar 2027
Resource utilisation
Patch position
Recent actions
- Patch scan2h ago · r.santos
- Remote terminalYesterday · j.delacruz
- Compliance scan3d ago · system
Every action is attributed to a named operator and written to the audit log.
And what the agent cannot see
An agent inventory is only ever an inventory of machines that will take an agent. Network discovery scans a range and reports the switches, printers, appliances and unidentified hosts that will not. Discovered devices are kept in a separate register from agent-managed endpoints, so a discovery sweep can never inflate the number you manage.
Discovered
60
On 10.24.0.0/16
Agent-managed
41
Reporting to AegisOne
Unmanaged
19
No agent present
Unmanaged devices found
- 10.24.1.4Switch · Cisco
- 10.24.1.9Firewall · Fortinet
- 10.24.3.22Printer · Brother
- 10.24.3.51Access point · Ubiquiti
- 10.24.6.77Unidentified host
- 10.24.7.12NAS · Synology
Discovered devices are held separately from agent-managed endpoints, so the two counts are never conflated in reporting.
Security model
Deliberate access, recorded afterwards
A tool that can open a shell on every machine you manage is, by construction, a high-value target. The security model is built around two ideas: access should be an explicit act, and every explicit act should leave a record.
Identity
Who the operator is
Operator accounts support TOTP multi-factor enrolment, verification and disable, and login attempts are tracked. New operators arrive through an invite rather than self-registration, so the set of people who can reach an endpoint is a set somebody decided on.
Federated sign-on through SAML or OIDC is on the roadmap and is not available today — we would rather say so here than let you discover it during procurement.
See what is in development →Session authorisation
How a session is granted
Remote sessions are not a standing tunnel. Each one is authorised individually: the platform issues a ticket for the WebSocket channel, and that session is bound to the operator identity that requested it.
The consequence is that “who was on that machine at 02:00” has an answer, rather than a shortlist.
Credentials
Where secrets live
Shared operational credentials belong in a vault with an explicit reveal action, not in a shared note. Reveal events are captured in the audit log, which turns credential access from something ambient into something observable.
Evidence
What is kept afterwards
Privileged actions across the platform are written to an audit log carrying actor, action and target. Agent-side operations additionally land in the action log against the endpoint they touched.
That record is what makes the compliance layer possible: framework scoring and evidence export draw on the same trail, rather than on a separate set of numbers assembled for the auditor.
Our controls are designed against ISO/IEC 27001 principles. AegisOne is not ISO certified, and we do not display a certification seal we have not earned. See Security and Compliance for the full position.
Integration model
Directory context in, platform events out
AegisOne integrates in two directions, and it is worth being precise about which of them is built.
Context pulled in
An endpoint is more useful when the platform knows who owns it and what licence they hold. AegisOne currently synchronises directory and tenant data from 3 live sources — Active Directory, Microsoft Entra ID and Microsoft 365 — enriching the managed estate with users, devices, security posture and licence position.
That is the honest count. Everything else on our integrations page is labelled Beta, Coming soon or Planned, and none of it is presented as working today.
Data taken out
The console runs on a documented REST surface, and that same surface is available to your own automation. It is offered as beta rather than generally available because we have not yet published the versioning and rate-limit guarantees an external consumer is entitled to expect — the API works, the promises around it are not finished.
Reporting exports to PDF, Excel and PowerPoint are generally available, and are how most teams currently get AegisOne data into a board pack. Outbound webhooks are not yet available.
In practice that second direction is mostly an export. A report is generated from the catalogue against a client and a period, then leaves the platform in whatever format the meeting runs on.
Quarterly business review · Northwind Logistics
- Tickets resolved
- 184
- Mean resolution
- 4h 12m
- Patches applied
- 2,140
- Incidents prevented
- 11
Ticket volume, last 8 weeks
Export
- Executive PDF
- PowerPoint deck
- Excel workbook
- CSV extract
Built for the meeting, not just the screen.
What sits on top
The capability layer, by group
Everything below is running in production today and available in the demo environment. Work in progress is kept on the roadmap where it belongs.
- Endpoint Management3
Enrol, inventory, group and control every device under management.
- Monitoring & Health2
Continuous visibility into endpoint, network and service health.
- Remote Support2
Reach any endpoint and resolve the issue without leaving the console.
- Automation & Patching2
Close the loop between detection and remediation.
- Security & Compliance4
Harden endpoints and produce the evidence auditors ask for.
- Service Operations4
Run the commercial side of managed services, not just the technical side.
- AI & Analytics3
Turn operational data into summaries, risk scores and recommendations.
Enrol one endpoint and judge it from there
The architecture is easier to assess against a real machine than a diagram. Start a 14-day demo, or have someone walk the platform through against your own estate.