SENTINEL — Self-Hosted Endpoint Security & DLP Platform for Source-Code Protection

SENTINEL by Kolpolok — Watch, detect, and respond across every company device. One console for endpoint visibility, data-loss prevention, and real-time response.

Project Overview

Project Summary

SENTINEL is a self-hosted endpoint security and data-loss-prevention platform I designed and delivered to solve a problem most commercial EDR products handle badly for software companies: protecting source code, secrets, and credentials on developer machines without turning monitoring into surveillance.

The platform gives the security team a single console to see what every company-owned device is doing, detect sensitive data leaving those devices, and respond in real time — remote lock, malware scan, USB block — with every action written to an append-only audit log. Detection runs across three operating systems from one codebase, and the whole system is deployed on-premise on a single self-hosted server, so no telemetry ever leaves company infrastructure.

The design constraint that shaped every decision was data minimisation: SENTINEL collects metadata and cryptographic hashes only. Never file contents. Never keystrokes. Never personal accounts. That constraint is not a limitation bolted on for compliance — it is the reason the platform was accepted by the engineering team it monitors.

Confidentiality note: SENTINEL is proprietary software owned by Kolpolok Limited. This write-up covers architecture, design decisions, and engineering outcomes only. No source code, detection rule content, configuration, or internal identifier is published. Screenshots are redacted.

The Problem

A software company’s most valuable asset is code it has not shipped yet — repositories, API keys, cloud credentials, customer schemas. That asset sits on laptops, gets copied to USB drives, gets pasted into public repositories, and walks out of the building inside a backpack. The available options were all bad:

The requirement was therefore: self-hosted, cross-platform, metadata-only, and capable of responding — not just alerting.

Architecture — Three Tiers

SENTINEL is a three-tier system: an agent fleet on the endpoints, a policy and detection server on the LAN, and a browser console for the security team. It is built as a modular monolith with clean internal service boundaries, so components can be separated later without a rewrite.

The description below is deliberately architectural. Specific components, libraries, and detection engines are internal implementation detail and are not published.

Tier 1 — Endpoint Layer

A lightweight cross-platform agent runs on Windows, macOS, and Linux from a single codebase. Its design principle is integration over invention: rather than writing collectors, it orchestrates established, well-audited telemetry and scanning components already trusted in production environments, and delivers their output in one normalised stream.

Responsibilities:

• Integrity telemetry — change detection on administrator-defined paths, plus device posture assessment
• Host state collection — running processes, connected devices, installed software, and user context
• Threat scanning — dispatched to the platform-appropriate scanning engine per operating system, so each host uses the engine best supported on it
• Self-update — cryptographically signed packages; the agent installs nothing it cannot verify against a trusted key

The agent maintains a single outbound heartbeat on a short interval. That one channel carries status up, and commands plus signed updates down. The consequence is architectural, not incidental: no endpoint runs an inbound listener, and no developer laptop needs a firewall exception. The highest-risk surface in any agent architecture — the channel that can install code — is reduced to one authenticated, signed, outbound-initiated path.

Tier 2 — Server Layer

A single self-hosted server on the LAN, containerised for deployment, running four logical concerns:

1. Ingestion — receives agent telemetry and normalises it into a common event shape
2. Policy engine — evaluates normalised events against administrator-defined rules and decides what constitutes an alert, at what severity
3. Asynchronous execution — queued background work for scans, scheduled repository sweeps, and report generation, so long-running jobs never block the live event path
4. API surface — a request/response interface for the console and a streaming channel for live updates

Persistence is split by access pattern: structured operational state (devices, policies, alerts, audit records) in a relational store, and high-volume event history in a search-optimised store built for retention and query at scale. Splitting these was a deliberate decision — one store optimised for both is a store that is good at neither.

Authorisation, session handling, and audit are enforced at the server boundary, on every action, not inside individual features.

The privacy model is also enforced here, in code. An allow-list ingestion model means the server persists only the fields policy explicitly permits. Anything an agent sends that is not on the allow-list is discarded before it reaches storage. The server never trusts agent-supplied schema — so even a compromised agent cannot widen what the platform collects. Data minimisation is a code path, not a policy document.

Tier 3 — Console Layer

