Siphrix in one paragraph

Siphrix is an AI Action Audit & Risk Monitor. It watches what an AI agent actually does: every action is evaluated against a policy, recorded in an auditable decision trail, and anything risky raises a risk-ranked warning. By default nothing is blocked — enforcement is an opt-in mode for operators who want prevention rather than monitoring.

Under the hood it is four coordinated layers — a policy decision layer, a runtime enforcement layer, a trust / audit / governance layer, and an operator readiness surface — but externally it is one product: the audit layer between agent intent and real-world action.

Quickstart

The canonical first-run path is three commands — fully offline.

pip install siphrix
siphrix demo      # the block / allow / audit walkthrough
siphrix doctor    # human-readable launch-readiness report

siphrix demo is the golden path: it prints a blocked unsafe action, an allowed safe action under the shipped safe_defaults pack, and an auditable decision-trail recap.

Core concepts

Verdicts

Every evaluation returns exactly one outcome, a machine-readable reason code, and the material for an audit record.

Fail-closed

When policy is missing, ambiguous, or evaluation cannot complete, the verdict is BLOCK — never a quiet ALLOW. An empty allowlist yields BLOCK for everything (policy_empty_allowlist). In the default audit mode that surfaces as a warning; only opt-in enforce mode actually denies.

Policy packs

Policies ship as packs — versioned, optionally ED25519-signed bundles of rules. The shipped safe_defaults pack allows ordinary read/inert actions and blocks destructive, financial and exfiltration categories. You layer your own rules on top.

Policy schema

A policy is a declarative document of rules matched against an action context. Rules are evaluated first-match, the engine resolves deterministically and fails closed — duplicate keys, unsafe YAML tags and unknown schema versions are rejected outright.

# minimal v4 engine policy (see docs/policy-schema-v4.md)
schema_version: 4
version: 4
default_action: BLOCK
global:
  rules:
    - id: allow_file_read
      when: { action_name: file_read }
      then: ALLOW
      reason: file_read_allowed_by_pack
    - id: block_file_delete
      when: { action_name: file_delete }
      then: BLOCK
      reason: file_delete_blocked_by_pack

CLI

The siphrix command is the front door to everything local.

Run siphrix --help to discover every subcommand and its flags.

Python SDK

Evaluate any action from your own code in two lines. The public surface is small and stable.

from siphrix import ActionEvaluator, PolicyManager

evaluator = ActionEvaluator()                  # loads active policy
verdict = evaluator.evaluate(action, context)  # → outcome, reason_code, …

if verdict.outcome != "ALLOW":
    raise Blocked(verdict.reason_code)        # do not run the action

For a full pipeline (normalize → evaluate → record), use run_pipeline(user_text). The repo walkthrough at examples/example_agent.py is a deeper integration tour.

Daemon API

The local loopback daemon (siphrix serve --foreground) exposes 20+ bearer-authed routes. The console, extensions and editors all talk to it. Highlights:

MCP server

A verdict-only Model Context Protocol server over stdio lets any MCP client ask Siphrix for a decision before acting. The operator's console Block/Allow rules answer here too — the same shared overlay the daemon and the Claude Code hook consult.

python -m siphrix.mcp                         # start the stdio server
python -m siphrix.mcp.client_config --client codex   # wire into a client

Editors & agents

One command wires everything: siphrix agent-setup detects the agents on the machine and configures each with what it supports — an auditing PreToolUse hook for Claude Code (enforcement is opt-in), an advisory MCP registration for Codex. The VS Code extension's Set Up Agent Firewall button and the Windows installer's checkbox run the same brain.

One command center: the console's Block/Allow rules and approval queue govern every evaluation surface through one shared gate (siphrix.local_overlay) — the daemon's /evaluate (used by the VS Code and browser extensions), the Claude Code hook, and the MCP tools Codex consults. Flip a rule in the console and the very next matching agent action is judged by it; every decision from every surface lands in the same audit trail. Verdicts are block-only and fail-closed: a console rule can add BLOCK verdicts but never lifts an engine BLOCK, and an operator approval only lets the engine reconsider. Enforcing those verdicts stays opt-in.

And across machines: siphrix cloud-connect --server URL --code TOKEN enrolls a machine in the login console (siphrix.com or a local siphrix console) as a least-privilege device. Org rules pull down into that machine's monitor — covering its Claude Code, Codex and daemon — and its agent decisions push up into the console's Activity view, labelled per device. Outbound-only and opt-in; a failed sync keeps the last rules in force.

