The Primod platform
Runtime evidence
for the decisions that follow.
Investigate suspicious behavior, understand affected workloads, and bring production execution into vulnerability prioritization. Primod connects the sensor's observations to the workflows security and engineering share.
Understand why the alert fired.
Review the observed activity, process ancestry, and workload identity behind a finding. Follow related alerts through an ordered incident timeline, with request context when it is available.
- What was observed
- Where it ran
- What followed
The evidence keeps its limits. An attempted operation is different from a successful one, and gaps in capture matter when interpreting a finding.
Explore runtime threat detectionIncident timeline · 4 related alerts
+0 ms
POST /api/upload
Observed+18 ms
Web process launches /bin/sh
Succeeded+43 ms
Process opens service-account token file
Succeeded+91 ms
Connection to 203.0.113.10:443
Failed
Illustrative attack scenario · Product UI preview
Put production execution into the patch decision.
A vulnerability in an image is a starting point. Primod's vulnerability views bring inventory and runtime findings into a workflow for reviewing execution evidence, affected workloads, and available fixes.
Use runtime observations alongside severity, exposure, and your remediation policy. A code path that has not been observed executing is not proven safe.
Explore vulnerability prioritizationVulnerability Funnel
Illustrative vulnerability workflow · evidence levels shown only where the finding supports them
Example finding · real CVE, sanitized reference data
Call stack
Call-stack excerpt · where runtime and language support capture it
Start with the service your team recognizes.
Move from a finding to its Kubernetes workload context: namespace, pod, container, and image information where available. Give engineering a concrete place to begin the investigation.
- Workload
- Image
- Finding history
Topology edges show how the cluster is organised. They are not labelled as attacker movement unless supporting events exist.
Activity Timeline
Every detection, version change and remediation for this workload, in the selected period.
Version History
Every image version this workload has run, and how long each was live.
Finding history · reference workload
Workload map · node → namespace → pod → container
Preview the action before enabling it.
Start with observe mode to review what supported response policies would deny. On compatible nodes, operators can enable supported enforcement for selected rules or hardening policies.
The response mechanism targets an operation rather than using a pod kill as its unit of action. Availability depends on the operation, policy, and kernel capabilities. Review the rollout with your platform team.
Observe mode does not block. A requested action is not a confirmed denial.
Discuss response requirementsResponse preview · observe by default · Product UI preview
Illustrative AI workload scenario · Product UI preview
Follow what the AI workload did.
Investigate suspicious commands, credential access, and network activity associated with supported AI workloads. Runtime evidence helps security and AI platform teams examine the consequences of agent actions.
The sensor observes what a process did. It does not classify prompt intent or read the model's output.
Explore AI runtime securityEvaluate the fit for your environment.
Deploy the runtime sensor on supported Linux environments and send security telemetry to the Primod platform. Review privileges, workload coverage, and resource use as part of your evaluation.
Alerts and incidents can be exported through OTLP, OpenTelemetry's transport protocol. Destination compatibility depends on receiver configuration and field mapping.
Coverage and evidence quality belong in the evaluation. Check which detections are available on your nodes and inspect telemetry for capture or delivery limitations.
Primod SensoreBPF · one per supported Linux nodeKubernetesDockerHost mode
Primod PlatformAlerts, incidents, workload context, vulnerability findingsInvestigatePrioritizeRespond (preview)Alert export runs on its own queue. A bounded queue can drop alerts under sustained pressure; the evaluation should confirm delivery requirements for your receiver.
Supported environments
OS, kernel, runtime, required privileges, and detection-versus-enforcement coverage are confirmed per environment against the current release rather than published as a blanket matrix.
Bring a real security question.
We can walk through a runtime finding, review a vulnerability workflow, and discuss the deployment requirements that matter to your team.
Request a demoIllustrative product UI · 65-second tour, captions on
Buyer questions, concise answers.
What the evidence includes, what it does not prove, and what to confirm during an evaluation.
- What is Primod?
- Primod is a runtime security platform. A runtime sensor collects activity from supported Linux workloads and sends security telemetry to the platform, which brings investigation and vulnerability workflows together. Process activity, workload identity, and available request context help teams understand findings and decide what to investigate or fix.
- Does every alert include an HTTP request?
- No. Request context depends on supported instrumentation and an available span. Activity outside a traced request can still carry process evidence.
- Does observed execution prove a vulnerability was exploited?
- No. Execution is one input to prioritization. Exploitability also depends on the vulnerability, configuration, inputs, and other conditions.
- Does observe mode block activity?
- No. It shows what supported policies would deny. Enabling enforcement is a separate operator decision and depends on node capabilities.
- Can Primod send findings to our existing tools?
- Alerts and incidents have an OTLP export path. The evaluation should confirm your receiver, field mapping, and delivery requirements.
- What performance impact should we expect?
- Measure the sensor and scanning workload in a representative environment. We do not promise a universal CPU percentage or zero event loss.
- How is Primod deployed?
- The runtime sensor is deployed on supported Linux environments, on Kubernetes nodes or in host mode, and sends security telemetry to the Primod platform. Privileges, workload coverage, and resource use are reviewed as part of your evaluation.
Have a workflow in mind?
See the evidence behind the alert.
Weekly email
Runtime Evidence
One email a week: a runtime finding worth understanding, how it was investigated, and what to check in your own clusters. No product pitches in disguise; unsubscribe in one click.