Jibril Review: eBPF State Maps Instead of Event Streams — What Garnet's Runtime Sensor Actually Delivers

Jibril is a Linux runtime security sensor built by Garnet Labs Inc., an Ontario-registered company led by Rafael David Tinoco, a core developer of Aqua Security's Tracee before this. It launched on Hacker News in March 2025 with a thesis worth taking seriously: most runtime security tools stream every kernel event through ring buffers into a userspace engine, and on ephemeral, bursty workloads — CI runners, short-lived pods, edge boxes — that pipeline costs more than the detection it produces. Jibril inverts the model: eBPF programs continuously maintain state maps in the kernel, and a userspace query engine polls those maps on a fixed cadence to evaluate detection recipes against whatever the kernel currently knows. No ring buffer, no per-event userspace hop, bounded memory by construction.

The short version: the architectural bet is real and internally consistent — the docs describe map types, cache sizes, and poll intervals with unusual honesty, down to admitting that a badly tuned cadence produces constant CPU and that undersized caches overflow. The supply chain story is genuinely above the industry bar: keyless Sigstore signing, attestations, a public release ledger, and a verification doc you can hand to a security team. But the review found three things the marketing does not lead with. First, the enforcement story has shrunk since launch: the JavaScript reaction engine that once killed, paused, and introspected processes is deprecated — "no longer built," rules carrying a reactions: block now fail validation — and the only synchronous enforcement left is DNS-aware network policy. Second, roughly half the shipped detection corpus (23 of 45 recipes) is private: the compiled logic ships in the binary, and you cannot read it. Third, the "open source" framing that circulates in third-party coverage is simply wrong — the release channel README states plainly: "Binary distribution only; source is not public." The license is MIT-Binary-Restricted, internal use only, redistribution prohibited, reverse-engineering prohibited, in a binary that embeds GPLv2 eBPF objects. If you can live with a closed-source root sensor on every node, the query-driven model is one of the more original designs in this space. If you cannot, nothing else about Jibril will change your mind.

We downloaded the actual v2.17.0 binary, verified its SHA-256 against the published checksums, ran it on a kernel 6.8 host, and traced every architecture claim in this review to the vendor's own documentation or to GitHub API data — including the places where the docs contradict the marketing. This review is grounded in the current stable release (v2.17.0, September 2026) and the v2.18.0-rc.2 prerelease (November 6, 2026), with the March 2025 launch material used only to show what has changed since.

Executive Scorecard

What Jibril Actually Is — and What It Is Not

Start with the identity facts, because they determine whether this tool can enter your environment at all:

• The vendor: Garnet Labs Inc., registered in Ontario, Canada. The lead developer is Rafael David Tinoco, who describes his own background as core developer on Tracee (eBPF) and Ubuntu, with stints at Aqua Security, Canonical, IBM, Linaro, Red Hat, and Sun Microsystems. The pedigree is real and it shows in the engineering choices.
• The product surface: Jibril is the sensor. Garnet — the company's commercial product at garnet.ai — is a CI runtime review service that runs Jibril on GitHub Actions runners and posts "Execution Profiles" to pull requests at $0.50 per run after 500 free monthly runs. The sensor is free to use internally; the money is the control plane.
• The distribution: a single statically linked, stripped ELF binary (~87 MiB) from garnet-org/jibril-releases, plus a Docker image (garnetlabs/jibril) and a Helm chart. The vendor's own release channel README says it directly: "Binary distribution only; source is not public."
• The license: MIT-Binary-Restricted (MIT-BR) — free of charge for internal use only, with distribution, publication, sub-licensing, and reverse-engineering all prohibited without written consent. The embedded eBPF objects are GPLv2; the userspace loader and agent are MIT-BR, statically linked with libbpf (LGPLv2.1 OR BSD-2-Clause).
• The maturity: v2.17.0 is the current stable (September 9, 2026) after a ten-round release-candidate train; v2.18.0-rc.2 shipped November 6, 2026; the Docker Hub v0.0 daily-build tag is pushed continuously (the newest at the time of writing: the same morning this review was written). The release cadence is healthy. The community is not: 6 stars, and the issue tracker contains exclusively the vendor's own release-automation ledger entries — zero user-filed bugs.

