Home

Siphrix local daemon status. This console talks only to the local daemon over loopback. No cloud sync, no telemetry, no billing.

Getting started

Three steps to drive the console. Everything here is local and decision-only — nothing you do executes a real action.

1
Add your token. Open Settings and paste the token portion of your SIPHRIX_LOCAL_DAEMON_TOKENS entry. Home works without it; every other page needs it.
2
Simulate an action. Go to the Simulator, enter an action like file_delete, and read the verdict (ALLOW / BLOCK) with its reason. The action is never run.
3
Shape policy. In Rules add a local block rule or an approval, then re-simulate to watch the decision change.

Daemon status

Alpha posture

Local-only alpha — single-machine, single-operator use.
No cloud sync.
No telemetry.
No hosted control plane.
No billing or commercial features.
Rules and approvals are persisted as local JSON files under your user profile only — no remote database.

Support diagnostics

A sanitized local report you can paste into a support ticket. Nothing is uploaded and no tokens, raw payloads, rule match values, approval summaries, internal paths, or audit event bodies are included. Copy manually if support asks; the daemon never sends this anywhere. Requires a bearer token — paste it on the Settings page first.

Calls GET /diagnostics.

Operator posture checklist

Quick read of what this local console guarantees and what it does not do. Each line is a contract pinned by tests in the shipped package.

Loopback only — the daemon binds 127.0.0.1 and never a public interface.
Bearer-token auth is required on every product route (Simulator, Audit, Rules, Approvals). The Home page is the only token-free surface.
The bearer token is kept in browser memory only — never written to localStorage / sessionStorage, never put in a URL, and cleared on reload.
No cloud sync. No telemetry. No hosted control plane in this local alpha.
Only BLOCK rules are honoured locally — ALLOW rules, regex, and shell-exec rules are rejected fail-closed.
Approvals are operator workflow notes — they do not execute actions and they do not bypass BLOCK decisions.
The Windows installer ships unsigned by default — real Authenticode signing is gated on certificate procurement.

Simulator

Try out an action and see whether Siphrix would allow or block it. Nothing actually happens — you only see the decision.

Audit

Read-only audit summary over the canonical events log. Raw record payloads and absolute file paths are never surfaced here — only the closed-vocabulary safe fields.

Summary

By verdict

By reason

Rules

Read-only view of shipped policy packs and the policy-builder preset index, plus a local-only block rules store. Rules are saved to your user profile and listed here. Enabled local block rules can block Simulator / POST /evaluate decisions. Only BLOCK rules are supported — ALLOW rules are not supported. Disabled rules are kept for editing but do not affect decisions.

Shipped policy packs

Builder presets

Local block rules

Rules are stored locally under your user profile and never sent anywhere. Only BLOCK rules are accepted; ALLOW rules, regex, and shell-exec rules are rejected fail-closed. When you tick Enabled, the rule is consulted by POST /evaluate as a block-only overlay and matching actions will be blocked.

A name for this switch? What kind of action?? Apply it when the details…? …this text? Block it right away?

Saved on your computer only.

Local approval queue

The local approval queue is operator-workflow state. Approvals do not execute actions and approvals do not bypass the engine's BLOCK decisions — an approved record never makes an action run. An active (approved, non-expired) record only lets /evaluate reconsider a matching local block rule: the engine still decides, and a default-deny or engine BLOCK still blocks. Pending, rejected, or expired records leave the local block in force. Records are stored locally under your user profile and never sent anywhere.

For YAML-shaped policy authoring, the shipped CLI surfaces (siphrix policy-builder, siphrix packs) remain the canonical workflow. The local rules and approvals shown above are a separate per-user store; they coexist with policies without replacing them.

Settings

Local-only configuration. The bearer token is kept in browser memory only. It is never written to localStorage, never logged, and never displayed back to you in plain text.

API base URL

base_url

Local bearer token

Bearer auth is required for the Simulator, Audit, and Rules pages. The Home page does not require a token. Token values are kept in memory only and are cleared on page reload.

Token (kept in memory only)?

Validate token exercises the existing GET /policies route with the in-memory token and reports whether the daemon accepted it. The token itself is never displayed and never put in the URL.

token_loadedno

token_validationnever checked

Token guidance

Tokens come from the env var named by --token-env at siphrix serve time. The default name is SIPHRIX_LOCAL_DAEMON_TOKENS. The value is a CSV of actor:role:token triples. The --token flag is intentionally not supported, so a bearer value cannot land in shell history.

# PowerShell
$env:SIPHRIX_LOCAL_DAEMON_TOKENS = "user:viewer:<your-local-token>"
python -m siphrix serve --no-open

# bash / zsh
export SIPHRIX_LOCAL_DAEMON_TOKENS="user:viewer:<your-local-token>"
python -m siphrix serve --no-open

Out of scope for this alpha: system-tray, auto-start, auto-update, signed installer (the build scaffold is in place; real signing requires a code-signing certificate), cloud sync, telemetry, billing, multi-tenant / hosted org workflow, browser extension.