Platform Structure

Looking for a product overview? See What is Kronyx? on the home page. This documentation covers how the platform is organised and how to use each module.

Kronyx is organised into three top-level components accessible from the dashboard sidebar: EDR, Network, and Pentesting. Each component contains dedicated modules grouped by function.

EDR

Detection & Response
• Devices
• Autoruns
• Binaries
• Collected Files
Management
• Escalations
• Investigations
• Reports
Security & Access
• Teams

Network

Discovery & Analysis
• Network Discovery
• Traffic Analysis
• Network Topology
Security
• WiFi Security
• Port Services
• Threat Detection
Monitoring
• Bandwidth Usage

Pentesting

Targets & Scanning
• Targets (Domains & Servers)
• Scan Types
• Full Scan & Scheduling
Results & Access
• Findings & CVSS
• PDF Reports
• SARIF / Slack Export
• Server Terminal

Admin Setup Guide

Everything you need to set up Kronyx for your organisation from scratch. Estimated time: 20–30 minutes.

Step 1 — Log In & Verify

Open the Kronyx dashboard and sign in with your credentials. If two-factor authentication is enabled, enter the 6-digit code from your authenticator app.

Step 2 — Invite Your Team

Go to Teams in the sidebar and click Invite Member. Select a role that matches each person's responsibilities. Kronyx ships with ten predefined security roles — assign the one that most closely matches the analyst's day-to-day work:

Role	Typical Responsibilities
Administrator	Full platform access — manages users, settings, and all data
SOC Lead	Team oversight, escalation management, investigation review
Senior Analyst	Full investigation and incident response capabilities
Security Analyst	Alert triage, investigations, and daily monitoring
Tier 1 Analyst	First-line alert triage — escalates to senior analysts
Incident Responder	Active incident handling, containment, and evidence collection
Threat Hunter	Proactive research and hypothesis-driven hunt campaigns
Network Engineer	Network discovery, topology, and traffic analysis
Compliance Officer	Audit trail and compliance reports — read-only on investigations
Read-Only	View-only access across all platform modules

If none of the predefined roles fits, go to the Roles tab on the Teams page and click Create Role to define a custom role with its own name and description.

Start with one or two analysts before inviting the full team. It is easier to validate permissions and test the workflow before rolling out access to everyone.

Step 3 — Enroll Your First Device

Go to EDR → Detection & Response → Devices and click Add Device.

Select the operating system (Windows, macOS, or Linux)
Click Generate Installer — the file downloads automatically
Copy the installer to the target machine and run it as Administrator
The device appears in the Devices list within 1–2 minutes with a Connected status

The agent runs as a background service and sends heartbeat data every 30 seconds.

Step 4 — Configure Escalation Rules

Go to EDR → Management → Escalations and click New Rule. Recommended starting rules:

Rule	Trigger	Action
Critical Threat Alert	Severity = Critical	Notify All Admins
Malicious Binary	Binary verdict = Malicious	Create Investigation automatically
New Autorun	Any new autorun entry	Notify assigned Analyst
Unknown Network Device	Network Discovery finds new device	Notify Admin

Step 5 — Run Your First Network Scan

Go to Network → Discovery & Analysis → Network Discovery and click Start Scan. Review results for any unrecognised devices — these should be investigated immediately.

Setup Checklist

At least one device enrolled and showing as Connected
At least one team member invited
At least one escalation rule configured
Network Discovery scan completed
Network Topology map reviewed

Analyst Quickstart

Your daily workflow in Kronyx. Covers alert triage, device checks, investigation management, and network monitoring.

Daily Workflow

Check Escalations → Active Queue — acknowledge anything that fired overnight
Check Devices — confirm all endpoints are connected
Review Binaries — triage new VirusTotal alerts
Review Autoruns — check for new persistence entries
Check Network → Threat Detection — network-level IoCs
Work open Investigations — update evidence and notes
Check Network Discovery — spot unauthorised devices

Responding to a Threat

Step	Action
1. Assess	Note the severity, affected device, and what was detected
2. Gather context	Check Devices, Autoruns, and Binaries for the same endpoint
3. Correlate	Check Traffic Analysis for unusual outbound connections from that device
4. Open investigation	Create an Investigation, link all related evidence, assign an investigator
5. Escalate if needed	Trigger escalation rules or notify your team directly
6. Document & close	Add resolution notes, update status to Resolved

Severity Reference

Level	Meaning	Action
Critical	Active, confirmed threat	Respond immediately, escalate
High	Strong indicator of compromise	Investigate within the hour
Medium	Suspicious behaviour requiring review	Investigate within the day
Low	Informational, low risk	Review during routine checks

EDR — Detection & Response

Devices

The central registry of all endpoints enrolled in Kronyx. Each device runs a lightweight agent that continuously reports health and security telemetry.

Navigate to EDR → Detection & Response → Devices. The device list shows every enrolled endpoint with its current status, OS, last heartbeat timestamp, and live resource metrics.

Status	Meaning
Connected	Agent active and reporting normally
Warning	Connected but reporting elevated resource usage
Disconnected	No heartbeat received — investigate

Adding a Device

Click Add Device
Select the target operating system
Click Generate Installer
Run the installer on the target machine — the agent registers automatically

Removing a device from the dashboard does not uninstall the agent from the endpoint. Uninstall the agent manually after removing it from the platform.

Internal Network Scan

This is Kronyx's internal pentest capability — since the agent already runs inside your network, it's a real internal vantage point, not a separate on-prem appliance. Click Internal Scan on a connected device to sweep that device's local subnet for live hosts, then port-scan each one found for the same high-risk services (Telnet, SMB, exposed databases, and similar) Kronyx already checks for externally.

Results appear in Pentesting → Findings alongside every other scan type, not on the Devices page itself — the same unified Findings pipeline domains, servers, and repositories already feed.

Windows and Linux only for now — the macOS agent doesn't yet support remote-dispatched commands of any kind, internal scanning included.

Autoruns

Monitors persistence mechanisms on enrolled endpoints — the locations where malicious software installs itself to survive reboots.

Navigate to EDR → Detection & Response → Autoruns. Kronyx tracks autorun entries across Windows registry run keys, startup folders, scheduled tasks, Windows services, macOS login items, LaunchAgents/Daemons, and Linux systemd services and cron jobs.

Status	Meaning
New	Entry appeared since the last scan — requires review
Existing	Known, previously reviewed entry
Suspicious	Characteristics common in malware (unusual path, obfuscated command)
Malicious	Confirmed malicious based on hash or behavioral analysis

High-Risk Patterns

