Features

Built to stop ransomware
before it spreads.

Detection, containment, compliance and managed response — from kernel-level event collection to SIEM integration and host isolation. Every feature is designed for Linux server and container environments.

Feature 01

Linux Runtime Monitoring

Every process execution and file operation on your Linux hosts is observed at kernel level via eBPF tracepoints. RuntimeGuard sees everything — no blind spots, no polling delays, no missed events.

Unlike inotify-based tools that only watch configured directories, eBPF sees activity across the entire filesystem, regardless of path — catching ransomware that operates outside expected locations.

  • execve tracepoint: every process execution captured
  • openat tracepoint: file writes tracked by syscall, not directory
  • renameat2 tracepoint: rename operations caught at kernel level
  • Sub-millisecond latency from kernel event to detection
eBPF tracepoint stream
[14:22:07]execve/usr/bin/nginx pid:2847
[14:22:07]openat/var/log/nginx.log O_WRONLY
[14:22:08]execve/usr/bin/bash pid:3012
[14:22:09]execve/usr/bin/find pid:3891
[14:22:09]openat/home/data/file01.docx O_WRONLY
[14:22:09]openat/home/data/file02.xlsx O_WRONLY
[14:22:10]openat/home/data/backup.tar O_WRONLY
[14:22:10]renameat2file01.docx → file01.locked
↑ 847 events/sec · 0 dropped
Feature 02

Behaviour-based Ransomware Detection

RuntimeGuard doesn't match malware signatures — it watches what processes do. Ransomware has consistent behavioural fingerprints: it writes many files rapidly, then renames them with new extensions.

Detection rules run against a 60-second sliding time window. When a process crosses a threshold, an incident is created immediately — before encryption completes.

  • Sliding window: events counted over a 60-second rolling window
  • Per-host analysis: each monitored host evaluated independently
  • Low false positive rate: thresholds tuned for production workloads
  • Custom thresholds available in Growth and Business tiers
