Promtact — inline policy enforcement point for agent tool calls
Promtact — inline policy enforcement point for agent tool calls
深度判断
结论：晋升为正式 source page。 Promtact 只有 0 stars，但 README 的方法论密度高：它把 agent tool-call 安全从“事后观测”推进到 inline policy enforcement point（PEP），在调用发生前按 policy、identity、provenance 决定 allow / gate / deny，并把审计轨迹做成 hash-linked、off-host witnessed evidence。这对 Hermes 的无人 cron、MCP/tool 使用和高风险副作用边界有直接启发。
机制 / 一阶原理
Promtact 的一阶原理是：检测到 agent 已经删文件、外传数据或花钱，最多只能补救；真正的控制必须位于 effect boundary 之前。它把 agent/MCP client 和 upstream tool/server 之间插入一个决策点：验证工具允许做什么、调用者身份是否可信、工具 provenance 是否匹配；高风险动作进入 human approval queue，拒绝和允许都进入 telemetry/audit。
README 特别强调四个设计选择：预调用决策不是事后 log；数据库故障时 denial 仍应生效并写本地 journal；tool content 永远是 data 不是 instruction；删除、外传、花钱等 consequential actions 需要人类 gate。
与已有 wiki 概念的关系
| Promtact 与 Harness-Engineering 的 deterministic gates、GDM AI Control Roadmap 的 AI control、agentlock-provenance-action-gate、prismor-runtime-control-plane 和 [[nemo-relay-agent-runtime-control | NeMo Relay]] 构成同一控制层谱系。不同点是 Promtact 更强调 inline PEP + witnessed audit，而不是单纯 observability 或产品控制台。 |
相关页面：Harness-Engineering · Agent-Benchmarks · agentlock-provenance-action-gate · prismor-runtime-control-plane
对 Hermes / llm-wiki 的启发
- 无人 cron 中无法澄清的高风险动作应默认 HOLD 或降级只读；不能因为 prompt 要求“自主完成”就扩大副作用。
- llm-wiki radar 的 web/GitHub/arXiv 搜索是只读，低风险；但安装外部 skill、执行 repo 脚本、发布/删除/迁移等应需要 PEP 式 gate。
- Hermes 最终报告可以借鉴 witnessed receipt：关键 claim 不只写“已做”，还要绑定文件路径、命令输出或审计条目。
失败模式、边界条件与未解问题
Promtact 成熟度仍需验证：0 stars、AGPL/commercial license、需要部署/运维，且 policy 设计本身可能误报或阻塞正常工作。它适合先作为 agent tool-call control pattern 入库，不应在无人任务中直接安装或接入生产工具链。
来源与证据
- GitHub: https://github.com/hunterinvariants/Promtact
- Stars at ingest: 0
- Last pushed at ingest: 2026-08-14T23:39:24Z
- Raw archive: promtact-inline-policy-enforcement-point-2026-08-15
写入记录
- 2026-08-15 09:01 CST：从 GitHub README 深度入库，新增 inline PEP/source page，并关联 Harness Engineering、runtime control 与 provenance gate。