xSypher-Stream: Inline eBPF & BPF LSM Kernel Defense for AI Agent Hosts

Direct Answer:
xSypher-Stream is an open-source Linux runtime security sensor that pairs five eBPF CO-RE tracepoints and a zero-capability Python lineage engine with five BPF LSM hooks to block MCP prompt-injection chains inline (-EPERM) in ~2.1 ms. Telemetry runs on Linux 5.10+ with BTF, while full inline enforcement requires CONFIG_BPF_LSM=y, active lsm=bpf boot parameters, and dedicated-node baselining before production rollout.

An MCP server that can spawn sh is a shell on your host with extra steps. Most Linux runtime security tools tell you that shell happened 50 to 2,000 milliseconds after the instance metadata token has already left the box; xSypher-Stream Zero Trust Kernel Log Telemetry (shortened to xSypher-Stream) is built to make the kernel return -EPERM before the socket opens. It separates an unprivileged Python policy engine from a privileged C++20 eBPF collector and enforces containment across five BPF LSM hooks. The architecture is purpose-built for dynamic AI-agent workloads, but deploying it safely requires separating what the source code already proves from what still requires target-host validation: as of October 30, 2026, user-space simulation and ABI verification pass cleanly in CI, while automated QEMU live-kernel verification and shared-host runtime classification still keep full inline enforcement in dedicated-node evaluation territory.

The project does not stop a model from reading a poisoned document or choosing a hostile tool call. It targets the operating-system consequences: starting a shell, contacting cloud metadata, reading credentials, staging a memory-backed executable, or opening an outbound command-and-control channel. That boundary matters because the official MCP trust model says servers retain access to resources in their execution environment; protocol-level consent does not replace process isolation or kernel policy.

xSypher-Stream 2.0.0 at a glance

The package manifest and CMake project identify the software as version 2.0.0, while the binary interface has reached ABI v3. There is no tagged GitHub release, so the current distribution model is a source checkout or pinned bootstrap snapshot rather than a conventional stable release.

The license split follows Linux requirements: BPF LSM programs need a GPL-compatible license, while the collector, engine, documentation, and other files remain under Apache-2.0.

The architecture is the right shape

Linux BPF LSM programs attach to security hooks and can return an error before an operation completes. BPF CO-RE uses kernel BTF information and libbpf relocations so one compiled object can adapt to compatible kernel layouts without compiling source on every target host. Those are established Linux mechanisms rather than project-specific inventions.

• Run the host preflight before compiling.

npm install -g .
xsypher doctor

Check Linux version, BTF availability, cgroup v2, BPF LSM activation, capabilities, and the native toolchain. The command exits non-zero when a blocking prerequisite fails.

• Use a dedicated VM or disposable node.
  Verify both the compiled option and active LSM list:

grep CONFIG_BPF_LSM /boot/config-$(uname -r)
cat /sys/kernel/security/lsm

CONFIG_BPF_LSM=y is not enough by itself; the active boot list must contain bpf. On stock Ubuntu 22.04+ and many managed cloud images, the kernel compiles BPF LSM in but boots with only capability,landlock,yama,apparmor active—meaning BPF LSM programs attach without error and then enforce nothing. Warning: Enabling bpf in the LSM stack requires editing the kernel command line and rebooting. Never set lsm=bpf by itself: on Linux, specifying lsm= overrides the distribution's default module order unless you explicitly preserve the existing stack (for example, lsm=lockdown,capability,landlock,yama,apparmor,bpf). Getting that string wrong on an AppArmor or SELinux host reboots the node with weaker baseline confinement than you started with.

• Build and inspect every verification result.

make vmlinux
make all
make verify

 Treat a reported SKIP as missing evidence, not a pass. The build system can skip native BPF verification when bpftool or other required tooling is unavailable.

• Run the collector and engine without enforcement first.

sudo build/xsypher-collector 
  --socket-path /run/xsypher/stream.sock

 Capture normal build, deployment, package-installation, notebook, and agent traffic. Tune the runtime names and rules before proceeding.

