pii-gate这类“fail-closed个人数据门”可以插在Codex CLI执行shell命令、写文件、调网络之前拦截敏感泄露，但Codex不向hooks暴露hosted web工具——科研数据安全到底该靠外部hook兜底，还是从一开始就不该把敏感数据交给云端Agent？

摘要

围绕 Codex CLI 的 hook 机制与 hosted web 工具之间的可见性断层，本文提出一条贯穿全文的分析主线：“拦截面 = 数据流经的可观测边界”。凡是数据流经本地进程、文件系统、出站 socket 的环节，fail-closed 的 pii-gate 都能构成有效闸门；凡是数据在云端 Agent 内部完成检索、拼接、生成并直接回传的环节，本地 hook 在结构上不可见。本文据此区分“可兜底区”与“不可兜底区”，给出双层防护模型、可落地的工程步骤、量化评估方法与边界条件，并对“数据不出域”与“出口可证”两条路线的取舍做出前瞻判断。

目录

一、导语与问题定义：一个“看不见的出口”

在科研场景里引入云端编码 Agent，最先被问到的往往不是“它能不能写对代码”，而是“它会不会把不该出去的东西带出去”。Codex CLI 这类工具把模型能力下沉到本地终端：它可以执行 shell 命令、读写文件、发起网络请求，也可以在需要时调用托管在云端的 web 检索工具。前几类动作在本地进程空间里留下了可被 hook 观测的边界，后一类动作则发生在服务端，本地只能看到一次工具调用的请求与返回，看不到中间检索了什么、拼接了什么、又向模型侧回传了什么。

这正是 pii-gate 这类“fail-closed 个人数据门”的价值与困境所在。所谓 fail-closed，指判定链路一旦异常（规则缺失、解析失败、超时、模型不可用），系统默认拒绝放行，而不是默认通过；与之相对的 fail-open 则在异常时放行。所谓 个人数据门（PII gate），指在数据离开受控域之前，对载荷做实体识别与策略判定，命中敏感类别即阻断或脱敏的中间件。把这样一道门插在 shell 执行、文件写入、网络调用之前，工程上是成立的；但把它当作“云端 Agent 数据安全的全部答案”，则在结构上不成立。

本文的分析主线只有一句：拦截面等于数据流经的可观测边界。边界之内，hook 可以兜底；边界之外，hook 只能看到“发生过一次调用”，看不到“带走了什么”。这条主线将贯穿后文的机制拆解、覆盖率量化、工程部署与路线取舍。笔者认为，把“该不该用云端 Agent”与“hook 能不能兜底”混为一谈，是当前讨论中最常见的范畴错误：前者是数据治理的准入问题，后者是运行时防护的工程问题，二者不能互相替代。

二、背景：Codex CLI 的执行模型与 hook 的可观测边界

2.1 本地执行面：命令、文件、网络三类可拦截动作

Codex CLI 的本地执行面可以抽象为三类系统调用族：进程创建（执行 shell 命令）、文件系统写入（创建、修改、删除文件）、出站网络连接（HTTP/HTTPS、DNS 解析）。这三类动作在操作系统层面都有明确的拦截点：进程创建可挂 execve 钩子或使用 seccomp 过滤，文件写入可挂 inotify/fanotify 或文件系统层过滤，出站连接可经本地代理或 eBPF 观测。Codex 的 hook 机制本质上是在 Agent 的“工具调用”抽象层再包一层：在工具真正落地为系统调用之前，把结构化参数交给外部程序判定。

这种设计的工程优势在于结构化。hook 拿到的不是一段难以解析的 shell 字符串，而是“工具名 + 参数对象”，例如 {"tool":"shell","cmd":"grep -r ..."} 或 {"tool":"write_file","path":"...","content":"..."}。结构化参数让策略判定可以做得很细：按路径前缀放行、按命令白名单放行、按内容正则阻断。本文评述：结构化 hook 的判定精度上限，取决于工具抽象层是否把“数据载荷”完整暴露给 hook；一旦某个工具在抽象层就把载荷藏进服务端，hook 的精度再高也无的放矢。

2.2 云端执行面：hosted web 工具为何不在 hook 视野内

