工具结果发给模型之前，OpenPI 该不该做 fail-closed 的 secret egress filter？

[tt-a1i]

一句话问题：工具结果进入模型上下文之前，OpenPI 该不该做 fail-closed 的 secret egress filter？ 这和「拦不让跑」（#497）以及「装不装包」（#475）不是同一条轴。

这不是 commit 计划，也不是 Adopt。倾向 Discuss。本轮未安装、未运行下列包。不提议新安装器。Pi 继续拥有 install / update / uninstall。不新增第二条 /openpi-setup。若以后做成 hook 而不是模型工具，就不需要 child-tool 分类；若做成模型可见工具，必须写入 CHILD_EXCLUDED_TOOL_NAMES 或 CHILD_SAFE_PACKAGE_TOOL_NAMES，未分类 = fail-closed。

为什么目录里这个机制看起来有趣

冻结身份（last-seen 2026-09-08）：

包 / 源	版本 / 日期	来源
michalvavra/agents filter-output.ts	git-only（仓库 last-push 2026-07-01）	https://github.com/michalvavra/agents/blob/main/agents/pi/extensions/filter-output.ts
cc-safety-net	npm 2.3.4（2026-09-08）	https://www.npmjs.com/package/cc-safety-net · 偏「拦 secret 文件访问」，更靠近 #497
pi-hermes-memory	npm 0.9.8（2026-09-05）	把 secret scanning 绑进 Memory 产品；不作为 #167 候选

公开 README / 路径声明的机制（未在本轮执行验证）：

• filter-output：在发给模型前捕获并改写敏感值；
• cc-safety-net：hook 拦破坏性命令和 secret 文件访问（执行门，不是出站脱敏）；
• OpenPI 现有 extensions/suggestions/src/transcript.ts 的 redactSecrets 只服务 suggestions 投影，不是全局 tool_result 门。

事实

• runtime: 试点全局 allow/ask/deny，不引入社区权限包依赖 #497 试点的是 allow/ask/deny 执行门。社区包风险收据：只读评估应由独立插件、Skill 还是 OpenPI 承担？ #475 问的是安装前风险收据。两者都不覆盖「已经执行成功的工具输出里带着 key，下一轮 prompt 把它送给模型」。
• AGENTS.md：运行时拥有权限 / fail-closed；不要靠 prompt 守不变量。
• 对照修订：OpenPI a9b40f0。本轮未安装、未运行。

推断

全局出站脱敏可能值得做成正交 hook：不引入社区包、不把 Memory 产品当载体、不让模型当分类器。风险是假阳性（模型需要用刚读到的 token 调 API）、以及和 Pi 原生工具结果生命周期抢权。

建议

先回答所有权：Pi 核心、OpenPI hook、还是继续停在 suggestions 投影。不要 merge filter-output，不要把 secret scan 绑进 #167。配置若有，只走 /openpi-setup。

未知

• 假阳性率、对 child / Workflow 工具结果的覆盖、以及 Pi 是否已有或即将有同类 hook（本轮未跑、未读 Discord）。

关联

• runtime: 试点全局 allow/ask/deny，不引入社区权限包依赖 #497 执行门 · 社区包风险收据：只读评估应由独立插件、Skill 还是 OpenPI 承担？ #475 安装收据 · memory: 研究 Project-scoped Durable Learning，并严格区分事实、经验与 Skill #167 Memory（跳过）
• 研究记录：docs/research/PI_COMMUNITY_PLUGIN_SURVEY_2026-09-08.md

[redbotster]

the concrete gap you've identified is real: redactSecrets in transcript.ts is scoped to the suggestions projection, so a tool result carrying a raw api key still lands in the next model context turn unfiltered. before picking an owner (pi core vs openpi hook), worth confirming whether pi's tool result lifecycle exposes a stable intercept point at all, because hooking after the fact means racing the context append.

on the false positive risk you flagged: if the model needs the token it just read to make an immediate api call, a fail-closed filter breaks that flow with no good recovery path, so the ownership question and the false positive question are actually the same question.

(i work on 1claw, which takes a different approach by keeping the raw secret out of model context entirely via path references to an hsm-backed vault. relevant if the conclusion here is that post-execution filtering is too fragile, but not a substitute for the hook architecture you're discussing.)