Lock down the socket boundary and verify all three planes independently before moving past audit mode. Treat write access to /run/xsypher/stream.sock as equivalent to root enforcement authority: the runtime directory must be mode 0750, owned by root, and never mounted into container workloads, because any local process that can write a 32-byte UNQUARANTINE command to that socket can clear kernel policy maps. Once running, verify each plane from the terminal: check test -S /run/xsypher/stream.sock for collector liveness, query curl -s http://127.0.0.1:9109/metrics | grep -E '^(xsypher_events_total|xsypher_commands_failed_total|xsypher_lsm_blocks_seen)' to confirm telemetry and map delivery, and alert if xsypher_commands_failed_total{reason="disconnected"} climbs while xsypher_lsm_blocks_seen stays flat—that pair is the signature of a sensor enforcing policy in Python that the kernel never received.

• Run positive and negative live-kernel tests.
  
  Confirm that forbidden activity is denied and expected activity remains available. The project’s own validation notes call for tests covering openat2, io_uring, IPv6 IMDS, worker-thread exit, fork storms, ring-buffer saturation, and policy reloads.

• Export logs before relying on the audit chain.
  Send JSONL records to append-protected or immutable remote storage. Alert on event drops, command-delivery failures, stale heartbeats, and a lack of observed LSM blocks during scheduled denial tests.
  

Does xSypher-Stream stop prompt injection?

No. xSypher-Stream does not inspect prompts or determine whether model input is malicious. It limits selected consequences after an AI or MCP process attempts an operating-system action. Prompt filtering, tool authorization, user consent, input validation, sandboxing, least privilege, and restricted network egress remain separate controls.

Does xSypher-Stream require root access?

The Python policy engine is designed to run without capabilities, but the native collector needs enough privilege to load eBPF programs, access BTF, attach tracepoints, and manage BPF maps. Container and Kubernetes deployment examples therefore give the collector elevated access while keeping the engine unprivileged.

Can xSypher-Stream replace Falco or Tetragon?

Not for most production fleets. xSypher-Stream has six agent-focused rules and a smaller code path. Falco covers a much broader event and rule ecosystem, while Tetragon supplies Kubernetes-aware tracing and enforcement policies. xSypher-Stream makes more sense as a focused control or research base than as a general runtime-security replacement. If you run xSypher-Stream alongside Falco for defense in depth, budget for two eBPF pipelines competing for tracepoint execution time and ring-buffer headroom on the same node.

Is the xSypher-Stream audit log immutable?

No. Its SHA-256 chain can reveal edits that were not followed by recomputing later records, but it is not cryptographically signed or anchored outside the host. A capable attacker with write access can regenerate the file or remove its tail. Forward the ledger to protected remote storage if it must support an investigation or audit.

Verdict: evaluate it on a dedicated agent node

xSypher-Stream has a better architecture than its current maturity level suggests. The narrow collector, fixed ABI, BPF LSM enforcement, in-kernel lineage work, bounded state, and audit-only rollout path show serious engineering thought.

The public evidence still falls short of its “kernel-verified” positioning. The live-kernel workflow needs to pass, its logs need to survive failed runs, the version and wire documentation need to agree with the normative header, and default runtime classification needs a safer workload identity than generic python3 or node.

Our recommendation is to deploy xSypher-Stream first in audit-only mode on a dedicated AI-agent node. Start with xsypher simulate 10000—which requires zero privileges—to verify transport and rule matching on your hardware, then run xsypher doctor and cat /sys/kernel/security/lsm on the target host. If BTF is missing, stop—you have a kernel image problem, not a tooling problem. If BTF and lsm=bpf are active, baseline your agent traffic before flipping --enforce-kernel, and watch the Prometheus counters on day one: if the simulation streams events but xsypher_lsm_blocks_seen stays flat during live denial tests, your enforcement plane never loaded, and everything you are looking at is just a log file with good intentions.

Disclosure:

xSypher-Stream is an open-source project developed by our Founder, Anwar Iqbal Dawar.