Runtime threat detection for Kubernetes, with the audit evidence to prove it.
Maps to SOC 2, ISO 27001, PCI DSS, and HIPAA. One sensor per node, learning your workloads from the first sample. No security team required.
What PandoCore does
Traditional runtime security tools require you to write detection rules for every threat you want to catch. If you don't write the rule, you miss the attack.
PandoCore takes a different approach. It automatically learns what normal looks like for each workload, then continuously monitors for deviations. When anomalous behavior is detected, it responds with a graduated action chain: alert, then isolate. On a first encounter that reached isolation, detection to containment took about 60 seconds without a human in the loop, measured twice on live infrastructure.
Automatically learns normal patterns and detects anomalies
Graduated response: alert, then network isolation
No rules to write, works out of the box
250m CPU and 256Mi requested per node, limited to 2 cores and 1Gi. One sensor per node, whatever that node runs.
Installing it is two Helm charts: see Getting Started, or the configuration reference for every value it takes.
Complements your security stack
PandoCore runs as a node-level agent and a cluster controller in its own namespace. Nothing is injected into your pods, and your workloads are not modified or restarted to be protected.
PandoCore is not a replacement for encryption, authentication, a service mesh, observability, secrets management or network policies. It adds a behavioral detection and response layer at runtime, alongside the controls you already run. If one of them fails, a behavioural layer narrows what that failure buys an attacker; it does not cancel it.
Compliance controls
PandoCore is a runtime threat detection control for Kubernetes. It does not make you compliant; your auditor decides that. It gives you a control that runs continuously and evidence that it ran.
Free on unlimited nodes for detection and alerting. Auto-issued on signup, no card and no call.
Start free| Framework and control | What the control asks for | What PandoCore provides |
|---|---|---|
| SOC 2 CC7.2 | Monitoring system components for anomalies that may indicate malicious activity | Learns each workload's normal behavior and alerts on drift. Every detection produces a signed evidence record with alert history in the portal. |
| SOC 2 CC6.8 | Detecting unauthorized or malicious software | Detects unexpected process execution inside protected workloads, including cryptominers. |
| SOC 2 CC7.4 | Containing security incidents | Optional response: isolate a workload by network policy. Every action is logged with the evidence that triggered it. Your incident response plan stays yours. |
| ISO 27001 A.8.16 | Monitoring for anomalous behavior and evaluating potential incidents | Continuous behavioral monitoring with graded alerts and a record for each event. |
| ISO 27001 A.8.15 | Producing, protecting, and retaining logs | Evidence records are cryptographically signed (Ed25519), so tampering is detectable. Retained per plan. |
| ISO 27001 A.8.7 | Protection against malware | Unexpected process detection across protected workloads. |
| ISO 27001 A.5.26 | Responding to security incidents per documented procedure | Response actions execute your procedure and leave a signed record of what ran and why. |
| PCI DSS 5.3.2 | Anti-malware that performs continuous behavioral analysis of systems or processes | Continuous behavioral analysis is what PandoCore does. Per-workload baselines and full detection history. |
| PCI DSS 5.3.4 | Anti-malware audit logs enabled and retained | Detection logging is always on for protected workloads and retained per plan. |
| PCI DSS 10.3.2 | Audit logs protected from modification | Signed evidence chain. Tampering is detectable. |
| PCI DSS 10.5.1 | 12 months of audit log history, 3 months immediately available | Enterprise plans retain evidence for 13 months, Growth for 90 days. This is the period evidence is kept for, and makes no claim about querying it. |
| HIPAA §164.308(a)(1)(ii)(D) | Regularly reviewing records of information system activity | Detection history and signed evidence records in the portal. |
| HIPAA §164.308(a)(5)(ii)(B) | Guarding against, detecting and reporting malicious software | Detects unexpected process execution inside protected workloads, including cryptominers. |
| HIPAA §164.308(a)(6)(ii) | Identifying, responding to and documenting security incidents | Optional response: isolate a workload by network policy. Every action leaves a signed record of what ran and why. |
| HIPAA §164.312(b) | Mechanisms that record and examine activity in systems containing ePHI | Records and signs detection events for protected workloads. |
PandoCore holds no third-party security attestation yet; the trust center states where we stand and what we target.
Validated against real workloads
The node sensor has been run against production-representative workloads in extended soak runs on GKE. No manual configuration or tuning was performed, and every workload ran with default settings.
Zero false isolations across 3,966 engine-hours of sensors that were permitted to isolate, 1,231 of them on the exact build we ship.
Measured warm and enforcing on the shipping build, across two runs: a 130.4 mCPU p95 with a 106.9 MiB working set over a 24-hour warm window, and 127.3 mCPU with 110.6 MiB over a 34-hour run. The working set held a flat slope in both, so there is no leak to grow into the limit.
Cumulative across two runs rather than one unbroken window, measured on one node per run, against production-representative synthetic workloads rather than customer traffic. A zero bounds the rate rather than being one: at most one false isolation in 1,324 engine-hours, at 95 percent confidence. Profiling is automatic across the 24 workload types these runs covered, spanning web servers, databases, and JIT and interpreted runtimes, with no manual tuning required. These figures are from the node sensor; the earlier per-pod collector's numbers are not carried forward. Those runs measured CPU, memory and false isolations. They are not a measure of detection coverage, and we do not present them as one.
The access it needs, and what it is denied
The sensor runs as a hostPID DaemonSet, as uid 0, with CAP_SYS_PTRACE, reading the node's process namespace read-only. Anything that never executes there is outside what it can see. That is a real privilege, and what bounds it is the grant rather than a promise: its ClusterRole withholds pods: delete, pods: patch and endpoints: get by name. Each sensor watches up to 70 pods per node, and a Prometheus gauge reports any past that.
It will not run on GKE Autopilot or EKS Fargate. Both forbid hostPID, so there is no install path on either. Standard GKE is the configuration this release was validated on.
Getting Started has the rest: the externally managed Secret to use where your values file is committed, the opt-out label, and what the learning window does before anything can be detected.
You have enough here to decide
The mapping, the measurements and the privileges are all above, limits included. If that leaves something open, let's talk.