redstamp：确定性 agent tool-call firewall

redstamp：确定性 agent tool-call firewall

核心判断

redstamp 值得深度入库，因为它把 agent 安全从“让 LLM 自我判断是否危险”推进到确定性、离线、可复现的 tool-call firewall。它与 Harness-Engineering、anthropic-agent-containment、portcullis-claude-code-security-hooks 和 cyvisguard-mcp-security-control-plane 共同指向一个趋势：安全控制必须贴近真实 effect boundary，而不是停留在 prompt 层。

机制 / 一阶原理

redstamp 在 agent 与工具之间拦截每个 action，将风险分成 green / yellow / red / black 四层，并用 policy 处理 allow/deny、egress allowlist、write roots、secret exfil、prompt-injection / poisoned skill 文本和 tamper-evident audit。它强调“同一个 tool call → 同一个 verdict”，因此核心判断路径不依赖 LLM；可选 LLM judge 只能提高风险，不能降低 block。

一阶原理是：越靠近副作用边界，越需要确定性。LLM 适合解释灰区、总结风险，但不适合作为最终授权者；因为攻击者可以诱导模型改变判断，而且概率式判断很难审计。确定性 firewall 的价值在于 reproducibility、policy-as-code、可回放和审计链。

对 Hermes / llm-wiki 的启发

Hermes 的工具调用和 cron 自动化也应按 effect tier 管理：只读搜索/读取属于 green；写 wiki、改配置、发布文章属于 yellow/red；凭证、网络外传、删除、部署、跨 profile 修改属于更高风险。当前每日雷达在无人场景下应默认只做低风险 wiki 写入，并对安装外部技能、执行未知脚本、触碰凭证类操作保持 HOLD。

对外部 skill 生态，redstamp 提醒“README 看起来有用”不等于可安装。llm-wiki 可以学习其设计模式，但安装执行包前需要 dependency manifest、脚本审查、网络/文件/环境变量权限和最小 sandbox detonation。

失败模式与边界

redstamp 自称 deterministic recall/precision 来自其 labeled corpus，但这类指标仍需独立复现；README 也承认 regex 不能安全处理某些 evasion bucket，而是路由给可选 LLM judge。因此它适合成为 policy/control plane 的样本，而不应被当成已验证万能防线。若 policy 配置过宽、write roots 过大或 audit 不被实际检查，firewall 仍可能变成摆设。

相关页面

• Harness-Engineering
• anthropic-agent-containment
• portcullis-claude-code-security-hooks
• cyvisguard-mcp-security-control-plane

写入记录

• 2026-07-31 09:01 CST：新增对 redstamp 确定性 tool-call firewall、risk tier、secret/prompt-injection blocking 和 Hermes effect-tier 安全启发的分析。