Start and Verify

With Sevorix installed: log in, start the daemon, optionally enable ML prompt-injection detection, and confirm enforcement is actually on.

Log in and start

Pro checks your subscription when the daemon starts, so log in to Sevorix Hub first:

sevorix hub login        # or, for a new account: sevorix hub register

Then start the daemon:

# Auto-assigns a session name and the first free port from 3000
sevorix start

# Or start a named session on a specific port with an initial role
sevorix start --name my-project --port 3001 --role developer

sevorix start prints the Observatory's URL, which carries a ?token= parameter:

http://localhost:3000/dashboard/desktop.html?token=…

If you lose it, sevorix status prints it again.

That token authenticates the Observatory's session-control buttons — Kill, Freeze, Unfreeze. Without it the Observatory still shows live traffic, but those controls are rejected. The same token gates the POST /api/session/* endpoints, which is what stops an arbitrary local process from killing or re-roling a live agent session. It is generated at startup and written to the session metadata file at ~/.local/state/sevorix/sessions/<name>.json, mode 0600; sevsh and the sevorix session commands read it from there automatically.

Optional: ML prompt-injection detection

The installer does not set this up — enable it yourself once Sevorix is installed:

sevorix models pull protectai-v2 --with-policy

This downloads the protectai-v2 classifier model — roughly 740 MB — and adds the prompt-injection-check policy to your default role. That policy blocks Network-context traffic when the model's confidence crosses 0.90.

Two things about this are worth being explicit about, because the trade runs in both directions:

• It is not free if you enable it. Every scanned request pays classifier latency, and the model artifacts occupy disk.
• It is not a no-op if you skip it. Without a classifier, prompt-injection content is judged by pattern-matching policies alone.

The classifier fails closed: a missing, unloadable, or digest-mismatched model blocks the traffic it was meant to score rather than passing it. Model artifacts are pinned by SHA-256 and byte size, verified both at download and at load, with no bypass flag — a tampered classifier that scores every injection as benign is indistinguishable from a working one at runtime, so an unverifiable artifact is refused rather than trusted.

Verify that enforcement is on

Installing is not the same as enforcing. Run these four checks.

1. The daemon is running, and at the tier you expect.

sevorix status

Confirm it reports a running session, and check the enforcement tier line. A DEGRADED marker means you asked for the Advanced tier on a system that cannot provide it — expected on WSL2, most stock cloud kernels, and any install without the eBPF kernel bytecode (see the eBPF installer note). Standard is still enforcing.

2. The configuration parses and the roles resolve.

sevorix config check

This parses every file in ~/.sevorix/policies/ and ~/.sevorix/roles/, reports policies that fail validation, and warns about Allow policies broad enough to disable a role's enforcement wholesale.

3. A policy actually produces a verdict.

sevorix validate "DROP TABLE users" -r <your-role> -C Shell

Expect "verdict": "BLOCK" and a non-zero exit status. If you get ALLOW, the policy you expected to fire is either not in that role, scoped to a different context, or not loaded at all.

4. The verdict is enforced on the real path.

sevsh -c "DROP TABLE users"

sevorix validate asks the engine a question; sevsh is the thing that acts on the answer. A BLOCK from step 3 that runs anyway here means the shell channel is not wired up.

Next

The default policies are a starting point, not a security posture. Read Policy Format to review them and write your own, and keep Troubleshooting handy if a policy does not fire the way you expect.