hosted web 工具（托管检索、托管浏览、托管代码执行沙箱）的运行位置在服务端。本地 Agent 只发起一次“工具调用请求”，服务端完成检索、抓取、摘要、拼接，再把结果作为工具返回值交回本地。整个过程对本地 hook 暴露的只有请求参数与返回文本，中间的检索查询、抓取页面、上下文拼接全部不可见。更关键的是，某些实现会把“检索到的内容”直接注入模型上下文，而不经过本地进程，这意味着数据在“本地 → 服务端”这一跳就已经完成了跨域。

从可观测性角度，这构成了一个结构性盲区：hook 能看到“调用了一次 hosted web”，却无法在调用前判断这次调用会携带哪些隐含上下文（例如模型上下文中已存在的本地文件片段），也无法在调用后判断返回内容是否已被污染或是否包含不应回流的第三方数据。本文评述：这不是 hook 实现得不够好，而是信任边界与观测边界不重合导致的必然结果。把观测点放在本地，却期望覆盖服务端的内部行为，在信息论上就不成立。

2.3 一条被忽视的链路：模型上下文本身就是数据载体

多数讨论聚焦于“工具调用带走了什么”，却忽略了“模型上下文里已经有什么”。当 Agent 读取了一个本地 CSV、解析了一段日志、总结了实验记录，这些内容就进入了模型上下文。此后任何一次 hosted 工具调用，哪怕请求参数看起来人畜无害，服务端也可能基于完整上下文做检索增强或查询改写，从而把上下文中的敏感片段间接带出。这条链路的隐蔽性在于：敏感数据的“出口”不是某一次显式的文件上传，而是上下文的持续累积与任意一次后续调用的隐式携带。

笔者认为，这条链路是判断“hook 能否兜底”的关键。若 hook 只检查单次工具调用的显式参数，它对上下文累积型泄露几乎无能为力；若 hook 要检查完整上下文，则需要 Agent 在每次调用前把上下文完整交给 hook，这在工程上可行但代价高昂，且上下文本身可能包含大量与本次调用无关的敏感信息，导致误报率上升。这个张力在后文的覆盖率分析中会量化呈现。

三、原理：fail-closed 数据门的判定逻辑与失效模式

3.1 判定流水线：识别、分类、策略、执行

一个可用的 PII gate 通常包含四级流水线：实体识别（NER + 正则 + 校验位）、敏感分类（按法规与机构策略映射到类别）、策略判定（放行、脱敏、阻断、转人工）、执行（改写载荷或终止调用）。fail-closed 的语义落在第三、四级：当识别器置信度低于阈值、当策略表缺失该类别、当判定服务超时，一律按“阻断”处理。

def pii_gate(payload, policy, timeout_ms=120):
    try:
        ents = detect(payload)              # NER + 正则 + 校验位
        cats = classify(ents, policy)       # 映射到敏感类别
        decision = decide(cats, policy)     # allow / mask / block / review
        if decision.confidence < policy.min_conf:
            return BLOCK                    # fail-closed
        return decision
    except (TimeoutError, ParseError, PolicyMissing):
        return BLOCK                        # fail-closed

这段伪代码的关键不在识别算法，而在异常分支的处理。fail-closed 的工程代价是可用性：任何一次识别服务抖动都会导致合法调用被拒。因此生产部署通常需要“分级 fail-closed”——高敏感类别严格阻断，低敏感类别降级为脱敏放行，并对降级行为做审计留痕。本文评述：fail-closed 不是“一律拒绝”的口号，而是一套按敏感度分层的降级策略，其设计目标是在可接受的误拒率下把漏放率压到接近零。

3.2 失效模式一：载荷不可见导致的“空判定”

当 hook 拿到的参数不包含真实载荷时，识别器会对一个空壳做判定，结果自然是“未命中敏感实体”，于是放行。这不是识别器的错，而是输入不完整。hosted web 工具的典型形态正是如此：hook 看到的是查询字符串，真实的数据携带发生在服务端基于上下文的检索增强。此时 gate 的判定结果在形式上合法，在实质上无效。

这类失效最难被发现，因为它不报错、不告警，审计日志里显示“已检查、已放行”。笔者认为，评估任何 PII gate 时，第一个要问的问题不是“识别率多高”，而是“它到底看到了多少字节的载荷”。看不到载荷的 gate，识别率再高也只是装饰。

3.3 失效模式二：上下文累积与跨调用拼接

