Identity is not
containment.

Traditional firewalls filter packets. Identity systems verify principals. Sevorix filters actions. It sits between your agent and the system it's operating on, evaluating every shell command, outbound request, and syscall against your policy before execution. If an agent attempts a destructive or unauthorised action — from a bad inference or a successful jailbreak — the call fails at the OS, not at a prompt.

Three paths. In-kernel blocks resolve at Ring-0 with no round trip. Traffic that matches no policy takes the green lane and passes through in about 5ms. Only the middle case — suspicious but not definitively dangerous — escalates, either to an operator or to concurrent multi-model evaluation, inside a sub-50ms end-to-end budget before any model latency.

Different layers, and you probably want both. An MCP server or L7 gateway governs the tool calls your agent declares — structured, well-formed, visible at the application layer. Sevorix governs what actually executes. If an agent is injected into dropping to a raw shell or opening a socket directly, it never touches the gateway; Sevorix still sees the execve or connect. The gateway is policy. We're enforcement — and that enforcement extends to MCP itself: MCP tool calls are a first-class policy context of their own, not something we route around. See the next answer.

Yes, and it is a first-class policy context, not a special case of shell. The Mcp context sits alongside Shell, Network, Syscall and Inbound in the same engine, with its own structured evaluation path: a policy can match an MCP call on server and tool name directly — block the filesystem server's write_file tool by naming the two, rather than pattern-matching a flattened string and hoping. Substring and regex policies still work against the flattened call if that is what you want. Allow-supersedes-deny, Block over Modify over Flag, and fail-closed on an unavailable checker all behave exactly as they do everywhere else, because it is the same precedence code.

Enforcement is real interception, not observation. Installing the Claude Code integration rewrites every entry in the client's MCP server config to launch through sevsh, so Sevorix sits in the stdio pipe between the agent and the server. Every tools/call is evaluated before it is forwarded. A Block never reaches the server: the agent gets a JSON-RPC error back instead, and a policy marked kill terminates the agent process outright.

The honest boundary: this covers local stdio MCP servers launched by the client, in the client-to-server direction. Responses coming back from an MCP server pass through the relay unexamined — inbound content scanning is a separate control with its own configuration. And initialize, tools/list, resources and prompts calls are forwarded untouched; the policed surface is the tool call itself. As with every other context, you can check a rule before it is live: sevorix validate takes -C Mcp like any other context.

Sevorix enforces at the host level, so it's framework-agnostic — it sees what the process does, not what the framework intended, and works the same for raw Python as for any orchestration library. It requires the agent to run inside a supervised process tree, which it enters by launching through our shim — the same on a laptop, a Linux host, or inside a Docker container. We ship first-class integrations for Claude Code and Codex today; OpenClaw is the one still in development.

Depends on the tier, and we'll be precise. Lite runs entirely on your machine — no account, no telemetry. Pro enforces locally too; the only thing that leaves the machine is a licence check against our hub, which the daemon requires at startup. There is no event upload and no hosted history — the Observatory is local. Enterprise is self-hosted or air-gapped; enforcement and storage both stay inside your boundary. Centralised policy sync and the shared audit ledger live on Enterprise where you deploy them. One path does send data outward, and it is worth being blunt about: if you turn on Jury of Rivals, the action under review — the payload and the accumulated session context — is sent to the model providers you configured, under your own API keys, as written. We do not mask or tokenize it on the way out, and it goes to those vendors, not to us. The jury is off until you configure it, you choose which providers sit on the panel, and every deterministic verdict is still made locally: no action waits on a network call to Sevorix. If that disclosure is the thing standing between you and turning the jury on, it is avoidable: a jury member is a model endpoint, not a vendor. Point the panel at models running on your own hardware — any OpenAI-, Anthropic- or Gemini-shaped endpoint you can reach, including a local one — and the payload never leaves the machine. You lose the frontier models' judgment and you keep the architecture.