Entries pointing to files in %TEMP%, %APPDATA%, or C:\Users\Public
Entries using encoded or obfuscated PowerShell commands
Entries with randomised or meaningless names
Multiple new entries appearing on the same device simultaneously

Binaries

Analyses executables discovered on managed endpoints and checks them against VirusTotal to identify malicious or suspicious files.

Navigate to EDR → Detection & Response → Binaries. Each binary entry shows the file name, path, SHA256 hash, VirusTotal score, and the device it was found on.

Verdict	Description	Recommended Action
Clean	No vendors flagged this file	No action required
Suspicious	1–5 vendors flagged the file	Review context; investigate if in unusual location
Malicious	6+ vendors flagged the file	Treat as confirmed threat; open investigation immediately
Unknown	File not in VirusTotal database	Manually review — unknown does not mean safe

Unsigned binaries are flagged automatically. Unsigned does not automatically mean malicious — use the path, location, and VirusTotal verdict together to make a judgement.

Collected Files

A centralised repository of files pulled from managed endpoints for analysis or evidence preservation.

Navigate to EDR → Detection & Response → Collected Files. Every collected file has MD5, SHA1, and SHA256 hashes recorded at the moment of collection — these serve as the integrity record.

Collecting a File

From the Device detail view, browse the endpoint file system and click Collect File. The file appears in Collected Files once collection is complete. You can then link it to any open investigation.

EDR — Management

Escalations

Escalations are the platform's safety net — automated rules that ensure no serious incident is silently ignored. When an incident matches a rule's conditions, it is pushed into a visible queue that requires an analyst to explicitly acknowledge it.

What is an Escalation?

An escalation is a formal record created by the system when an open incident meets the conditions of one of your rules. Think of it as the platform raising its hand and saying: "This incident has not been dealt with — someone needs to take ownership of it right now."

Without escalations, a Critical incident could sit open in the list for hours with no one noticing. Escalation rules enforce your team's SLAs by making inaction visible: every escalation in the queue represents an incident that needs immediate attention and has not yet been claimed.

Escalations complement incidents — they do not replace them. An incident is the record of what happened. An escalation is the alarm that fires when the incident isn't being acted on fast enough.

The Escalation Lifecycle

Stage	What it means	Who acts
Incident opens	A security event is detected and an incident record is created	System / Kronyx AI / Analyst
Rule evaluates	The system checks whether the incident matches any active escalation rule — immediately on creation or after a configured delay	Automated
Escalation created	The incident enters the Active Queue with a pulsing severity indicator. The assigned analyst (or all analysts) receives a notification	Automated
Acknowledge	An analyst clicks Acknowledge — this means they have seen it and taken ownership. The escalation leaves the queue	Analyst
Resolved	The underlying incident is investigated and closed. The escalation is marked resolved	Analyst

Acknowledging an escalation does not close the incident. It only confirms that a human is now aware and responsible. You must still investigate and resolve the incident separately.

The Active Queue

Navigate to EDR → Management → Escalations to see the Active Queue. Each card shows:

Field	What it tells you
Escalation ID	Unique reference — use this when discussing the escalation with your team
Severity	Inherited from the incident — Critical, High, Medium, or Low
Incident #	The linked incident record. Click it to open the full incident detail
Reason	The human-readable explanation of why the rule fired — e.g. "Critical incident open for more than 1 hour"
Time ago	How long the escalation has been sitting unacknowledged in the queue

Items are sorted by severity — Critical escalations always appear first. The queue refreshes automatically every 30 seconds. If you see the count climbing, it means incidents are being created faster than they are being acknowledged.

Escalation Rules

Navigate to the Rules tab on the Escalations page. Rules are the conditions that decide when an escalation is created. Each rule has two parts:

Part	What it controls
Trigger Severity	Which incident severity levels this rule applies to. You can select multiple. A rule set to "Critical + High" will fire for both.
Trigger After (hours)	How long the incident must be open before the rule fires. Set to 0 to escalate the moment an incident of that severity is created. Set to 1 to give analysts one hour to pick it up before escalating.

Rules can be toggled on or off without deleting them. Disabled rules are shown in a separate section — this lets you keep rules that are only relevant during specific periods (e.g. out-of-hours coverage rules).

Writing Effective Rules

A good escalation rule answers one question: "What situation would make my team uncomfortable if it were missed for this long?" Use the following starting templates and adjust the timing to match your team's capacity:

Rule name	Severity	Trigger after	Purpose
Immediate Critical Response	Critical	0 hours	Any Critical incident triggers an escalation the moment it is created — no grace period
High Priority SLA	High	1 hour	High severity incidents that have not been claimed within one hour are escalated
Medium Backlog Check	Medium	4 hours	Prevents Medium incidents from sitting unworked during busy periods
End-of-Day Sweep	Critical, High, Medium	8 hours	Catch anything that slipped through a full work day without being addressed
After-Hours Critical	Critical	0.5 hours	For out-of-hours coverage — escalate Critical incidents after 30 minutes if on-call has not responded

Start with two rules: one for Critical at 0 hours (immediate) and one for High at 1 hour. Add Medium and Low rules once you understand your team's average response time — otherwise the queue will fill with noise.

BluAI and Automated Escalations

BluAI — the platform's AI security analyst — can create escalations directly when it detects a high or critical threat on an enrolled device. These appear in the Active Queue like any other escalation, labelled with the source AI Detection. BluAI also posts a message to the #alerts channel in Team Messages so the entire SOC is notified immediately, not just the device owner.

You can identify AI-generated escalations by the incident title prefix "AI Detection:" and by the Source field in the incident record showing ai_analysis.

Analyst Responsibilities

When you acknowledge an escalation you are making a commitment: you have seen this incident and you are taking responsibility for it. The platform records who acknowledged it and at what time — this feeds the Avg Response Time metric, which leadership uses to assess SOC performance.

Do	Do not
Acknowledge escalations you are actively working	Acknowledge and then walk away — acknowledgement means ownership
Open the linked incident immediately after acknowledging	Acknowledge on behalf of another analyst without telling them
Add a note to the incident explaining your initial assessment	Let escalations sit in the queue because the incident looks low-risk — if you disagree with the rule, disable it
Escalate to your SOC Lead if the incident is beyond your scope	Create duplicate escalations by triggering the same rule multiple times

Investigations

A structured workspace to document and track the full lifecycle of a security event from detection through containment and resolution.

Navigate to EDR → Management → Investigations and click New Investigation. Fill in a title, severity, description, and assign an investigator.

Investigation Statuses

