Doberman-Core

Open source alternative to Zenity, WorkOS FGA, AuthZed, Oso Cloud and Lutril

282 stars
Apache-2.0
Active this week
Last commit 3 days ago

Last verified Oct 20, 2026

Secure AI coding agents at runtime with adaptive authorization, blocking dangerous tool calls before they execute. Apache 2.0, pip-installable, local-first.

Visit website GitHub282

Read the full breakdownWho it is for, how it works, trade-offs, the quick start and the FAQ

who it's for

Who Doberman-Core is for#

Developers running Claude Code or Codex autonomously

Doberman wires directly into Claude Code's hooks system and gates every built-in and MCP tool call before it runs. The setup is two commands: pip install and doberman setup. Developers who let Claude Code run long autonomous sessions can set the strictness mode to Balanced or Strict and receive AUTH prompts for file deletions, shell commands, or sensitive reads.

Skip if:

If your agent sessions are always supervised and you review every proposed action before it runs, the additional interception layer adds friction without a matching safety benefit.

Security engineers auditing MCP server exposure

Doberman's MCP proxy mode wraps any MCP-compatible tool server and logs every tool call with a verdict. Security teams evaluating what an LLM could do with a given set of tools can run Doberman in monitor mode, record the decision log, and analyze the verdict distribution before switching to enforcement mode.

Skip if:

If you are auditing a non-MCP agent framework, Doberman's current host support does not cover it. Check the parity matrix in the README for current coverage.

Platform teams deploying multi-agent coding pipelines

Teams running fleets of AI coding agents can apply consistent policy across all agents through Doberman's strictness modes and plugin system. The policy-change ledger provides an append-only audit trail, and the AUTH approval flow with 2FA gating means policy weakening requires deliberate human action with a traceable record.

Skip if:

Doberman does not yet include a central management console or fleet-wide policy distribution. Each instance is configured locally. If you need centralized policy management across many hosts, you will need to build the distribution layer yourself.

Developers building guardrail plugins or audit integrations

The doberman.rules entry-point group lets you register custom guardrail rules without forking the core package. The doberman.audit_sinks entry point forwards the redacted decision log to any external pipeline, such as a webhook, SIEM, or logging service. A worked example is in examples/plugin-guardrail/ in the repo.

Skip if:

If your security requirement is authorization for web application users rather than agent tool calls, general-purpose authorization platforms are a better fit for that use case.

the problem

The problem it solves#

AI coding agents run autonomously. Given the right prompt injection or a hallucinated tool argument, they will rm -rf your repository, read and exfiltrate your .env file, or force-push to a protected branch. There is no natural chokepoint: once the model decides to call a tool, most agent frameworks execute it without a separate review step.

Prompt-inspection guardrails inspect the conversation and offer warnings, but they run before the model acts, not before the tool runs. If the model ignores the warning or an injection bypasses the inspection, the action executes anyway. Post-execution monitoring tells you what happened after the data is gone. Neither approach stops the dangerous call on the execution path.

how Doberman-Core solves it

How it solves it#

Execution-Path Interception

Doberman sits between the agent and its tools as an MCP proxy or a host hook, not as a prompt analyzer. Every tool call passes through the decision engine before reaching the underlying tool. A blocked call never executes; the downstream tool's call log stays empty, which is verified by the CI integration test suite.

Three-Verdict Decision Engine

Each tool call receives one of three verdicts: PASS (routine work, straight through), AUTH (sensitive, paused for human approval with a 2-minute desktop timeout before auto-denying), or BLOCK (dangerous, stopped cold). The verdict is final before the tool runs.

Fail-Closed Guarantee

Any error, unhandled case, or unanswered approval prompt resolves to a denial, not a default allow. A pending AUTH that nobody answers times out and is logged as timeout rather than denied. An agent running unattended cannot get a tool call approved by inaction.

Raise-Only Policy Learning

Guardrails and adaptive learning can auto-tighten over time, but they never silently loosen. Any permanent policy weakening requires explicit human approval gated by a possession factor: TOTP if enrolled, or the local Doberman password. Every weakening is recorded in an append-only policy-change ledger.

Strictness Modes and Plugin System

Four strictness modes (Light, Balanced, Strict, Paranoid) let you tune the friction level. Third-party rules register through the doberman.rules entry-point group; the core package never imports your plugin by name. The same entry-point pattern (doberman.audit_sinks) lets you forward the redacted audit log to your own pipeline.

strengths · trade-offs

Strengths and trade-offs#

Strengths

On the Execution Path, Not Just AdvisoryMost guardrail tools inspect prompts and advise; if the advice is ignored or bypassed, the action runs. Doberman's interception is structural: the tool call passes through the decision engine, and a BLOCK verdict means the downstream server never receives the call. This is verified by the CI integration test suite, not just claimed in documentation.
Apache 2.0 License with Local-First DeploymentThe Apache 2.0 license allows commercial use, modification, and distribution without copyleft requirements. Deployment is local: no data leaves your machine to Doberman's servers. Compared to proprietary services like WorkOS FGA or Oso Cloud, which require sending authorization decisions through a third-party API, Doberman keeps the policy engine on your infrastructure.
CI-Proven Protection Parity MatrixThe protection parity matrix maps each security feature to each supported agent host (Claude Code, Codex, MCP proxy, OpenClaw). Each checkmark links to the CI test that proves it, and the matrix regenerates from those tests on each build, so it cannot drift from what is actually implemented.