The release train itself is worth a table, because it tells you where the project's energy is going:

The Architecture: State Maps, Not Ring Buffers

Every mainstream runtime security sensor — Falco, Tracee, Tetragon's observability path, and commercial EDR — is built on some version of the same spine: eBPF (or a kernel module) fires per-event, the event crosses into userspace through a perf event array or BPF ring buffer, and a userspace engine evaluates every event against rules. Falco's kernel-events architecture documents exactly this shape: capture in the kernel, deliver over a ring buffer, evaluate in userspace. The failure modes of that spine are equally well known: ring buffers drop events when consumers fall behind, the per-event userspace hop scales with workload, and short-lived workloads can be gone before their event stream is processed.

Jibril's docs describe the inversion in one sentence: "Jibril retrieves security events on demand from kernel memory rather than streaming them through ring buffers. This query-driven model eliminates overflow, bounds memory usage, and maintains constant CPU overhead regardless of event volume." The kernel-side components do the same continuous capture as everyone else — process execution and lifecycle, file access and modification, network connections and DNS queries, container operations — but instead of shipping events, the eBPF programs maintain three map families: hash maps for event metadata and context, array maps for configuration and counters, and LRU maps whose eviction is the memory bound. The userspace side is a query engine that polls the maps on a configured cadence, correlates what it drained, and hands the result to a detection engine that walks every enabled recipe, assigns threat scores, and routes detections to outputs.

CLASSIC EVENT-STREAMING PIPELINE (Falco / Tracee / Tetragon class)

        KERNEL                             USERSPACE
  kprobes / tracepoints            perf-array / ring buffer
        │                                   │
        ▼                                   ▼
  eBPF captures EVERY event ──────► agent reads every event
  (argv, env, payloads included)    rule engine evaluates
        │                           EACH event, one by one
        │                                   │
        └─ alert latency: µs–ms             ▼
                                    outputs (per event)
  loss mode: ring buffer drops when consumer falls behind


JIBRIL QUERY-DRIVEN PIPELINE (state maps + cadence polling)

        KERNEL (continuous)                   USERSPACE (every cadence tick)
  eBPF hooks write STATE, not events          query engine polls maps
        │                                     correlates + filters
        ▼                                     │
  hash maps ─ tasks, files, peers, flows       ▼
  array maps ─ config, counters           detection engine walks
  LRU maps  ─ bounded, evict oldest       ALL enabled recipes
        │                                     │
        ├─► DNS answer observed ─► sync network policy (drop NOW)
        │                                     ▼
  loss mode: LRU eviction before     outputs (batched per tick)
  the next poll reads the map       alert latency: up to cadence (default 9 s)

Three properties of this design deserve the senior-engineer once-over, because they are the actual product:

Bounded memory is architectural, not tuned. The LRU eviction that bounds RAM is the same mechanism that silently discards state. The vendor is refreshingly explicit about this in the cache tuning docs: "Shorter cadences may require larger caches: less time to process cached data before new data arrives; risk of cache overflow if processing takes too long." Translate: the "zero event loss" claim on the detection mechanisms page has an asterisk — under enough process/file/network churn with default cache sizes (16–64 entries per map), entries can evict before a poll reads them. The docs' own memory-profile guidance implicitly acknowledges the workload dependence:

The CPU story is a single-core design, stated verbatim: "While much of its logic could be parallelized, it has parts that are intentionally serialized to ensure that no more than a single CPU core is utilized at any given time, even on high-traffic systems." That is the right trade for edge and CI runners and the wrong one for a 256-core database host — one core is the ceiling of detection throughput, and each evaluation pass walks every enabled detection recipe against the drained state.

Enforcement and detection are decoupled, and only one is synchronous. The network policy path is enforced in the kernel at connect time — "Jibril intercepts DNS queries and enforces policy at kernel level for the resolved IPs, as soon as they are known (this is a synchronous operation)" — independent of any cadence. Detection alerting, by contrast, happens when the next cadence tick runs, a distinction the cadence documentation makes explicitly: cadences do not affect policy application, detection accuracy, data collection, or event loss — they govern how long a completed attack pattern sits in a kernel map before anyone is told about it.