即便单次调用的载荷完全干净，多次调用的组合仍可能泄露。例如第一次调用读取了受试者编号表，第二次调用发起一个看似无关的统计查询，服务端在完整上下文下可能把两者关联。这类风险的判定需要跨调用状态，而多数 hook 是无状态的单次判定。要支持跨调用判定，gate 需要维护一个会话级的敏感实体登记簿，并在每次调用前做“上下文—载荷”联合检查。

本文评述：跨调用判定在工程上可行，但会显著增加延迟与实现复杂度，且登记簿本身成为新的敏感数据存储点，需要同等强度的保护。这形成一个递归：为了保护数据不泄露，gate 自己必须先安全地持有数据。这个递归没有免费的解法，只能靠最小化持有与加密存储来缓解。

3.4 失效模式三：编码、分片与语义等价绕过

识别器基于模式匹配时，base64、URL 编码、字符插入、同形字替换、分片跨多次调用都能绕过。语义层面的绕过更难防：把身份证号改写成“出生日期 + 地区码 + 校验位”的分段描述，模式匹配失效，但语义等价。对抗这类绕过需要语义级判定，而语义判定又依赖模型，模型本身引入新的不确定性与成本。

笔者认为，对编码绕过可以用“先规范化再识别”的预处理缓解，对语义绕过则必须承认不存在完备解，只能通过多层防御（规范化、语义判定、出口流量审计、事后抽检）把残余风险压到可接受水平。任何声称“百分百拦截”的方案，要么定义了一个极窄的威胁模型，要么在误报率上做了不可告人的妥协。

四、关键数据与案例：拦截面覆盖率的量化分析

4.1 覆盖率的形式化定义

为把“hook 能不能兜底”从争论变成可计算的问题，本文定义一个简单指标：拦截面覆盖率 = 被 gate 观测到完整载荷的敏感数据流出次数 / 敏感数据流出总次数。分母需要先定义“流出”：数据离开受控域（本地进程 + 受控内网）即计为一次流出。分子取决于 gate 的观测点位置与载荷可见性。

上表为本文基于执行模型的结构化推演，非实测数据。可以看出，覆盖率的分水岭不在识别算法，而在载荷是否可见。前三类通道的覆盖率可以做到接近 1，后三类则受限于架构，无法仅靠本地 hook 补齐。

4.2 一个可复现的评估方法

要得到可比较的数字，建议用“注入—观测—核对”三步法：第一步，构造一组带标记的合成敏感数据（如带校验位的虚构证件号、带固定前缀的虚构样本编号），注入到 Agent 可读的工作目录；第二步，让 Agent 完成一组典型科研任务（数据清洗、统计脚本生成、文献检索、结果汇总）；第三步，在受控出口（本地代理、DNS 日志、服务端回传记录）核对标记是否出现。标记出现即计为一次流出，被 gate 阻断则计为一次拦截。

这个方法的优点是可复现、可比较，缺点是合成数据与真实数据的分布差异会影响识别率。建议同时报告两组数字：合成标记的拦截率（衡量通道覆盖）与真实脱敏样本的识别率（衡量识别质量），二者不可互相替代。本文评述：当前公开讨论中大量“拦截率 99%”的说法，往往只报告了识别质量，回避了通道覆盖，读者需要主动追问分母是什么。

4.3 案例观察：科研数据的三类典型流出

第一类是显式上传：把整份实验记录贴进对话，请求模型总结。这类流出最容易被 hook 捕获，因为载荷完整出现在工具参数或对话内容中。第二类是脚本外联：Agent 生成的脚本把数据 POST 到外部统计服务。这类流出可经本地代理拦截，前提是强制所有出站流量走代理。第三类是检索增强的隐式携带：Agent 在已读取敏感表格的上下文中发起文献检索，服务端基于上下文改写查询。这类流出在本地几乎不可见，是覆盖率的主要缺口。

笔者认为，第三类流出的治理不能靠“更聪明的 hook”，而要靠“更早的准入”：在数据进入 Agent 上下文之前就做分级，敏感级别高的数据根本不进入可被云端工具触达的上下文。这把问题从运行时拦截前移到了数据治理，是本文在结论部分要展开的核心主张。

五、工程实践：pii-gate 的可操作部署路径

5.1 第一步：把出口收敛到可观测点