Detection engine — window analysis
Window: 60s · host: prod-server-01
file_write12 eventsthreshold: 10
file_rename6 eventsthreshold: 5
process_exec4 eventsthreshold: 15
⚠ 2 RULES TRIGGERED
file_write_burstMEDIUM · 65
file_rename_burstHIGH · 80
Detection rules
26 rules included out of the box
Every RuntimeGuard plan ships with battle-tested detection rules covering ransomware, rootkits, persistence, injection, credential access, anti-forensics, container escapes, C2 communication and statistical anomaly detection. Growth and Business customers can tune thresholds per host. Business customers can define custom rules.
file_write_burst
Fires when a single process writes to ≥10 files within a 60-second window. Primary signal for encryption-in-progress.
MEDIUM SCORE 65
file_rename_burst
Fires when a process renames ≥5 files within 60 seconds. Consistent with ransomware adding encryption extensions (.locked, .enc).
HIGH SCORE 80
process_exec_burst
Fires when a parent process spawns ≥50 child processes within 60 seconds. Detected via PPID tracking — the parent is identified and can be contained.
HIGH SCORE 75
network_burst
Fires when a single process makes ≥20 outbound connections to public IPs within 60 seconds. Indicates exfiltration or C2 beacon activity.
MEDIUM SCORE 60
priv_esc_attempt
Fires when a non-root process calls setuid(0) ≥3 times — even if the kernel rejects it. Detects active privilege escalation attempts in real time.
HIGH SCORE 85
file_delete_burst
Fires when a process deletes ≥20 files within 60 seconds. Matches the destruction phase of ransomware attacks and wiper malware targeting backups and archives.
HIGH SCORE 78
chmod_burst
Fires when a process changes file permissions on ≥15 files within 60 seconds. Common in malware that locks files (chmod 000) or prepares them for exfiltration.
MEDIUM SCORE 60
memfd_exec
Fires when a process calls memfd_create ≥3 times. memfd_create creates anonymous in-memory file descriptors — a classic technique for fileless malware that never touches disk.
CRITICAL SCORE 95
ptrace_injection
Fires when a process calls ptrace(PTRACE_ATTACH) or ptrace(PTRACE_SEIZE) ≥3 times. Indicates process injection — attaching to another process to execute arbitrary code in its context.
CRITICAL SCORE 92
suspicious_path_exec
Fires when ≥3 executables are launched from temporary directories (/tmp, /dev/shm, /var/tmp, /run/user). Legitimate binaries don't live there — this is a strong indicator of a dropped payload.
HIGH SCORE 82
kernel_module_load
Fires when a process calls init_module or finit_module ≥2 times. Loading a kernel module is the primary technique for rootkit installation — the module can hide files, processes and network connections from all userspace tools.
CRITICAL SCORE 97
bind_backdoor
Fires when a process binds a listening TCP socket ≥3 times. Indicates an attacker opening a bind shell — waiting for inbound connections. Legitimate server software binds once at startup, not repeatedly in a short window.
HIGH SCORE 85
ssh_key_tamper
Fires on the first write to any authorized_keys file. Adding an SSH public key gives an attacker permanent, passwordless access to the host — surviving reboots, password changes and incident response. One write is enough.
CRITICAL SCORE 96
pam_tamper
Fires on the first write to /etc/pam.d/ or /etc/pam.conf. PAM controls all authentication on Linux — SSH, sudo, su, console. Modifying it lets an attacker capture passwords in plaintext, bypass authentication entirely, or create backdoor accounts invisible to /etc/passwd.
CRITICAL SCORE 94
cron_tamper
Fires on the first write to /etc/cron*, /etc/crontab or /var/spool/cron. Cron is a classic persistence mechanism — an attacker adds a job that runs every minute to maintain access, download updates or exfiltrate data, surviving reboots automatically.
HIGH SCORE 88
systemd_persist
Fires on the first write to a systemd unit directory (/etc/systemd/system/, /lib/systemd/system/). A systemd service with Restart=always is the most robust persistence mechanism on modern Linux — it survives reboots, password changes and manual malware removal attempts.
HIGH SCORE 86
ld_preload_inject
Fires when a process is launched with LD_PRELOAD set — detected by reading /proc/PID/environ after execve. LD_PRELOAD allows replacing standard libc functions like open, read, pam_authenticate before they are called — enabling credential theft, rootkit behaviour and keylogging without touching disk.
CRITICAL SCORE 93
c2_connection
Fires when an outbound connection matches a known C2 IP address. Checked against Feodo Tracker (Emotet, TrickBot, QakBot) and Emerging Threats (free, refreshed hourly), plus AlienVault OTX IP reputation (optional API key). Detects communication before encryption begins.
CRITICAL SCORE 99 THREAT INTEL
known_malware
Fires when an executed binary's SHA256 hash matches a threat intelligence database. Checked against MalwareBazaar (free), VirusTotal multi-engine scan (optional API key) and AlienVault OTX pulse data (optional API key). All results are cached for 24 hours.
CRITICAL SCORE 99 HASH INTEL
anomaly_burst
Statistical anomaly detection using Welford's online algorithm. Learns the normal event rate for each host independently — then fires when the current rate is ≥3 standard deviations above average. Catches unusual activity that falls below fixed thresholds but is abnormal for that specific host.
HIGH SCORE 70–88 ADAPTIVE
credential_access
Fires on the first write to /etc/shadow or /etc/passwd. Writing to these files allows an attacker to add backdoor accounts, modify password hashes, or change shell assignments — changes that survive reboots and password resets.
CRITICAL SCORE 91
log_tamper
Fires when a process deletes files under /var/log/. Log deletion is a standard anti-forensics technique — attackers remove evidence of their presence to slow down investigation and complicate incident response. One deletion is enough to trigger.
HIGH SCORE 84
docker_socket_access
Fires when any process opens a file descriptor to /var/run/docker.sock. Access to the Docker socket is equivalent to root on the host — it allows spawning privileged containers, mounting the host filesystem, and escaping any container boundary. Detected via background /proc/pid/fd scanning.
HIGH SCORE 87
reverse_shell
Fires when a shell process (bash, sh, zsh, fish, dash) is spawned by a process that made an outbound TCP connection within the last 60 seconds. This state machine catches the classic reverse shell pattern — outbound connect followed immediately by interactive shell spawn.
CRITICAL SCORE 98
namespace_escape
Fires when a process calls unshare() — the syscall used to detach from Linux container namespaces. Calling unshare(CLONE_NEWNS) creates a new mount namespace that can be used to access the host filesystem. Mapped to MITRE ATT&CK T1611.
CRITICAL SCORE 96 CONTAINER
container_escape
Fires when a process calls setns() — the syscall used to join an existing Linux namespace by file descriptor. Joining the host's mount or PID namespace via /proc/1/ns/ gives full host access. Requires CAP_SYS_ADMIN, making false positives very rare. Mapped to MITRE ATT&CK T1611.
CRITICAL SCORE 98 CONTAINER
Feature 03