VS Code extension

One-click agent-firewall setup (bundled engine wheel — works offline), plus health, evaluate and audit with Allow / Block / Pause control over /rules, in the editor. Marketplace id siphrix.siphrix-vscode.

Claude Code plugin / hook

A PreToolUse hook — every tool call is evaluated and recorded before it runs, mapped to the shipped-pack action vocabulary, with every decision in the audit trail. Enforcing BLOCK verdicts is an opt-in switch. Installed by agent-setup or via the plugin marketplace.

Codex / generic agent bridge

Advisory verdict tools via MCP (registered automatically by agent-setup when Codex is present) plus a client-config generator and the siphrix.console.ai_tool_bridge contract for any local agent. Evidence even without enforcement: agent-setup also registers a Siphrix observer as Codex's notify program, so every notable Codex event lands in the canonical audit trail as a value-safe OBSERVED record — event type and counts only, never message content.

Browser extension

An MV3 extension and JS SDK watch uploads and secret-pastes into AI sites via the local daemon, flagging risky ones. It supports account login and a per-platform watch level (Off / Basic / Strict) from the popup. Dev-load today; store publishing is an operator step.

Service tier

A real, persistent local service: SQLite storage, hashed API keys (PBKDF2), RBAC, tenant isolation, a decision API, audit ingestion and approvals — loopback only.

python -m siphrix.service        # start the service tier

Console & dashboard

Siphrix ships three operator surfaces, all unified in the web console on this site:

• Account console — pick a watch level (Off / Basic / Strict) per AI app in plain language; power users add scoped rules.
• Operator dashboard — Overview, Readiness, Release state, Runtime, Policy Packs, Policy Check, Demo and Audit.
• Web console — Simulator, Audit, Rules and Approvals against the local daemon.

The console talks only to the local daemon / service. The session token stays in page memory; nothing is persisted to browser storage.

Audit & replay

Every decision produces an audit record. Records are redactable and can be exported (JSON/CSV) or bundled into a portable evidence bundle. The trust layer adds ED25519 policy signing and an integrity-chained ledger.

Replay re-decides historic actions under a candidate policy, so you can measure the impact of a change before shipping it.

Rotation. The canonical events log rotates in place at 10 MiB (three .1–.3 backup generations kept; SIPHRIX_LOG_MAX_BYTES overrides the threshold, 0 disables). Analytics and the console read oversized logs through a most-recent window, so metrics keep working at any log size.

Capabilities — the honest table

Every surface is labelled by maturity, on purpose. See the interactive matrix on the home page. The three levels:

Nothing is overclaimed. Where a surface is contract-only or external, the code and the table say so plainly.

Security posture

• Fail-closed on missing/ambiguous policy and on evaluation failure.
• No silent execution — /evaluate is decision-only; the broker is record-only by default and real backends are opt-in in code.
• Token hygiene — bearer/session tokens stay in memory; never written to storage or logs.
• Signed policy — ED25519 signing + verification and an integrity-chained ledger.
• Strict policy parsing — duplicate YAML keys are rejected outright (policy_duplicate_key) instead of silently resolving last-wins, so an ambiguous policy can never turn permissive.
• Hardened local daemon — loopback-only, constant-time bearer auth, same-origin CSP + frame denial on the console, per-connection socket timeouts, and a single version-scrubbed Server header.
• Tenant isolation in the service tier; hashed API keys (PBKDF2); RBAC.

External handoffs

Some capabilities cannot be made real inside the repository — they need credentials, hosting, store accounts or platform signing that live with the operator. Siphrix builds everything up to that boundary as real, tested code, then stops. It never simulates these as if done.

Roadmap

Siphrix is at v1.0.3, a private-beta candidate. v1.0.3 is a QA-hardening release: a strict duplicate-key policy loader (fail-closed), hardened-mode pack-export, canonical-log rotation, windowed analytics over large audit logs, and a hardened local daemon (CSP, socket timeouts, single Server header). Direction of travel: hardening the enforcement bridges, expanding signed-policy distribution, deepening the governance models from contract toward shipping, and the operator-credentialed steps above. See ROADMAP.md and CHANGELOG.md in the repository for the ordered list.