Muzzle

CLI reference — Every command, flag and choice, generated from the CLI's own parser.

Summary

Muzzle is the AI input, output, and execution security layer. It runs as a transparent inspecting proxy in front of your model providers: clients keep talking to the same host and port, and every request, response, and tool call flows through Muzzle's policy engine on the way past. A path Muzzle has no inspector for is refused, not forwarded — an inspecting proxy that passes along what it cannot read is just an expensive router.

Status

Preview. A source tarball is published from the Hurricane AI Lab site, and Sentinel's installer pulls it automatically; either way v1 installs from source on a Linux host.

What v1 is

The v1 preview is a provider-agnostic gateway proxy. It started as an Ollama-only shim and now normalizes Ollama, OpenAI, and Anthropic traffic into one canonical model so a single policy engine inspects all three the same way — including streaming responses and tool calls. Muzzle can also stream from the model host and reassemble the answer, which keeps a long turn from being cut off by a timeout somewhere in the path while the model is still working.

A v1 install gives you four things:

• The proxy — one or more listeners, each binding a local port and forwarding to a configured upstream provider, inspecting traffic in both directions.
• A local admin UI — served on a second (admin) listener in the same process. It renders the live config as an editable form, accepts edits, previews policy decisions (simulation), and tails the JSONL decision log. The form supports adding and removing upstreams, listeners, policy overrides, and denylist terms, with an advanced YAML escape hatch.
• A muzzle CLI on PATH — for adding upstreams, editing policy, validating the config, checking status, running simulations, tailing logs, and restarting the service.
• Install/uninstall tooling — install.sh lays down /opt/muzzle/v1, a default /etc/muzzle/muzzle.yaml, a systemd unit, and a Python virtualenv with all dependencies; uninstall.sh removes the install, config, logs, CLI wrapper, and service artifacts.

How policy works

Detectors run rules-first and fast — prompt injection / jailbreak, secrets, PII, and a configurable content denylist. Each detector maps to a category, and each category has a per-direction action: allow, log, redact, transform, or block. Tool calls are blocked by default. An optional LLM judge can add a deeper second opinion but is off by default. Muzzle fails closed by default: if inspection cannot complete, the request is blocked rather than passed through (configurable to fail open).

Docs workflow

The living docs in products/muzzle are the canonical source of truth. When a doc set is approved, an export step writes a new immutable, timestamped MongoDB snapshot for each document, stamped with source path, commit, and digest. The API serves the latest approved snapshot for normal product pages, and the website can browse the version history and diffs per document.

Direction

v1 is the enterprise gateway foundation: one canonical model, three providers, streaming and tool-call inspection, and policy simulation shared by the CLI and the admin UI. Next steps deepen provider coverage and the policy surface rather than reworking the core.

More

• Getting started and v1 scope: v1/README.md
• How it works (technical): HOWITWORKS.md
• Plain-English overview: PLAINENGLISH.md
• Help desk: HELPDESK.md
• CLI reference: CLI.md