Status	Meaning
Open	Newly created, not yet actively worked
In Progress	Actively being investigated
Resolved	Threat contained and documented

Link all related evidence to the investigation — binaries, autoruns, collected files, and network threats. The timeline is shared with your team and every change is automatically logged.

Reports

Generate summaries of security activity for management review, compliance audits, or team retrospectives.

Navigate to EDR → Management → Reports and click New Report. Select a report type, set the date range, and optionally filter by device, severity, or investigator.

Report Type	Contents
Security Posture Summary	Device health, alert counts, open investigations
Threat Activity Report	All detections within a time period
Investigation Summary	All investigations and resolution status
Device Health Report	Per-device metrics and connectivity status

EDR — Security & Access

Teams

Manage user accounts, roles, and access within your Kronyx organisation.

Navigate to EDR → Security & Access → Teams. From here you can invite members, change roles, and deactivate accounts.

Permission	Admin	Analyst	Viewer
View all modules	✓	✓	✓
Create/edit investigations	✓	✓	—
Create/edit escalation rules	✓	—	—
Generate reports	✓	✓	—
Download agent installers	✓	✓	—
Invite / remove team members	✓	—	—
Change user roles	✓	—	—

Deactivating a user immediately revokes their access. Their historical data (investigation notes, reports) is preserved and can be reviewed at any time.

Network — Discovery & Analysis

Network Discovery

Scans your local network to discover all connected devices and build a live asset inventory.

Navigate to Network → Discovery & Analysis → Network Discovery and click Start Scan. Results populate in real time as devices respond. New devices are highlighted — review them to confirm they belong on your network.

Any device that appears in scan results and is not in your known asset list should be investigated. Common causes include new approved devices, unauthorised personal devices, or rogue hardware placed by a threat actor.

Traffic Analysis

Monitors network traffic flowing through your environment and identifies anomalous patterns at the flow level.

Navigate to Network → Discovery & Analysis → Traffic Analysis. The dashboard shows live connection data, top talkers, protocol breakdown, and a historical bandwidth timeline.

Anomalous Traffic Patterns

Large outbound data transfers to unknown external IPs — possible exfiltration
DNS queries with very large payloads — possible DNS tunnelling
High-frequency short connections — possible C2 beaconing
RDP or SMB connections to unexpected internal devices — possible lateral movement

Network Topology

A visual map of how devices on your network are connected and related to each other.

Navigate to Network → Discovery & Analysis → Network Topology. Nodes represent devices; edges represent observed connections. Node colour indicates risk status — grey (normal), amber (warning), red (active threat).

Kronyx tracks your topology over time. When the map changes — a new device appears or a new connection is established — the change is logged and can trigger an escalation rule.

Network — Security

WiFi Security

Scans for wireless networks in range and assesses their security posture.

Navigate to Network → Security → WiFi Security. Each detected network is assessed and assigned a risk level.

Risk	Criteria
Safe	WPA2 or WPA3 encryption, SSID matches known corporate networks
Warning	WPA (original), hidden SSID, or unknown network near corporate premises
Danger	Open (no encryption), WEP encryption, or BSSID spoofing a known corporate network

A rogue AP is an unauthorised wireless access point connected to your network. Watch for SSIDs resembling your corporate network with a different BSSID, or open networks appearing near your premises.

Port Services

Scans hosts on your network for open ports and identifies what services are running.

Navigate to Network → Security → Port Services. Enter a target IP, hostname, or range, select scan type, and click Start Scan.

Scan Type	Scope
Quick	Top 100 most common ports
Standard	Top 1,000 ports
Full	All 65,535 ports (slower)

High-Risk Ports

Port	Service	Why it is risky
22	SSH	Remote access — should not be exposed to the internet
23	Telnet	Unencrypted remote access — should never be open
3389	RDP	Remote desktop — commonly exploited
445	SMB	Common ransomware propagation vector
1433	MSSQL	Database — should never be internet-facing
5900	VNC	Remote access — unencrypted by default

Threat Detection

Analyses network traffic behaviour in real time to identify indicators of compromise and active threats.

Navigate to Network → Security → Threat Detection. The live feed shows alerts classified by type and severity.

Category	Description
C2 Communication	Traffic patterns consistent with command-and-control beaconing
Data Exfiltration	Large or unusual outbound data transfers
Lateral Movement	Internal connections consistent with an attacker moving through the network
Port Scanning	A device scanning many ports on other hosts
DNS Anomaly	Unusual DNS query patterns (high volume, large payloads, unknown resolvers)
Brute Force	Repeated authentication attempts against a service
Known Malicious IP	Connection to or from an IP on a threat intelligence blocklist

Network — Monitoring

Bandwidth Usage

Tracks network bandwidth consumption per device and across the network, supporting both operational visibility and anomaly detection.

Navigate to Network → Monitoring → Bandwidth Usage. The dashboard shows total network throughput, top consumers, a historical chart, and a per-device breakdown.

Status	Meaning
Normal	Bandwidth within expected range for this device
High	Sustained usage above the device historical baseline
Spike	A sudden, brief surge in bandwidth usage

After 7 days of monitoring, the status column becomes more accurate as Kronyx builds a baseline for each device. Sustained high outbound from a workstation is a common early indicator of data exfiltration.

Pentesting — Targets & Scanning

Overview

Pentesting is Kronyx's core capability — the module that turns everything else the platform collects into an active, adversarial test. Instead of only watching for threats, Kronyx actively tests your own domains and servers using the same categories of checks a real attacker or professional penetration tester would run, and turns every result into a tracked Finding with a severity, a real CVE/CVSS score where one genuinely applies, and remediation guidance.

EDR and Network give you visibility into what's running and what's connected. Pentesting tells you what's actually exploitable — the difference between passive monitoring and a verified, fixable security posture. If you're new to Kronyx, start here.

Navigate to Pentesting in the sidebar. There are two tabs: Targets (register and manage what you scan) and Findings (everything discovered across every target, filterable and exportable).

Active scans send real requests to the target. Only add domains and servers you own or are explicitly authorised to test.

Targets (Domains, Servers & Repositories)

A target is anything Kronyx will run scans against — a domain/web application, a server reachable over SSH, or a git repository. Add one from Pentesting → Targets → Add Target.

Adding a Domain

Click Add Target → Domain... and enter the domain. Kronyx generates a unique DNS TXT record you must add before any active scan can run — this proves you control the domain.

Field	Value
Record Type	`TXT`
Value	`kronyx-verify=<your unique token>`

DNS changes can take a few minutes to propagate. Once the record is live, click Verify — Kronyx checks the record over live DNS. You can retry verification any time; the record and instructions stay available on the target.