Instant Alerting

The moment a detection rule fires, RuntimeGuard creates an incident and sends alerts through your configured channels. No polling lag — alerts fire as soon as the incident is created.

  • Webhook: POST JSON payload to any URL — works with PagerDuty, Opsgenie, and custom systems
  • Slack: formatted alert with severity, score, host, and rule name
  • Email: delivered via your SMTP or through RuntimeGuard's mail infrastructure
  • Deduplication: only one open incident per rule/host — no alert storms
  • Auto-resolution: alert cleared when the rule condition drops below threshold
Slack alert payload
🚨 [HIGH] Incident on prod-server-01
Rule: file_rename_burst
Score: 80 / 100
Tenant: acme-corp
Time: 2026-03-17 14:22:10 UTC
→ View incident in dashboard
Feature 04

Incident Timelines

Every incident is stored with a complete timeline of events: which process triggered it, which files were involved, when activity started and when it cleared.

Timelines give your team everything needed to investigate what happened, understand the scope, and respond — without digging through raw logs.

  • Full event context: PID, process name, file paths
  • Start and resolution timestamps
  • Severity score with rule explanation
  • Searchable by host, tenant, rule, severity, or status
  • Available via dashboard and REST API
Incident detail
INC-2026031700142
Hostprod-server-01
Rulefile_rename_burst
SeverityHIGH
Score80 / 100
StatusRESOLVED
14:22:07 → event stream started
14:22:10 → threshold crossed (6 renames)
14:22:10 → INCIDENT CREATED
14:23:18 → below threshold → RESOLVED
Feature 05 · Business tier

Automated Process Containment

When a high-confidence detection fires, RuntimeGuard can automatically send a kill signal to the offending process — stopping encryption mid-flight before more files are affected.

Containment is configurable: choose automatic kill, alert-only, or manual confirmation. Containment actions are logged with full audit trails.

  • Configurable per rule: auto-kill, alert-only, or require confirmation
  • Kills only the offending process — not the entire host
  • Full audit log of all containment actions
  • Available in Business tier
Containment action log
✓ CONTAINMENT EXECUTED
ActionSIGKILL → pid:3891
Process/usr/bin/encryptor
Triggerfile_rename_burst
Time14:22:10.847 UTC
Files affected6 before kill
✓ Process terminated in 847ms from first event
Feature 06

Adaptive Anomaly Detection

Fixed thresholds work for generic attack patterns. But every host has different normal behaviour — a file server writes thousands of files per minute; a web server almost none. RuntimeGuard learns what's normal for each host individually and flags deviations automatically.

Statistical baselines are built per host using Welford's online algorithm. After a short warmup period, any event rate more than 3 standard deviations above the historical average triggers an anomaly incident — even if it falls below the fixed rule threshold.

  • Per-host baselines — each host evaluated against its own history, not a global average
  • Detects unknown attack patterns without pre-defined rules
  • Complements threshold rules — catches slow, low-and-slow attacks
  • Baseline persists across restarts — stored in PostgreSQL
  • Reset baseline via dashboard in one click when behaviour changes legitimately
Anomaly detection — baseline comparison
web-server-01 · file_write baseline
mean2.3 events/batch
stddev0.8
observations1,847 batches (61h)
current batch47 events
z-score55.9σ above mean
multiplier20.4× above normal
⚠ ANOMALY DETECTED
file_write (20.4× above baseline, z=55.9)
Feature 07