在写任何识别规则之前，先把所有出站流量收敛到本地代理，并禁止 Agent 绕过代理直连。工程上可用容器网络策略 + 环境变量注入 + DNS 指向本地解析器三件套。这一步的收益是把“网络调用”从不可观测变成可观测，是覆盖率提升最大的一步，成本却最低。很多团队跳过这一步直接调识别模型，结果是在一个漏水的桶里做水质检测。

具体步骤：其一，为 Agent 运行环境配置独立网络命名空间，默认路由指向本地代理；其二，用 eBPF 或 iptables 记录所有非代理出站尝试并告警；其三，对 hosted 工具的域名做单独标记，便于区分“本地可控出口”与“云端不可控出口”。可参考 Cloudflare One 的零信任出口文档 与 Linux eBPF 官方文档 了解实现细节。

5.2 第二步：在 hook 里做结构化判定

hook 的判定逻辑应尽量无状态、可缓存、可审计。无状态指单次判定不依赖外部可变状态，降低延迟与故障面；可缓存指对相同载荷哈希的判定结果可复用，避免重复调用识别模型；可审计指每次判定都记录“输入哈希、命中类别、决策、耗时”，便于事后复盘。对 shell 命令，重点检查重定向与管道后的真实载荷；对文件写入，重点检查目标路径是否在受控目录之外；对网络调用，重点检查请求体与 URL 查询参数。

# 伪配置：按工具类型分派判定策略
hooks:
  pre_shell:
    checks: [cmd_whitelist, redirect_payload, env_dump]
    on_fail: block
  pre_write:
    checks: [path_prefix, content_pii, file_size]
    on_fail: block
  pre_network:
    checks: [proxy_required, body_pii, domain_allowlist]
    on_fail: block
  pre_hosted_tool:
    checks: [query_pii, context_manifest]
    on_fail: review   # 载荷不完整，降级为人工复核

注意最后一项：对 hosted 工具，由于载荷不完整，判定结果不应被当作“已放行”的充分证据，而应降级为“需人工复核”或“需上下文清单核对”。本文评述：把不完整观测下的放行标记为“已检查”，是审计中最危险的假阴性来源，工程上应显式区分“检查通过”与“无法检查”。

5.3 第三步：建立会话级敏感实体登记簿

为应对上下文累积型泄露，可在会话开始时为每个敏感实体生成不可逆指纹（如加盐哈希），登记簿只存指纹与类别，不存原文。每次工具调用前，把当前上下文做同样的指纹化，与登记簿求交，交集非空即触发复核。这样既避免了登记簿自身成为敏感数据仓库，又能在不暴露原文的前提下做跨调用关联。

局限也要说清楚：指纹化只能发现“同一实体再次出现”，无法发现“语义等价改写”。对后者需要语义相似度判定，成本更高。笔者认为，登记簿方案的价值在于把不可见的上下文携带变成可告警的信号，哪怕有漏报，也比完全无感要好。实现上可参考 NIST 隐私框架 中的“数据最小化”与“可追溯”控制项。

5.4 第四步：分级准入与数据分区

最有效的一步往往最不“技术”：把数据按敏感级别分区，高敏感数据放在 Agent 根本无权读取的目录，中敏感数据放在可读但禁止外联的沙箱，低敏感数据才允许进入可调用云端工具的会话。这样做的效果是把“运行时拦截”转化为“准入控制”，从源头减少需要拦截的流量。工程上可用文件系统权限、容器挂载策略、会话初始化脚本三者配合实现。

具体操作：其一，为每个敏感级别定义目录与标签，写入时自动打标；其二，Agent 会话启动时按任务需要挂载对应分区，任务结束即卸载；其三，对 hosted 工具调用做会话级开关，默认关闭，需显式申请并记录理由。可参考 NIST SP 800-207 零信任架构 中“按需授权、最小权限”的原则。

5.5 第五步：审计、抽检与红队

任何拦截方案都需要独立的验证闭环。建议每月做一次红队演练：由不参与开发的成员构造绕过用例（编码、分片、语义改写、上下文携带），检验 gate 的实际拦截率；同时对审计日志做抽样人工复核，检查“已放行”记录中是否存在应拦未拦。红队结果应反馈到规则库与准入策略，形成迭代。

本文评述：安全工程里最容易被省略的就是验证环节，因为它在顺利时不产生可见收益。但没有红队的 gate，本质上是一个“我们相信它能拦”的信仰系统。把红队纳入常规流程，是把信仰换成证据的最低成本方式。

