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
Decision-only simulation. The daemon evaluates the action
against the policy runtime and returns a verdict. The
underlying action is never executed.
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.
Local approval queue
The local approval queue is operator-workflow state only.
Approvals do not execute actions and
approvals do not bypass BLOCK decisions:
an approved record is just a stored note that the
operator has reviewed something. Enabled local block
rules still block matching actions even when an
approval record exists. 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.
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.
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.