Per-host Rule Tuning

A file server has a very different threat profile than a web server or a build agent. RuntimeGuard lets you configure detection thresholds per host — so each machine is evaluated against rules that match its actual workload.

Host-specific overrides take priority over tenant-wide defaults. Overrides can be set and reset from the dashboard without editing configuration files or restarting the agent.

  • Set thresholds per rule per host from the Detection Rules tab
  • Enable or disable individual rules per host
  • Host overrides are clearly marked in the dashboard
  • Reset to tenant default in one click
  • Changes take effect on the next agent batch — no restart required
Detection Rules — file_write_burst
WEB-SERVER-01
threshold10 (default)
scopedefault
FILE-SERVER-01
threshold500 ↑ host override
scopehost
Each host evaluated against its own thresholds.
Feature 08

False Positive Management

Security tools that cry wolf get ignored. RuntimeGuard gives you direct controls to reduce noise without turning off protection — maintenance windows, per-host tuning, and baseline resets.

  • Maintenance window — suppress all incidents on a host for N minutes during planned maintenance
  • Baseline reset — clear the anomaly baseline and let the system re-learn after a legitimate workload change
  • Per-host thresholds — raise thresholds for noisy rules on specific hosts
  • Learning mode — observe without alerting while you tune thresholds on new infrastructure
  • Manual close — resolve any incident from the dashboard with a single click
Maintenance window active
🔧 MAINTENANCE WINDOW
hostprod-db-01
duration240 minutes
expires02:00 UTC
incidents suppressedyes
Events are still collected and baselines still update. Only incident creation is paused.
Feature 09

Kubernetes & Container Detection

RuntimeGuard detects container escape techniques at the syscall level — where no container runtime or Kubernetes admission controller can intercept them. Two dedicated rules cover the two primary escape syscalls: unshare() and setns().

Every process execution event is enriched with container context — container ID, pod name, and namespace — so incidents are immediately scoped to the right workload.

  • namespace_escape — unshare() syscall detection, MITRE ATT&CK T1611
  • container_escape — setns() syscall detection, namespace switching to host
  • docker_socket_access — /var/run/docker.sock fd detection via /proc scanning
  • Container context on all process_exec events: container_id, k8s_pod, k8s_namespace
  • Works on any container runtime — Docker, containerd, CRI-O
Container escape detected
[09:14:02]process_execnsenter pid:4821
container_ida3f8c12e9b01
k8s_podwebapp-7d9f8b-xk2pn
k8s_namespaceproduction
[09:14:02]setns/proc/1/ns/mnt → host mount ns
⚠ CONTAINER ESCAPE DETECTED
rulecontainer_escape
severityCRITICAL · 98
podwebapp-7d9f8b-xk2pn
mitreT1611 · Escape to Host
Feature 10 · Enterprise

SIEM & SOAR Integrations

RuntimeGuard sends incidents to your existing security toolchain the moment they are created — no polling, no manual export. Configure one or more destinations per tenant via the dashboard or API.

  • Splunk HEC — events forwarded as JSON to your Splunk HTTP Event Collector endpoint
  • Elasticsearch — incidents indexed directly into your Elastic cluster
  • Datadog — incidents sent as Datadog events with severity tags
  • PagerDuty — incidents trigger PagerDuty alerts with deduplication key per rule/host
  • Managed via POST /v1/integrations — multiple destinations per tenant
Integration configuration
POST /v1/integrations
typesplunk_hec
urlhttps://splunk.acme.com:8088
token••••••••••••••••
enabledtrue
typepagerduty
routing_key••••••••••••••••
enabledtrue
→ Incidents dispatched on creation · no polling
Feature 11 · Enterprise

Compliance Reporting

RuntimeGuard maps its detection coverage to SOC2 and CIS Benchmark controls and generates a report on demand. The report shows which controls are covered by active detection rules and which incidents are relevant per control.

  • SOC2 Trust Services Criteria — availability, security, confidentiality
  • CIS Benchmark — Linux OS hardening controls mapped to detection rules
  • Available as JSON download via GET /v1/compliance/report
  • Compliance tab in the dashboard — visual coverage overview
  • Exportable for audit evidence packages
