Endpoint telemetry, detection, and controlled response — end to end.

Panopticon is a security-focused, multi-repository EDR/XDR capstone and research platform. Endpoint agents on Windows and Linux collect real host telemetry, a rule-, correlation- and behavior-based detection engine turns it into alerts and incidents, and — only where an analyst or a narrow auto-safe policy allows it — the Manager authorizes and dispatches one of a closed set of typed response actions back to the originating endpoint, with full lifecycle tracking and audit.

This is a capstone/research project, not a commercial product. Maturity varies by repository, and every repository's README states its own validated scope and known limitations rather than hiding them.

Project site: panopticon-co.github.io — architecture, components, all 22 diagrams and team statistics in one place.

_{Panopticon Console in Manager mode — pipeline counters, alert severities and the live alert feed (lab data).}

flowchart LR
    subgraph Endpoints
        W["Windows agent<br/>(Officer)"]
        L["Linux sensor<br/>(panopticon-sensord)"]
    end
    subgraph Manager["Manager control plane"]
        API["Ingest / command API"]
        DB[("SQLite WAL<br/>events · alerts · commands")]
        DE["Detection engine<br/>(eyedetect)"]
        RE["Response engine<br/>7 actions · 2 tiers"]
    end
    C["Console"]
    A(["SOC analyst"])

    W -- "HTTPS telemetry" --> API
    L -- "HTTPS telemetry" --> API
    API --> DB --> DE
    DE -- "alert + recommendation" --> RE
    RE -- "pending action" --> DB
    C -- "query / decision proxy" --> API
    A --- C
    API -. "typed command (after authorization)" .-> W
    API -. "typed command (after authorization)" .-> L

_{Figure 1 — Running components and trust boundaries: endpoints, the Manager control plane, and the console. Source: panopticon-diagrams.}

Detection and execution are deliberately separate. The detection engine and the response engine only ever produce recommendations and typed commands — neither calls subprocess, os.kill or any OS API. Only the endpoint agents execute anything, and only after Manager authorization.

_{Figure 2 — Ingest is acknowledged once committed; detection runs asynchronously; a destructive action waits for analyst authorization before the endpoint polls for it.}

Figure 3 — Level-1 data flow across the Manager's stores.

Figure 4 — One obfuscated PowerShell launch, followed end to end.

_{Incident investigation in the console: stage timeline, process lineage, causal path and an explained score (lab data).}

• A closed response vocabulary. KILL_PROCESS, COLLECT_PROCESS_INFO, COLLECT_NETWORK_CONNECTIONS, COLLECT_FILE, QUARANTINE_FILE, ISOLATE_HOST, RELEASE_HOST_ISOLATION — there is no path to arbitrary remote execution.
• Two authorization tiers. Only COLLECT_PROCESS_INFO and COLLECT_NETWORK_CONNECTIONS may run automatically; every other action, including file collection, requires explicit analyst approval.
• PID-reuse protection. Process-targeted actions carry the process start time (and, on Windows, the boot binding) so an action can never land on a recycled PID.
• Signed commands and evidence. The Linux sensor executes only Manager-signed (ES256) commands; evidence is signed with endpoint-enrolled keys and verified on every retrieval; and a SHA-256 hash-chained audit trail records who requested, approved, dispatched and viewed what.
• Versioned wire contracts. Every producer and consumer is checked against the golden fixtures in panopticon-contracts.

Shreyas Tekawade

Aryan Sokhi

Aditya Singh

Rishi Bose

pie showData
    title Commits by member (default branches)
    "Shreyas Tekawade" : 377
    "Aryan Sokhi" : 230
    "Aditya Singh" : 37
    "Rishi Bose" : 3
    "Other identities" : 27

Commits per repository

• Windows — endpoint agent with documented x64 and ARM64 builds.
• Linux — sensor validated on Ubuntu 22.04, kernel 5.15, x86_64.
• Backend and console — platform-independent Python.

macOS and mobile endpoints are not supported and are not currently planned.

The project follows a vertical-slice-first roadmap: telemetry → detection → alert was built and validated first, then response authorization and execution, then broader telemetry and response depth. For the precise, evidence-backed status of each component, start with:

• Windows agent — capability matrix
• Linux agent — handoff and validation status
• Manager — response engine state
• Contracts — cross-repository compatibility matrix

Each repository has its own CONTRIBUTING.md for its toolchain (CMake/vcpkg for the C++ agents, pytest for the Python services). Keep changes focused, add or update tests, and call out any cross-repository contract impact in the pull request.

Please do not open a public issue for a suspected vulnerability. Each repository's SECURITY.md explains how to report privately through GitHub Security Advisories. This is a capstone/research project maintained on a best-effort basis, with no formal response SLA.

All Panopticon-Co repositories are licensed under the MIT License unless a repository's own LICENSE file states otherwise.

Panopticon is a capstone and research project. It is not a certified, audited or commercially supported security product, and no claims of production-readiness, compliance or formal security certification are made.