Repository navigation
Roadmap
Last updated: October 2026 (agent v3.5.0). Quarters are indicative, not commitments. Each planned item has exit criteria; it is done when they are met, not when its quarter ends. GitHub epics will be linked as they are created.
This page covers the whole platform: the SentinelGo agent (this repository) and the backend (admin console, database and server functions). Most of the product's features live in the backend; the agent is the trusted hands and eyes on each device. The repository's
ROADMAP.mdtracks agent-only housekeeping, and everything in it is reflected here.
Contents: Where we are · Delivered · Direction · At a glance · Now · Next · Later · Parked · How this page changes
| Area | What the platform does today |
|---|---|
| Fleet & inventory | Windows, macOS and Linux agents; online/offline status; hardware down to each partition, GPU and peripherals; full software inventory for every user account; OS services; browser extensions; device groups and tags; devices mapped to their owners |
| Security posture | Encryption per partition, firewall, EDR/AV presence, patch status, OS end-of-life tracking, CVE matching of installed software against the National Vulnerability Database, fleet risk views |
| Compliance | Configurable compliance checks with categories, severities and evidence rules |
| Policies & automation | Visual policy editor, policy groups assigned to device groups, scheduled/recurring execution with history; drag-and-drop workflow builder (joiner/leaver and custom flows) triggered manually, on a schedule or by an alert |
| Remote actions | PowerShell/Bash/shell scripts to one device or a group, reusable templates, AI-assisted script writing, native tasks (reboot, firewall on/off, …), structured results (exit code, reboot required) |
| Software deployment | Curated app catalog over native package managers (winget, Chocolatey, Homebrew, APT, DNF, YUM, Snap, Flatpak); uploaded installer files up to 4 GiB, verified end to end by agent and server; install from the catalog, a device or a policy |
| Alerting | Rule wizard with an enterprise template gallery and AI-assisted rules, severity, acknowledge/resolve, recurrence tracking, one-click remediation commands linked to rules |
| Encryption key escrow | BitLocker enablement with recovery keys kept in an encrypted vault |
| Logs & audit | Agent audit-log collection (Windows Event Log, journald, macOS unified log) ingested and searchable per device; full admin activity trail with diffs, saved filters and CSV export |
| Access control | Role-based access with custom roles, scoped assignments (organisation, department, device group, site, device), just-in-time roles with approvals, Azure SSO, sign-in protection |
| Self-service | Employee portal showing "My Devices" |
| Integrations | Wazuh SIEM (syslog over TLS), Odoo HR directory sync, NVD, GitHub, AI gateway |
| Operations | Self-hostable Docker deployment, automatic migrations, scheduled backups to S3/SFTP/SMB with restore |
| Trust in the agent | Signed self-update, signed and checksummed installers, build-provenance attestations, SBOM per binary, reproducible builds, 31 continuously-run fuzz targets, OpenSSF Scorecard and Best Practices |
Development started in May 2026 (backend) and the agent's public history starts in June 2026 (v2.1.17; the agent code predates this repository). Since then: 24 agent releases, five static binaries (Windows x64, Linux x64/ARM64, macOS Intel/Apple silicon), and a backend that grew from an admin console into a full endpoint-management platform.
- Admin console: dashboard, device list and detail, users, settings, device logs.
- Agent registration and per-agent installer issuing; employee directory sync and bulk import.
- Remote commands with AI-assisted script generation; app catalog; employee "My Devices" portal.
- Device groups, policies and alert rules (with AI-assisted rule writing).
- Vulnerability management: NVD CVE scanning, OS end-of-life tracking, vulnerabilities page.
- Agent releases page, integrations hub, scheduled jobs, first compliance checks.
Agent
- v2.1.17–v2.2.1: cross-platform agent running as a native Windows Service / systemd / launchd service; richer network and system inventory; reworked audit-log collection on all three OSes.
- v3.0.0: signed self-update. Every release is signed (Ed25519), and the agent refuses unsigned updates.
- v3.0.1–v3.1.0: native remote-task framework with per-task timeouts, remote reboot, USB mass-storage detection.
- v3.1.2–v3.1.3: one-click installers for every desktop OS; firewall enable/disable tasks.
- v3.2.0: updates delivered from the backend's own release storage instead of an external host.
- v3.2.1–v3.2.6: session recovery, emergency logging, OS-services inventory, cross-platform security-posture and patch-compliance assessment, reliable de-duplicated delivery, a diagnostics dump, sensitive values redacted from logs, software inventory for every user.
Backend
- Workflow builder for joiner/leaver processes; AI-assisted catalog entries; catalog and alert-rule import/export.
- Self-hosted packaging: Docker deployment with automatic database migrations and function deploys.
- Backend: role-based access control with custom roles, scoped and just-in-time assignments, approvals, and an audit trail of permission changes.
- Backend: admin activity log with timeline, diffs and CSV export.
- Backend: compliance checks made fully configurable; alert-rule wizard with a template gallery; acknowledge/resolve lifecycle.
- Backend: default "Standard" device group for new agents; generic (not only joiner/leaver) workflows; first backup & restore; default command, alert-rule and catalog content.
- Agent v3.2.7: browser extensions reported with stable IDs and readable names.
- Backend: modular widget dashboard; Wazuh SIEM export over TLS; scheduled backups.
- Backend: BitLocker recovery-key vault; the console becomes Endpoint Management.
- Backend: policy engine v2 with recurrence and app installs; faster first sync after enrollment; more accurate patch alerts.
- Agent v3.2.8: HTTPS-only backend connections; restrictive permissions on the installation.
- Agent: code-quality sweep across ~30 files; system tools invoked by absolute path.
- Backend: software-inventory reconciliation, first-admin setup wizard, production Docker image, dedicated installer project.
Agent
- v3.3.0: Supply-chain security. OpenSSF Scorecard, GitHub Actions pinned to commit SHAs, least-privilege CI tokens, build-provenance attestations, an SBOM for every binary, licence allow-listing, signed and checksummed installers.
- v3.3.0: Continuous fuzzing. 31 fuzz targets over every parser that reads untrusted input, run nightly.
- v3.3.0: One in-house backend client. All backend access goes through one typed client with reliable session renewal and retries, replacing two community SDKs.
- v3.4.0: Quality push. 12 bugs found and fixed while raising test coverage; project website, governance, CODEOWNERS, changelog-driven one-click releases.
- v3.5.0: Backend-defined installers. The agent downloads and verifies installer packages before running install scripts, advertises its capabilities, and returns structured results. Also: reproducible builds, race detection in CI, a published security assurance case, OpenSSF Best Practices badge.
Backend
- Alert remediation runnable straight from the resolve step; RBAC permission matrix by resource; read-only device detail for employees.
- Backup & restore rebuilt: per-table settings, S3/SFTP/SMB destinations, restore from upload.
- Signed installer bundles with checksums and CPU-architecture selection, built from the platform's own storage.
- Sign-in hardening: strong password policy, account lockout, optional CAPTCHA, closed public sign-up.
- Installer files for every OS: resumable uploads up to 4 GiB, server-side hashing, install-command templates, install from catalog, device or policy.
The platform already observes, alerts and acts: it collects posture, flags risk, and can run scripts, policies and workflows. The next step is from running actions to guaranteeing state:
- Harden every remote-action path, so stronger powers are safe to add.
- Make deployment generic (OS-signed packages + enrollment tokens), so the agent can be rolled out by standard tools, including MDM.
- Unify compliance and policy into desired state: one definition of "compliant" that is both measured and enforced.
- Enforce it everywhere: agent-side on Windows and Linux, MDM on macOS (see MDM Assessment).
Work that does not serve this direction is deliberately deferred. See Parked and the DLP Assessment.
| Horizon | Item | Depends on |
|---|---|---|
| Now (Q4 2026) | 1. Security hardening | — |
| Now (Q4 2026) | 2. Platform code signing | — |
| Now (Q4 2026 → Q1 2027) | 3. Enrollment v1 | backend contract |
| Now (Q4 2026 → Q1 2027) | 4. Desired-state compliance | — |
| Now (ongoing) | 5. Agent reliability & project health | — |
| Next (Q1–Q2 2027) | 6. Enforcement with drift correction (Windows/Linux) | 1, 4 |
| Next (Q1–Q2 2027) | 7. macOS MDM pilot | 1, 2, 3, 4 + discovery gate |
| Later (H2 2027) | 8. MDM at scale | 7 |
| Later (H2 2027) | 9. DLP visibility (Tier 1) | 4, 6 |
| Later | 10. Windows MDM | 6 proves insufficient |
| Later | 11. Independent security review | 1 |
| Parked | Content-aware DLP, kernel drivers, browser extension | — |
Q4 2026 Q1 2027 Q2 2027 H2 2027
[1 Hardening ]
[2 Code signing ]
[3 Enrollment v1 ──────────]
[4 Desired-state compliance]
[5 Reliability & project health (ongoing) ─────────────────────────────]
[6 Enforcement + drift (Win/Linux)]
[7 macOS MDM pilot ─────────────]
[8 MDM at scale ───]
[9 DLP visibility ─]
[11 Security review]
Why: Policies, installers, workflows and soon MDM all give the backend real power over devices. Every remote-action path has to be integrity-protected before that power grows further.
Scope:
- Agent credentials in the OS credential store: the Windows credential APIs and the macOS Keychain, without cgo. A copied configuration file must not be usable from another machine.
- Signed task execution: the agent runs a task or script only if it carries a valid signature from a key that database access alone can't produce. Needs an agent–backend contract first.
- Self-check of the installation: the agent verifies its own file permissions at startup and reports the result to the backend, so the fleet's state is visible in the console.
Exit criteria: an unsigned or tampered task is rejected and reported; credentials copied off a host are useless elsewhere; installation self-checks are visible fleet-wide.
Why: Agent releases carry our own Ed25519 signatures, which the updater verifies, but not OS-recognised signatures. That means SmartScreen and Gatekeeper warnings, friction with EDR products, and no MDM package deployment or macOS privacy (PPPC) grants, both of which identify an app by its code signature.
Scope:
- Apple Developer ID signing + notarization for the macOS binary and package.
- Authenticode for the Windows binary and installer, ideally with an HSM-backed certificate.
- Signed release tags, so the source of a release can be verified as well as its binaries.
- All signing happens in the release workflow, with keys never on a laptop.
Exit criteria: spctl --assess and Get-AuthenticodeSignature pass on release artifacts; release tags verify.
Why: Each install is currently a per-agent bundle with server-generated configuration. That model can't be deployed by MDM, GPO, Intune or package managers, which all expect one generic package.
Scope:
- Generic signed packages:
.pkg(macOS),.msi(Windows),.deb/.rpm(Linux). - First-run enrollment: the agent exchanges a one-time enrollment token (installer property, MDM-managed preference or file) for its own credentials through a new backend endpoint.
- Tokens are single-use or short-lived, scoped, and revocable from the console. The device lands in the right group automatically.
- The current bundle installer keeps working during migration.
Exit criteria: a device can be enrolled with only the generic package plus a token; tokens can't be reused; the agent never keeps the token after enrollment.
Why: The backend already has configurable compliance checks and a policy engine, but they are separate ideas: one measures, the other runs actions. Making a policy a declaration of desired state that is both evaluated and later enforced is the foundation for items 6 and 7.
Scope:
- Extend the existing compliance model so each check can name a setting, an expected value, and per-OS evaluation and (later) remediation.
- Per-device compliance with evidence in the console: compliant / non-compliant / unknown, and why.
- Starter baseline (about 10 checks): disk encryption; firewall; screen lock ≤ N minutes; OS updates within N days; EDR/AV running; agent up to date; USB mass storage disabled or encrypted-only; no personal cloud-sync clients; removable-drive encryption; MDM enrolled (macOS).
- The DLP posture signals from the DLP Assessment (Tier 0) ship here as ordinary checks.
- Any new agent capability is advertised only in the same release that implements it.
Exit criteria: the console shows "N% of devices compliant with check X" with per-device evidence; a new data-driven check needs no agent release.
Ongoing items carried over from the repository's ROADMAP.md:
- Automatic rollback when an update installs but fails to start (failed binary replacement already rolls back).
- Finish verifying the in-house backend client on staging (gateway auth and error behaviour).
- Test coverage to 90% (currently about 82%).
- OpenSSF Best Practices silver: remaining work is DCO sign-off on commits.
- SPDX licence and copyright headers in every source file.
Why: The policy engine can already run actions on a schedule. What's missing is a guarantee: if a setting drifts, it is detected and put back, and the console shows it. On Windows and Linux the agent runs as SYSTEM/root, so it can do this without MDM.
Scope:
- For checks from item 4 where it is safe, add a built-in remediation: policy registry keys, firewall, USB storage (
USBSTOR/usb-storage), screen lock, encryption enforcement (building on BitLocker enablement and key escrow). - Detect drift every cycle, re-apply, and report each change in the activity log.
- Staged rollout (pilot → ring → fleet) with a per-check kill switch.
- Remediations run as signed tasks (item 1).
Exit criteria: enforced checks return to compliance within one cycle after manual drift; any enforcement can be rolled back fleet-wide in one action.
Why: macOS is the platform where an agent alone can't enforce policy; Apple routes that through MDM. Full analysis: MDM Assessment.
Gate: answer the discovery questions. There is no existing MDM in the organisation (confirmed October 2026), so the plan is to build. The remaining questions are about Mac fleet size, Apple Business Manager, Apple certificates and ownership.
Scope:
- Obtain the MDM vendor signing certificate and APNs certificate, with a documented renewal owner.
- Build the MDM endpoints in our TypeScript backend: check-in, command queue,
Mdm-Signatureverification and signed enrollment profiles (backend app server or edge functions), plus APNs push (app server). All device traffic goes through a dedicated, permanent MDM hostname. Payload and command types are generated from Apple's published schemas. Design: MDM Assessment §4. - Device identity for the pilot: per-device PKCS#12 identity in the enrollment profile.
- Manual enrollment of 10–20 pilot Macs.
- Profiles generated from the item 4 baseline: FileVault (with recovery-key escrow alongside the existing BitLocker vault), passcode, firewall, PPPC grant for the agent, managed login item for the agent.
- Deploy the signed agent
.pkg+ enrollment token through MDM (items 2 and 3).
Exit criteria: pilot Macs reach 100% compliance on the pilot checks without user action; the certificate-renewal runbook has been rehearsed; the agent detects and reports MDM removal.
SCEP or ACME (hardware-attested) device certificates; Apple Business Manager / ADE zero-touch, supervised enrollment; Declarative Device Management for OS updates; lock/erase behind the existing just-in-time approval flow; ring-based profile rollout.
USB-device and removable-media write events, print auditing, and an opt-in data-at-rest scan that reports types and counts only, never content. Needs a legal/HR position on scanning employee devices first. See DLP Assessment.
Windows' built-in MDM client (OMA-DM) is complex to serve. Build only if agent-side enforcement (item 6) proves insufficient.
An external review of the agent, the updater, the release pipeline and the backend's device-facing surface, once item 1 lands. A second maintainer for the agent repository also belongs here, so main can require independent review again.
| Item | Why parked | Revisit when |
|---|---|---|
| Content-aware DLP blocking (Tier 3) | Needs kernel drivers / system extensions; breaks the no-cgo single-binary model; high fleet risk, low marginal return | See [[DLP Assessment |
| Own kernel drivers of any kind | Signing burden, crash risk, separate native codebase | A requirement no OS API or existing product can meet |
| Browser extension | A separate product surface per browser | DLP or web filtering becomes a funded product line |
- Propose changes as a GitHub issue labelled
roadmap, linking the evidence (customer request, audit, incident). - Every Now / Next item gets an epic before work starts. Work that spans the agent and the backend shares one written contract, as the installer work did.
- When an item ships, move it to Delivered under its month, so this page stays the record of what we've achieved as well as what's next.
- Review this page every quarter and at every agent minor release.
SentinelGo
Repository docs