Compliance report — SOC2 coverage
GET /v1/compliance/report · tenant: acme-corp
CC6.1Logical access · ssh_key_tamper, pam_tamper
CC6.6Malicious software · memfd_exec, known_malware
CC7.2Anomaly detection · anomaly_burst, c2_connection
CC9.2Business continuity · file_delete_burst, log_tamper
24 / 26 rules mapped · 12 SOC2 controls covered
Feature 12 · Enterprise

SIEM Export API

Pull raw events and incidents into any SIEM or data pipeline using the export API. Three output formats and a real-time server-sent events stream for live ingestion.

  • GET /v1/events — historical event export, filter by host/type/time range
  • GET /v1/events/stream — real-time SSE stream, connect once and receive new events as they arrive
  • GET /v1/incidents/export — bulk incident export for SIEM ingest
  • Output formats: ndjson, csv, splunk (Splunk-compatible key=value)
  • Authenticated via X-API-Key — works with any HTTP-capable SIEM connector
GET /v1/events/stream (SSE)
Content-Type: text/event-stream
data:{"ts":"09:14:01","host":"prod-01","type":"process_exec","comm":"bash"}
data:{"ts":"09:14:02","host":"prod-01","type":"net_connect","dst":"1.2.3.4:4444"}
data:{"ts":"09:14:02","host":"prod-01","type":"reverse_shell","pid":4821}
Stream stays open · events pushed as they arrive
Feature 13 · MDR

Incident Triage & Analyst Workflow

RuntimeGuard includes a full analyst workflow layer for teams that triage incidents internally or operate a managed detection and response service. Every incident can be tracked through its full lifecycle.

  • Triage status: investigating → contained → resolved
  • Assignment — assign incidents to analysts from the dashboard
  • Priority levels: low / medium / high / critical
  • Analyst notes — timestamped investigation log per incident
  • SOC admin feed — cross-tenant view of all open incidents (GET /v1/admin/soc)
  • Metrics — MTTD and MTTR tracked per tenant (GET /v1/metrics)
Incident triage — INC-2026031700142
statusinvestigating
assigned_toalice@acme.com
prioritycritical
ANALYST NOTES
09:15:03 alice: Confirmed malicious — reverse shell from webapp pod. Isolating host.
09:18:41 alice: Host isolated. Root cause: RCE via log4j in webapp-7d9f8b.
→ Status updated: contained · MTTR 3m 38s
Feature 14 · MDR

Playbooks & Host Isolation

Every detection rule ships with a MITRE ATT&CK-mapped response playbook. When an incident fires, the analyst gets structured response steps tailored to that specific technique — no generic runbooks.

Host isolation blocks all network traffic at the iptables level via a dedicated RUNTIMEGUARD chain, while keeping the agent's connection to the backend open so the host remains under observation.

  • Playbooks for all 26 detection rules — GET /v1/incidents/{id}/playbook
  • Each playbook includes MITRE technique, indicators, containment steps, and recovery actions
  • Host isolation via PUT /v1/hosts/{id}/isolate — agent applies iptables RUNTIMEGUARD chain
  • Isolation preserves agent connectivity — host stays monitored while isolated
  • Unisolate via DELETE /v1/hosts/{id}/isolate — chain removed, normal traffic restored
Playbook — reverse_shell
mitreT1059 · Command and Scripting Interpreter
tacticExecution / C2
RESPONSE STEPS
1. Isolate host to block C2 channel
2. Kill PID 4821 (shell process)
3. Capture /proc/4821/exe hash for IOC
4. Review parent process (net_connect origin)
✓ HOST ISOLATED
iptables RUNTIMEGUARD chain active · agent connected
Feature 15

Threat Intelligence Integration

RuntimeGuard enriches every detection with multiple threat intelligence sources — automatically, without any extra configuration for the free tier. Optional API keys unlock deeper coverage from VirusTotal and AlienVault OTX.

