“提交前必须跑完整测试”这种规则看起来很简单，直到 AI 编程 agent 在上次测试后又改了源码。接下来继续执行 git commit。不过，内核只看见普通进程在写提交对象，harness 也只看见又一次工具调用。但真正决定这次提交能不能放行的，是哪次测试结果仍然有效、哪次编辑让它失效，还有规则在当前任务里该如何实例化。

ActPlane 论文量化了开发者写下的行为规则与程序实际能够检查的规则之间有多大落差。论文逐条分析了数千条指令语句后发现，开发者并不缺少规则。困难在于把自然语言要求转成程序可以持续观察和判断的状态。许多规则虽然涉及文件、进程或网络行为，却还要结合仓库结构、任务进度或先前事件才能判断当前操作是否合规。所以单次 OS hook 只能覆盖其中一部分。

者已经写下了这些策略

讨论 AI agent 安全时大多数人从威胁模型或攻击面入手。ActPlane 换了一个出发点：开发者已经告诉 agent 该做什么、不该做什么了那把这些指令变成可执行的规则需要什么？

论文调研了 50 个含 CLAUDE.md 和 AGENTS.md 的热门仓库，覆盖 120 份指令文件和 4 300 条独立语句。与此前只在文件或章节标题粒度做分析的研究不同，ActPlane 对每一条语句独立分类。提出三个问题：

• 指令文件主要是行为策略还是描述性上下文？
• 哪些策略需要 OS 级强制执行，需要什么类型的检查？
• 将这些策略实例化为具体可执行规则又需要什么上下文？怎么说呢，

语句的提取脚本确认了完整的源覆盖和逐字 span 匹配。并由独立的 Claude 和 Codex agent 交叉检查。最终1 200 条分层抽样语句经人工标注者独立审核，确认标签正确。

在这 4 300 条语句中。约 70% 是策略，它们要求、禁止或约束某个具体 agent 行为；其余约 30% 是描述性上下文，例如架构说明或项目背景。各仓库的策略密度从 20% 到 80% 不等，策略数量多于描述性内容。文件或章节标题粒度的研究不会报告这种语句级分布，这正是细粒度分类的价值。

为了解策略在各关注领域的分布。论文将每条语句分配到改编自先前指令文件研究的 8 个主题类别中，应用于语句粒度而非文件粒度。流程和实现细节两类的策略占比最高，分别达到 35% 和 28%。架构以描述性内容为主，策略仅占 12%。因为目录布局和设计摘要构成了这些章节的主体。

强制执行缺口 来自上下文

每条策略按强制执行瀑布的第一个匹配层级退出。纯语义涵盖推理、沟通或输出风格；内容检测涵盖文件内容上的谓词；单事件涵盖单个命令、文件访问或网络连接；跨事件涵盖依赖跨操作的时间顺序或数据来源的策略。内容检测、单事件和跨事件的并集叫做程序可观测。

🔥User Pain Point： 开发者常抱怨“程序只能看到表面的程序调用。却无法理解业务意义”，导致大量合法操作被误拦截或者违规操作逃过检测。

{0} 条策略中只有约 15% 是纯语义，其余约85% 是程序可观测。其中约40% 需要内容检测，约30% 匹配单个 OS 事件，约15% 需要跨事件状态。 只有单事件和跨事件两类能直接在 OS 挂载点上强制执行，合计约45%。跨事件策略集中在开发流程领域，占全部跨事件策略的 60%。不过，

跨事件策略反复出现为四类关系：

• 时序排序：如“提交前先跑测试”。要求先后关系，而不是仅仅在更早时间点跑过一次。
• 跨文件一致性： "行为变更时同步更新文档" 把源码编辑和文档更新联系起来。
• 多步工作流： "发布清单逐项，上一步完成后才能进入接下来”。
• 条件触发： "改了规范就必须同步 SDK"，仅在前置条件成立时生效。话说回来，

🔥User Pain Point： 很多安全团队缺乏能够追踪这些跨步骤关系的数据结构。一旦攻击者利用子进程逃逸，就会导致"看不到" 的违规行为。

{0} 条程序可观测策略中，仅约20% 是自包含的；多数需要项目上下文——比如“测试套件”或“上游源码”必须结合具体仓库解析才能变成具体规则；另有10% 要求任务上下文，如“除非使用者明确要求”。即便是看似简单的 S5 “不得修改上游源码”。也必须先确定哪些方法属于“上游源码”，才能让文件写入检查生效。

一条规则会跨越多个强制执行层级

基于 prompt 的指令依赖模型自身遵从能力。但容易受 prompt 注入攻击，而且在长中与使用者任务 prompt 抢占注意力。独立的 agent 或 LLM 守卫可以在运行时检查 prompt、响应或行为轨迹，但这些检查本质上是概率性的。

工具调用层面的守卫和应用级信息流控制程序在 harness 边界确定性地拦截。但它们只能观察经过 harness 中介的请求，看不到工具开始执行之后产生的程序级效果。说到例如，

subprocess.run
# 脚本通过 python 执行
python script.py
# 工具调用层只看到 “运行 python script.py”
# 看不见脚本里的 git push

seccomp、AppArmor、Landlock、Tetragon 等 OS机制控制的是资源访问而非开发者所描述的行为。它们要求静态预写策略，只返回一句不透明 E​P​E​R​M​ ,无法解释是哪条规则被触发，也不给出恢复建议。

🔥User Pain Point： 运维人员常因缺少明确错误信息而陷入“到底是哪条安全政策导致阻断？” 的调试死循环，

The gap lies in **context vs observability**. 项目与任务上下文掌握在 agent 一侧，需要 agent 把自然语言策略转成具体规则。但很多策略限制的是**事件顺序**或**数据流**——工具调用守卫根本看不见这些程序效果。ActPlane 必须同时满足两项要求：

1. 让 developer‑written 策略能够被 **OS 层** 确定性强制执行；
2. 提供 **结构化反馈** 给 agent。以便其快速恢复合规状态，而不是盲目重试。说起来，

把意图编译成可强制执行状态

A ActPlane rule consists of five components:

1. ID 声明：The source of governance object .
2. TARGET 操作：The system call or resource type .
3. EFFECT：.
4. TEMPORAL GATE ： A “after …since ，” clause that encodes ordering.
5. Causal REASON string：A human‑readable message returned when rule fires.

kill exec "git" "commit" unless after exec "go" "test" exits since write "**/*.go"
# 意思：除非最近一次 .go 文件编辑后成功运行 go test，否则阻止 git commit。# 当触发时会返回类似 “请先运行 go test 并确保通过”。

The three possible effects map to two usage categories:

• Denying actions : 用于C​O​N​S​T​R​A​I​​NＴ S​T​​R​​A​​T​​E​​GIES​​.\*Guidance : 用于提示性的指令，让 agent 知道接下来应该做什么而不直接阻断操作。\]