The Cadence Contract: Detection Latency You Configure

This is the paragraph to read before any procurement conversation. Jibril's detection latency is not a number the vendor measured — it is a number you pick in YAML. The default is 9 seconds. The vendor's own performance table for a five-minute window:

Two sentences in the cadence documentation do more damage to the marketing than any critic could, so quote them in full. First: "Depending on workload, cadences might last tens of seconds" — meaning the configured interval is a floor, not a ceiling; a heavy evaluation pass on a busy host extends your effective detection latency beyond what you configured. Second, the tell for sizing: "Constant CPU usage means cadences are too short." The "constant CPU overhead regardless of event volume" claim on the architecture page and the "constant CPU usage is a misconfiguration symptom" guidance on the cadence page are the same fact seen from two angles — the sensor will happily consume its single core every tick if you ask it to, and the operator's job is to lengthen the interval (stretching detection latency) until it does not. There is no published benchmark anywhere in the vendor's materials quantifying any of this: the comparison pages carry adjectives ("Critical environments are welcome", "No other tool matches this level of visibility") and zero measurements, zero methodology, zero comparison systems. Any "typically under 5% CPU" figure you may have read in third-party coverage is not a vendor number and has no published methodology behind it.

For fairness in the other direction: a ring-buffer sensor does not escape this conversation either, it just relocates it. Falco-class pipelines trade cadence tuning for buffer sizing and userspace rule-evaluation cost — under load they drop events at the buffer, where Jibril evicts at the LRU map. Neither model gives you free real-time on constrained hosts; Jibril's version is simply more legible in the config file, which is a genuine operational virtue.

Enforcement: The Feature That Shrank

The March 2025 Show HN launch marketed Jibril as "runtime security monitoring and enforcement": freezing suspicious processes, killing, pausing, introspecting. In the launch thread, the lead developer described the design in detail: "We have synchronous actions (like our network policy update, and, soon, execution and file access policies) and mitigation reactions (try to kill, pause, introspect, etc) jittered from original trigger." The HN audience asked exactly the right question — one commenter asked how false positives would avoid taking down legitimate workloads, and another reported having abandoned Falco in production and "long[ing] for a production-ready runtime monitoring tool that can ACTUALLY be used in a blocking mode."

Nineteen months later, the v2.17 docs tell a different story, and it is the most important thing this review verified. From the architecture page: "The JavaScript-based reaction engine is no longer built, and a rule carrying a reactions: block fails validation. Network blocking is done by the network policy." From the network policy page: "Reactions, which used to do this programmatically, are deprecated and no longer executed." The promised "execution and file access policies" do not exist in v2.17. What remains is real but narrow:

• Synchronous network policy, off by default. The shipped configurations comment the policy feature out; netpolicy.yaml is installed but not loaded. When enabled, it enforces allow/deny rules over IPs, CIDRs, and domains at connect time, with DNS interception pinning policy to resolved IPs the moment an answer arrives. Blocked connections emit dropip events carrying the offending process, its tree, and its opened files.
• Honest degraded-mode behavior. A rule that is invalid or fails to load into the kernel is skipped, logged, flagged in jibril.status.json (features.policy: degraded with per-rule error messages), and the process exits with an error at shutdown — the sensor refuses to die silently. This is better failure behavior than most of the market ships.
• No process enforcement, at all. Nothing in v2.17 kills, pauses, freezes, or contains a process. Detection recipes generate events; blocking a domain means listing it in netpolicy.yaml. If your incident response playbook requires in-place process termination from the sensor itself, this is disqualifying in the current release — Tetragon's enforcement model (in-kernel policy actions including synchronous SIGKILL from the kernel) is the open-source reference for what Jibril does not offer.

Note that third-party coverage has not caught up with this pivot: at least one syndicated blog post still describes live process-freezing capabilities. Verify against the current docs before you plan around anything you read about Jibril secondhand — including this review; the enforcement surface has already changed direction once.

The Detection Corpus: Half of It Is a Black Box

