Overview

Sevorix is a sidecar proxy that verifies an agent's intent and execution, not just its input. Every action an agent takes — a shell command, an HTTP request, a syscall — passes through the enforcement plane before it reaches the real system, and is classified into one of three lanes: blocked, flagged for review, or allowed.

Most "AI gateway" products inspect only the prompt going in. An agent that is handed a raw shell or a direct socket bypasses that entirely. Sevorix sits one layer lower, on the wire between the agent and the systems it acts on.

How enforcement works

There are three interception points, and all three consult the same policy engine:

Channel	Interception point	What it sees
Shell	sevsh, a guarded shell the agent is given in place of a raw one	The command string, before it is executed
Network	The HTTP/HTTPS proxy	Outbound requests, and (with TLS interception enabled) the response bodies coming back
Syscall	seccomp-unotify, optionally layered with eBPF	The syscall and its resolved path arguments, before the kernel acts on them

A verdict from the policy engine is applied at the point of interception: a blocked shell command is never executed, a blocked request is never forwarded, a blocked syscall returns EPERM (or kills the process, if the policy says so).

Enforcement only covers processes started under sevsh

A process that was not launched through sevsh — directly, or via one of the integrations — is not observed at all. This is the most common misunderstanding about Sevorix's scope. Starting the daemon does not retroactively contain anything already running, and it does not contain a shell you opened yourself.

The three traffic lanes

Every action is classified into one of three lanes.

• 🔴 Red — Block. Deterministic, zero-latency rejection. Any policy with action: Block that matches sends the action here; no model is consulted. A session with no role configured blocks everything by default.
• 🟡 Yellow — Flag. Ambiguous intent. The action is held, and resolved either by a human operator in the Observatory or, in pro builds, by the Jury of Rivals consensus engine.
• 🟢 Green — Allow. Approved patterns pass with effectively zero overhead.

The lanes are not equally capable on every channel:

Channel	Red Lane (Block)	Yellow Lane (Flag)
Network (HTTP proxy)	Blocked before forwarding	Full hold-and-wait
Shell (sevsh)	Denied before execution	Full hold-and-wait
Syscall (seccomp / eBPF)	EPERM, or SIGKILL with kill: true	Observatory notification only — fire-and-forget, the syscall is not held

A Flag on a syscall notifies you; it does not pause the agent. If you need a syscall stopped, it needs a Block.

See Policy Format for how to write the rules that drive this.

Human-in-the-loop review

When an action lands in the Yellow Lane, Sevorix can hold it open and route it to a human instead of auto-deciding:

1. Sevorix suspends the agent's process tree with a cgroup freeze, so it cannot fork or exec while you decide, and broadcasts a pending event to the Observatory.
2. The Observatory shows the payload, the reason, a countdown, and the agent's containment state — ❄ FROZEN, … CONTAINING, or ⚠ NOT FROZEN.
3. You click Allow, Block, or Pause (which freezes the countdown for longer review).
4. If no decision arrives before the timeout, the configured default fires.

Configured in ~/.sevorix/settings.json:

{
  "intervention": {
    "timeout_secs": 30,
    "timeout_action": "block",
    "containment": "required"
  }
}

When the agent cannot be suspended

The freeze runs through a root-owned cgroup helper that the installer offers to install. If it is missing, has no passwordless sudo rule, or the agent is not running inside a registered session cgroup, the agent cannot be suspended — and a review that cannot suspend the agent provides no containment, because the agent keeps forking and exec'ing while you read the prompt.

intervention.containment decides what happens then:

Value	Behaviour
"required" (default)	Fail closed. The flagged action is blocked rather than held in a review that contains nothing. The Observatory raises a banner naming the cause and the remedy.
"best_effort"	The review proceeds without suspension. The failure is still announced, and the pending card is marked ⚠ NOT FROZEN.

A freeze is only reported as successful when the kernel confirms it — the daemon reads the cgroup's own cgroup.events rather than trusting the helper's exit code. An unrecognised value for containment falls back to "required", so a typo cannot silently downgrade containment.

Recovery needs no restart. Containment is re-evaluated on every flagged action, so installing the helper or starting the agent through an integration restores reviews immediately.

Enforcement tiers (Linux)

Syscall-level interception has two tiers:

Tier	Mechanism	Requirement
Standard (default)	seccomp-unotify filter applied per sevsh session	Always available on Linux
Advanced	BPF LSM hooks layered on top of seccomp	Kernel booted with bpf in its active LSM list (/sys/kernel/security/lsm) and experimental.lsm_blocking: true in ~/.sevorix/settings.json