Five Pro licences. There is no team tier and no seat minimum to clear — Pro is licensed per engineer, each daemon enforces locally against its own policy file, and nothing about running five of them differs from running one. What you do not get that way is a single place to change policy: five machines means five policy files, kept in step by whatever you already use to distribute config. That is the real reason to move to Enterprise, and it is worth doing when drift between those files starts being a risk rather than a chore. If you want the licences on one invoice rather than five card charges, ask — that is billing, not a different product.

No — not for the way almost everyone runs it. AGPL-3.0 is copyleft on Sevorix’s source, not on the code Sevorix supervises. Running the daemon on your own machines to police your own agents is use, not distribution: your application source, your agent’s code and your policy files stay yours, and nothing in the licence asks you to publish any of it. Policies are JSON or YAML you author against a documented schema — we do not treat them as derivative works of the engine, and we will say so in writing.

Two things do trigger obligations, and they are worth naming rather than burying. If you modify Sevorix’s source and distribute the modified binary, the licence terms apply to what you distribute. And section 13 — the clause the extra A stands for — reaches the case where you take a modified Sevorix and offer it to third parties over a network: those users have to be offered the corresponding source of your modified version. Running an unmodified build inside your own organisation does neither of those things.

If that still does not survive your legal review — and some organisations have a blanket policy against AGPL anywhere in the tree regardless of how it is used — there is a commercial licence, and it exists precisely for this. It covers embedding Sevorix in a closed-source product and running it as a hosted service without publishing source. Email chris@sevorix.com and we will send terms. None of this is legal advice and your counsel will want to read the licence themselves; we would still rather answer the question here than lose an evaluation to a question nobody got to ask us.

You cannot prompt-inject a Linux kernel. No runtime layer stops injection — it happens in the context window, before an action exists to intercept. What Sevorix changes is the blast radius. Assume the injection succeeds. Assume the model is fully compromised and doing exactly what an attacker wants. It still has to make a syscall to do damage, and that syscall meets a policy written by you, not by the model. We don't secure the prompt. We make it survivable.

A canary credential — and it is the one control that produces a positive signal rather than the absence of one. Sevorix ships a fake secret, an AWS_SECRET whose value is a Sevorix canary and nothing else, and scans every payload it sees for it: proxied HTTP traffic, JSON bodies, raw text, and anything submitted to the analysis endpoint for a verdict. You seed it wherever a compromised agent would go looking — an environment variable, a config file, a credentials block in the agent's context. Nothing legitimate ever touches it. It opens nothing, it authenticates against nothing, and no correct behaviour involves reading it back out.

So when that value turns up in an outbound request, there is nothing to score and nothing to weigh. It is evidence. The request is refused and the session is treated as compromised — the honey-pot has been triggered and the agent is assumed compromised. It catches the scenario the rest of the stack is worst at: a successful injection or jailbreak that has not done anything obviously destructive yet, but is already reading credentials it was never asked to read and putting them somewhere.

Two layers, two jobs. The kernel layer is deterministic and unconditional. It doesn't reason, it doesn't score, it enforces. If a rule says deny, the syscall fails — every time, regardless of what the model believes it's doing. Above it, Jury of Rivals handles the cases policy can't express as a pattern: a panel of frontier models from rival vendors — OpenAI, Anthropic, and Google are the built-in providers — queried concurrently, with a majority required to block by default. You pick the panel and the quorum. It is probabilistic, and the architecture treats it that way — it can only narrow what the deterministic floor already permits, never widen it. A hung jury doesn't open a door.

It degrades before it blocks, and it doesn't quietly open.

Start with what isn't affected. Your deterministic policies live in compiled eBPF maps on the node. They don't call out, they don't wait on anything, and they have no network dependency — a total loss of connectivity to Sevorix changes nothing about whether a denied syscall is denied on your box. On Lite that is the whole decision path: there's no external evaluation to fail.

