The policy firewall for AI agents.

Yes. The full runtime, including the policy engine, wire-level transports, approval queue and dashboard, is Apache 2.0, source on GitHub. Self-hosted, single binary. Vanzik Cloud is a separate hosted layer that never gates the open path.

One command. On macOS or Linux: curl -fsSL https://github.com/lictorate/vanzik/releases/latest/download/install.sh | sh. On Windows, in PowerShell: irm https://github.com/lictorate/vanzik/releases/latest/download/install.ps1 | iex. Both install the server, the MCP gateway, and the LLM API proxy after checking them against the release checksums. Then run vanzik setup: a menu that starts Vanzik at login with a starter policy and an API key, and later updates or uninstalls it. Running the install command again also updates. There is also a multi-arch Docker image, ghcr.io/lictorate/vanzik, and go install lictorate.com/vanzik/v2/cmd/vanzik@latest for Go 1.26+.

Run the install command above as the user who set AgentGuard up. AgentGuard is now Vanzik, and in 2.0 the rename is the only breaking change. The installer then runs vanzik migrate --from-agentguard, as vanzik setup also does: it moves the login service, the config and data folders and the database, and points the Claude Code, Cursor, Gemini CLI and Codex hooks at vanzik, keeping a backup of every file it edits. Policies, audit logs and databases carry over unchanged. Rename any AGENTGUARD_* variable to VANZIK_*: one that would be used now stops the program instead of being ignored. 1.x's own Update can't install 2.0. Releases before 2.0 stay on PyPI as agentguardproxy and on npm as @lictorate/agentguard. Full steps: the migration guide at vanzik.lictorate.com/docs/migration.

Vanzik intercepts at the protocol boundary instead of asking the agent to opt in. The MCP gateway sits between any MCP client (Claude Desktop, Cursor, Cline, Continue, Zed) and the real MCP server, policy-checking every tools/call. The LLM API proxy sits in front of the OpenAI and Anthropic APIs: set one base-URL environment variable and tool calls in the response stream are gated before your code ever sees them.

Yes. vanzik hook claude-code, cursor, gemini-cli and codex plug into each agent's own hook system and check its shell commands, file reads and writes, web fetches and MCP tool calls against the same policy as every other path (Claude Code since v1.3; Cursor, Gemini CLI and Codex CLI since v1.4). vanzik setup connects and disconnects each agent and can add a starter rule block for it. By default a call the hook cannot check goes ahead with a warning; with --fail-closed it is denied instead. Calls from subagents are linked to the session that started them, and the dashboard replays the session with one lane per agent.

It refuses it. Gating fails closed: a response the proxy cannot decode into a tool call, a stream that ends mid-tool-call, and a tool input that arrives orphaned from its call are all denied under a stable rule string rather than forwarded unexamined. v1.1 closed five such paths in the LLM API proxy. Before it, a stream that ended with a tool call still buffered produced an empty 200, and a body an SDK could execute but Go could not decode was passed through. Refusals are recorded in the audit trail with the DENY the client received, and they are deliberately not subject to --fail-mode allow: that flag governs an unreachable guard, not a healthy guard that cannot see what the client will execute.

No. Vanzik is self-hosted and makes no outbound calls by default. Prompts, tool arguments, and results stay in your network unless you configure notifications (Slack, webhooks) or opt in to Vanzik Cloud.

0.53 ms p99, measured end-to-end on the full HTTP check path with persistence enabled (the v1.0 verification). A CI gate fails the build of every release if p99 crosses the 3 ms budget; v1.2's command-by-command shell checks left the simple-command path at v1.1's speed.

Yes, since v1.0, and hardened in v1.1. The zero-config default is single-node SQLite; point --store-dsn at PostgreSQL and give each replica a --node-id to share approval, rate-limit, and cost state across nodes. Reconciliation runs in the background, so no synchronous database call is added to the /v1/check hot path, so the sub-3 ms p99 budget is preserved. v1.1 added an advisory lock so replicas no longer race each other through schema migration at boot, and a shared row-lock order that removed cross-node flush deadlocks: a three-node cluster served 5.1M requests across three runs with zero errors and zero deadlocks, where the pre-fix build of the same shape produced 393. Distributed rate limiting is bounded-overshoot by design, and conflicting approval resolutions always converge to DENY.

Tamper-evident, since v1.4. Vanzik writes an append-only JSON-Lines audit trail of every decision, recording agent, scope, command and reasoning, and with --audit-seal it chains every entry to the one before it with an HMAC-SHA256. vanzik audit verify checks the log offline, archives included, and names the first edited, deleted or reordered line by file and line. New installs made with vanzik setup are sealed; an existing server stays unsealed until you turn it on. A chain cannot show that its newest entries were cut off, so Vanzik publishes the chain head every few minutes: forward those anchors, or the trail itself, to append-only/WORM storage such as S3 Object Lock, a SIEM, or syslog.

No. Vanzik is a policy-enforcement and audit layer, not an OS sandbox: it does not intercept syscalls. Combine it with OS-level isolation (containers, seccomp, egress rules) when your threat model includes a hostile agent that controls its own runtime. As of v1.1 this is written down rather than implied: the threat model (vanzik.lictorate.com/docs/threat-model) states the actors in decreasing order of trust, the trust boundaries between them, the fail-open versus fail-closed matrix, and the explicit non-goals.