IP reputation and hash checks run inline during event ingest. When a match is found, an incident is opened immediately — before a rule threshold would have been reached.

  • Feodo Tracker + Emerging Threats — C2 IP blocklists, refreshed hourly, no API key
  • MalwareBazaar — SHA256 hash database, no API key, 24h result cache
  • VirusTotal API v3 — multi-engine malware scan results, optional VIRUSTOTAL_API_KEY
  • AlienVault OTX — IP reputation (4h cache) + hash pulse data (24h cache), optional OTX_API_KEY
  • Hash lookup uses /proc/PID/exe at execution time — catches malware before persistence
  • Checks cascade: MalwareBazaar → VirusTotal → OTX, stopping at first match
threat-intel · hash lookup pipeline
EVENT process_exec · PID 4821
exe/tmp/x86_enc
sha2563a4f9b2c1d...
HASH CHECK PIPELINE
MalwareBazaarno match
VirusTotal31 engines
⚠ INCIDENT OPENED · known_malware
sourcevirustotal: Ransom.LockBit (31 engines)
severitycritical
actionprocess killed · PID 4821
IP CHECK · net_connect
Feodo Trackerno match
AlienVault OTXthreat_score 85
⚠ c2_connection · 185.220.101.47 · alienvault-otx
Investigation
Attack graph from first event to root cause
Every incident links to an interactive process tree: all processes active in the ±5-minute window around the alert, assembled into a parent–child graph with pan, zoom and per-node detail. Follow the chain from a suspicious shell back to the process that spawned it — without touching the host.
incident · file_rename_burst · process tree
systemd [1]
└─ sshd [892]
└─ bash [4201]
└─ curl [4388] — net_connect → 185.220.101.x
└─ ./x86_enc [4821] ◀ INCIDENT · 847 renames
PID 4821 — x86_enc
exe: /tmp/x86_enc · ppid: 4388 (curl) · 847 file_rename events · process killed
Detection
Write your own detection rules in Sigma
RuntimeGuard supports Sigma-compatible YAML rules alongside the 26 built-in rules. Write a rule once, and it runs against every event on every host — no query language, no SIEM required. The YAML editor validates syntax on save and surfaces errors immediately.
custom-rules / bash_from_tmp.yml
title: Bash execution from /tmp
name:  bash_from_tmp
logsource:
  category: process_creation
  product:  linux
detection:
  selection:
    exe|contains:
      - /tmp/
      - /dev/shm/
    comm: bash
  condition: selection