Jibril ships roughly 45 detection recipes organized into two mechanisms — file-access and execution — each with MITRE ATT&CK tactic/technique/subtechnique fields, severity, and confidence. The rules documentation splits them explicitly into public and private: "The reason private rules are private is to: maintain competitive advantage in threat detection; protect proprietary threat intelligence sources; prevent adversaries from ingesting detection logic." Count them from the vendor's own list:

So 51% of the shipped corpus — including the recipes most teams actually care about first (credential file access, crypto-miner execution, execution from unusual directories, webserver-to-shell, runc anomalies, DoS tooling) — ships as compiled logic inside a closed binary. The security-model page is candid about the mechanism: "Detection recipes are distributed both as compiled logic and source patterns. If compiled, the detection logic is not exposed at runtime." For a detection engineering team, this is a categorical difference from Falco or Tracee, where every shipped rule is readable YAML or Go and every match is auditable down to the operator. You can still author your own recipes — the YAML schema is documented with breed, mechanism, MITRE fields, noise-reduction times blocks, and arbitrary filters over exe/comm/cmd/uid/pid/parent — and custom rules are genuinely first-class. But the default posture is trust-the-vendor, and the license prohibits you from verifying the compiled half by disassembly.

The second corpus limitation is stranger and worth internalizing before you write your first rule: process arguments and environment variables are never collected. The cache documentation is explicit on both: "Process arguments are never collected. The args cache key is still accepted so existing configs load, but it has no effect" and "Environment variables are never collected, the key is still accepted in the configuration file and ignored." This is a deliberate, defensible privacy posture — especially for the CI-runner use case where argv and env carry every secret in the pipeline — and it pairs with the Garnet product's "not your source, not your secrets" scope. But it has real detection consequences: no recipe can ever key on a command line. You cannot distinguish curl https://internal-host/metadata from curl https://pastebin.com/payload by argument; you match on the binary, the file paths it touches, and the peers it connects to. Meanwhile the visibility comparison page still sells "No other tool matches this level of comprehensive, tamper-proof visibility" — a sentence that sits awkwardly next to "never collected" in the same documentation tree. The correct framing: Jibril has complete visibility of resources and relationships (processes, files, peers, flows, ancestry) and zero visibility into arguments. Whether that is a feature or a hole depends entirely on your threat model.

The Attenuator: An LLM in the Alert Path

Jibril's optional AI layer is the Attenuator — a post-detection filter that sends each detection to an OpenAI-compatible chat-completions endpoint and gets back a structured verdict: is_false_positive, a re-scored severity and confidence, and a natural-language interpretation. The documented modes escalate meaningfully: amend annotates, reason annotates with model thinking, and block — quote — "automatically filters out events deemed false positives, dropping them without further processing." In block mode, a language model holds deletion authority over your security telemetry. The docs at least flag it ("use with caution") and recommend starting in amend/reason, and the feature is disabled by default. Default model: gpt-4o, temperature 0.3, per the configuration table.

Two production realities to plan around. First, data governance: enabling the Attenuator ships the event's full context — process tree, binary names, file paths, network peers, timing — to whatever endpoint you configure. The docs example is api.openai.com; the same configuration accepts a local Ollama instance (url: http://localhost:11434/v1/chat/completions), which is the only way to keep this data on-host, and the docs deserve credit for documenting that path with a concrete example model. Second, failure behavior: the docs do not specify what happens when the LLM endpoint is slow, unreachable, or returns garbage — the event pipeline documentation says transformer failures stop processing of the affected event, but Attenuator behavior under endpoint failure is unstated. Before enabling block mode anywhere that matters, answer: what is the alert path when the model is down, and who audits the drops? An alert-suppression system with an undocumented outage mode is an incident-review finding waiting to happen.

Hands-On: The Binary Itself

We downloaded the v2.17.0 release directly from the vendor's release channel and verified it end to end. Scope statement for integrity: this host runs Linux 6.8 but has no root or capability path to load eBPF programs, so this review exercised the binary's CLI surface, privilege gating, and release verification — not a live sensor under load. No eBPF runtime or benchmark claims in this review are ours; everything about live behavior is cited to the vendor's documentation, and labeled as such.

