Newly released · included with Caver · no extra charge

Carbide.The EDR that comes with the SIEM, at no additional cost.

Endpoint detection has been priced per agent for a decade, which is why so many estates have sensors on the servers that were easy to justify and nothing on the ones that were not. Carbide is included with Caver. Kernel level collection on Linux with eBPF CO-RE, container aware, OCSF on the wire, landing in the same lake as everything else you collect. No per-endpoint line item, no second console, no separate query language.

Request evaluation access →→Read the Carbide docs

Coverage gaps are usually a budget decision wearing a technical explanation

Ask why a host has no sensor and the answer is rarely that nobody thought of it. It is that the agent had a price, the host was not on the list that got funded, and the gap became permanent. Pricing the agent separately from the platform creates exactly the blind spots the platform then fails to see. Carbide is included because a sensor you decline to deploy protects nothing.

What Carbide gives you

An endpoint agent designed by people who had to run the SIEM afterwards.

Included, not another per-endpoint line item

Carbide ships with Caver. There is no per-agent charge, no seat count to true up at renewal, and no conversation about which hosts are worth covering. The estate you own is the estate you cover.

One lake, not a second console

Endpoint telemetry lands in the same lake as your firewall, identity, cloud and OT data, in the same schema. A process execution and the login that preceded it join in one query, because they were never in different systems.

Linux first, properly

Most EDR is Windows-first with Linux bolted on. Carbide starts on Linux with eBPF CO-RE: one binary across kernel versions, no per-host compilation, no kernel module to shear off during a patch window. It is the platform Sysmon-based detection content cannot reach at all.

Container aware in kernel

The container identity is resolved in kernel at the moment of execution, so it survives a process that has already exited. Short-lived containers are exactly where the interesting executions are, and exactly where a userspace poller loses them.

Lineage that actually joins

Parent and child are part of the event contract, not inferred afterwards from timestamps and hope. A chain follows across event types, which is the difference between a list of executions and a story about one.

It tells you when it goes blind

Every agent heartbeats on the same channel it ships telemetry on. A host that goes quiet raises an alert. A host that is reporting but collecting nothing raises a different one, because a green agent that has stopped seeing is the failure a dashboard hides.

Updates that undo themselves

Signed manifests, staged rollout by cohort, and a version that will not come up puts the previous one back on its own with nobody logging in. The rollback runs the same install path as an ordinary update, so it is not a route first attempted on the day it is needed.

OCSF on the wire, not a proprietary blob

Events leave the agent already in OCSF. There is no vendor schema to reverse engineer later, and no exit tax if you ever want the data somewhere else.

Two collection paths, one event shape

A fallback that emits a different schema is a second integration nobody maintains. Carbide's fallback emits the same OCSF records at lower fidelity, and says so on every event.

ebpf

eBPF CO-RE

Kernel tracepoints, one artifact across kernel versions and distributions. Full fidelity.

fallback

auditd and journald

For older kernels and hosts where loading eBPF is not permitted. Same OCSF shape at lower fidelity, never a different one.

declared

Fidelity is on the event

Every record says which path produced it. A degraded collector reads as degraded rather than quietly thinner, so nobody mistakes a gap for a quiet week.

Detection you can act on

Detection without response leaves an analyst reading about something they cannot stop. Carbide takes host actions driven from Caver, and because the detection and the response live in one platform, the trigger can be the content of a finding rather than the name of an alert.

Kill a process

Terminated by its stable identifier, so the action lands on the execution the detection fired on rather than on whatever now holds that PID.

Isolate a host

Network lockdown that leaves the agent channel reachable, so an isolated host stays observable and recoverable without a site visit.

Quarantine a file

Moved out of execution path into custody and hashed on the way, so the sample survives for analysis instead of being deleted by the responder.

Automation that reads the finding, not the alert name

Playbooks fire on what a detection actually found: the entity, its accumulated risk, the technique, the observables attached. A rule matching a known-bad hash can kill and quarantine outright, while the same rule at lower confidence only opens a case. A host can be locked down when its risk score crosses a threshold rather than on any single rule, which is the case a standalone EDR cannot make, because it only ever sees its own signals. Where a human decision is the right answer, a step waits for approval: isolating a domain controller at 03:00 is a decision, not an automation.

Response runs on a separate channel from collection, deliberately

The collector is one way. It ships events and cannot be instructed. Response instructions arrive over their own authenticated path with their own authorisation, because a collector that can be told to execute is a collector worth compromising, and an attacker who owns the telemetry agent should not thereby own remote execution across the fleet. Every action taken is recorded on the case with who authorised it and what it returned.

Carbide and Sysmon are the same telemetry, on two operating systems

These are not alternatives you choose between. Caver already normalizes Sysmon: the collector subscribes to theMicrosoft-Windows-Sysmon/Operational channel and reads it with no per-host configuration. Carbide is held to the same OCSF contract that the Sysmon path produces, down to the field paths, so the product name is the field that should differ between the two producers, and close to the only one.

That is the whole point of the pairing. Detection content is written once. A rule matching on a command line with a parent process fires on a Windows Sysmon host and on a Linux Carbide host, and there is no second Linux version of the rule that has to be kept in step with the first one. It also means the content you already have keeps working: adopting Carbide does not start a migration.

Windows today

Sysmon through the collector, which is what the content assumes. Nothing about Carbide changes that path or asks you to replace it.

Linux today

Carbide, on eBPF, on the hosts Sysmon was never going to reach. The same records, the same field paths, the same rules.

More than process starts

File, memory, module load and DNS events are classified rather than dropped into a generic bucket, so content spans the whole channel.

Linux first, on purpose

The endpoint market is Windows-first and it shows. Linux support tends to arrive as a port, with a kernel module that breaks on patch day and a detection library that was written for a different operating system. Carbide starts where the servers are, and where the widely deployed detection content genuinely cannot reach. Windows, macOS and AIX follow, on the same shared core and the same OCSF contract, so a second platform is an addition rather than a second product.

And Carbide does not have to be the only sensor. Caver ingests CrowdStrike, Defender, Sysmon, syslog and the forwarders already deployed in your estate. Most environments will run both, with Carbide covering the hosts where the alternatives were never a realistic option.

Put it on the hosts you could never justify covering

Carbide comes with Caver. If you are already evaluating the platform, the agent is part of what you are evaluating.

Request evaluation access →See pricing