六、对比与局限：外部 hook 兜底 vs 数据不出域

6.1 两条路线的能力边界

两条路线不是互斥的，而是纵深防御的两层。数据不出域解决“不该出去的出不去”，外部 hook 解决“万一要出去，能不能被看见、被拦住、被追溯”。笔者认为，把二者对立起来的讨论，往往隐含了一个错误前提：以为存在一种单一手段能同时满足安全与能力。现实是，安全强度与能力开放度之间存在结构性权衡，工程决策要做的是显式地选择权衡点并留下证据，而不是假装权衡不存在。

6.2 局限：hook 方案的三个硬约束

第一，观测边界约束：hook 只能看到 Agent 愿意暴露的参数，服务端内部行为不可见。第二，语义完备性约束：不存在能识别所有语义等价改写的识别器，残余风险恒大于零。第三，性能与可用性约束：fail-closed 的严格程度与误拒率正相关，过度收紧会让 Agent 不可用，进而诱发用户绕过 gate 的动机。

这三个约束都不是靠工程优化能消除的，只能靠架构设计来规避。本文评述：承认约束的存在，是做出正确路线选择的前提。把 hook 当作万能兜底，会在 hosted 盲区上产生虚假的安全感；把“数据不出域”当作唯一答案，则可能因能力受限而催生影子 IT，反而扩大风险面。

6.3 一个折中的架构判断

基于上述分析，笔者倾向于一个分层判断：对高敏感数据（可识别个人身份、受试者信息、未公开临床数据），坚持不出域，Agent 只在其上做本地处理，禁用一切 hosted 工具；对中敏感数据（已脱敏的聚合统计、内部方法学笔记），允许经 hook 管控的云端调用，但要求会话级登记簿与出口审计；对低敏感数据（公开文献、通用代码），放开云端工具以换取能力。这个分层不是拍脑袋，而是把“数据敏感度”与“通道可观测性”两个维度做笛卡尔积后得到的策略矩阵。

这个判断的可验证性在于：每一层都可以用 4.2 节的注入—观测—核对法独立评估，得到各自的覆盖率与残余风险数字。策略是否合理，不看口号，看数字是否落在机构的风险容忍度之内。可参考 ISO/IEC 27701 隐私信息管理 与 OWASP LLM 应用十大风险 中的相关控制项做映射。

七、结论与展望：把“信任边界”画在数据流上

回到标题的问题：科研数据安全到底该靠外部 hook 兜底，还是从一开始就不该把敏感数据交给云端 Agent？本文的答案是：二者都要，但顺序不能颠倒。先做准入分级，决定哪些数据根本不该进入可触达云端的上下文；再用 hook 在可观测边界上做运行时兜底，覆盖准入判断的疏漏与运行期的意外。顺序颠倒——先上 hook 再谈准入——会把大量本可在源头避免的风险拖到运行时，既增加误拒，又制造虚假安全感。

贯穿全文的主线“拦截面等于数据流经的可观测边界”，其工程含义是：先画数据流，再画信任边界，最后才选拦截点。hosted web 工具的盲区不是某个产品的缺陷，而是“观测点与信任边界不重合”的普遍现象。任何未来的 Agent 工具链，只要把执行放到服务端，就会重现这个盲区。因此，评估新工具时，第一个问题应当是“它的数据流经哪些边界、哪些边界对本地可见”，而不是“它支持哪些 hook”。

展望未来，笔者认为有三个方向值得投入：其一，可验证的出口清单，让 Agent 在每次云端调用前生成并签署“本次携带的数据清单”，把不可见变为可审计；其二，上下文最小化的工程化，在 Agent 内部实现按任务裁剪上下文，减少隐式携带；其三，分层 fail-closed 的标准化，把“检查通过”与“无法检查”在协议层区分开，避免审计中的假阴性。这三项都不依赖某个具体产品，而是可迁移到整个 Agent 工具生态的基础设施。

最后需要强调边界条件：本文的覆盖率分析基于执行模型的结构化推演，非实测数据；分层策略的具体阈值需各机构按自身风险容忍度标定；红队与抽检的有效性依赖于用例设计的独立性。任何把这些结论直接当作合规依据的做法，都超出了本文的论证范围。技术方案能降低风险，但不能替代治理决策。

主要参考文献