Primod vs Tetragon: kernel-level enforcement or the workflow above the sensor?

01

What Tetragon is

Tetragon is an eBPF-based security observability and runtime enforcement project from the Cilium community, hosted by the CNCF. It is configured through tracing policies: Kubernetes resources that select kernel functions or tracepoints, filter their arguments inside the kernel, and optionally attach actions. Events are emitted as JSON with process ancestry and Kubernetes identity. Enforcement actions include sending a signal to the offending process and, where the kernel supports it, overriding a hooked function's return value so the operation fails.

Tetragon's strengths are precision and cost control: you see exactly the kernel events you asked for, filtered at the source, and you can deny an operation in the kernel rather than react after the fact. The trade is expertise. Writing a good tracing policy means knowing which hook to select, what its arguments mean, and whether an override is safe on your kernel.

02

What Primod is

Primod is a runtime security platform. Its sensor collects activity from supported Linux workloads and sends security telemetry to the platform. The platform's job is the workflow: an alert with process ancestry and workload identity, related alerts grouped into an ordered incident timeline, request context where instrumentation supplies it, Kubernetes workload views, and vulnerability prioritization informed by observed execution.

Primod ships its own behavioral detections. You do not author kernel hooks; you review findings, their evidence, and their limits. Response starts in observe mode and is a technical preview; on compatible nodes, operators can enable supported enforcement for selected rules.

03

Side by side

Tetragon is compared as a sensor and enforcement layer; Primod as a platform. The rows where Tetragon is the stronger option are stated as such.

Dimension
What it is	Open sourceeBPF security observability and enforcement; a Cilium project hosted by the CNCF	CommercialRuntime security platform: sensor plus investigation and vulnerability workflows
Sensor	eBPFIn-kernel filteringeBPF programs attached to the kernel hooks your tracing policies select; arguments filtered in-kernel	eBPFOne eBPF sensor per supported Linux node; Kubernetes or host mode
Policy model	Policies you writeTracing policies you write: kernel hooks, argument filters, actions	Shipped detectionsBehavioral detections shipped with the platform; rule revision recorded on every alert
Event precision	MatureExactly the hooks and arguments you select; very strong	Detection-scopedSecurity-relevant process, file, and network activity chosen by the detections
Enforcement	MatureSignals · overridesSignals and return-value overrides in policy, where the kernel allows	Observe by defaultTechnical previewObserve mode by default; supported enforcement on compatible nodes
Investigation	Your pipelineJSON events with process ancestry and Kubernetes identity; correlation is yours	Incident timelineWorkload identityIncident timeline, workload identity, request context where available, evidence-quality states
Vulnerabilities	Not in scopeNot part of the project	Inventory + runtimeInventory and runtime findings in one review; observed execution as one input
Delivery	JSON exportJSON to stdout, files, gRPC; export to your pipeline	OTLP exportOTLP export of alerts and incidents; receiver configuration required
Performance impact	eBPFMeasure itIn-kernel filtering keeps event volume low when policies are scoped; cost scales with the hooks you select. Measure per policy.	eBPFMeasure itSensor scoped to security-relevant events. Measure on representative workloads; no universal CPU figure or zero-loss promise.
System stability impact	In-kernel enforcementA return-value override fails the operation inside the kernel; a wrong policy can break an application. Test each policy on your kernel before enabling it.	Observe by defaultDesigned to fail openResponse targets one operation, never a pod kill, and starts in observe mode. Designed to fail open if the sensor stops; an application can still mishandle a denied operation.
Operations	You operate itPolicies, kernel and BTF compatibility, event volume per policy	Evaluated with youPrivileges, coverage, and resource use reviewed in a sales-assisted evaluation
Cost	Open sourceNo licence; kernel expertise to author and test policies	CommercialCommercial licence; demo and evaluation

Chips describe status and scope, not a score. Performance and stability rows are things to measure in your environment, not vendor figures.

04

Where Tetragon is the better fit

Choose Tetragon when kernel-level observability and policy-controlled enforcement are the requirement, and the team has or wants the kernel expertise. If you need to deny a specific operation in the kernel today, with a policy you can read and version, Tetragon is the more mature option. Platform teams that already run Cilium will also find it a natural extension.

05

Where Primod is the better fit

Choose Primod when the requirement is the workflow above the sensor. A security team that needs to hand a finding to the engineers who own the service, with the workload, the image, the sequence of observed activity, and the vulnerability context in one place, is buying something Tetragon does not try to be. Primod's response capability is deliberately labelled a technical preview; if enforcement is your first requirement, evaluate that section with your platform team before anything else.

06

Can they be used together?

Primod is not a Tetragon integration and does not consume Tetragon events. Running both on the same nodes is possible for an evaluation, with the usual caution about two eBPF programs attaching to overlapping hooks and the resource cost of each. Decide what the team needs to do after an event fires, then pick the sensor that serves that.

• Write one Tetragon tracing policy and one benign look-alike; note the time and expertise it took.
• Run the same scenario through Primod and compare what a responder can read from each output.
• If enforcement matters, test Tetragon's override on your kernel and Primod's observe-mode preview side by side.