First-time onboarding

Follow this order: sign up, verify email, deploy sensor, then run event analysis.

This page is the operator's guide for Runtime Security. It tells you the exact order to bring a new environment online, the five deployment paths available, the detection domains and their console entry points, and the daily operating loop. Per-target deployment pages for each supported runtime are linked in the resources section.

View 5-step onboarding Open Sign-up Form Resources Log-in After Verify

How to start

First-time 5-step onboarding path

Complete these steps in order to go from account creation to runtime analysis and control. The first two steps are one-time. Steps three through five are repeated per environment you want to cover.

Step 2

Activate account

Open your email and click the verification link. The token is single-use and short-lived. First login is blocked until verification succeeds.

Step 3

Deploy sensor

Choose the deployment path that matches where your workloads run. Copy the per-tenant command from the console after login — it already embeds your customer UUID and pin.

Standalone Docker K8s EKS ECS

/docs.html#deployment-tracks

Step 4

Validate telemetry

Confirm the new host, pod, or task shows up in Runtime Overview → Inventory. Check that process, file, and network counts are non-zero in the current window.

Step 5

Analyze + control

Triage findings by severity, walk the event timeline for context, and tune file/process/network policies where alert volume is high or a compliance requirement applies.

Production onboarding sequence

Sign-up and verification must happen first. Deployment comes next, then event analysis and policy hardening in the runtime console.

Start Sign-up Deployment Methods Open Console

Solution model

What Runtime Security includes

After onboarding is complete, use this as the operating model for daily runtime security work. Each pillar maps to a section in the console you will see after login at overview.php.

1) Runtime observability

Ingest kernel-level runtime signals (via eBPF) from Kubernetes-managed containers, standalone containers, and Linux hosts into one inventory and event model.

Process, file, and network telemetry (exec, open, connect)
Asset context: host, pod, container, namespace, image
Unified inventory with exposure markers (ports, SSH, privileged)
Per-workload event timeline for reconstruction

2) Unified detection

Correlate threat, vulnerability, and behavioral findings — then rank by severity, business context, and compliance scope.

MITRE ATT&CK tactic + technique mapping
PCI DSS and compliance signal tagging
Top process alert list tied to finding evidence
Drill-down from finding → event → exact command line

3) Runtime control

Apply policy controls to reduce alert noise and enforce monitoring coverage where risk is concentrated. Policies sync to sensors live — no restart, no redeploy.

File monitoring control (paths, read/write filters)
Process monitoring control (binary, argv, privilege)
Network monitoring control (DNS, egress, IOC)
Per-host / per-namespace / per-container scoping

Deployment tracks

Select deployment path by runtime environment

Choose one method first (standalone, Docker, Kubernetes, EKS, ECS), then verify event flow and control posture. Reference command templates live on the home page; per-tenant commands are shown in the console after login.

Kubernetes-managed containers

Enable namespace, pod, label, and container context for runtime findings and policy actions. Sensor installs as a DaemonSet.

Onboard cluster sensors from the deployment view (kubectl create -f …).
Confirm pod and namespace metadata in Runtime Overview.
Open Findings view for combined threat and process triage.
Apply file/process/network policies scoped to namespace.

/docs.html#deployment-tracks

Non-managed containers

Cover standalone container runtimes (Docker, containerd, podman) and host-level container workloads.

Validate inventory rows for runtime and image context.
Check open exposure and process behavior in findings.
Tune file and process controls for high-risk images.
Re-baseline after image updates or registry changes.

/overview.php?view=containers

Linux hosts

Track host process execution, file drift, and network runtime events for VMs, bare metal, and edge hosts.

Confirm host telemetry in Runtime Overview.
Triaging process alerts tied to host identity.
Apply file/process/network policies based on findings.
Re-baseline after host patch or kernel upgrade.

/overview.php?view=inventory

Operational workflow

Map daily operations to console sections

Use this sequence to reduce context switching and improve runtime response quality.

1) Observe

Get coverage and telemetry health before deep investigation.

Runtime Overview
Container Runtime
Event Explorer

2) Triage

Use combined findings and process alerts to prioritize investigations.

Threat + vulnerability findings
Top process alerts
Drill-down to event explorer

3) Control

Apply monitoring controls where detections are noisy or high-risk.

File monitoring control
Process monitoring control
Network monitoring control

Detection domains

Runtime signal model reference

Use this table as the default mapping between detection signals and control actions. Each console URL below is the direct entry point — bookmark the ones you use most.

Domain	Primary signals	Triage entry point	Control action
Threat + Vulnerability	MITRE tags, PCI tags, CVE-linked indicators, exploit behaviors	`/overview.php?view=findings`	Prioritize assets and map policy hardening
Process	Unexpected execution chains, privilege escalation, noisy binaries	`/overview.php?view=top_alerts`	`/overview.php?view=policies_process`
File	Sensitive path writes, config drift, binary tampering	`/overview.php?view=events&action=fim`	`/overview.php?view=policies_file`
Network	IOC lookups, egress anomalies, unexpected destinations	`/overview.php?view=events`	`/overview.php?view=policies_network`

Troubleshooting

Common operator questions

Short answers to the questions we see most often during first-month rollouts.

Why does findings show low volume for one environment?

Validate that the environment has active sensors and current inventory events. Then verify date range and customer scope filters. If sensor health is green but event volume is zero, confirm the kernel version (5.8+) and that eBPF is not blocked by host policy.

Where should I start when alerts are noisy?

Open combined findings first, identify top process alert sources, then tune process and file policies for those binaries and paths. A small number of noisy binaries typically account for the majority of alert volume on day one.

How do I confirm host visibility is healthy?

Review Runtime Overview asset matrix and ensure host rows include process and file signal counts in the current time window. If the host row appears but signal counts stay at zero for more than a minute, check sensor logs on that host and kernel version (eBPF requires 5.8+).

Can I use policies without Kubernetes?

Yes. Policy controls support host and non-managed container use cases in addition to Kubernetes-managed workloads. The policy distribution path is the same across all deployment targets.

Where do the ingest commands live?

The console's deployment view renders per-tenant install commands with your customer UUID and pin. Template versions (with placeholders) are on the home page.

Is there an AI scoring or correlation layer?

Yes. After ingest, an AI event scoring job enriches raw events with context (process lineage, image history, endpoint reputation) before they land in findings. The data flow is shown in the architecture diagram on the home page.

Resources + pages

Where to go next

Every page in the product site, grouped so you can pick the right level of detail.

Home + overview

Landing page with feature pillars, deployment paths, architecture, and techniques.

index.html — marketing and quick overview
signup.html — account creation
overview.php — live runtime console

Per-target deployment pages

Printable one-page diagrams for review boards and change tickets.

References + console

Background references and the live runtime console.

overview.php — live runtime console (inventory, findings, events, policies)
privacy — privacy notice
Detection domain table — signal-to-control mapping

Need implementation help?

Use this order: sign-up, verify email, deploy sensor, validate events, then tune controls in the console.