Ownership verification only gates active scans (Nuclei, port scan, TLS/SSL audit, API fuzz). Four passive recon scans — subdomain discovery via certificate transparency, GitHub code-leak search, related-domain discovery, and a CIDR net scan — are available immediately, before verification.

Adding a Server

Click Add Target → Server (SSH)... and provide connection details.

Field	Notes
Label	A friendly name, e.g. "prod-web-1"
Host / IP	The server's address
Port	Defaults to 22
Username	The SSH login user
Auth method	Private key (with optional passphrase) or password — both supported

Kronyx attempts a real SSH connection immediately with the credentials you provide. A successful connection marks the server Verified — there is no separate ownership-proof step like DNS, since a working SSH login already proves access. Credentials are encrypted at rest before being stored.

Adding a Repository

Click Add Target → Repository... and provide the clone URL and, for a private repository, an access token.

Field	Notes
Label	A friendly name, e.g. "kronyx-backend"
Clone URL	An https:// git URL
Access token	Optional — leave blank for a genuinely public repository

Kronyx attempts a real connection immediately (a lightweight git ls-remote, no full clone). A successful connection marks the repository Verified — the same reasoning as servers: working access already proves authorization, no separate ownership challenge is needed. The access token is encrypted at rest before being stored.

Unlike domains, every scan type on a repository needs real repository content — there's no passive-OSINT-only category here — so verification gates all of secrets, SAST, and dependency scanning, not just a subset.

Verification Status

Status	Meaning
unverified	Not yet confirmed — active scans and scheduling are locked
verified	Confirmed — DNS TXT record found (domains), SSH login succeeded (servers), git connection succeeded (repositories), or AWS STS call succeeded (cloud accounts). Scanning unlocked
failed	Last verification attempt did not succeed — check the DNS record, SSH credentials, repository access, or AWS credentials and retry

Scan Types

Every verified target can run four active scan types, each mapping to a real, industry-standard tool — not a simulation.

Scan	Tool	What it finds
Nuclei (active scan)	ProjectDiscovery Nuclei	Known CVEs and misconfigurations, matched against a large community template library
Port scan (active)	Kronyx port scanner (nmap-based)	Open ports and the service on each — flags high-risk ports like SSH, RDP, SMB, Telnet
TLS/SSL audit (active)	testssl.sh	Weak ciphers, protocol downgrade issues, certificate problems, and specific named vulnerabilities (e.g. SWEET32, LUCKY13, BEAST, BREACH)
API fuzz (active)	Schemathesis	Auto-discovers an OpenAPI/Swagger spec on the target and property-tests every documented endpoint for server errors, auth bypass, and schema violations

API fuzz sends real state-changing requests (POST/PUT/DELETE with fuzzed data) to whatever the target's API spec documents — it can create or modify real data. It is rate-limited and capped per run, but only enable it against targets where that's acceptable. This is also why API fuzz is excluded from scheduled/automatic scanning by default.

Domains additionally offer five passive recon scans that don't require verification: Cert (subdomain discovery via certificate transparency logs), Subdomains (broader passive subdomain discovery via subfinder — DNS aggregators and search engines, not just certificate logs), Net (CIDR range scan), Related domains, and GitHub (code-leak search).

Launch scans from a target's Run Scans button, which opens a dialog with one button per scan type plus a job history table (status, result count, timestamp).

Nmap and Masscan are real tools the platform uses, but they aren't Run Scans buttons — they're only reachable hands-on, from the Sandbox Terminal below.

Repository Scan Types

Connected repositories offer three scan types of their own, launched the same way — a target's Run Scans button.

Scan	Tool	What it finds
Secrets	gitleaks	Committed credentials and API keys — scans the repository's full git history, not just the current files, since a secret committed once and force-pushed over is still a real historical leak
SAST	semgrep	Real code-level vulnerabilities (command injection, insecure defaults, and more) via community-maintained rulesets
Dependencies	osv-scanner	Known-vulnerable packages in the repository's manifests/lockfiles, matched against the OSV database

Each scan clones the repository fresh and discards the checkout afterward — nothing from your source code is retained beyond the scan results themselves.

Adding a Cloud Account

Click Add Target → Cloud Account (AWS)... and provide an AWS access key pair. Create a dedicated IAM user for Kronyx first and attach AWS's own managed SecurityAudit policy — a broad read-only policy purpose-built for exactly this kind of posture scanning.

Field	Notes
Label	A friendly name, e.g. "prod-aws"
Access key ID / Secret access key	The IAM user's key pair
Region	Defaults to us-east-1 — used for the initial verification call, not a scan-scope limit (IAM/S3 checks are global; EC2/etc. checks cover all regions automatically)

Kronyx attempts a real, read-only AWS STS GetCallerIdentity call immediately. A successful call marks the account Verified and records the AWS account ID — the same reasoning as servers and repositories: a working, authenticated connection already proves the credentials are valid, no separate challenge is needed. The secret access key is encrypted at rest before being stored and is never displayed again after entry.

Kronyx currently connects via a long-lived IAM access-key pair rather than a cross-account IAM role — use a dedicated, least-privilege IAM user for this (SecurityAudit only) rather than reusing broader credentials, and rotate the key periodically.

Cloud Scan Types

Connected cloud accounts offer one scan type, launched the same way — a target's Run Scans button.

Scan	Tool	What it finds
Posture Scan	Prowler	Cloud misconfigurations — publicly accessible S3 buckets, wide-open security groups, missing root account MFA, and over-privileged IAM policies/roles/users

Findings carry compliance framework mappings straight from Prowler's own checks (CIS, PCI-DSS, SOC2, HIPAA, and more) in their evidence, giving every posture finding a ready-made audit trail.

The initial scan scope is deliberately focused on the highest-signal categories above rather than Prowler's full check catalog (hundreds of checks across every AWS service) — broader coverage is a planned follow-on once this first pass is proven out against real accounts.

Adding a Network

Click Add Target → Network (IP/CIDR)... and provide an IP or CIDR range you own — e.g. 203.0.113.0/24 or a single host as 203.0.113.5/32.

Unlike domains (DNS), servers (SSH), and repositories (git access), a bare IP range has no direct "prove you control this" mechanism, so Kronyx instead looks up the range's real, live RDAP registration (the modern, JSON-based successor to WHOIS) and checks whether the registrant or a contact email's domain matches your organization's name or one of your already-verified domains.