Trade-offs

-Alpha Status with Known Detection GapsDoberman is in alpha. The README documents several known detection gaps: whole-script homoglyph confusables are not caught by the core deterministic check, bare hex or UUID-shaped secrets with no surrounding credential name pass the weak detection path, and egress classification is static (it parses command strings but cannot verify the actual network destination). These are defense-in-depth gaps, not complete bypasses, but they are real and documented.
-Python 3.11+ Required, 44 Open IssuesPython 3.11 or later is required. Teams running older Python stacks will need to upgrade or isolate Doberman in a separate virtualenv. With 44 open issues on a project created in June 2026, the surface area is still changing quickly.
-No Managed Cloud OptionDoberman is local-first only. There is no managed cloud service or hosted version. Platform teams deploying agent fleets on remote infrastructure will need to deploy and maintain Doberman instances themselves. The enterprise platform is on the roadmap but not yet shipped.

versus alternatives

Doberman-Core vs alternatives#

Doberman-Core vs WorkOS FGA

WorkOS FGA is a managed fine-grained authorization API designed for web application access control: it evaluates whether a given user can perform an action on a resource. Doberman-Core targets a different problem, gating tool calls made by AI coding agents at runtime before the tool executes. Teams building agent infrastructure often reach for general-purpose authorization platforms first and find the model does not map to the agentic execution path.

WorkOS FGA is proprietary and API-only; each authorization decision requires a network call to WorkOS servers. Doberman runs locally, keeps policy on your machine, and issues verdicts without an external API round-trip. For teams with data-residency requirements or air-gapped agent environments, local policy evaluation is a hard requirement that WorkOS FGA cannot meet.

Doberman-Core vs AuthZed

AuthZed is an open source authorization platform (Apache 2.0) based on the Google Zanzibar permission model, built for relational access control across application resources. Like WorkOS FGA, it is designed for user-to-resource authorization in web services, not for intercepting tool calls on an AI agent's execution path.

AuthZed requires running a SpiceDB instance with a PostgreSQL or compatible backend and writing permission schemas in its schema language. Doberman requires only pip install and a two-command setup. For teams specifically preventing AI agents from executing dangerous actions, AuthZed's relational model addresses a structurally different problem. AuthZed remains the better fit for application-layer RBAC and relationship-based access control for human users.

Doberman-Core vs Oso Cloud

Oso Cloud is a managed authorization service with a declarative policy language (Polar) for application-layer access control. It is proprietary and requires sending authorization requests to Oso Cloud's API.

Oso Cloud is the better fit for teams that need fine-grained, role-based, or relationship-based access control for human users across multiple application services. Doberman-Core is the better fit for teams running AI coding agents who need a decision engine on the tool-execution path, with fail-closed behavior and a local policy engine that does not depend on an external service call for each verdict.

install · quick start

Quick start#

bash

Install Doberman via pip, then run the setup wizard to wire it into your agent.
```bash
pip install doberman-core
doberman setup
```

tech stack · detected from GitHub

What it's built on#

Languages: Python

frequently asked

FAQ#

Is Doberman-Core free to use?

Yes. Doberman-Core is Apache 2.0 licensed and free to run. The package is distributed via PyPI (pip install doberman-core). There is no managed cloud service or paid tier currently; all features are in the open source package.

Which AI coding agents does Doberman support?

Doberman supports Claude Code (via native hooks), Codex CLI (experimental, via PreToolUse hook), Claude Desktop and Cursor (via MCP proxy), OpenClaw (via native plugin adapter), and any MCP-compatible agent through the MCP proxy mode. The parity matrix in the repo documents which protections are active for each host.

What happens if Doberman crashes or an approval prompt times out?

Doberman fails closed. Any error, unhandled case, or unanswered approval prompt resolves to a denial. A timed-out AUTH prompt (2 minutes for the desktop dialog, 20 minutes as the overall backstop) is logged as timeout rather than denied, so the distinction is visible in the decision log. The agent does not get a silent allow by waiting.

Can I write my own guardrail rules for Doberman?

Yes. Third-party rules register through the doberman.rules Python entry-point group. The core package never imports your plugin by name, so you install your rule package alongside doberman-core and it auto-registers. A worked example is at examples/plugin-guardrail/ in the GitHub repo.

How does Doberman compare to prompt-based guardrail tools?

Prompt-based tools inspect the conversation and offer advice before the model decides. If the model ignores the advice or a prompt injection bypasses the check, the tool call executes anyway. Doberman intercepts on the execution path, after the model decides and before the tool runs, so a BLOCK verdict stops the underlying tool call regardless of how the agent was prompted.

also worth a look