The tier in force is the minimum of what you configured and what the running kernel provides. At startup Sevorix probes the kernel's list of active LSMs and resolves the two:

• Advanced requires both the opt-in setting and bpf in that list. Neither alone is enough.
• Detection never upgrades a session. A kernel that could provide BPF LSM but has no opt-in set stays on Standard, so Advanced remains an explicit choice.
• Detection does downgrade, loudly. Requesting Advanced on a kernel that cannot provide it yields a startup warning, a DEGRADED marker in sevorix status, an amber badge in the Observatory, and "enforcement_tier_degraded": true from GET /api/version. It does not refuse to start — Standard-tier enforcement is real protection, and dropping all of it because one layer is unavailable would leave the agent entirely unguarded.

Stock WSL2 kernels cannot be given BPF LSM (there is no way to pass custom boot parameters), so Advanced is permanently unavailable there. Standard remains fully functional. Check which tier is actually active with sevorix status.

One residual gap, stated plainly: the probe establishes that the kernel can attach BPF LSM programs, not that every hook did attach. If a hook fails for another reason — missing BTF, a kernel/loader mismatch — the eBPF daemon logs a warning and continues, and the reported tier will still read Advanced.

Running an agent under Sevorix

sevorix integrations routes an AI coding tool's shell commands through sevsh:

sevorix integrations list
sevorix integrations status claude
sevorix integrations start claude

Three tools are registered: Claude Code, Codex, and OpenClaw. The launcher bind-mounts sevsh over /bin/bash inside a scoped mount namespace, so even a tool that calls /bin/bash by absolute path is intercepted rather than only one that resolves it through PATH.

See the CLI Reference for the full command surface.

Editions: Lite and Pro

Sevorix comes in two editions, which are separate products:

• Sevorix Pro is commercial software, distributed as prebuilt binaries from sevorix/sevorix and requiring an active subscription.
• Sevorix Lite is open source (AGPL-3.0) at sevorix/sevorix-lite, builds from source, and needs no account. It is a complete, self-contained tool — proxy, policy engine, sevsh, the Observatory, and the Standard enforcement tier — with a smaller feature set. It is not a source release of Pro.

Capability	Lite	Pro
HTTP proxy, policy engine, Red/Yellow/Green lanes	✅	✅
sevsh shell interception	✅	✅
The Observatory, live traffic WebSocket, Policies tab	✅	✅
Human-in-the-loop review (manual)	✅	✅
Session naming and port selection (--name, --port)	✅	✅
Concurrent sessions	1	many
Traffic logs (sevorix logs list, tail, show, stats)	✅	✅
Compile-time built-in policies (sevorix config list-builtins)	—	✅
Named-session targeting (stop --name, status --name, start --role)	—	✅
Jury of Rivals consensus engine (sevorix jury)	—	✅
Hooks on policy lifecycle events (sevorix hooks)	—	✅
Tamper-evident receipts (sevorix receipt, Ed25519-signed)	—	✅
ML prompt-injection classifiers (sevorix models, MlClassifier policies)	—	✅
Log export to SIEM (sevorix logs export, logs verify)	—	✅
--session / --accumulate on integrations start	—	✅

Throughout this documentation, pro-only features are marked (pro). Note that a Lite binary's --help output simply omits pro commands rather than listing them as unavailable — if a command documented here is missing from your build, that is why.

To install Pro, see Install. To install Lite, follow the sevorix-lite README.

Jury of Rivals (pro)

The Yellow Lane can also be resolved automatically by convening a Jury of Rivals — a multi-LLM consensus engine (OpenAI, Anthropic and Gemini providers are built in) evaluated against a policy prompt you write. Each configured member votes on the flagged payload; if quorum votes to block, the action is denied, otherwise it is released.

sevorix jury enable
sevorix jury add '{"provider": "anthropic", "api_key": "sk-..."}'
sevorix jury set-quorum majority
sevorix jury test "some payload"

Configure it from the Observatory's Configuration card, the CLI, or POST /api/config. See the CLI Reference.

In this section

• Policy Format — how a policy is written, how matches are evaluated, and how conflicting rules resolve.
• CLI Reference — the sevorix and sevsh commands.
• File Locations — where every binary, setting and log is installed, and who owns it.
• Troubleshooting — common problems with an install, and what to check for each.
• Uninstall — removing Sevorix, with or without your own configuration.

To install Sevorix in the first place, start with Getting Started → Install.