A single-page browser application served behind a reverse proxy, updating live over a streaming connection rather than polling. It presents severity-ranked alerts with an acknowledge and resolve workflow, device inventory and live status, findings, and one-click response actions — each gated by role and each written to the audit log.

                    SENTINEL — HIGH-LEVEL DATA FLOW

  ┌──────────────────────┐  events ▸   ┌─────────────────────┐  live ▸  ┌──────────────────┐
  │      ENDPOINTS       │────────────▸│  SELF-HOSTED SERVER │─────────▸│  SECURITY TEAM   │
  │                      │             │       (LAN)         │          │                  │
  │  Windows·macOS·Linux │             │  ingest →           │          │  SOC console     │
  │  single agent        │◂────────────│  normalise →        │          │  alerts, devices │
  │  codebase            │  commands + │  policy engine →    │          │  findings,       │
  │                      │  signed     │  alert              │          │  one-click       │
  │                      │  updates    │                     │          │  response        │
  └──────────────────────┘             │  operational store  │          └──────────────────┘
                                       │  + event store      │
   short-interval outbound             └─────────────────────┘
   heartbeat, no inbound listener

Why this shape

Capabilities Delivered

Monitor — Visibility

• File integrity monitoring — real-time alerts on create / edit / delete of secrets and sensitive documents inside watched folders
• USB activity — drive attach plus mass-copy detection, with folder copies and loose files flagged as separate event classes
• Device status — online / idle / uptime, agent version, top applications, streamed live
• Path management — admin-defined watch folders applied at three levels (global → group → device) plus keyword auto-discovery, pushed to agents with no reinstall required

Detect — Threats & Leakage

• Data-loss / egress DLP — flags a registered secret leaving a machine, identified by salted fingerprint and destination only. The platform can prove that secret #47 left device #12 for destination X without ever storing secret #47.
• Malware / threat scan — one-click Quick Scan dispatched to the native engine per OS
• Repository secret scanning — organisation repositories, employee public accounts, and a push webhook for real-time detection, combining entropy-based and rule-based scanning so neither high-entropy blobs nor known credential formats are missed
• Config & rootkit checks — security posture assessment and anomaly detection against benchmark policy

Respond — Act on Risk

• Remote device lock — admin-only, always audited, locks the live session
• Rule-driven controls — USB block and session suspend, triggered by policy rather than by a human deciding case-by-case
• Alerts & notify — severity-ranked with acknowledge / resolve workflow, delivered to email and Slack
• Reports — scheduled PDF / CSV summaries to the security inbox

Manage — Govern & Trust

• Role-based access — custom roles with granular permissions on every action
• Append-only audit — every admin action and every response recorded, immutably
• Signed auto-update — agents update themselves, verified, no manual reinstall across the fleet
• Privacy by design — no keylogging, no personal-account scraping, metadata only

Design Decisions That Mattered

Lifecycle — Enroll, Detect, Respond

01 · Enroll — install from the portal. One command with a single-use key; the device exchanges it for its own token. Reinstalls keep the same identity.

02 · Detect — endpoints emit FIM / USB / egress events. The server retains only allow-listed metadata, then the policy engine decides what constitutes an alert.

03 · Respond — an admin locks or scans a device. The command executes on the next heartbeat and is written to the audit log.

Engineering Outcomes

Security Posture of the Platform Itself

A security platform is a high-value target. Controls applied to SENTINEL itself:

• Data minimisation — metadata and hashes only, enforced server-side
• Access control — token-based sessions, policy-driven role-based access control, single-use enrolment keys exchanged for per-device tokens
• Integrity — cryptographically signed updates; append-only audit of every action
• Scope & ethics — company devices only; no keylogging; no personal-account scraping. The boundary is documented and enforced technically.

Testing & Verification

• ~260 automated tests covering agent, API, policy engine, and RBAC paths
• Cross-platform agent verification on Windows, macOS, and Linux
• End-to-end validation: event emitted on endpoint → alert visible in console under 60 seconds
• Response-path validation: command issued → executed on next heartbeat → present in audit log
• Negative testing: unsigned update package rejected by agent; non-allow-listed field dropped at ingestion
• RBAC verification: every response action denied to roles without explicit permission

Challenges & Solutions

Roadmap

Hardening — transport security at scale. mTLS for agents and public HTTPS with managed or internal-CA certificates, removing the per-machine trust step for internet-facing deployment.

Scale — reliability & HA. Fleet-wide macOS/Linux verification, container health checks, data-retention lifecycle, and the preserved horizontal-scale path for high availability.

Detection — deeper coverage. Process and behavioural analytics, network-egress inspection, and policy-gated clipboard / print DLP — beyond files and USB.

Integrate — fits the SOC. SIEM and webhook export, ticketing hooks, SSO, and admin-tunable discovery keywords with per-group defaults.