This is a best-effort match. RDAP records for cloud/hosting-provider IP space often name the hosting provider, not the actual tenant — if verification fails, the error shows exactly what RDAP reported so you can tell whether it's a genuine mismatch or your range is registered under a different legal entity name. Private, loopback, and other non-public ranges are rejected outright (they have no public RDAP record) — use the EDR agent's Internal Network Scan for internal ranges instead.

Networks have no automated scan type or Run Scans button — verifying one only adds its range to the Sandbox Terminal's egress allowlist. nmap and masscan are the only tools that make sense against a raw CIDR, and (matching the platform's existing policy for those two tools against every other asset type) they're hands-on-only. See the Sandbox Terminal section below.

Full Scan & Scheduling

Instead of clicking each scan type separately, Run Full Scan launches all four active scans for a target in one click.

Open Run Scans on a verified target and click Run Full Scan (all active scans) — Nuclei, port scan, TLS/SSL audit, and API fuzz are all queued at once. Track progress in the job history table below it; it auto-refreshes every 10 seconds while any job is pending or running.

Scheduled / Automatic Scanning

Toggle Automatically re-scan on the same dialog and set an interval in hours (1–720) to have Kronyx re-run scans on its own, without you clicking anything.

Scheduled scanning always runs Nuclei, port scan, and TLS/SSL audit — never API fuzz. Unattended, repeating state-mutating traffic against an API is a bigger commitment than a one-off click, so API fuzz stays manual-only.

The dialog shows Last scheduled scan with a timestamp once at least one automatic run has completed.

Sandbox Terminal

For hands-on testers who'd rather type real commands than click buttons — the Sandbox Terminal is a real, isolated Linux shell with the platform's actual pentest tools pre-installed, opened directly from the dashboard.

This is a different feature from the Server Terminal below — that's a direct SSH session into one specific verified server. The Sandbox Terminal is a disposable environment whose network access is locked to every verified target in your organisation at once, for running tools by hand.

Opening a Session

Go to Pentesting → Targets and click Open Sandbox Terminal. This requires at least one verified domain, server, or network — an empty allowlist would boot a shell with no reachable targets at all, so Kronyx refuses to open one rather than hand you a useless session.

Limit	Value
Idle timeout	10 minutes of inactivity
Hard cap	60 minutes, regardless of activity

What's Installed

Tool	Command	Used for
Nmap	`nmap`	Port/service scanning, OS detection, NSE vulnerability scripts
Masscan	`masscan`	High-speed port scanning across large ranges
Subfinder	`subfinder`	Passive subdomain enumeration — the same engine behind the Subdomains scan button
Nuclei	`nuclei`	Template-based vulnerability scanning — the same engine behind the Nuclei scan button
testssl.sh	`testssl.sh`	TLS/SSL configuration and vulnerability auditing
metabigor	`metabigor`	OSINT recon — the same engine behind Cert, Net, Related, and GitHub
Schemathesis	`st`	OpenAPI/Swagger fuzzing — the same engine behind API fuzz
Standard utilities	`curl, dig, whois, jq, openssl`	General reconnaissance and scripting

subfinder, amass, trufflehog, and gitleaks are not installed — if a guide elsewhere references them, they won't work here.

Network Access

A default-deny firewall restricts all outbound traffic to your organisation's verified targets' resolved IP addresses, plus DNS — re-resolved every 60 seconds so a target's IP can change without breaking the session.

This restriction is IP-based, not hostname-based, so it doesn't defend against a DNS-tunnelled exfiltration attempt through an allowlisted domain's own resolver, or against a verified target that happens to share an IP with unrelated sites behind a CDN. It scopes the shell to your own declared targets — it is not a general-purpose, multi-tenant isolation boundary.

Running Commands

The scan-mode buttons above the terminal fire the exact same tracked scan jobs the dashboard's Run Scans dialogs use — their results become real Findings. Typing a command directly into the shell only prints to that terminal; it doesn't create a Finding or appear anywhere else in Kronyx. Use the buttons when you want a result tracked, and the shell when you want to explore, learn, or run something custom.

Replace target.com below with one of your own verified targets.

# Cert — subdomains via certificate transparency

echo target.com | metabigor cert --json --clean

# Net — CIDR ranges (not written to Findings even via the buttons — too high-volume; check scan-job history instead)

echo target.com | metabigor net --domain --json

# Related domains (--json doesn't reliably emit JSON in the current version — expect plain text)

echo target.com | metabigor related

# GitHub — code-leak search

echo target.com | metabigor github --json

# Subdomains — passive enumeration (DNS aggregators, search engines, etc.)

subfinder -d target.com -silent -json

# Nuclei — quick mode (critical + high severity only)

nuclei -u https://target.com \

-t /opt/nuclei-templates -jsonl -silent -duc \

-timeout 10 -rate-limit 50 -severity critical,high

# TLS/SSL audit — standard mode

testssl.sh -U -S --severity LOW --quiet target.com

# Nmap — quick scan (top 100 ports)

nmap -Pn -T4 -F target.com

# Nmap — every TCP port

nmap -Pn -T4 -p- target.com

# Nmap — vulnerability scripts

nmap -Pn --script vuln -T4 --top-ports 1000 target.com

# Masscan — needs an IP, not a hostname, so resolve it first

dig +short target.com

masscan -p1-1000 --rate 1000 <resolved-ip>

# API fuzz — point Schemathesis at a discovered OpenAPI/Swagger spec

st run https://target.com/openapi.json \

--checks all --max-examples 10 --rate-limit 10/s

Port scan (the GUI button) is Kronyx's own lightweight scanner, not an installed binary — there's no raw command for it here. Use Nmap or Masscan above for hands-on port scanning.

Scanning a Verified Network Range

A verified Network has no scan-mode buttons at all — nmap and masscan both take a CIDR range natively, so there's nothing to wrap in a tracked job. Replace 203.0.113.0/24 below with your own verified range (shown in the target bar above the terminal as "Also reachable: ...").

# Discover live hosts in the range first

nmap -sn -T4 203.0.113.0/24

# Then a full port/service scan across the whole range

nmap -Pn -T4 -sV --top-ports 1000 203.0.113.0/24

# Masscan — fast sweep of an entire range

masscan -p1-1000 --rate 1000 203.0.113.0/24

As with any manually-typed command, output here doesn't become a Finding automatically — Networks have no Run Scans/Findings integration at all, by design (see the Adding a Network section above).

Kronyx logs that a sandbox session happened (duration, target count) for audit purposes, but never logs the transcript of what was typed or displayed — the same handling as the Server Terminal.

Pentesting — Results & Access

Findings & CVSS

Every scan result becomes a Finding — a single unified record type shared across domains, servers, and endpoint devices, so you review everything discovered anywhere in one place.

