DefenseClaw 代理治理

要解决的问题

当你的 Agent 开始按需加载第三方技能、MCP 服务器和插件时，实际上等于把一台能执行工具调用的机器暴露给了不可信输入：一个来路不明的 skill 可能携带恶意提示词，一个 MCP server 可能在运行时篡改 completion，而生成的代码在执行前往往无人检查。传统做法是靠事后审计或人工评审兜底，但工具调用频率一旦上来，人工根本不具备逐条 review 的能力。

核心能力与工作方式

DefenseClaw 的切入点很直接：在所有能力运行之前加一层 operator 掌控的准入与运行时防线。它由几个协同工作的部分组成：

• Python CLI：运维人员日常操作的入口，负责扫描与策略下发；
• Go gateway sidecar：运行时的守护节点，拦截并执行治理规则；
• 可选的 OpenClaw TypeScript plugin：与现有 agent 工具链集成。

工作流程分两段：

1. 准入控制：技能、MCP 服务器、插件、自动生成的代码在运行前先经过扫描与策略校验，不合规的直接阻断；
2. 运行时护栏：对运行中的 prompts、completions、tool calls 以及 sandbox 活动做持续监控，异常行为被记录或拦截。

审计层支持多种落地方式，包括 SQLite 本地审计历史、JSONL、OTLP、Splunk 以及 webhook sink，运维人员也可以通过 TUI 视图直接查看治理状态。

适用边界与注意点

• DefenseClaw 是防御与审计层，不是漏洞扫描器本身；策略规则的质量直接决定拦截效果，需要团队持续维护；
• 它依赖 DefenseClaw CLI 与 Go gateway sidecar 的部署配合，组件不齐时准入与运行时两段无法同时生效；
• OTLP/Splunk/webhook 等 sink 为可选配置，未配置时审计数据默认落到 SQLite，长期运行需自行做归档方案。