Doberman：AI Agent 的贴身保镖，让危险操作在执行前戛然而止

你一定见过这样的场景：团队引入了一个 AI 编程助手，开发者们兴奋地把项目交给它处理——批量重命名文件、批量修改配置、甚至直接 git push。然后，有人手滑点错了 AI 的建议，它真的执行了 rm -rf .，一夜回到解放前。

更可怕的是，AI Agent 本身也可能被攻击。提示词注入（Prompt Injection）可以让模型在不知不觉中帮攻击者「顺手」把 .env 里的 API Key 发出去。API 泄露、数据外传、仓库被删——这些不是危言耸听，而是 2024 年以来 GitHub 上多起真实事件的缩影。

Doberman 正是为解决这个痛点而生的：它是一个专为 AI 编程 Agent 设计的安全护栏框架，位于 Agent 和它的工具之间的 MCP 代理层，在任何危险操作执行之前将其拦截。它的核心原则只有两条——Fail Closed（不确定就拒绝）和 Raise-Only（规则只能收紧，不能自动放宽）。

背景：为什么 Agent 安全是个真问题

2023-2024 年，随着 Claude Code、Cursor、Copilot 等 AI 编程 Agent 大规模落地，一个根本性的矛盾浮出水面：Agent 的能力越强，它能造成的破坏也越大——而且是自主完成的，没有二次确认。

传统安全工具（Nginx WAF、静态代码扫描、CI/CD 检查）都是面向人类开发者的流程，Agent 的实时交互完全绕过了这些节点。Agent 可以在一次对话中连续执行 curl、git push、pip install——这些动作在人类开发中通常需要多个步骤和审批，在 Agent 场景下只是一个 API 调用。

开源社区为此提出的方案大体分为两类：一类是 Prompt Guardrails（提示词护栏），分析输入输出中的可疑内容；另一类是 Tool Use 权限控制（如 MCP 官方方案）。前者是"建议性"的，模型可以选择忽略；后者是"配置性"的，管理员手动设置权限。

Doberman 走的是第三条路：执行路径上的强制拦截。它不是告诉模型"你这样做不好"，而是直接说"这个操作不能执行"。

核心架构：三层门卫的精密配合

Doberman 的技术架构分为三层，每层各司其职：

第一层：Egress（出口控制） 负责管控 Agent 与外界的通信通道。egress/allowlist.py 维护了一个可配置的允许列表，控制哪些域名/IP 可以被 Agent 访问；egress/artifact.py 追踪数据外发行为；egress/velocity.py 检测异常高频的出站请求（防止数据批量外泄）。

第二层：Decision Engine（决策引擎） 这是 Doberman 的心脏。engine/adjudicator.py 对每个工具调用进行风险评估，engine/detectors/ 目录下有多个检测器（如 token_channels.py 检测 Token 耗尽攻击），engine/rules/ 目录下是规则引擎，支持命令白名单、路径限制、敏感文件保护、密钥泄露检测等。engine/subjective.py 处理主观风险评估（如操作是否越权），engine/objective.py 处理客观风险评估（如命令本身是否危险）。

第三层：Authorization（授权层） 三段式判决机制：

• PASS：常规操作，直接放行，零延迟
• AUTH：敏感操作（如写文件、执行 shell 命令），暂停等待人工审批
• BLOCK：危险操作（如删除仓库、访问 .env），直接阻断，返回拒绝原因

关键设计：Fail Closed 原则。如果 Doberman 遇到任何未知的错误或异常情况，默认行为是拒绝操作，而不是放行。这意味着即使用户配置出错，系统也是安全的。

技术栈：纯 Python，最小依赖

Doberman 的技术选型非常务实：

组件	技术选型	理由
语言	Python 3.11+	主流 AI 生态，AI 开发者友好
核心依赖	pydantic v2, mcp >= 1.27	数据验证 + MCP 协议支持
存储	aiosqlite	本地 SQLite，无额外依赖
认证	pyotp（TOTP）	支持二次验证
异步	river >= 0.21	在线学习/自适应规则
CLI 框架	typer	现代化命令行工具

可选依赖分为三类：dev（pytest、ruff）、tui（textual 文本界面）、dash（starlette + uvicorn Web 仪表盘）。

上手体验：两行命令即可保护你的 Agent

安装极其简单：

pip install doberman-core

安装后，Doberman 提供两种接入方式：

方式一：MCP Proxy 模式（推荐） Doberman 作为 MCP 服务器代理运行，AI Agent 通过它访问工具。Claude Code、Cursor、Codex 等主流 Agent 均支持 MCP 协议。

# 启动 MCP 代理
doberman mcp --port 8080
# 然后在 Agent 端配置 MCP 服务器地址

方式二：Host Hooks 模式 Doberman 以本地 Hook 形式植入，拦截主机级操作（文件系统、shell 命令）。

Dashboard（doberman dash）提供可视化监控，实时显示：

• 当前 Agent 的所有工具调用记录
• 拦截事件的详细原因（Reason Code）
• 待审批队列（AUTH 状态的人工确认界面）

容器化与部署

当前状态：暂不支持 Docker 容器化部署，这是项目的一个明显短板。没有 Dockerfile 和 docker-compose.yml，意味着在生产环境大规模部署时需要额外的工作。

Web UI（Dashboard）需要单独安装 dash 依赖：

pip install doberman-core[dash]
doberman dash

硬件要求极低，不需要 GPU，普通开发机即可运行。

局限性：不回避的坦诚

Doberman 并非银弹，以下问题值得注意：

1. MCP 协议依赖 目前最成熟的接入方式是 MCP 协议。不支持 MCP 的 Agent（如某些老版本工具）无法直接使用 Doberman 的全部能力。

2. 需要主动配置规则 开箱即用的默认规则有限，要真正保护自己的项目，需要针对项目特点编写 Guardrail 插件。文档中有"Write a custom Guardrail"指南，但有一定学习曲线。

3. 性能开销 每个工具调用都经过 Doberman 代理层，对于极高频的操作场景（如需要每秒执行数千次工具调用的测试框架），会有可感知的延迟。

4. alpha 状态 README 中明确标注项目处于 alpha 阶段，API 可能在未来版本中发生变化。

行业意义

Doberman 的出现反映了 2024 年 AI Agent 安全领域的一个核心趋势：从"信任但验证"（Trust but Verify）到"默认拒绝"（Deny by Default）的范式转换。

随着 AI Agent 从实验走向生产，它们会越来越多地接触真实系统和敏感数据。Doberman 代表了一种务实的工程路线：用透明、可审计的代理层，在不影响 Agent 工作效率的前提下，提供有实质意义的安全保障——不是建议，而是执行前阻断。

---

总结：Doberman 是一个面向 AI Agent 开发者的生产级安全护栏框架。它以 MCP 代理层的方式，在每个危险操作执行前进行强制拦截。纯 Python 实现，部署简单，但容器化支持尚待完善。适合对 AI Agent 安全性有较高要求的团队在开发测试阶段引入。