level: high
Sigma-compatible format
Reuse rules from the Sigma community repository. Field aliases (Image, CommandLine, DestinationIp) are automatically translated.
Field modifiers
Supports |contains, |startswith, |endswith, |re (regex), and exact match.
Conditions
Use selection and not filter to exclude known-good processes, or 1 of them for multi-selection rules.
Instant feedback
YAML is validated on save. Invalid syntax surfaces a clear error before the rule goes live.
Compliance
Monitor file integrity on critical system paths
Add any file or directory to the FIM watchlist. RuntimeGuard detects writes, renames, deletes and permission changes and creates an incident for every match — with the process name, PID and timestamp.
fim / recent changes
file_write/etc/passwdpython3PID 4821 file_rename/etc/shadow.bak → /etc/shadowbashPID 4822 file_delete/var/log/auth.logrmPID 5100 file_chmod/usr/bin/sudochmodPID 5210
Prefix-based matching
Watch entire directories with a single entry. Adding /etc/ flags all writes under that directory — not just a specific file.
Four event types
Detects file_write, file_rename, file_delete and file_chmod — covers the full attack surface of file-based persistence and anti-forensics.
PCI-DSS & CIS ready
File integrity monitoring is a mandatory control in PCI-DSS, CIS Benchmark and SOC2. Every FIM match is logged with actor, path and timestamp for your audit package.
Per-host view
Filter the changes table by host to investigate a specific server without noise from the rest of the fleet.
Rootkit Detection
Detect rootkits that hide from userspace tools
RuntimeGuard's agent scans /proc every 30 seconds for three rootkit indicators — without requiring a custom kernel module or external scanner. Detections are sent to the backend and surfaced as critical incidents immediately.
Preload tamper
Detects a non-empty /etc/ld.so.preload — the primary mechanism for LD_PRELOAD-based userland rootkits that intercept every libc call on the system.
CRITICALSCORE 95
Rootkit module
Baselines /proc/modules at agent start and alerts on newly loaded kernel modules with known-bad names (diamorphine, reptile, suterusu, kovid, and others).
CRITICALSCORE 96
Hidden process
Finds processes whose /proc/PID/exe resolves to a deleted path. Indicates fileless malware or binary replacement by a kernel rootkit attempting to erase its on-disk footprint.
CRITICALSCORE 97
Automation
Automate your incident response
Define playbooks that execute automatically the moment a matching incident opens — no analyst required. Combine multiple actions per playbook to build a complete SOAR-level response chain, all configured from the dashboard.
Isolate Host
Immediately block all network traffic via iptables. A dedicated chain keeps the RuntimeGuard backend reachable so monitoring continues during the incident.
NETWORK ISOLATION
Block IP
Drop inbound and outbound traffic to the IP address found in the triggering event — or specify a static IP. Applied instantly via iptables on the affected host.
IPTABLES
Notify Webhook
POST the full incident JSON to any URL — Slack, Teams, JIRA, custom SOAR. Runs in addition to the existing Slack and email alerting.
WEBHOOK
PagerDuty Alert
Trigger a PagerDuty incident via Events API v2 with severity, description and host metadata — directly from the playbook action without a separate integration.
PAGERDUTY
Trigger conditions
Match on specific rule name (or all rules) and minimum severity. A critical-only playbook never fires on medium incidents — surgical precision, not alert fatigue.
Action chains
Combine multiple actions in a single playbook. Isolate the host and notify Slack and page the on-call engineer — in one rule.
Execution log
Every action is logged with status (ok / error) and detail. Audit every automated decision — required for SOC2 and most security certifications.
Enforcing mode only
Playbooks only execute in enforcing mode. Hosts in learning mode are never automatically acted upon — safe to deploy agents before tuning is complete.
Kubernetes
Stop dangerous pods before they start
RuntimeGuard acts as a Kubernetes ValidatingAdmissionWebhook. Every pod creation is checked against your security policy in real time — if a violation is found, the pod is rejected before it ever runs. One webhook URL, seven configurable checks, zero agents on the control plane.
Privileged containers
Rejects pods with securityContext.privileged: true — grants full access to the host kernel, equivalent to running as root on the node.
CRITICAL
hostPID / hostNetwork / hostIPC
Blocks pods that share the host's process, network or IPC namespace. Each of these breaks container isolation and is a primary container escape vector.
CRITICAL
Dangerous capabilities
Rejects containers that add SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE or ALL to their capability set.
CRITICAL
hostPath volumes & image registries
Blocks pods that mount the host filesystem, and enforces an image registry allowlist — only images from approved registries (e.g. gcr.io/myproject) are admitted.
CONFIGURABLE
One-line cluster setup
k8s-webhook.yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: runtimeguard
webhooks:
  - name: admission.runtimeguard.io
    clientConfig:
      url: https://api.runtimeguard.io/v1/k8s/admission?key=YOUR_API_KEY
    rules:
      - operations: [CREATE, UPDATE]
        resources: [pods]
Dry-run mode
Enable dry-run to log violations without blocking pods. Roll out the webhook safely to an existing cluster — review the admission log for a week before switching to enforcement.
Per-tenant policy
Each tenant configures their own policy from the dashboard. Toggle individual checks, manage the registry allowlist and review the admission log — no kubectl access required.
Enterprise
Role-based access control and full audit trail
Every action taken in RuntimeGuard is logged. Assign the right level of access to every team member — and prove it to your auditors.
Admin
Full access: manage API keys, configure integrations, isolation, billing, role assignments, and view the audit log.
FULL ACCESS
Analyst
Triage incidents, add investigation notes, view playbooks, and access process trees. Cannot modify system configuration.
TRIAGE ACCESS
Viewer
Read-only access to incidents, hosts, metrics and compliance reports. Suitable for management dashboards and auditors.
READ ONLY
Audit log
Every POST, PUT, PATCH and DELETE is written to a tamper-evident audit log with actor, timestamp and HTTP status. Exported for SOC2 evidence packages.
SOC2 READY
Feature · Network