$ curl -sL -o jibril https://github.com/garnet-org/jibril-releases/releases/download/v2.17.0/jibril
$ curl -sL -o SHA256SUMS https://github.com/garnet-org/jibril-releases/releases/download/v2.17.0/SHA256SUMS
$ cat SHA256SUMS
05285e7ba90c64e934ebd8705b8cfd8512b5dafc0c79209d436a66f67409e3f3  jibril
7a5160e4555bd526b8673f9497f0827e7ba356b8b2e3777b9cfedd4e4d2f423f  jibril-v2.17.0-linux-x86_64.tar.gz
$ sha256sum jibril
05285e7ba90c64e934ebd8705b8cfd8512b5dafc0c79209d436a66f67409e3f3  jibril   # match

$ file jibril
jibril: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked,
BuildID[sha1]=e4c461cddb2198c6ca668c783706f9d92c88bba8, for GNU/Linux 3.2.0, stripped

$ ls -la jibril
-rwxrwxr-x 1 pm pm 91389176 Nov 12 05:02 jibril     # 87 MiB static binary

$ ./jibril --version
v2.17.0

$ ./jibril --help
Jibril is a runtime security tool that does runtime security magic in front of your eyes.

Usage:
  jibril [flags]

Flags:
      --config string    Path to YAML config file
  -h, --help             help for jibril
      --notify           Notify systemd about readiness
  -s, --systemd string   (un)install, (dis|en)able(-now), st(op|art)
      --version          Show version

$ ./jibril
Nov 12 05:04:07 ERR cmd/jibril/main.go:113 > must be run as root
(exit code 1, immediate)

$ ./jibril --config /tmp/nonexistent-config.yaml
Nov 12 05:05:06 ERR cmd/jibril/main.go:113 > must be run as root

Three observations that matter operationally. First, the privilege gate is the first thing that runs: a non-root start dies immediately at main.go:113 with a clean one-line error — good. But the gate precedes everything, including config validation: --config /tmp/nonexistent-config.yaml produces the identical root error, meaning you cannot lint, dry-run, or CI-validate a configuration without root on a target-representative host. A jibril --config-check subcommand that validates YAML and exits would be a one-day fix and would materially improve the config-in-Git workflow. Second, the CLI surface is almost nonexistent — five flags total, one of which self-installs a systemd unit (--systemd install creates the unit, config, netpolicy skeleton, and token environment file). Whether you consider that minimalism or missing tooling depends on how much you value a jibril test-rule or jibril query capability; osquery users coming from the HN thread's praised query model will notice there is no interactive query surface at all. Third — and this is tone, not engineering — the help text of a security product says it "does runtime security magic in front of your eyes." The team that ships that sentence also ships the best release-verification doc in the niche. Both things are true simultaneously; plan for the second and enjoy the first.

Deployment Surface: Read This Before the DaemonSet Lands

The vendor's own Kubernetes manifest is the honest source of the sensor's blast radius. It is a privileged DaemonSet — hostPID, hostNetwork, hostIPC, privileged: true (or an explicit capability add of SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_RESOURCE), running as UID 0, mounting /sys/fs/bpf read-write (plus debugfs, sysfs, procfs), raising locked memory limits, and deleting stale pinned maps at startup. This is the standard shape for eBPF host sensors — Falco, Tracee, and Tetragon all ask for comparable privileges — but for Jibril the trust calculation is sharper, because the sensor is a closed binary: you are giving an unauditable, root-running, kernel-attached process the ability to observe every syscall and enforce network drops on every node, on the strength of the vendor's signing identity and documentation. If that sentence is uncomfortable, that is the review's core procurement finding, not a footnote.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: jibril
  namespace: security
spec:
  template:
    spec:
      hostPID: true
      hostNetwork: true
      hostIPC: true
      containers:
      - name: jibril
        image: garnetlabs/jibril:v2.10.8
        securityContext:
          privileged: true
          capabilities:
            add: ["SYS_ADMIN", "NET_ADMIN", "SYS_PTRACE", "SYS_RESOURCE"]
          runAsUser: 0
        resources:
          requests: {memory: "512Mi", cpu: "500m"}
          limits: {memory: "1024Mi", cpu: "2000m"}
        env:
        - name: GOGC
          value: "20"           # aggressive GC: RAM for CPU
        command: ["/bin/sh", "-c"]
        args:
        - |
          ulimit -l unlimited
          rm -f /sys/fs/bpf/jb_*   # clear stale pinned maps
          exec /usr/bin/jibril --config /etc/jibril/config.yaml
        volumeMounts:
        - {name: bpffs,   mountPath: /sys/fs/bpf}
        - {name: debugfs, mountPath: /sys/kernel/debug}
        - {name: sysfs,    mountPath: /sys, readOnly: true}
        - {name: procfs,   mountPath: /proc, readOnly: true}

