Retention, evidence, and who touched the account

On a real production system running about 100GB a day, that change did two things:

• Idle searches went from 1,200 milliseconds to 11 milliseconds.
• Files opened per search dropped from 466 to 10.

Older data moves to a sealed tier that is simply a folder. Months outside your search window are never opened at all. There is no separate index to rebuild before a search or an alert can reach that folder: detections and dashboards query it directly, measured at 172 milliseconds for an alert and 76 milliseconds for a dashboard panel over a million events.

What this means for you: "how far back can I search" becomes a storage question, not a performance question. You stop choosing between logging everything a regulator might ask about, for as long as they might ask and staying inside budget.

Where your data sits

• In your own storage. AWS, Azure, Google, MinIO or Cloudflare. Your bucket, your keys.
• In an open format (OCSF Parquet). No proprietary index.
• Still readable if you leave. Other tools can query it directly.
• Required to be encrypted when you tell CAVER it holds protected data. It will not start against storage it cannot confirm is encrypted.

How sensitive identifiers are handled

To spot a pattern you have to know it is the same subject. To be safe, you would rather not hold their name. CAVER does both, converting the identifier into a salted one-way key:

• The same subject produces the same key, so activity links across systems.
• The key cannot be reversed into the original identifier, by us or by anyone who obtains it.
• The salt is unique to your deployment, so two sites cannot be cross-referenced, even by us.
• Carrying the real identifier is off by default and reported when it is on, so anyone auditing the deployment sees it without reading a config file.

What works on day one, and what needs a baseline

Almost all of this works the day your data lands. One part does not, and it is worth being exact about which part, because the difference is usually explained badly.

• Day one, everything rule-based. Access after termination, a login from a context that has never been used, a disabled account still authenticating. These are facts about your data rather than judgments about a person, so there is nothing to learn first.
• Two to four weeks, the behavioral detections only. Judging whether a person's activity is unusual means first knowing what usual looks like here. That baseline is the only thing that waits, and it waits while everything above it is already running.
• While it learns, CAVER says so. The behavioral models report themselves as not ready. You do not get an empty dashboard.

That last point is the one that matters. "We found nothing" and "we are not ready yet" look identical on a screen, and only one of them is good news. A tool that does not distinguish them is quietly telling you that you are safe during the exact period it cannot tell.

Silence is a result, and it is recorded

An agent that speaks only when it finds something is indistinguishable from one that is broken, and the second is far more common than anyone admits. Every run is written down whether or not it found anything, carrying what it checked and over what window. A quiet morning becomes evidence rather than an absence of evidence.

Why none of them needs a model

Twenty of the thirty-six are rules, joins and thresholds: the same data gives the same answer on any day, and it can be explained to an auditor as a query. The other sixteen are baselines, peer groups and rarity, which is still arithmetic over your own history. Five can use a language model to write their summary in prose; turn it off and you lose the wording, not the finding.

The platform roster covers the things an examiner asks about and nobody owns: a feed that stopped, coverage that rotted, access that outlived an employment.

They arrive switched off, and you switch them on

Every agent ships disabled, and you enable them one at a time from the product. That is deliberate. An agent making findings about named staff is a control you introduce deliberately, not one that appears at install.

Sysmon, read as process lineage

Sysmon process, network, file, registry, module-load, DNS and memory events all arrive as OCSF with the parent and child identifiers carried in the event, so a chain of executions joins across hosts rather than only inside one log line. A coverage screen shows which Event IDs are arriving now, which were seen in the last week and not in the last day, and which hosts are reporting. Every freshness figure is the time of the last event, never a count, because a count is satisfied by history: a source that died last week still has a large one.

Carbide, on Linux, Windows and macOS

• Kernel-level capture. On Windows it reads ETW and kernel providers, and on macOS EndpointSecurity. On Linux, process execution is taken at the kernel with eBPF, as one binary that runs across kernel versions without compiling per host. Container aware, with the container identity resolved in the kernel so it survives a process that has already exited.
• It says when it is blind. Every event declares its own collection source and fidelity. On a host where the kernel path cannot attach, the agent falls back to polling and marks every event as partial, so a thinner feed reads as thinner instead of as quiet.
• Silence raises its own alarm. The agent heartbeats on the channel it ships telemetry on. A host that stops is reported as missing, and a host that is reporting while collecting nothing is reported as empty, which is the case a green dashboard hides.
• Updates that undo themselves. Signed manifests, rollout by stage, and a version that will not come up puts the previous one back without an operator.
• One rule, every source. Detection content written for process lineage fires on a Windows Sysmon host and on a Linux, Windows or macOS Carbide host alike. That is asserted by a test in our build, not repeated in a slide.

That row is why the agent exists. A process that starts and exits between two polls is most of what execution telemetry is for, and a poller cannot see it.

Available to design partners

• Change control. Change plans are auto-drafted, config is captured and versioned as golden config, change access is time-boxed through PAM, and a change rolls back in one step.
• Windows endpoints. Carbide Console policy, execution control, BitLocker escrow and signed MSI rollout. Windows laptop deployment is delivered on request, typically within 30 days of order.
• UBA depth. Seasonal baselines, score decay and per-model precision and recall benchmarks.

