A useful security policy needs to describe the project you're working on. A migration, a generated file and an ordinary source edit can carry different consequences, even when the same coding agent performs them.
Doberman has a few ways to make those boundaries explicit and inspect the decisions they produce. This week's focus is customization and visibility.
A repo-root doberman.policy.yaml puts supported policy settings in git. You can review a protected-path change in a pull request, alongside its reason. The file is resolved on the action path. A weakening change still needs the explicit policy-file acceptance path and human verification; editing YAML doesn't quietly remove the protection already in force.
For behavior beyond the supported policy settings, the plugin interfaces let you attach your own implementation. A rule or detector is a Python package advertising the documented entry point, and it must be explicitly enabled. Rules use the objective guardrail; detectors use the subjective guardrail on the adaptive MCP path. The extension guide includes a worked detector example. This is code you need to review and test, rather than a promise that any natural-language rule can be pasted in safely.
Once the policy is in place, you need to understand its effect. The local dashboard shows the decision feed. On the MCP proxy path it can also present actionable pending approvals. Host-hook decision rows appearing in the feed do not establish that those approvals use the dashboard, so a demonstration should identify the integration. The terminal UI and log explanations provide another way to inspect a decision.
Deletion safeguards make that visibility concrete. The host-hook flow can show a bounded preview of the effect and re-check it before forwarding an approved deletion. A detected change prevents the changed effect from inheriting the earlier approval. It isn't an atomic filesystem transaction, and any demonstration should use the exact released version it claims to show.
For the adaptive MCP path, memory seed accepts validated allowed-action traces to initialize persisted baseline statistics. It doesn't switch off the deterministic security floor. The in-memory Half-Space-Trees model still starts cold in a new proxy process, and native Claude/Codex hooks don't automatically run that full adaptive stack. Those boundaries matter when describing what has been warmed.
The quieter tools are useful too. A scan can inspect the configured surface, doctor can point to wiring problems, and policy history can help explain a change. A clean configuration report should be followed by a real interception check before relying on the integration.
I built Doberman so the boundaries and decisions can be inspected. I would start with one repo, one policy requirement and one harmless verification case, then expand from something that works.
Doberman is open source, and the extension and setup guides describe the supported paths. What would you want to attach first: your own protected paths, a custom rule, or an audit integration?
Top comments (0)