Navigate to Pentesting → Findings. Filter by source type (which scan/target category it came from) or status, and click any row to see full detail, including the raw evidence returned by the scanning tool.

Status	Meaning
Open	Newly discovered, not yet reviewed
Acknowledged	Seen by an analyst, not yet being worked
Remediating	A fix is in progress
Resolved	Fixed and confirmed
False Positive	Reviewed and determined not to be a real issue
Won't Fix	Accepted risk — reviewed and intentionally left as-is

CVE / CVSS Scoring

Where a finding corresponds to a real, known vulnerability, Kronyx resolves a genuine CVSS score — never a fabricated one — using three sources in order: a score already captured by an endpoint vulnerability scan (matched live against the NVD CVE database), CVSS metadata already included in a Nuclei template's own output, or — for TLS/SSL findings that reference a bare CVE ID (e.g. SWEET32, LUCKY13) — a live lookup against the NVD CVE API.

Not every finding has a CVE. Open-port and API-fuzz findings show N/A — those categories are never tracked in the CVE system, so there's nothing to look up. A bare — instead means the finding is a CVE-eligible type (TLS/SSL or vulnerability scan) where a score genuinely couldn't be resolved.

PDF Reports

Click PDF Report on the Findings tab to generate a complete, presentation-ready penetration test report — cover page, executive summary, charts, a full findings table, and remediation guidance — built entirely from your real scan results.

Section	Contents
Cover page	Kronyx branding, report scope (source/status filter applied), finding count, generation timestamp
Executive summary	Narrative summary plus a severity bar chart and a findings-by-category pie chart, generated from the actual counts — not a filled-in template
Findings table	Every finding grouped by severity (critical → info), with asset, CVE/CVSS where available, and status
Recommendations	Real, standard remediation guidance mapped to each specific check that fired, with an honest generic fallback for anything unmapped

The report respects whatever Source type and Status filters are currently set on the Findings tab — narrow to a single target or scan category before generating if you want a scoped report rather than everything.

Because CVSS resolution can require a live NVD lookup, generation can take several seconds for reports with many distinct CVEs — this is expected, not a hang.

Exporting (SARIF / Slack)

Findings can also be pushed into your existing security tooling instead of read inside Kronyx.

SARIF Export

Click Export SARIF on the Findings tab to download a SARIF 2.1.0 log of the currently filtered findings. SARIF is a standard format most security dashboards understand directly — including DefectDojo, which imports SARIF natively, so no separate DefectDojo integration is needed.

Slack Notifications

Click the Slack button to send the currently filtered findings to a Slack channel via an incoming webhook. Set the webhook URL once — it's an organisation-wide setting, shared by your whole team. Once saved, Kronyx never displays the webhook URL again, the same handling as any other secret.

This is an on-demand "send now" action, not an always-on alerting engine — use Escalations if you want automatic, rule-based notifications instead.

Server Terminal

Every verified server gets a live, real SSH terminal directly inside Kronyx — no separate SSH client needed for quick manual checks.

Open a verified server's terminal from its row in Targets. It opens as a right-side dock, consistent with the device and network recon terminals elsewhere in the platform — not a popup, so you can keep working in the rest of the dashboard while it's open.

Kronyx logs that a terminal session happened (server, host, duration) for audit purposes, but never logs the transcript of what was typed or displayed — the same as any other credential-adjacent session in the platform.

BluAI — Artificial Intelligence

What is Kronyx AI?

Kronyx AI is the platform's built-in AI security analyst — powered by Claude (Anthropic). It monitors every enrolled device continuously, learns what normal looks like, and alerts your team the moment something deviates from that baseline.

Most security platforms surface raw data and leave interpretation entirely to the analyst. Kronyx AI changes that. Instead of reading through hundreds of process names and network connections, you receive a structured threat assessment — in plain language — for every device, updated every time new telemetry arrives.

Kronyx AI operates across four integrated layers, each building on the last:

Layer	What it does	Analyst benefit
Behavioral Detection	Learns each device's normal CPU, memory, process, and network patterns. Flags statistical anomalies.	Alerts only fire when something genuinely unusual happens — not on every spike
Threat Classification	Sends suspicious activity to Claude for contextual analysis. Returns a structured verdict with confidence score.	You get a plain-English summary and recommended actions, not raw telemetry
Autonomous Response	For high/critical threats, automatically creates an incident, posts to #alerts, and notifies your team.	Threats are tracked and visible the moment they are detected, even outside office hours
AI Security Analyst	A conversational interface where analysts can ask questions about any device or investigate threats using natural language.	Junior analysts can investigate at a senior level — ask 'what's suspicious today?' and get a structured answer

Kronyx AI requires an Anthropic API key configured in the backend environment (ANTHROPIC_API_KEY). Without it the platform runs in demo mode — anomaly detection still works but the Claude classification step is skipped. All other features function normally.

Behavioral Detection Engine

Kronyx AI builds a unique baseline for every enrolled device by observing 24 hours of normal activity. Once enough data is collected it can identify when a device is behaving abnormally — even if no known malware signature is involved.

How baselines are built

Every time an agent sends a metrics heartbeat, Kronyx AI records the data and updates the device's rolling baseline. The baseline tracks:

Metric	What is measured	Anomaly threshold
CPU usage	Average and standard deviation of processor load	More than 2 standard deviations above the baseline mean
Memory usage	Average and standard deviation of RAM consumption	More than 2 standard deviations above the baseline mean
Running processes	Set of process names seen in the last 24 hours	Any process not previously observed on this device
Network connections	Set of established remote IP addresses	Any outbound connection to an IP not seen before

Baselines require a minimum of 10 data samples before anomaly detection activates. For a device reporting every 5 minutes, this takes roughly 50 minutes after first enrolment. Until then, Kronyx AI collects data silently.

Why statistical baselines matter

Signature-based detection can only catch known threats. A device running legitimate-looking processes that are subtly different from its normal pattern — a common indicator of living-off-the-land attacks — would pass signature checks entirely. Statistical baselines catch this class of threat because they ask not "is this malicious?" but "is this normal for this specific machine?"

A new process flagged on a server that runs the same 12 processes every day is far more significant than the same process appearing on a developer's workstation with hundreds of different processes. Kronyx AI accounts for this per-device context.

Threat Classification

When the behavioral detection engine flags anomalies on a device, Kronyx AI assembles a structured snapshot of the device's current state and sends it to Claude for contextual analysis. The result is a threat verdict in a consistent, actionable format.

What Kronyx AI sends to Claude