Escalation exists on Pro and Enterprise, where actions your policy can't express as a pattern go to Jury of Rivals — a panel of hosted frontier models, reached over the network. That is the part that can fail, and it fails closed: each member has its own timeout, 8 seconds by default, and a member that errors or times out counts as a block rather than an abstention. Losing connectivity entirely doesn't degrade kernel enforcement at all; it just means nothing gets escalated and the ambiguous cases stop. The absence of a verdict is never counted as approval.

Fail-closed is the default on every action an agent takes. Each failure mode is reasoned about on its own rather than covered by a blanket rule: a jury member that errors or times out is a block, a held action nobody answers is a block, and an evaluation layer that cannot be reached at all is a block. Two switches can invert that — the jury's on-error action and the hold timeout action can each be set to allow — and both are opt-in, off by default, and something you have to go and turn on.

One default does not fail closed, and it runs in the other direction: scanning responses on their way back to the agent. When a response is too large to read in full, the partially-scanned remainder is forwarded and flagged rather than blocked — response size is attacker-controlled, so blocking on it would let any oversized page cut your agent off from the web. Set inbound_scan.oversize_action to block if you want that one closed too. Security over uptime is the constraint the system is built around; the failover path exists so that constraint costs as little availability as possible, not so it can be relaxed by accident.

Every BLOCK, HOLD, and ALLOW event records the agent identity, the intercepted action, the matching policy, the verdict, and a timestamp — structured, exportable audit records for the chain of custody your HIPAA, ISO 42001, and EU AI Act auditors will ask for.

Yes — and you don't have to start there. Policies are JSON or YAML: substring, regex, or an external checker binary, scoped to shell, network, or syscall context and grouped into roles. Rules hot-reload without restarting agents. You also don't have to write the first one from scratch: SevorixHub, the policy registry, holds versioned artifacts you can search, pull onto the machine, adapt, and push back under your own version. For enterprise, Sevorix ingests your existing compliance documents and compiles them into deterministic constraints, then signs the compiled policy with your enterprise private key before it's pushed to the fleet. The local daemon verifies that signature against a pinned public key before it touches the eBPF maps — invalid, missing, or altered in transit, the update is dropped and the fleet alerts.

Start by never guessing what a policy will do. sevorix validate evaluates a command against your real policy set — under a role you name, in the context you name — and prints the verdict, the lane, the matching rule and the confidence as JSON, without running the command and without an agent anywhere near it. It exits non-zero on a BLOCK, so it drops straight into CI: assert that the commands your pipelines legitimately run come back ALLOW before the policy change merges, and that the ones you meant to stop come back BLOCK. It refuses to run at all if the policy set fails to load, rather than printing a confident ALLOW against a half-loaded rulebook.

Then scope it. Policies are grouped into roles, and a session runs as exactly one role — so the destructive-SQL rules that make sense for an analyst agent do not have to be the rules your build agent runs under, and you can start a daemon restricted to the roles you want it to be able to assume. sevorix config check validates the whole set before it goes anywhere, and rules hot-reload without restarting agents, so tightening a rule is not a maintenance window.

Now the part most vendors leave out. The shipped default role blocks the genuinely destructive verbs — DROP, DELETE, TRUNCATE, SHUTDOWN — and flags a much broader list: SELECT, ADMIN, INSERT, UPDATE, ALTER, CREATE, UNION, PASSWORD, SECRET, KEY, TOKEN, AUTH. Those are case-sensitive substring matches, so any command containing the word matches. On a real workload, on day one, that will flag constantly. This is deliberate — the defaults are tuned to show you your own traffic, not to be the policy you run forever — and it is survivable because a Flag is not a Block: it takes the yellow lane, gets recorded, and the command runs. Nothing is denied that you did not write a Block for.

So the rollout is: install, run against real work with the defaults, read the flags, and turn what matters into narrow rules of your own. Deny broadly and carve exceptions with Allow, which supersedes every Block, Flag and Modify in the same role — which is exactly why an Allow with a match-everything pattern logs a loud warning at startup and is reported by sevorix config check: it silently disables the rest of the role, and that is almost never what anyone meant.