Two details in that excerpt are more interesting than they look. The vendor's own resource requests are 512Mi–1GiB memory and up to 2 CPUs — real, defensible numbers that quietly contradict any "negligible overhead" framing you picked up from a blog; size your nodes accordingly (and remember the docs' own heavy-I/O guidance allows up to 4GB). And GOGC=20 forces the Go runtime to garbage-collect aggressively, trading CPU for the memory bound the architecture promises — evidence the bounded-RAM story is engineered, not just asserted. One caution: the install docs still pin v2.10.8 in the image tag and download URLs while the release channel is at v2.17.0 — pin deliberately, and verify what you deploy against the release ledger rather than trusting the docs' example tags.

Supply Chain: The Part Garnet Genuinely Nails

If Jibril were only as good as its weakest section, this would still be worth reading for the release engineering. Every release carries exactly three assets — the binary, the tarball, a two-line SHA256SUMS — and the tarball holds exactly six members: the binary, a checksums file, a release.json, and one keyless Cosign (Sigstore) bundle per artifact. The release tag names a reviewed commit in a public ledger; the verification doc pins the signing workflow, the cosign identity (jibril-public-release.yml@refs/heads/main), the OIDC issuer, and prescribes both a manual Ubuntu runbook and a drop-in GitHub Actions workflow that performs checksum, signature, and gh attestation verify checks. The docs are explicitly written for "automation or AI agents that must decide whether a release is trustworthy" — an unusually forward-looking framing, and consistent with a product whose primary consumption path is other people's CI runners. This is the standard against which Falco/Tetragon/Tracee binary consumers should measure their own ingestion pipelines, and we verified the first link of it ourselves (checksum match, above). The verification chain we could not complete on this host: signature and attestation validation requires gh and cosign, which are not installed here — the doc's runbook is the authoritative procedure.

The Commercial Wrapper: Garnet CI Runtime Review

Jibril is free to run internally; the business is Garnet, the control plane. The mechanics, from the platform docs: a GitHub App plus one workflow step downloads and verifies Jibril, runs it as a systemd service for the duration of the job, and records each execution chain — the path from the runner's root process to an observed outbound connection, plus the destination reached. The result is posted as an Execution Profile to the pull request; a companion app posts it as a PR comment, and the contract is documented for review bots, merge gates, and coding agents over MCP. The scope is deliberately narrow — "execution chains and destinations, not contents": process names, steps, domains, IPs, ports, protocols; "not your source, not your secrets" — which is exactly the right scope given that the sensor never collects argv or env vars in the first place. Egress is scoped to api.garnet.ai and the release download; on unauthenticated PR runs the sensor runs control-plane-less and uploads its profile as a workflow artifact instead. For self-hosted runners, GitLab, Jenkins, and Buildkite there is garnetctl plus the Jibril agent, kernel 5.10+, root for eBPF.

Pricing is the cleanest part of the story: $0 forever for public repositories, $0.50 per run on private repos with the first 500 runs each month free, no per-seat charges, and enterprise tiers (SSO/SAML, self-hosting, committed-use pricing) past 10,000 runs per month. At 500 free runs the evaluation cost is literally zero; the thing to model before adopting at scale is what a "run" is — one CI job producing one Run Profile — multiplied by your job volume. The CI use case is also the one place Jibril's architecture has an unambiguous edge: a runner lives minutes, the workload is bursty, secrets are everywhere, and nobody wants a streaming event pipeline per ephemeral VM. A state-map sensor that batches per cadence and refuses to collect secrets is a better fit for that environment than any ring-buffer agent — and the fact that the vendor built its product on its own sensor is the strongest available evidence they believe the architecture works.

Exact Conditions Under Which Jibril Degrades

