Runtime security that runs itself
One sensor per Kubernetes node learns how each workload normally behaves, and flags what changes as signed evidence mapped to SOC 2, ISO 27001, PCI DSS and HIPAA controls.
Two Helm charts, the privileges it takes, and the per-node figures
The problem
Someone asked how you monitor production.
A customer's security questionnaire or your auditor wants to know what watches your Kubernetes workloads at runtime. "Nothing yet" isn't an answer.
There's no security team to answer it.
You're shipping product with a small team. Nobody owns runtime security. Hiring a security engineer runs $135K+ a year, and experienced cyber roles often take 3 to 6 months to fill.
Rule-based tools need someone to run them.
They assume someone writes and tunes the rules. If nobody owns that, the box stays unchecked.
Sources: Jobicy and ZipRecruiter US security engineer salary data (2026); ISACA State of Cybersecurity 2025.
A different approach
Rule-based runtime security asks you to anticipate the attack and then maintain the rule. PandoCore learns what normal looks like for each of your workloads instead, flags when behavior deviates, and responds within a ceiling you set. On a first encounter that reached isolation, detection to containment took about 60 seconds without a human in the loop. Install the two charts and the workloads already running on each node start learning, with nothing to label.
Measured on GKE: zero false isolations across 3,966 engine-hours of sensors permitted to isolate, 1,231 of them on the build we ship.
An engine is the per-pod detection instance, one pod to one engine. An engine-hour is one hour in which an engine was fully warmed and permitted to isolate; hours spent learning a workload's baseline are excluded, because an engine that is still learning cannot isolate anything.
What it solves
An answer for the questionnaire
"Yes, we monitor production at runtime."
Two Helm charts, with no rules to write and no security hire. PandoCore starts learning immediately and begins flagging changes after a 30-minute learning phase. Free covers detection and alerting on as many nodes as you like; containment is what the paid tiers add.
Evidence your auditor can inspect
"Here's the record."
Every detection becomes an Ed25519-signed evidence record mapped to SOC 2, ISO 27001, PCI DSS and HIPAA controls, so tampering is detectable. Your auditor decides what it's worth. PandoCore gives them something real to look at.
Response that can't overreach
"Safe to leave on."
The hardest thing PandoCore can do to a workload is cut its network egress. It cannot delete a pod, and that is not a promise: the sensor's Kubernetes permissions withhold pod deletion outright, so termination is unreachable whatever its licence says. You can set it more conservative, never less.
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. 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.
What you would actually run
Two charts, and nothing to label afterwards. Your portal dashboard carries both lines pre-filled with your license key and the current chart version.
# 1. The cluster controller
helm install pando-controller \
oci://us-central1-docker.pkg.dev/pandocore-prod/charts/pando-controller \
--version 2.0.0 \
--namespace pando-system --create-namespace \
--set license.key="YOUR_LICENSE_KEY"
# 2. The node sensor: one pod per node
helm install pando-node-sensor \
oci://us-central1-docker.pkg.dev/pandocore-prod/charts/pando-node-sensor \
--version 2.0.0 \
--namespace pando-system \
--set license.key="YOUR_LICENSE_KEY"The sensor requests 250m CPU and 256Mi per node and is limited to 2 cores and 1Gi. Those are per node, for the whole node, not per workload. 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. No CFS throttling, no OOMKill and no sensor restart in 77 hours.
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.
Join the pilot program
We're taking a small number of pilot partners, and we build the path to your first audit with you.
- Stay on Free as long as you like. It detects and alerts, and containment is the paid capability, so on Free nothing is ever acted on.
- When you do turn isolation on, which is the NetworkPolicy that cuts a workload's egress, we are on the call for it.
- A direct line to the founder, and a check-in every two weeks.
- 30% off Growth for your first year, which is $10.50 per node per month.
No one has taken PandoCore evidence through an audit yet. Pilot partners are the first.