Yes, and that is the design rather than an availability accident. sevsh refuses to start a supervised session it cannot validate: with the daemon unreachable it exits non-zero with a fail-closed "not reachable" diagnostic instead of dropping you into an unsupervised shell that looks exactly like a supervised one. The same check guards the non-interactive entry points — sevsh -c and sevsh -- — so a command issued while the daemon is down is refused rather than executed unvalidated. There are dedicated end-to-end tests on each of those three paths whose only job is to catch a regression here, because a shell that silently fails open is worse than no shell at all: the operator sees a normal prompt and believes a policy is being enforced.

It is the same rule as everywhere else in the system — a jury member that times out is a block, a held action nobody answers is a block, an evaluation layer that cannot be reached is a block. Scope is worth being precise about: this stops agents inside Sevorix sessions. A process you never launched through the shim is not observed at all, so what you are looking at is a containment boundary failing closed, not a system-wide lock on your machine.

Upgrade is re-running the installer. It stops any running daemon before it overwrites binaries, reinstalls the CLI to ~/.local/bin and the privileged artifacts to the root-owned /usr/local/lib/sevorix/, and — this part matters — re-records the SHA-256 of the newly installed sevsh from the installed bytes. The agent launcher checks that digest before it will bind-mount the shell, so an upgrade that skipped it would leave you unable to start a session rather than silently trusting an unverified binary. Your policies, roles and settings live in ~/.sevorix/ and are not touched.

Uninstall is honest work rather than one command, and we would rather tell you that than imply a script that does not exist. Removing Sevorix means sevorix stop, then deleting the CLI from ~/.local/bin, the root-owned tree at /usr/local/lib/sevorix/, the helpers and launchers the installer placed in /usr/local/bin (sevsh, the cgroup helper, the agent and per-tool launchers), any /etc/sudoers.d/sevorix-* rules it wrote, and ~/.sevorix/ if you want your policies gone too. None of that list is a surprise: every non-trivial install step is an interactive prompt that names the exact path it is about to write. Nothing lingers in the kernel — the eBPF programs and seccomp filters are attached per session and go away with the process tree.

Linux, WSL and macOS. On Linux there are two syscall-enforcement tiers and Sevorix is explicit about which one you are getting. Standard — a seccomp-unotify filter applied per session — is always available. Advanced layers BPF LSM hooks on top of it and needs two things at once: a kernel booted with bpf in its active LSM list, at /sys/kernel/security/lsm, and experimental.lsm_blocking set true in your settings. Neither alone is enough, and detection never silently upgrades you — Advanced stays an explicit choice.

It does downgrade, loudly. Ask for Advanced on a kernel that cannot provide it and you get a startup warning, a DEGRADED marker in sevorix status, an amber badge in the Observatory and enforcement_tier_degraded in the version endpoint — but the daemon still starts, because dropping the proxy, the policy engine and sevsh as well would leave the agent completely unguarded. Stock WSL2 kernels cannot be given BPF LSM at all, so Advanced is permanently unavailable there and Standard is what you run. One related floor: path-pattern rules need openat2, so on kernels older than 5.6 such a rule fails to compile rather than loading in a form that can be walked around. Run sevorix status to see the tier actually in force rather than the one you configured.

macOS is a narrower build, and it is worth being exact about how. A Mac has no seccomp and no eBPF, so neither syscall tier exists there: enforcement is the policy engine applied through the local proxy and the sevsh shell wrapper. The shell commands and outbound requests an agent issues through them get the same verdicts, lanes and audit record as on Linux, but raw syscalls are not intercepted, and the kernel-level guarantees on the threat model page are Linux guarantees. Sevorix Lite publishes builds for both Intel and Apple Silicon Macs. Sevorix Pro is Apple Silicon only, and its macOS build is not notarized by Apple — install it with curl as the release notes show, or a copy downloaded through a browser will be quarantined until you clear the flag.