Data included	Detail
Device identity	Hostname, operating system, last-seen timestamp
Resource snapshot	Current CPU %, memory %, bytes received
Top 10 processes	Process names sorted by CPU usage — the most active processes
Top 10 connections	Established outbound connections with remote IP and process name
Security status	Windows Defender state, firewall state, threat count
Detected anomalies	The specific deviations the baseline engine flagged, including the σ score

The threat verdict

Field	Values	Meaning
Threat level	low · medium · high · critical	Overall severity of the detected activity
Confidence	0.0 – 1.0	How certain the AI is of its assessment. Below 0.6 warrants manual review.
Summary	Plain English, 1–2 sentences	What is happening and why it is concerning
Recommended actions	List of specific steps	Immediate actions the analyst or the system should take

Kronyx AI is a decision-support tool, not a replacement for analyst judgment. A high verdict with 0.55 confidence should be investigated manually before any response action is taken. Always check the underlying evidence in the device detail view.

Result caching

Analysis results are cached per device for 5 minutes. Requesting a device summary twice within that window returns the same result without a new API call. The cache is invalidated when new metrics arrive.

Autonomous Response

For high and critical threat verdicts, Kronyx AI acts without waiting for analyst input — creating incident records, notifying the team, and dispatching response commands to the affected device's agent.

What happens automatically

When Kronyx AI classifies a device as High or Critical, the following chain fires in sequence:

Incident created — a new incident record is written with source type ai_analysis, the threat summary as the description, and the device linked as the affected endpoint
Escalation rules checked — the escalation engine runs immediately. Any rule with Trigger After = 0 hours fires right away, pushing the incident into the Active Queue
Notification sent — an AI Threat notification is delivered to the device owner with a direct link to the incident
#alerts channel updated — Kronyx AI posts a bot message to the #alerts messaging channel so the entire SOC is notified simultaneously
Response commands queued — if Claude recommended a kill_process or quarantine_file action, the command is dispatched to the device agent and executed within 3 seconds

Autonomous agent commands are only dispatched when Claude explicitly recommends them with a high-confidence verdict. To disable autonomous commands for a specific device, remove or pause its agent policy in the Devices section.

Identifying AI-created incidents

Field in incident record	Value
Title	Begins with "AI Detection:"
Source	ai_analysis
Description	JSON block containing the full threat summary, anomalies list, confidence score, and recommended actions

AI Security Analyst (Kronyx AI Chat)

Navigate to Kronyx AI in the sidebar to open the conversational analyst interface. Ask questions in plain English and receive structured, contextual answers grounded in your platform's live data.

Selecting a device context

Use the device selector in the top-right of the Kronyx AI page to focus the conversation on a specific endpoint. When a device is selected, Kronyx AI injects that device's latest metrics, processes, and connection data into the conversation — every answer is grounded in the device's actual state, not generic advice. Leave the selector on All devices for platform-wide questions.

Quick action buttons

Button	What it asks
What's suspicious today?	Summarises anomalies and open incidents across all devices from the last 24 hours
Analyze all devices	Runs a sweep of each enrolled device and returns a ranked threat summary
Show open incidents	Lists currently open incidents with severity, device, and time open
Any unusual network activity?	Reviews recent outbound connections and flags any that deviate from baseline

Response action chips

When Kronyx AI recommends a specific action (e.g. "Kill process X", "Quarantine file Y"), a clickable chip appears below the response. Clicking it dispatches the command directly to the selected device's agent — no navigation required.

The conversation history is maintained within your session (up to the last 6 messages). If you switch devices mid-conversation, mention the new hostname so Kronyx AI understands the context before you ask follow-up questions.

Collaboration & Communication

Team Messaging

Kronyx includes a built-in team messaging system so your SOC can communicate, coordinate investigations, and share security context without switching to an external tool. All communication stays inside the platform alongside the incidents, devices, and reports it relates to.

Access messaging via the chat icon in the top header bar.

System channels

Four channels are created automatically when your team first accesses messaging. These cannot be deleted.

Channel	Purpose
#general	Day-to-day team communication — shift handovers, announcements, general discussion
#incidents	Incident coordination — loop in colleagues, share initial findings, agree on response actions
#threat-intel	Threat intelligence sharing — IOCs, threat actor TTPs, new CVEs, external intelligence feeds
#alerts	Managed by the BluAI bot. Do not post here manually — it is the authoritative record of every AI-detected threat

Direct messages

Click the person+ icon at the top of the channel sidebar and search by name or email. Selecting a team member creates a private channel visible only to the two of you.

Sharing security context

Click the paperclip icon in the compose bar
Select the type — Incident, Report, or Investigation
Search and select the item
It appears as a rich card in the message — recipients click it to open the full record inside Kronyx

Use message attachments during incident handovers. Post to #incidents with the incident attached, a one-line status update, and an @mention of the incoming analyst. Everything they need is in one place.

The #alerts channel and BluAI

Alert message field	Content
Title	Threat level and affected device — e.g. "[High] AI Detection: DESKTOP-01"
Summary	Plain-English description of what was detected and why it is concerning
Incident card	A clickable attachment linking directly to the auto-created incident record
Severity badge	Colour-coded — red for Critical, orange for High

Notifications

Kronyx delivers targeted, contextual notifications to keep individual analysts informed of events that specifically require their attention — without flooding the entire team with every alert.

The bell icon in the top header bar shows your unread count. Clicking it opens the Notifications page.

Type	When it fires	Who receives it
AI Threat	BluAI detects a High or Critical threat on a device	The owner of the affected device
Escalation	An escalation rule fires and creates a new escalation	All platform users
Incident Assigned	An incident is assigned to you	The assigned analyst
Mention	A team member @mentions you in a message	The mentioned user
System	Platform-level events	All admins

Notifications page

Notifications are grouped by date (Today / Yesterday / earlier) and filterable by type. Clicking a notification marks it read and navigates directly to the relevant record. Hover and click ✕ to dismiss without navigating.

Use Mark all read at the start of each shift to create a clean baseline — any new notifications that arrive during your shift represent activity that occurred while you were actively working.

Live Collaboration

Kronyx shows you in real time which colleagues are active on the platform and what page they are viewing — enabling situational awareness that normally requires a voice call.

The online indicator in the top header bar shows the number of analysts currently active. Clicking it lists each analyst by name and role. When multiple analysts are on the same page, their live cursors appear as labelled pointers overlaid on your screen.

Cursor state	Meaning
Moving cursor with label	The analyst is actively navigating the page
Pulsing cursor — "Investigating"	The analyst is actively investigating — set automatically on certain actions
Click ripple effect	The analyst clicked something — useful for following along during a walkthrough