• High process/file/network churn with default caches. LRU maps sized 16–64 entries evict oldest-first; the tuning docs' own words are "risk of cache overflow if processing takes too long." A database host or busy CI runner with a short cadence and default caches can evict state before the poll that would have detected it. Sizing guidance exists (Heavy I/O profile: up to 4GB) but is capacity planning you must do, not overhead you avoid.
• Short cadences on busy hosts. Detection passes are serialized onto a single core and walk every enabled recipe. The docs' own diagnostics: "constant CPU usage means cadences are too short" and passes "might last tens of seconds" under load — your configured interval is a floor, not a ceiling.
• Attacks whose signal is in argv or environment variables. Both are never collected. Command-line-based detection classes (encoded-payload-in-argument, malicious-flag combos, env-var-pivoting) are structurally invisible, no matter how you configure recipes.
• Attacks faster than your cadence. An execution-and-exfiltration pattern completed and cleaned within the poll interval exists only in whatever map entries survived LRU. Detection latency defaults to 9 seconds and stretches under load; there is no per-event alert path at all.
• Attenuator outages. LLM-endpoint failure behavior is undocumented; in block mode an unreachable or degraded model is an undefined alert path. Treat block mode as unproven until the vendor documents the outage contract.
• Docs drift. Install pages pin v2.10.8 image tags, the theory-behind page linked from the launch thread 404s, and the rules corpus has already pivoted once (reactions deprecated). Operational runbooks built on vendor docs need re-verification each release — pin versions and verify against the release ledger.
• Vendor dependency. One company, one lead engineer, six stars, zero external issue reports, license prohibits redistribution and reverse-engineering. A product direction change (the reaction-engine deprecation already demonstrated this) can remove a capability you deployed around, with no community fork possible.

Jibril vs the Open-Source Field

The honest summary of that table: Jibril is not competing with Falco's ecosystem, Tracee's capture depth, or Tetragon's enforcement — it is proposing a different point on the latency-versus-footprint curve and a different trust boundary (closed binary, no secrets collected). Where that point wins: ephemeral, bursty, secrets-dense environments where a streaming pipeline is waste and a 9-second detection bound is acceptable. Where it loses: every requirement in the table's rows two through five.

Verdict

Run Jibril if your highest-value surface is CI/CD runners, ephemeral Kubernetes workloads, or memory-constrained edge hosts; if your secrets posture requires a sensor that structurally cannot collect argv or environment variables; if DNS-aware synchronous egress blocking is the enforcement you actually need; and if you are comfortable pinning a closed binary from a small vendor whose release engineering is verifiable even though its detection logic partially is not. The Garnet CI product at $0.50/run with 500 free runs is a genuinely low-risk way to find out whether the Execution Profile workflow changes your PR review — that integration is the most differentiated thing the company has shipped.

Skip Jibril if any of these are true: you need per-event, sub-second detection alerting for incident response (stay on a ring-buffer tool); you need the sensor itself to kill or freeze processes (Tetragon's in-kernel enforcement model is the open-source answer, and Jibril's own reaction engine is already deprecated — the "freeze suspicious processes" claims in circulating blog posts describe a feature that no longer builds); your compliance regime requires auditing every detection rule you ship (51% of the corpus is compiled and the license forbids reverse-engineering); your threat model needs argv- or env-keyed detections; or you require published benchmarks before a root-privileged closed binary lands on every node (there are none — the vendor's performance pages contain adjectives, not measurements, and this review could not generate load numbers without a privileged eBPF environment either).

The architecture idea — kernel state maps polled on a cadence instead of an event firehose — is the real thing, and it is documented with an honesty that is rarer than it should be: the vendor prints its own trade-offs (cadence floors, cache overflow risk, single-core serialization, deprecated features) in its own manual. What you are buying into is a two-sided bet: an original design executed by a credible eBPF team, wrapped in a license and a corpus opacity that assume you trust them. Verify their releases (they make it easy), pin what you deploy, keep the network policy enabled even if only in allow-mode, and do not put the Attenuator in block mode until its outage behavior is documented. And if any of your requirements drift toward the rows Jibril loses in the table above, the open-source field remains one helm install away.