Trust
An agent on every endpoint is a trust decision. Here is what we do with it.
AegisOne holds administrative reach into machines you are responsible for. This page describes the controls that protect that reach — accounts, agents, remote sessions, stored credentials, API traffic, audit records and the data we hold on your behalf.
What this page deliberately does not say
Security pages in this category tend to list every control the buyer might want to hear about. We have written the opposite kind of page: it describes controls that are implemented and can be demonstrated in the product, and it stays silent on the ones that are not.
You will not find a penetration-test result, a tamper-detection claim, a named encryption-at-rest algorithm, an IP allowlisting feature or a conditional-access policy engine described here, because we have not built or independently verified them. If a control you require is missing from this page, assume we do not have it and ask us — that is a more useful conversation than discovering it during implementation.
AegisOne is a young platform. Several controls enterprise buyers reasonably expect are on the roadmap rather than in the product. They are listed further down this page, labelled as such.
Accounts
Who can get in, and as whom
Every action in AegisOne is attributable to a person. That property is only worth something if accounts are individual, protected and revocable — so those come first.
Operator authentication
Access to the console is per-person. Operators are onboarded by invitation rather than by shared credentials, so every account maps to a named individual who can be revoked independently.
- Invite-based operator onboarding — no generic shared logins
- TOTP multi-factor authentication, with enrolment, verification and disable flows
- Login attempt tracking, so repeated failures against an account are visible
- Rate limiting on authentication and API endpoints
Role-based access
Operators hold roles rather than blanket administrative rights. Privileged surfaces — the credential vault, remote sessions, audit records — are gated on role, and access decisions are recorded rather than assumed.
- Role-based operator accounts
- Client, site and department structure scopes what an operator sees
- Client portal users are a separate surface from operator accounts
- Privileged actions are attributed to the operator who performed them
Agents
Enrolling a device without opening it up
The agent is the most sensitive component we ship. It is designed so that installing it does not widen the endpoint's attack surface.
Enrolment
An endpoint joins the platform by presenting an install token. Tokens are issued deliberately from the console and have a configurable lifetime, so a token that leaks out of a deployment script does not remain useful indefinitely.
- Token-based enrolment with configurable token lifetime
- Tokens issued from the console and scoped to a deployment
- Scripted install for fleet deployment without embedding operator credentials
- Managed uninstall path so removal is a controlled action
Connectivity
The agent maintains an outbound connection to the platform. It does not listen for inbound connections, which means enrolling an endpoint does not require opening a port or writing an inbound firewall rule on the device or its network.
- Outbound-only connectivity from the endpoint
- No inbound firewall rules required on managed devices
- Agent traffic to the platform is carried over TLS
- A compiled binary with no runtime dependency chain to maintain
Sessions and secrets
Reaching a machine, and reading a secret
Remote access and credential access are the two capabilities most likely to be abused. Both are ticketed or explicit, and both are recorded.
Remote session authorisation
A remote terminal session is not opened by pointing a browser at a socket. The console requests a short-lived ticket for a specific endpoint, and the WebSocket connection is authorised against that ticket. A session that has not been ticketed does not connect.
- Ticketed WebSocket authorisation issued per session
- Sessions bound to the requesting operator identity
- Remote actions written to the endpoint action log
- Session and action attribution to a named operator, not to the platform
Credential handling
Shared operational credentials live in the vault rather than in tickets, spreadsheets or a technician’s password manager. Reading one is an explicit action that produces a record — access is deliberate, not ambient.
- Per-client credential storage in the vault
- Explicit reveal action required to read a stored secret
- Every reveal captured in the audit log with actor and target
- Vault access gated on operator role
What a ticketed session looks like
The console asks the platform for a short-lived ticket scoped to one endpoint, and the WebSocket refuses the connection without it. The operator who requested the ticket is the operator the session is attributed to, and the whole exchange lands in the action log rather than in a technician’s memory.
Session opened · operator j.delacruz · MNL-WS-114PS C:\> Get-Volume C | Select SizeRemainingSizeRemaining : 12.4 GBPS C:\> Clear-RecycleBin -ForcePS C:\> Get-Volume C | Select SizeRemainingSizeRemaining : 48.9 GBSession recorded · written to audit logSessions are authorised per connection and bound to the operator who opened them. Nothing here runs without an authenticated ticket.
Records and data
Audit trail, API surface and customer data
The audit log is a product feature, not an internal debugging convenience — it exists so you can evidence to someone else what happened on your estate.
Audit records
Privileged actions across the platform are written to an append-only audit log carrying the actor, the action and the target. The log is designed to be read as evidence — by your auditors, and by you when you need to reconstruct what happened.
- Append-only audit logging of privileged actions
- Actor, action and target recorded on every entry
- Login attempt records held alongside the action log
- Audit data exportable as part of an evidence package
API and customer data
API traffic is authenticated per operator and carried over TLS. Data is organised by client and site so that access controls, reporting and deletion all follow the same boundaries the rest of the platform uses.
- TLS for API and console traffic in transit
- Authenticated, rate-limited API surface
- Data scoped by client, site and department
- Documented processing and retention settings
Not yet built
Security work on the roadmap
Listed here rather than omitted, so that a gap you care about is visible before you commit to an evaluation.
Single sign-on (SAML 2.0 and OpenID Connect)
In developmentFederated operator login against your identity provider, with passkey and conditional-access support. Authentication today is email and password plus TOTP multi-factor.
Roadmap items carry no delivery date on this site. When one ships it moves into the control sections above and onto the capability list.
Security documentation
Available on request, not as a download
We do not publish a self-serve document portal, because that would imply a library that is larger and more formal than the one we actually maintain. Tell us what your assessment needs and we will send the current version, dated.
Security overview
A written summary of the controls described on this page, suitable for attaching to a vendor assessment.
Architecture overview
How the console, API, agent and datastore relate to one another, and where each component runs.
Data-flow summary
What the agent collects, where it is transmitted, what is retained and for how long.
Subprocessor list
The third parties involved in delivering the service, and what each one processes.
Data Processing Agreement
Our standard DPA for customers acting as data controllers.
Vulnerability disclosure policy
How to report a suspected vulnerability, and what you can expect from us in return.
Incident response overview
How we triage, contain and communicate a security incident affecting customer data.
These documents are provided on request so that we can send you the current, dated version rather than a cached PDF. Requests reach our security team at security@aegisone.lynxclub.ph.
Reporting
Found something? Tell us directly.
If you believe you have found a vulnerability in AegisOne, contact our security team before disclosing it publicly. We will acknowledge your report and keep you informed as we work through it.
Please include
- The affected component, URL or endpoint
- Steps that reproduce the behaviour
- What you were able to access or affect
- Any logs, requests or screenshots that help us reproduce it
- How you would like to be credited, if at all
Please do not test against other customers’ data, degrade the service for others, or access more data than is necessary to demonstrate the issue.