DNS Exfiltration Detection

Data exfiltration over DNS is the covert channel of choice for advanced persistent threats — it bypasses firewalls, passes through most enterprise filters, and is invisible to connection-based monitoring. RuntimeGuard captures raw DNS traffic at the kernel level using an AF_PACKET raw socket and analyses every query for exfiltration patterns.

Shannon entropy analysis runs on every DNS subdomain. Normal hostnames have predictable, low entropy. Base64-encoded or hex-encoded payloads pushed through DNS tunnels produce high-entropy subdomains that stand out immediately.

  • AF_PACKET raw socket — full DNS capture without a userspace DNS proxy
  • Shannon entropy per subdomain — detects encoding regardless of scheme
  • High query rate detection — unusually frequent queries to a single domain
  • Long subdomain detection — legitimate domains don't use 60-character labels
  • Fires a CRITICAL incident with the triggering query and entropy score
DNS exfiltration analysis
AF_PACKET capture · host: prod-db-01
queryapi.acme.com
entropy1.8 bits/charnormal
queryaGVsbG8td29ybGQ.c2VjcmV0LWRhdGEuZXhl.c2NmaWwuaW8
entropy5.9 bits/charHIGH
label_len52 charsANOMALOUS
⚠ DNS EXFILTRATION DETECTED
ruledns_exfiltration
severityCRITICAL · 94
entropy5.9 bits/char (threshold: 4.5)
Feature · MSP / MSSP

MSP / MSSP Portal

RuntimeGuard's Business tier is built for managed service providers who protect multiple customer environments. From a single login, manage any number of customer tenants — each with full data isolation, its own API keys, hosts, incidents and alerting configuration.

The MSP portal gives you a unified view across all customers with a cross-tenant SOC feed, per-tenant drill-down, and bulk management tooling — without sharing credentials or mixing customer data.

  • Create and manage unlimited customer tenants from the admin panel
  • Cross-tenant SOC feed — open incidents across all customers in a single view
  • Per-tenant isolation — incidents, API keys and data never bleed across tenants
  • Tenant statistics — host count, event volume, incident rate per customer
  • API key last_used_at tracking — quickly spot inactive deployments
  • Volume pricing for MSPs with more than 5 tenants
MSP admin — cross-tenant SOC feed
GET /v1/admin/soc · 3 open incidents
CRITICALreverse_shell · acme-corp · prod-web-01
09:14:02 UTC · unassigned
HIGHfile_rename_burst · beta-client · db-01
08:47:31 UTC · alice@msp.io
HIGHpriv_esc_attempt · gamma-inc · app-02
08:31:10 UTC · unassigned
Switch tenant context in dashboard → full drill-down
Feature · Enterprise

SSO / OIDC Login

RuntimeGuard supports single sign-on via Google and Microsoft OIDC, letting enterprise teams use their existing identity provider without managing separate credentials. SSO authentication is available in addition to API-key authentication — each method is independently controlled per tenant.

  • Google OIDC — log in with any Google Workspace account
  • Microsoft OIDC — log in with Azure AD / Microsoft Entra accounts
  • RBAC roles apply to SSO identities — admin, analyst and viewer roles enforced at login
  • SSO sessions are tenant-scoped — no cross-tenant access via shared IdP
  • Dashboard and API key authentication remain available alongside SSO
SSO login — identity providers
Sign in to RuntimeGuard
GContinue with Google
MContinue with Microsoft
identityalice@acme.com (Google)
tenantacme-corp
roleanalyst
✓ Session established · role enforced
Performance
Designed for production
RuntimeGuard is built to run on production servers — minimal resource footprint, no performance impact on your workloads.
<1%
CPU overhead on monitored host
11MB
Agent memory footprint
<60s
Time to first incident on attack
5.8+
Minimum Linux kernel version (eBPF)

See it in action.

Deploy RuntimeGuard on your Linux servers and start detecting threats in minutes.

Start free trial → View pricing