How it works
Telemetry → classification → explanation → integration
Four stages, each independently swappable — collection doesn't dictate detection, and detection doesn't dictate where a verdict ends up.
1
Telemetry
On Kubernetes, collection is eBPF via Tetragon out of the box — kernel-level execve capture with no agent to instrument inside the build image itself. For legacy or non-Kubernetes runners, the ingest contract is a plain, documented event shape (see Integrations): any collector that can watch process execution and POST that shape works, including your own. Collection is decoupled from detection on purpose — the model never has to know or care where an event came from.
2
Classification
Command sequences are scored by a detection model trained specifically on real execve traffic — not a general-purpose model prompted to guess whether a shell command looks suspicious. Every promotion is evaluated against a held-out benchmark before it can replace the current model in production; nothing ships because it merely trained well offline. See Security for how a model earns the right to serve traffic.
3
Explanation
A verdict alone isn't actionable — an analyst needs to know which command drove it. Every flagged window carries hit1_command, the single highest-attribution command, computed for every plan. Entitled tiers additionally get the full attack chain: the sequence of commands that together explain the verdict. No raw sensitivity scores or magnitudes are ever exposed — deliberately: they're hints for an analyst, not a number to over-index on.
4
Integration
Every verdict — the window-level alert and its explanation — ships as an OCSF Detection Finding, an open, vendor-neutral schema already understood by most SIEMs. Delivery is a webhook or a log file, your choice. There's no proprietary console you have to add to your team's rotation of tools to babysit; findings land where your team already looks.
Why behavioral, not declared-state
What execve-level monitoring catches that a scanner structurally can't
Postinstall scripts
A dependency manifest declares a package name and version — not what its install hooks actually run. A scanner sees the lockfile; Protet sees the curl | bash the postinstall script executed.
Dependency confusion
A malicious package that resolves ahead of your intended internal one looks identical to a legitimate dependency in an SBOM. What it does once installed is where the attack actually becomes visible.
Hijacked runners
A compromised CI credential doesn't show up in any manifest at all — the attacker is just running commands as your build. That's exactly the surface behavioral monitoring is watching.