Live collaboration requires a WebSocket connection. If the indicator shows "Offline", check that the backend is running. The rest of the platform continues to function — only real-time presence is affected.

FAQ & Troubleshooting

Common questions and solutions.

Device Issues

A device shows as Disconnected

Confirm the device is powered on and connected to the network, then check that the Kronyx agent service is running:

Windows: Open services.msc and look for "Kronyx Agent" — it should be Running
macOS: Run launchctl list | grep kronyx in Terminal
Linux: Run systemctl status kronyx-agent

If the service is stopped, start it. If it is running but the device still shows Disconnected, check that the agent can reach the Kronyx server on port 8000. Review the agent log at /var/log/kronyx/agent.log (macOS/Linux) or C:\ProgramData\Kronyx\logs\agent.log (Windows).

A device enrolled but does not appear in the Devices list

After installation the agent can take 1–2 minutes to register. If it still does not appear after 5 minutes: confirm the installer was generated with the correct server address, verify the agent can reach the server with curl http://<server-ip>:8000/health from the device, then restart the agent service.

EDR Questions

A binary shows as Unknown in VirusTotal — is it safe?

No. Unknown means the file has not been submitted to VirusTotal before and has no prior verdict. This can happen with custom internal tools, newly compiled malware, or niche legitimate software. Treat Unknown binaries in sensitive locations (Temp, AppData, user profile) with caution.

Our internal tools keep getting flagged as Suspicious

Open the binary detail view and click Mark as Reviewed to acknowledge it as legitimate. Add a note explaining why. This prevents the binary from re-alerting unless a new version with a different hash is detected.

Network Questions

Network Discovery is not finding all devices

Network Discovery is designed to surface every device on your network — including unregistered and potentially rogue devices that have no agent installed. If a device does not appear, check the following:

Host firewall blocking ICMP — some devices are configured to silently drop ping requests. Kronyx also uses ARP and port-based probing to detect these devices even when ICMP is blocked.
Device is powered off or disconnected — discovery only captures devices that are active on the network at scan time. Schedule recurring scans to build a more complete picture over time.
Scan range not configured — ensure your scan target covers the full IP range of your network, not just the default subnet. You can set a custom CIDR range in the Network Discovery settings.
Devices on separate VLANs — deploy a Kronyx agent on a host within each VLAN segment so discovery scans run from inside that segment. This is intentional security architecture, not a platform limitation.

Any device that responds on the network — registered or not — will appear in the discovery results. Unregistered devices are flagged so analysts can investigate whether they are authorised.

Traffic Analysis shows no data

Traffic Analysis requires the Kronyx backend to have visibility into network traffic. You may need to configure a SPAN/mirror port on your switch, or deploy the Kronyx network sensor on a device with access to network traffic. Consult your network administrator.

Too many false positives in Threat Detection

Go to Threat Detection → Settings and adjust sensitivity thresholds or whitelist specific source/destination IPs. Common sources of false positives include backup software generating high outbound traffic and internal vulnerability scanners — whitelist their IPs to suppress noise.

Pentesting Questions

A finding shows N/A instead of a CVE/CVSS score

This is expected for open-port and API-fuzz findings — neither is tracked in the CVE system (an open port or an API schema violation isn't a "vulnerability" with a CVE identifier the way a known software flaw is). A bare "—" instead of N/A means the finding is a CVE-eligible type (TLS/SSL or vulnerability scan) but a score couldn't be resolved — usually because that specific check doesn't reference a CVE at all (most testssl checks don't).

Will an API fuzz scan affect my live site or data?

Yes, potentially — unlike the other three active scans, API fuzz sends real state-changing requests (POST/PUT/DELETE with fuzzed bodies) to whatever your API spec documents. It's rate-limited and capped per run, and deliberately excluded from scheduled/automatic scanning for this reason. Only run it against targets and environments where that's acceptable.

I added a target but can't run active scans

Active scans (Nuclei, port scan, TLS/SSL audit, API fuzz) require the target to be Verified first. For domains, add the DNS TXT record shown in the Add Target dialog and click Verify. For servers, verification happens automatically the moment a real SSH connection succeeds with the credentials you provided — if it shows Failed, double-check the host, port, username, and credentials.

API Reference

Use the Kronyx REST API to integrate with your existing security tools, automate workflows, or build custom dashboards. All endpoints require a Bearer token.

Authentication

Generate an API key from Dashboard → API Settings. Every request must include the key in the Authorization header:

# Example — list all devices

curl -X GET \

http://localhost:8000/api/v1/devices \

-H "Authorization: Bearer kronyx_your_key_here" \

-H "Content-Type: application/json"

API keys are shown only once when generated. Store them securely — they cannot be retrieved afterwards. Revoke and regenerate if a key is ever exposed.

Endpoint Reference

All endpoints are prefixed with your server address (e.g. http://localhost:8000).

Authentication

Method	Path	Description
POST	/api/auth/login	Obtain an access token
POST	/api/auth/register	Create a new user account
POST	/api/auth/refresh	Refresh an expired access token
GET	/api/auth/api-keys	List your API keys
POST	/api/auth/api-keys	Generate a new API key
DELETE	/api/auth/api-keys/{id}	Revoke an API key

Devices

Method	Path	Description
GET	/api/v1/devices	List all enrolled devices
GET	/api/v1/devices/{id}	Get device details
POST	/api/v1/devices/enroll	Enroll a new device
DELETE	/api/v1/devices/{id}	Remove a device
GET	/api/v1/devices/{id}/metrics	Get live device metrics

Incidents & Escalations

Method	Path	Description
GET	/api/incidents	List all incidents
POST	/api/incidents	Create a new incident
GET	/api/incidents/{id}	Get incident details
PUT	/api/incidents/{id}	Update incident status
GET	/api/escalations	List escalation rules
POST	/api/escalations	Create an escalation rule

Threat Intelligence

Method	Path	Description
GET	/api/edr/binaries	List scanned binaries
POST	/api/edr/binaries/scan	Submit a file hash for scanning
GET	/api/threat-map/events	Get live threat map events

Network

Method	Path	Description
GET	/api/network/discovery	List discovered network devices
POST	/api/network/scan	Trigger a new network scan
GET	/api/network/traffic	Get traffic analysis data

Interactive Explorer

Try any endpoint directly below using your API key. The explorer is powered by the live FastAPI server running alongside this application.

Click Authorize in the explorer, paste your API key in theBearer field, then use any endpoint interactively.

Can't find what you're looking for?

Open Dashboard