The effect on a real board is the difference between "4,000 findings" and "these eleven are being exploited right now, start here".

Time to contain, measured

In 2026 CISA published an advisory in which two organizations faced the same red team with the same tradecraft and both fell to full domain compromise. One isolated three phished workstations in 10, 2 and 20 minutes and cut the command channel. The other actioned zero alerts. The difference was not the tooling and not the detection content; it was how fast a person acted on what the tooling already knew.

So CAVER measures that interval, per incident, from the case record:

• Detection to acknowledgement, how long until a person first acted.
• Acknowledgement to containment.
• Detection to containment, the headline number.
• Detection to close.

We publish compression and query speed as first-class numbers because they are how CAVER beats a per-gigabyte platform. Time to contain is the number that decides whether any of that mattered, and it is on the same screen.

Compression: 48 to 1, and how we measured it

• The top number is raw bytes received, which is what a per-gigabyte license would charge you for.
• The bottom number is the actual stored file size, taken from a storage listing.
• Our own system's internal logs are excluded from both.
• The ratio varies with your data mix.

Ask any vendor, including us, for the range across your own data types during a trial. Not just one blended figure.

Where the incumbents still win

An established SIEM has real advantages we will not pretend away:

• A large consulting ecosystem.
• A hiring pool that already knows its query language.
• A decade of your own custom content.

Those are genuine switching costs. Our answer is the parallel-run and collector-only options above, which let you measure the difference instead of taking it on faith.

• Every item carries a cryptographic fingerprint and a signature covering the content, time, case and the person who filed it. A signature cannot be moved onto different content.
• Custody records are append-only. They are never edited.
• The ledger uses the same proven construction that underpins internet certificate transparency.
• Every read and every check is logged, with who, when and why.
• Verification does not need CAVER. A separate signed program checks the whole chain offline, so an opposing expert, outside counsel or an auditor can verify it without touching your systems.
• Export bundles can be encrypted with AES-256 under a password you set.

What this means for you: a record a regulator or an opposing expert can verify independently, without access to your systems and without taking your word for it.

What is included: 24 content packs and over 200 rules, covering prompt manipulation, data leaving through an AI tool, misuse of connected tools, and runaway automation.

CAVER can also sit in front of your AI traffic as a checkpoint, with a full audit trail, per-user limits and blocking of unapproved AI services. An employee pasting customer data into an unapproved model provider becomes a recorded, scored event.

Two postures, and you choose

• Sealed. Fully self-hosted. On-site vendor access only. No remote connection out of your environment. Nothing leaves. Appropriate where a persistent vendor connection into a regulated environment is not acceptable.
• Managed. The conventional arrangement, with remote monitoring and vendor-assisted operations.

This is your risk decision. Both are real products. Neither is a discouraged version of the other.

Signing in with what you already have

SAML 2.0 and OpenID Connect are both configured in the product: paste or fetch your identity provider's SAML metadata, or point at your OIDC issuer for discovery, then map the attributes or claims to roles. Test against the live provider before you can turn it on: enable is refused without a successful test in the last 24 hours. A saved change or a disable takes effect on the next request, no restart, and local login stays reachable so an identity-provider outage cannot lock your operators out. An OIDC client secret is sealed in the product's credential vault, never stored in the clear.

Provisioning through SCIM

SCIM provisioning is configured the same way: an operator mints a bearer token for the identity provider, shown once and stored only as a hash, revoked on the very next request rather than the next restart. Group membership from SAML, OIDC, or SCIM maps to roles by the same rule.

Four ways to start

• Full migration, with a practice run before cutover.
• Run alongside your current SIEM while your team checks coverage. CAVER can register as a Splunk search peer, or federate with Elastic, Sentinel, Sumo Logic or Datadog, so both systems answer the same question and you compare the answers.
• Collection only, sitting in front of your current tool with no disruption.
• One piece at a time. Take the Evidence Locker, AI monitoring or compliance reporting without replacing anything.

And everything else

• Anything that keeps a log. Syslog, a log file, Windows events, a cloud audit trail, a database table.
• Anything with an API. If it can be polled or can push, CAVER can take it.
• Anything that talks on a network you can mirror to us. Even with no log and no API.
• Custom collectors are built to order. That is ordinary work here, not a special request. If you have a system that matters and nothing off the shelf reads it, say so during the trial and it gets built.

More than 400 ready-made vendor packs ship for the common systems, so the bespoke work is the exception rather than the starting point.

1. Price seven years of retention against what you pay today for the minimum you are allowed to keep.
2. Run the insider models against a known past incident and see whether it surfaces without being told what to look for.
3. Ask what CAVER shows during the learning period. It should tell you it is not ready, not show you a clean dashboard. This is the claim that is easiest to fake.
4. Verify an evidence export yourself. Run our offline checker against a real export without touching the CAVER console.
5. Ask for the compression range across your data types, and for the load ceiling next to any speed figure.
6. Run it alongside your current SIEM so migration risk is measured during the trial rather than assumed afterward.